Zagadka: unchecked assignment

[Jacek Kunicki]

Mamy:

abstract class A {

    List<A> getChildren();

}

class B extends A {}

i gdzieś indziej:

void foo(A a, B b) {

    List<A> listA = a.getChildren(); //1

    List<A> listB = b.getChildren(); //2

}

Kompilator pokazuje warning w linii //1: unchecked assignment from 'java.util.List' to 'java.util.List<A>'. Linii //2 się nie czepia. Pytanie jest proste i brzmi: skąd warning w linii //1? Co tu jest "unchecked"?

Jacek

[Krzysztof Grajek]

Mysle ze odpowiedz znajdziesz na tej stronie: http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html

w sekcji

" Can I cast to a parameterized type?  "


Pozdrawiam
Krzysztof Grajek

2011/6/22 Jacek Kunicki <jacek....@gmail.com>

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „Warszawa Java User Group (Warszawa JUG)”.
Aby zamieszczać posty w tej grupie, wyślij e-mail na adres warsza...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres warszawa-jug...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/warszawa-jug?hl=pl.

[Krzysiek]

a gdzie body metody w klasie abstrakcyjnej?

>abstract class A {

>    List<A> getChildren();

>}

albo zrób ja tez abstrakcyjna...
Nie wiem jak do tych warningow doszło, bo wogole nei powinno sie skompilowac
w takiej konstrukcji.

--
Pzdr
Krzysiek
on JavaBlackBelt

[Maciej Biłas]

Hm… pozwoliłem sobie zrobić z tego kompilujący się kod Javy:

abstract class A {

    abstract List<A> getChildren();

}

class B extends A {

    @Override

    List<A> getChildren() {

        return Arrays.<A>asList(new B(), new B());

    }

}

public class ListGetter {

    public static void main(String[] args) {

        new ListGetter().foo(new B(), new B());

    }

    void foo(A a, B b) {

        List<A> listA = a.getChildren(); //1

        List<A> listB = b.getChildren(); //2

    }

}

I javac nie wypisuje żadnych warningów.

-- m.

2011/6/22 Krzysiek <kko...@gmail.com>

--
Maciej Biłas
maciej at inszy dot org

[Michal Margiel]

Szczerze mówiac, to mi to wygląda na jakiś błąd IDE, i bym przekompilował projekt/zresetował IDE.

Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Jacek Kunicki]

Wygląda na to, że faktycznie problem jest lokalny w IDE(A) - przy kompilacji Mavenem żadnego warninga nie ma.

Rzeczywiście kod, który wysłałem, się nie kompilował, w rzeczywistości metoda getChildren nie jest abstrakcyjna, ale zwraca jakąś listę. Na sam eksperyment nie ma to jednak wpływu.

Dziękuję za dyskusję :)

Jacek

2011/6/22 Michal Margiel <michal....@gmail.com>

[Jacek Laskowski]

2011/6/22 Jacek Kunicki <jacek....@gmail.com>:

> abstract class A {
>     List<A> getChildren();
> }

Sądzę, że tutaj należy szukać rozwiązania. Pytanie pomocnicze: czy
można mieć metodę bez ciała niebędącą jednocześnie abstract? Sądzę, że
odpowiedź brzmi: zdecydowanie nie. Przy kompilacji powinieneś otrzymać
błąd kompilacji: "missing method body, or declare abstract".

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl

[Jacek Laskowski]

>         return Arrays.<A>asList(new B(), new B());

Zawsze podziwiałem osoby, które potrafią zrozumieć tajniki
posługiwania się typami generycznymi. Ten zapis Arrays.<A>asList() nie
pozostawia złudzeń, że nowi w nauce języka nie mają lekko, bo i
starszym (doświadczeniem) przychodzi to z pewnym wysiłkiem (zakładam,
że nie związanym w żaden sposób z wiekiem) :-)

[Michal Margiel]

W dniu 22 czerwca 2011 14:24 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2011/6/22 Jacek Kunicki <jacek....@gmail.com>:

> abstract class A {
>     List<A> getChildren();
> }

Sądzę, że tutaj należy szukać rozwiązania. Pytanie pomocnicze: czy
można mieć metodę bez ciała niebędącą jednocześnie abstract? Sądzę, że
odpowiedź brzmi: zdecydowanie nie. Przy kompilacji powinieneś otrzymać
błąd kompilacji: "missing method body, or declare abstract".

A ja sądzę , że odpowiedź brzmi "przeczytaj wątek zanim przedstawisz swoje zdanie" :)

W dniu 22 czerwca 2011 12:00 użytkownik Jacek Kunicki <jacek....@gmail.com> napisał:

Rzeczywiście kod, który wysłałem, się nie kompilował, w rzeczywistości metoda getChildren nie jest abstrakcyjna, ale zwraca jakąś listę. Na sam eksperyment nie ma to jednak wpływu.

[Tomasz Szymański]

On Jun 22, 2011, at 14:32 , Michal Margiel wrote:

W dniu 22 czerwca 2011 14:24 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2011/6/22 Jacek Kunicki <jacek....@gmail.com>:

> abstract class A {
>     List<A> getChildren();
> }

Sądzę, że tutaj należy szukać rozwiązania. Pytanie pomocnicze: czy
można mieć metodę bez ciała niebędącą jednocześnie abstract? Sądzę, że
odpowiedź brzmi: zdecydowanie nie. Przy kompilacji powinieneś otrzymać
błąd kompilacji: "missing method body, or declare abstract".

A ja sądzę , że odpowiedź brzmi "przeczytaj wątek zanim przedstawisz swoje zdanie" :)

pwned ;-)

T.

[Jacek Laskowski]

2011/6/22 Michal Margiel <michal....@gmail.com>:

> A ja sądzę , że odpowiedź brzmi "przeczytaj wątek zanim przedstawisz swoje
> zdanie" :)

Michał,

Przeczytałem wątek i odpowiedziałem, aby mniej zaawansowani mogli
skorzystać i czegoś się nauczyć. Wiadomość Jacka (przedmówcy) była
myląca i niedoświadczeni mogliby wyciągnąć z tego mylne wnioski. A po
co? Stąd moja odpowiedź (uzupełniająca).

Uważam, że niczym złym uczestniczyć w dyskusji (nawet w tej, która
kończy się niepomyślnie dla uczestników - właśnie doświadczam tego
uczucia). Nawet w dobie "Google Ci powie", gdzie odpowiedzi leżą na
"wyciągnięcie klawiatury".

[Lasu]

On 22 Cze, 14:26, Jacek Laskowski <ja...@japila.pl> wrote:
> >         return Arrays.<A>asList(new B(), new B());
>
> Zawsze podziwiałem osoby, które potrafią zrozumieć tajniki
> posługiwania się typami generycznymi. Ten zapis Arrays.<A>asList() nie
> pozostawia złudzeń, że nowi w nauce języka nie mają lekko, bo i
> starszym (doświadczeniem) przychodzi to z pewnym wysiłkiem (zakładam,
> że nie związanym w żaden sposób z wiekiem) :-)
>
> Jacek
>
> --
> Jacek Laskowski

> Java EE, functional languages and IBM WebSphere -http://blog.japila.pl

> Warszawa JUG conference = Confitura (formerly Javarsovia) ::http://confitura.pl

Ave,

Ja tam lubię generyki np taki prosty przykład (jeden z wielu które
umożliwiały mi wygodne życie bez closures):
final static public//
<InputType, MiddleType, OutputType//
, InsideFunction extends Function<? super InputType, ? extends
MiddleType>//
, OutsideFunction extends Function<? super MiddleType, ? extends
OutputType>> ComposedFunction<InputType, OutputType> newComposition(//
InsideFunction inside//
, OutsideFunction outside) {...}

--
Pozdrowionka
Marek Kozieł
http://lasu2string.blogspot.com/

[Krzysiek]

Ale dales czadu :)
Musze sobie to jakos sformatowac ... tam nie ma zadnego srednika chm :/

K

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "Warszawa Java User Group (Warszawa JUG)".

Aby zamieszczać posty w tej grupie, wyślij e-mail na adres warsza...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres warszawa-jug...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/warszawa-jug?hl=pl.

[Irek Matysiewicz]

Warto dodać, że nie musisz pisać sam takich generykowych tasiemców - istnieją gotowe biblioteczki ułatwiające programowanie funkcyjne w Javie:
- http://code.google.com/p/lambdaj/
- http://code.google.com/p/functionaljava/

W dniu 26 czerwca 2011 20:31 użytkownik Lasu <develo...@gmail.com> napisał:

[Maciej Biłas]

Wspomniana wyżej funkcja jest dostępna w Guavie (oczywiście operuje na
typach w com.google.common):
http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Functions.html#compose(com.google.common.base.Function,
com.google.common.base.Function)

-- m.

2011/6/27 Irek Matysiewicz <iir...@gmail.com>:

--
Maciej Biłas

[Irek Matysiewicz]

W dniu 27 czerwca 2011 10:44 użytkownik Maciej Biłas <maciej...@gmail.com> napisał:

Wspomniana wyżej funkcja jest dostępna w Guavie (oczywiście operuje na
typach w com.google.common):
http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Functions.html#compose(com.google.common.base.Function,
com.google.common.base.Function)

Wsparcie do FP w Guavie ogranicza się chyba tylko do dwóch prostych klas. Te dwie biblioteczki co zacytowałem wyżej trochę więcej, ale i tak nic nie może równać się z FP w Groovim czy Scali. Niedoskonałości języka nawet najlepsza biblioteka sensownie nie rozwiąże.

[Pawel Cesar Sanjuan Szklarz]

Czesc

Czekawe ze rzadko widuje sie generiki z &, a przeciez to sie przydaje. Tutaj najbardziej porombane generyk, ktory dostalem w praktyce:

AbstractEditGridPresenter<D extends WidgetDisplay & GxtStoreDisplay<B, A>, R extends Result, A extends Action<R>, B, K extends Result, L extends Action<K>>

extends WidgetPresenter<D>

Mysle, ze pojawienie sie takich konstrukcji w kodzie powinno byc uznane za podejzliwy brzydki zapach w kodzie. W moim przypadku napewno tan poprzebne jest refaktoring, ale wiadomo, zycie.

Pawel Szklarz.

2011/6/26 Lasu <develo...@gmail.com>

[Lasu]

Ave.2

"Self-bounding generics" też są ciekawe (nie licząc kwestii
dziedziczenia):
SelfBounded<T extends SelfBounded<T>>
http://www.artima.com/forums/flat.jsp?forum=106&thread=136394

--
Pozdrowionka
Marek Kozieł
http://lasu2string.blogspot.com/

On 27 Cze, 11:18, Pawel Cesar Sanjuan Szklarz <pawe...@gmail.com>
wrote:

[Jacek Laskowski]

2011/6/27 Irek Matysiewicz <iir...@gmail.com>:

> Wsparcie do FP w Guavie ogranicza się chyba tylko do dwóch prostych klas. Te
> dwie biblioteczki co zacytowałem wyżej trochę więcej, ale i tak nic nie może
> równać się z FP w Groovim czy Scali. Niedoskonałości języka nawet najlepsza
> biblioteka sensownie nie rozwiąże.

A Clojure, które jest językiem funkcyjnym i reklamowane jest m.in.
jako biblioteka do programowania współbieżnego?

A tak przy okazji, dziwi mnie, że tak łatwo stawia się znak równości
między Groovy i Scalą a FP. Mam nieodparte wrażenie, że w przypadku
Grooviego można założyć, że to chęć utrzymania znanej składni na rzecz
wprowadzenia nowego, np. FP, ale Scala to krok znacznie dalej, bo nowa
składnia, więc już niedaleko do języka typowo funkcyjnego - Clojure.
Czyżby myślenie imperatywne i obiektowe tak utkwiło w naszych
umysłach, że niewielu pokusi się o Clojure? Pytam z czystej ciekawości
niż przekonania o słuszności stosowania Clojure (który mi osobiście
przypadł do gustu).

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl

[Lasu]

Ave.3

On 27 Cze, 12:58, Jacek Laskowski <ja...@japila.pl> wrote:
> Czyżby myślenie imperatywne i obiektowe tak utkwiło w naszych
> umysłach, że niewielu pokusi się o Clojure? Pytam z czystej ciekawości
> niż przekonania o słuszności stosowania Clojure (który mi osobiście
> przypadł do gustu).
>
> Jacek

Moim zdaniem czas w którym Javie wystarczyło uszczknąć z biznesowego
tortu powoli mija, lub raczej traci na znaczeniu i tu pojawił się
pomysł pójścia w Clojures co nie było zbyt mądrym posunięciem (choć
biznesowo korzystnym) - nowo powstały kod będzie w większości jeszcze
trudniejszy w utrzymaniu, a język nie dostał za to nic czego nie można
by było wprowadzić przy użyciu istniejących już mechanizmów.

Gdy Java zaistniała przełamała parę stereotypów - teraz raczej
dryfuje. Miejmy nadzieję, że to się zmieni.

[Irek Matysiewicz]

A tak przy okazji, dziwi mnie, że tak łatwo stawia się znak równości
między Groovy i Scalą a FP. Mam nieodparte wrażenie, że w przypadku
Grooviego można założyć, że to chęć utrzymania znanej składni na rzecz
wprowadzenia nowego, np. FP, ale Scala to krok znacznie dalej, bo nowa
składnia, więc już niedaleko do języka typowo funkcyjnego - Clojure.
Czyżby myślenie imperatywne i obiektowe tak utkwiło w naszych
umysłach, że niewielu pokusi się o Clojure? Pytam z czystej ciekawości
niż przekonania o słuszności stosowania Clojure (który mi osobiście
przypadł do gustu).

Nie tylko utkwiło w głowach, powody są też chyba inne:

1) Za mało się mówi o Clojure. O Scali czy Groovim od dłuższego czasu mówi się sporo, ale zanim na naprawdę dobre trafią do biznesu też pewnie jeszcze sporo czasu upłynie.

2) Składnia (+ x y) zniechęca, bo jesteśmy przyzwyczajeni do szkolnej składni x+y czy f(x, y) - było o tym jakiś czas temu.

3) Programowanie funkcyjne silnie naciska na immutability, idealnie by było jakby kod był w 100% immutable (pure functional). No tylko tyle, że problemy w których mamy rozbudowane struktury obiektów łatwiej się opisuje w podejściu 'mutable', czyli raczej imperatywnym a nie funkcyjnym.
Np. w Swingu możesz w każdej chwili zmienić tekst przycisku wołając: przycisk.setText(nowy tekst) - załatwia to prosty seter. Przy podejściu czysto funkcyjnym by dokonać takiej zmiany musisz zacząć od samej góry w drzewie komponentów (np. of JFrame w Swingu czy <body> w HTML-u) i iść w dół aż znajdziesz ten przycisk, skopiować go, nadać mu nowy tekst, i teraz idąc z powrotem w górę aż do korzenia wykonywać kopie kolejno spotykanych obiektów-rodziców i zmieniając w nich właśnie zmienione obiekty-dzieci. To działa świetnie gdy dana klasa nie trzyma innych obiektów (String, int, boolean, ...) albo gdy mamy stosunkowo prostą strukturę obiektów (np. wszelakie przykłady akademickie, tak też SVN przechowuje wersje plików i katalogów - http://goo.gl/uOUhi ), ale np. z GUI (wiele złożonych klas z wieloma złożonymi metodami) to by chyba było trudne w utrzymaniu.
Moje podejście: gdzie warto styl funkcyjny, ale nie za wszelką cenę.

[Vitaliy Oliynyk]

W dniu 27 czerwca 2011 12:19 użytkownik Lasu <develo...@gmail.com> napisał:

Ave.2

"Self-bounding generics" też są ciekawe (nie licząc kwestii
dziedziczenia):
SelfBounded<T extends SelfBounded<T>>
http://www.artima.com/forums/flat.jsp?forum=106&thread=136394

Super, dzięki za patent,  nie wiedziałem o tym, własnie zdałem sobie sprawę że można tak zdefiniować obiekt który implementuje Comparable że dodatkowo, w czasie kompilacji zostanie sprawdzone, że typ generycznego parametru to ten sam typ co definiowana klasa. Standardowo tak nie ma i można napisać: 

class A implements Comparable<Dupa> {...} 

co mnie zawsze irytowało, dla tego, że takiego "udupionego" objektu nie można posortować (przepraszam, że znów zaczynam o sortowaniu kolekcji) standardowo  za pomocą metody

public static <T extends Comparable<? super T>> void sort(List<T> list)

 

Teraz wiem, że mogę napisać coś takiego:

public interface GTSComparator<T extends GTSComparator<T>> extends Comparable<T>{}

public class A implements GTSComparator<A> {

    public int compareTo(A obj) {

       // .....

    }

}

Kompilator sprawdzi, że podaje prawidłowy parameter generyczny dla interfejsu GTSComparator

W ten sposób możemy udekorować ( dodając bezpieczeństwo typów generycznych, tam gdzie uważamy, że jego brakuje )  inne interfejsy biblioteki standardowej Javy

     

--
 Pozdrowionka
 Marek Kozieł
http://lasu2string.blogspot.com/

On 27 Cze, 11:18, Pawel Cesar Sanjuan Szklarz <pawe...@gmail.com>
wrote:

> Czesc
>
> Czekawe ze rzadko widuje sie generiki z &, a przeciez to sie przydaje. Tutaj
> najbardziej porombane generyk, ktory dostalem w praktyce:
>
> AbstractEditGridPresenter<D extends WidgetDisplay & GxtStoreDisplay<B, A>, R
> extends Result, A extends Action<R>, B, K extends Result, L extends
> Action<K>>
> extends WidgetPresenter<D>
>
> Mysle, ze pojawienie sie takich konstrukcji w kodzie powinno byc uznane za
> podejzliwy brzydki zapach w kodzie. W moim przypadku napewno tan poprzebne
> jest refaktoring, ale wiadomo, zycie.
>
> Pawel Szklarz.
>

[Lasu]

On 28 Cze, 00:46, Vitaliy Oliynyk <xao...@gmail.com> wrote:

Ja osobiście idę w stronę java.util.Comparator który jest znacznie
bardziej elastyczny i nie rozsypuje się przy dziedziczeniu, używaniu
kilku rodzajów sortowań itp...

//TODO Secure for NPE
class Person{

private final String name;
private final String surname;

public enum Comparators4Person implements Comparator<Person>{
byName{
@Override
public int compare(Person base, Person with) {
return base.name.compareTo(with.name);
}
},//
bySurname{
@Override
public int compare(Person base, Person with) {
return base.surname.compareTo(with.surname);
}
},//
...
;

[Jacek Laskowski]

2011/6/28 Lasu <develo...@gmail.com>:

>   //TODO Secure for NPE
>  class Person{
>
>        private final String name;
>        private final String surname;
>
>        public enum Comparators4Person implements Comparator<Person>{
>            byName{
>                @Override
>                public int compare(Person base, Person with) {
>                    return base.name.compareTo(with.name);
>                }
>            },//
>            bySurname{
>                @Override
>                public int compare(Person base, Person with) {
>                    return base.surname.compareTo(with.surname);
>                }
>            },//
>            ...
>            ;
>        }
>    }

Zaczynam powątpiewać w moją znajomość Javy :( To wyżej, to wciąż w
Javie?! Mógłbyś napisać, jak korzystasz z tych typów wyliczeniowych?

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl

[Bartek Kuczyński]

@Lasu, brawo!

Rzeczywiście elegancki przykład możliwości javy. Brakuje tylko
przykładu na komparator złożony :)

Pozdrawiam
Bartek "Koziołek" Kuczyński
http://koziolekweb.pl
Lepiej pomyśleć dwa razy i zacząć programować
niż dwa razy programować i potem zacząć myśleć
 \     /
 ~00~
  \_/
   |||

W dniu 28 czerwca 2011 11:40 użytkownik Jacek Laskowski
<ja...@japila.pl> napisał:

[Irek Matysiewicz]

W dniu 28 czerwca 2011 11:40 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2011/6/28 Lasu <develo...@gmail.com>:

>   //TODO Secure for NPE
>  class Person{
>
>        private final String name;
>        private final String surname;
>
>        public enum Comparators4Person implements Comparator<Person>{
>            byName{
>                @Override
>                public int compare(Person base, Person with) {
>                    return base.name.compareTo(with.name);
>                }
>            },//
>            bySurname{
>                @Override
>                public int compare(Person base, Person with) {
>                    return base.surname.compareTo(with.surname);
>                }
>            },//
>            ...
>            ;
>        }
>    }

Zaczynam powątpiewać w moją znajomość Javy :( To wyżej, to wciąż w
Javie?! Mógłbyś napisać, jak korzystasz z tych typów wyliczeniowych?

W Javie:

enum Nazwa implements Cośtam {

cośtam1(x, y, z) {/* metody */},
cośtam2(x, y, z){/* metody */};

Nazwa(TypX x, TypY y, TypZ z) {/* kod konstruktora */}

/* metody */
}

to nic innego jak syntactic sugar na mniej-więcej taki oto kod (pomijam głębsze szczegóły techniczne):

class Nazwa extends Enum implements Cośtam {
   public static final cośtam1 = new Nazwa(x, y, z) {/* metody */};
   public static final cośtam2 = new Nazwa(x, y, z) {/* metody */};

    Nazwa(TypX x, TypY y, TypZ z) {/* kod konstruktora */}
   /* metody */

    public static Nazwa[] values() { .... }
}

enum w Javie to po prostu wzorzec (albo antywzorzec) Singleton, tylko na sterydach.

Warto czasem pod JAD-em obejrzeć co generuje kompilator Javy (czy też Scali albo Grooviego). :-)

[Lasu]

On 28 Cze, 11:56, Irek Matysiewicz <iir...@gmail.com> wrote:
> enum w Javie to po prostu wzorzec (albo antywzorzec) Singleton, tylko na
> sterydach.
>
> Warto czasem pod JAD-em obejrzeć co generuje kompilator Javy (czy też Scali
> albo Grooviego). :-)

Ja tam bym chętnie jeszcze mu trochę sterydów dopakował ;) min.
rozszerzył wsparcie dla generyków tak aby były w stanie spinać
elementy różniące się typem.

[Jacek Laskowski]

2011/6/28 Lasu <develo...@gmail.com>:

> Ja tam bym chętnie jeszcze mu trochę sterydów dopakował ;) min.
> rozszerzył wsparcie dla generyków tak aby były w stanie spinać
> elementy różniące się typem.

Czy to nie to samo, co stworzenie wspólnego nadtypu? W końcu rozumiem,
że najbardziej zależy Ci na utrzymaniu silnego typizowania, tak?
Czyżby pora na Scalę?

[Lasu]

On 29 Cze, 13:08, Jacek Laskowski <ja...@japila.pl> wrote:
> 2011/6/28 Lasu <develop4l...@gmail.com>:

>
> > Ja tam bym chętnie jeszcze mu trochę sterydów dopakował ;) min.
> > rozszerzył wsparcie dla generyków tak aby były w stanie spinać
> > elementy różniące się typem.
>
> Czy to nie to samo, co stworzenie wspólnego nadtypu? W końcu rozumiem,
> że najbardziej zależy Ci na utrzymaniu silnego typizowania, tak?
> Czyżby pora na Scalę?
>
> Jacek
>
> --
> Jacek Laskowski

> Java EE, functional languages and IBM WebSphere -http://blog.japila.pl

> Warszawa JUG conference = Confitura (formerly Javarsovia) ::http://confitura.pl

Jestem sceptykiem jeśli chodzi o mutantów językowych. Później dojdą
nowe rzeczy do Javy i Scala straci na znaczeniu prawdopodobnie.

[Irek Matysiewicz]

W dniu 2011-06-29 20:22, Lasu pisze:

>
> Jestem sceptykiem jeśli chodzi o mutantów językowych. Później dojdą
> nowe rzeczy do Javy i Scala straci na znaczeniu prawdopodobnie.
>

Później to znaczy kiedy? Ile lat musięliśmy czekać na Javę 7 od czasów
Javy 5 (Java 6 to był tylko nieznaczny update na Javę 5). Oracle wydaje
mi się, że nie będzie się opieprzał tak jak Sun, ale nic nie wiadomo. I
właśnie taką lukę wypełniają języki alternatywne. Sam Oracle używa
Grooviego jako język walidacji w Oracle ADF.
Akurat na DZone jest artykuł (na pierwszej pozycji), że za 5 lat ktoś
szacuje taki udział w rynku: 50% Java, 20% Groovy, 20% Scala i 10% inne
języki JVM -
http://www.dzone.com/links/r/scala_in_5_years_my_prediction.html . Nawet
te 20% to niemało i ja tam wolę być w tych 20% czy 40%. :-)

[Michal Margiel]

"640K ought to be enough for anybody." - Bill Gates, 1981

Normalnie kocham takie przewidywania. 

Żeby nie było - nie mam nic przeciwko "alternatywnym językom", ale każdy z nas moze spobie powróżyć z fusów - a co będzie za 5 lat tego nikt nie wie. Ile to ja już lat słyszę o schyłku javy.. ale na słyszeniu się kończy...

Nawet Jacek L. mówił o schyłku javy kiedy byliśmy w radio występowaliśmy w radio 4 lata temu! I co? i nic..  

[Jacek Laskowski]

2011/6/30 Michal Margiel <michal....@gmail.com>:

> Nawet Jacek L. mówił o schyłku javy kiedy byliśmy w radio występowaliśmy w
> radio 4 lata temu! I co? i nic..

I przywołany do tablicy dopiszę, że po primo, nie było to 4 lata temu
(moja kariera blogerska ma 5 lat, a po roku daleko mi było do
publicznych wypowiedzi), a po sekundo, już niewielu siedzi na poziomie
samej składni javowej, a raczej skupia swoje wysiłki intelektualne na
poziomie rozpozna(wa)nia szkieletów/rusztowań, itp. Wiele wokół nas
warstaw wyższego poziomu, które ukrywają za nas niuanse programowania
i poznawania składni Javy => wprowadza się DSLe. Możnaby pokusić się,
że Groovy, Scala, Clojure to nic innego, jak właśnie takie DSLe i
warto przypomnieć, że całe zainteresowanie wokół Javy to ostatnimi
czasy właściwie wokół JVM. Stosunkowo niewiele jest zmian w samym Java
API (ale dalekim, aby stanowić wyrocznię, albo znawcę tematu).

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl

[Michal Margiel]

W dniu 30 czerwca 2011 12:00 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2011/6/30 Michal Margiel <michal....@gmail.com>:

> Nawet Jacek L. mówił o schyłku javy kiedy byliśmy w radio występowaliśmy w
> radio 4 lata temu! I co? i nic..

I przywołany do tablicy dopiszę, że po primo, nie było to 4 lata temu
(moja kariera blogerska ma 5 lat, a po roku daleko mi było do
publicznych wypowiedzi),

IMHO to było ok  maj 2008, więc nie 4, ale ponad 3.

 

a po sekundo, już niewielu siedzi na poziomie
samej składni javowej, a raczej skupia swoje wysiłki intelektualne na
poziomie rozpozna(wa)nia szkieletów/rusztowań, itp.

czy to znaczy że to schyłek javy? moim zdaniem wręcz odwrotnie.

 

Wiele wokół nas
warstaw wyższego poziomu, które ukrywają za nas niuanse programowania
i poznawania składni Javy => wprowadza się DSLe. Możnaby pokusić się,
że Groovy, Scala, Clojure to nic innego, jak właśnie takie DSLe i
warto przypomnieć, że całe zainteresowanie wokół Javy to ostatnimi
czasy właściwie wokół JVM. Stosunkowo niewiele jest zmian w samym Java
API (ale dalekim, aby stanowić wyrocznię, albo znawcę tematu).

Scala, czy groovy to zdecydowanie nie DLS. dls to po prostu wygodne  API opartego na danym języku, a języki wymienione przez Ciebei realizują magię na poziomie bytecodu.

równie dobrze mógłbyś powiedzieć że każdy język wyższego poziomu jest DLSem assemblera. I pewnie ziarenko (czy raczej atom) prawdy by w tym było. ale sensy w tym żadnego nie widzę.

[Irek Matysiewicz]

"640K ought to be enough for anybody." - Bill Gates, 1981

Normalnie kocham takie przewidywania. 

Żeby nie było - nie mam nic przeciwko "alternatywnym językom", ale każdy z nas moze spobie powróżyć z fusów - a co będzie za 5 lat tego nikt nie wie. Ile to ja już lat słyszę o schyłku javy.. ale na słyszeniu się kończy...

Nawet Jacek L. mówił o schyłku javy kiedy byliśmy w radio występowaliśmy w radio 4 lata temu! I co? i nic..  

 
Trendy w językach programowania nie zmieniają się aż tak szybko, i myślę że te przewidzenia na 5 lat są całkiem OK.
A co do Gatesa i jego 640K - aż tak bardzo się nie pomylił; 640K spokojnie wystarczyło sporej części (a może i większości) programów i gier DOS-owych.

[Irek Matysiewicz]

Scala, czy groovy to zdecydowanie nie DLS. dls to po prostu wygodne  API opartego na danym języku, a języki wymienione przez Ciebei realizują magię na poziomie bytecodu.

równie dobrze mógłbyś powiedzieć że każdy język wyższego poziomu jest DLSem assemblera. I pewnie ziarenko (czy raczej atom) prawdy by w tym było. ale sensy w tym żadnego nie widzę.

Ale w Scali czy Groovim DSL-e (zarówno wewnętrzne - wbudowane w język, jak i zewnętrzne - parsowanie tekstu) robi się o wiele, o wiele prościej. W dużej mierze jest to zaletą po prostu udogodnień w języku, jak domknięcia, automatyczne typowanie, przeciążanie operatorów, niejawne konwersje, itd. By w czystej Javie zrobić czy to wewnętrzny czy zewnętrzny DSL trzeba się o wiele więcej napracować.

[Tomasz Szymański]

On Jun 30, 2011, at 11:50 , Michal Margiel wrote:

W dniu 30 czerwca 2011 04:31 użytkownik Irek Matysiewicz <iir...@gmail.com> napisał:

W dniu 2011-06-29 20:22, Lasu pisze:

Jestem sceptykiem jeśli chodzi o mutantów językowych. Później dojdą
nowe rzeczy do Javy i Scala straci na znaczeniu prawdopodobnie.

Później to znaczy kiedy? Ile lat musięliśmy czekać na Javę 7 od czasów Javy 5 (Java 6 to był tylko nieznaczny update na Javę 5). Oracle wydaje mi się, że nie będzie się opieprzał tak jak Sun, ale nic nie wiadomo. I właśnie taką lukę wypełniają języki alternatywne. Sam Oracle używa Grooviego jako język walidacji w Oracle ADF.
Akurat na DZone jest artykuł (na pierwszej pozycji), że za 5 lat ktoś szacuje taki udział w rynku: 50% Java, 20% Groovy, 20% Scala i 10% inne języki JVM - http://www.dzone.com/links/r/scala_in_5_years_my_prediction.html . Nawet te 20% to niemało i ja tam wolę być w tych 20% czy 40%. :-)

"640K ought to be enough for anybody." - Bill Gates, 1981

To jest akurat legenda. Bill nigdy czegos takiego nie powiedzial (w koncu to jest bardzo inteligentny koles ... ) ;-)

T.

[Michal Margiel]

W dniu 30 czerwca 2011 12:14 użytkownik Michal Margiel <michal....@gmail.com> napisał:

Scala, czy groovy to zdecydowanie nie DLS. dls to po prostu wygodne  API opartego na danym języku, a języki wymienione przez Ciebei realizują magię na poziomie bytecodu.

równie dobrze mógłbyś powiedzieć że każdy język wyższego poziomu jest DLSem assemblera. I pewnie ziarenko (czy raczej atom) prawdy by w tym było. ale sensy w tym żadnego nie widzę.

Ja pierdziele.. co ja się tego DLS czepłem.. :/ oczywiście chodzi o DSL.

[Pawel Cesar Sanjuan Szklarz]

2011/6/30 Michal Margiel <michal....@gmail.com>

W dniu 30 czerwca 2011 12:00 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:

2011/6/30 Michal Margiel <michal....@gmail.com>:

> Nawet Jacek L. mówił o schyłku javy kiedy byliśmy w radio występowaliśmy w
> radio 4 lata temu! I co? i nic..

I przywołany do tablicy dopiszę, że po primo, nie było to 4 lata temu
(moja kariera blogerska ma 5 lat, a po roku daleko mi było do
publicznych wypowiedzi),

IMHO to było ok  maj 2008, więc nie 4, ale ponad 3.

 

a po sekundo, już niewielu siedzi na poziomie
samej składni javowej, a raczej skupia swoje wysiłki intelektualne na
poziomie rozpozna(wa)nia szkieletów/rusztowań, itp.

czy to znaczy że to schyłek javy? moim zdaniem wręcz odwrotnie.

 

Wiele wokół nas
warstaw wyższego poziomu, które ukrywają za nas niuanse programowania
i poznawania składni Javy => wprowadza się DSLe. Możnaby pokusić się,
że Groovy, Scala, Clojure to nic innego, jak właśnie takie DSLe i
warto przypomnieć, że całe zainteresowanie wokół Javy to ostatnimi
czasy właściwie wokół JVM. Stosunkowo niewiele jest zmian w samym Java
API (ale dalekim, aby stanowić wyrocznię, albo znawcę tematu).

Scala, czy groovy to zdecydowanie nie DLS. dls to po prostu wygodne  API opartego na danym języku, a języki wymienione przez Ciebei realizują magię na poziomie bytecodu.

"dls to po prostu wygodne  API opartego na danym języku, a języki wymienione przez Ciebei realizują magię na poziomie bytecodu"

A tu sie nie zgadzam. Np. w guice konfiguracja jest oparta o DSL, dokladnie:

http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Binder.html

ALE! Tam zrobione jest tak, ze ten DSL jest zwiazane z gramatyka niejawnie zadeklarowana w interfacach, np prosta gramatyka:

Bind -> "bind" KEY "to" PROVIDER

KEY -> "Type"

PROVIDER -> "Instance" | "Class"

jest realizowana przez interface

Interface BindProduction {

 ProviderProduction<T> bind(Type<T> t);

 }

ProviderProduction {

void alternatyweInstance(T instance);

void alternatyweClass(Class<? extends T> class);

} 

Wywolania do tych interfacow wtedy tlumaczymy do zdania z gramatyki (przy okazji, termy w zadaniu wskazuja na "zywe obiekty" w javie, a nie na stringi pasujace do regexp).

bind(Cos.class).to(Inplementacja.class)  => "bind" KEY(Cos.class) "to" PROVIDER:alternatywaClass(Inplementacja.class).

No i wlasnie, to nie "wygodne api", ale wlasnie "kod" w EDSL ktory jest kompilowane, ale nie przez kompilator javy, ale przez kompilator wbudowane w bibliotece guice specyficzne dla jezyka zadanego przez gramatyke wyzej:

Injector in = Guice.createInjector(new Module()) -> parsuj "kod dsl" w module, kompiluj go i generuj graph Key<T>-> Provider<T>

Pawel Szklarz.

równie dobrze mógłbyś powiedzieć że każdy język wyższego poziomu jest DLSem assemblera. I pewnie ziarenko (czy raczej atom) prawdy by w tym było. ale sensy w tym żadnego nie widzę.

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

--

[Michal Margiel]

W dniu 30 czerwca 2011 18:33 użytkownik Pawel Cesar Sanjuan Szklarz <paw...@gmail.com> napisał:

A tu sie nie zgadzam. Np. w guice konfiguracja jest oparta o DSL, dokladnie:

http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Binder.html

Ok, zgadza się. Uprościłem sprawę.. ale wciąż, skoro groovy to DSL to jaką on ma domenę? Rozumiem, ze domeną grooviego jest.. "programowanie" :) i wtedy znów wracam do stwierdzenia, że każdy język to dsl :) 

[Jacek Laskowski]

2011/6/30 Michal Margiel <michal....@gmail.com>:

> Ok, zgadza się. Uprościłem sprawę.. ale wciąż, skoro groovy to DSL to jaką
> on ma domenę?

Zluzowanie karbów kompilatora javy i zrzucenie odpowiedzialności
kompilatora na programistę => stworzenie języka dynamicznego (może
niekoniecznie w zgodzie z definicjami słownikowymi, ale w ogólnym tego
słowa znaczeniu). Czasami mam wrażenie, że kompilator przesłania
możliwości bajtkodu.

[Lasu]

Języki ułatwiajek to min.:
- Php
- Perl
"With free online books, over 22,500 extension modules, and a large
developer community, there are many ways to learn Perl 5."

Czy to dobry kierunek ?
W moim odczuciu niezbyt.... (oczywiście wyłączając dedykowane
zastosowania)
Rozumiał bym jak by Java była już wypucowana ... i wtedy stworzyć
kolejny język / generacje języka.
Skoro więc braki Javy nie zostały poważnie zniwelowane ani przez Scalę
ani przez Groovy-iego to dla mnie są to poniekąd martwe języki.
Poza tym częsta zmiana języków pogarsza jakość kodu a ja jestem
zdania, że mogę być jeszcze zajebistrzym programistą - więc bez sensu
dla mnie jest pchanie się w kolejny język jeśli nie zostanę do tego
zmuszony.

Jeśli chodzi o przewidywania co będzie a co nie to śliski temat - ale
biorąc pod uwagę kosz przepisania większego projektu stwierdzenie, że
jakikolwiek język umrze jest mało realne. Co prawda oznacza to większą
pensję dla tych kilku wybrańców którzy w nim wytrwają (+do pensji),
jeśli natomiast postawimy się na pozycji kierownictwa to taki
wynalazek może napsuć zdrowia.
U nas w firmie wspierany jest produkt w którym wszystkie zmienne muszą
mieć postać X123 X12 X2222 - zapewne domyślacie się jak wygląda samo
słuchanie rozmów na temat jakiejkolwiek zmiany...

[Irek Matysiewicz]

W dniu 2011-07-01 07:39, Lasu pisze:

> Skoro więc braki Javy nie zostały poważnie zniwelowane ani przez Scalę
> ani przez Groovy-iego to dla mnie są to poniekąd martwe języki.

O jakich brakach mówisz? Wiele braków Javy zostało przez Scalę /
Grooviego zniwelowane, choć nie mówię że są one idealne.

Źle do tego podchodzisz: do każdej działalności którą wykonujesz czy
zamierzasz wykonywać należy podchodzić jak do inwestycji (np. giełdowej
czy w nieruchomości). Tu nawet jak nie inwestujesz własnych pieniędzy,
to inwestujesz swój czas. A w inwestowaniu nie należy skupiać się na
jednej rzeczy (np. Javie), tylko na kilku (ale nie za wielu) różnych
(nazywa się to dywersyfikacją). Przykładem jest podejście low-risk,
low-reward (developerów Java z roku na rok jest coraz więcej i firmy
naprawdę mają w czym przebierać, ale masz przynajmniej jakąś pracę za
niekoniecznie duże pieniądze) + high-risk, high-reward (np. Scala,
Groovy - kto wie, może wkrótce warszawskie firmy będą szukać speców w
tych technologiach za wszelkie pieniądze). Jak high-risk, high-reward
wypali to super, jak nie, to na pocieszenie masz przynajmniej to
low-risk, low-reward. No i nie wspominając, że nawet jak to high-risk,
high-reward nie wypali, to przynajmniej będziesz miał przy tym niezłą
zabawę.

Z tym high-risk, high-reward zawsze jest trochę zgadywania. Kto 15 lat
temu zainteresował się Javą, teraz jest javowym guru (a wcale nie było
jasne czy to wypali), kto kilka lat temu zainteresował się aplikacjami
na Facebooka czy urządzenia mobilne teraz pewnie zarabia kupę kasy (a
wtedy też nie było jasne czy to wypali), a dla odmiany kto 15 lat temu
zainteresował się BeOS-em (był taki system operacyjny wokół którego było
całkiem głośno), niestety przegrał, a jak nie miał jednocześnie siatki
bezpieczeństwa w postaci low-risk, low-reward, to przegrał podwójnie.