106. Spotkanie Warszawa JUG - Metaprogramowanie w Javie

[Wojciech Erbetowski]

Cześć!

Zapraszamy gorąco w najbliższy wtorek, 8 stycznia o godzinie 18:00,
na Wydziale Matematyki Informatyki i Mechaniki UW (Banacha 2), w sali 3180 (II piętro).

Temat: Metaprogramowanie w Javie

Prelegentami będą Maciej Jankowski i Wojtek Erbetowski

O wykładzie

Ten wykład to absolutny "must" dla wszystkich developerów związanych z Javą (i w ogóle JVM). Początkujący w temacie dowiedzą się podstaw działania większości Javowych frameworków, czyli o manipulacjach na bytecode. Dowiecie się jak narzędzia są w stanie m. in. utworzyć mocki nagrywające wywołania w testach, czy założyć transakcje na naszą logikę biznesową. Mimo, że zaczniemy od podstaw w prezentacji będzie też kilka ciekawostek i uzupełnień wiedzy dla wytrawnych programistów.

Zaczniemy od wprowadzenia do generowania bytecodu, łącznie z pokazaniem, jak zrobić prostą klasę z niczego w czasie działania aplikacji. Następnie zobaczycie jak opakowują to najpopularniejsze biblioteki w używalny kod, oraz kto (jakie popularne frameworki) z tych narzędzi korzysta. Później już bardzo konkretnie opowiemy o CGLib, który w tej dziedzinie jest de facto standardem, a na sam koniec narzędzie, które powstało stosunkowo niedawno, czyli Plastic.

O prelegentach

Maciej od ośmiu lat programuje w Javie. Od pięciu lat komercyjnie. Nie lubi przetartych szlaków. Pasjonat nietypowych rozwiązań. Obecnie pracuje jako programista Java.

Wojtek jest Wam znany jako jeden z organizatorów warszawskiego JUG. W pracy programuje w Groovym, Scali i Javie, a także w Pythonie. Ostatnio stworzył bibliotekę RoboSpock, przy okazji której podszkolił się z tematu ładowania klas w Javie. Po godzinach już rozgląda się za nowym językiem/technologią.

Sponsor

Nasze spotkanie wspiera firma Polidea, dzięki której będziemy mogli się posilić i posłuchać, czym skuszą nas jako programistów, aby pracować z nimi.

A po spotkaniu

Planowany czas prezentacji wraz z dyskusją to 120 min. Następnie wybieramy się do pobliskiego baru, gdzie będzie możliwość kontynuacji tematu z prelegentami o temacie, lub też poznania innych zapaleńców technologii.

Potwierdź obecność

Abyśmy mogli sprawniej przygotować się do spotkania prosimy jedynie o kliknięcie

czy zamierzasz być na spotkaniu czy też nie (zliczamy kliknięcia). Dzięki!

Informacje o spotkaniach zawsze widoczne w kalendarzu grupy oraz na twitterze.

Zapraszamy!

[Kacper Kaśków]

Witam,

skoro wykład to takie must-be, to czy zostanie spotkanie nagrane i umieszczone na internetach w celu dotarcia do ludzi niemogących się pojawić?

Z góry dziękuję za odpowiedź i pozdrawiam, Kacper Kaśków

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Wojciech Erbetowski]

Postaramy się jak zwykle nagrać i wrzucić na youtube :-) 

[Irek Matysiewicz]

Metaprogramowanie w Javie to chyba zbyt szumny tytuł, skoro zamierzacie mówić tylko o bytecodzie. W Lisp, Clojure, a nawet w JavaScripcie, kod=dane, i z kodem można robić dosłownie wszystko. W Javie są duże ograniczenia.

[Jakub Nabrdalik]

On 04.01.2013 13:36, Irek Matysiewicz wrote:
> Metaprogramowanie w Javie to chyba zbyt szumny tytuł, skoro zamierzacie
> mówić tylko o bytecodzie. W Lisp, Clojure, a nawet w JavaScripcie,
> kod=dane, i z kodem można robić dosłownie wszystko. W Javie są duże
> ograniczenia.

Czekaj, czyli w sumie jest ok. No bo skoro w Javie żeby robić
'metaprogramowanie' jedyna opcja to sięgać po modyfikację bytecode'u, a
o tym chłopaki mówią o modyfikacji bytecode'u, to wszystki się zgadza.
Czy coś pomieszałem?


--
Jakub Nabrdalik
blog.solidcraft.eu

[Wojciech Erbetowski]

Tzn. Irek uznał, że to zbyt kiepskie metaprogramowanie by nazwać go metaprogramowaniem :-)

Żeby rozwiązać spór na poziomie definicji spójrzmy do Wikipedii:

Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data

A więc jak w mordę strzelił pasuje do manipulacji na bytecode (gdy bierzemy klasę która robi jedno i zwracamy klasę robiącą co innego).

Pozdro,

Wojtek

[Irek M]

W dniu 4 stycznia 2013 14:25 użytkownik Wojciech Erbetowski
<wojc...@erbetowski.pl> napisał:

> Tzn. Irek uznał, że to zbyt kiepskie metaprogramowanie by nazwać go
> metaprogramowaniem :-)
>

Dokładnie. To tak jakby hamburgera z McDonalda nazywać jedzeniem, albo
masturbację nazywać seksem :-)

Często na zupełnie prościutkich rzeczach manipulowanie bytecodem wymięka.

[Wojciech Erbetowski]

Często na zupełnie prościutkich rzeczach manipulowanie bytecodem wymięka.

Jakiś przykład może?

[Jakub Nabrdalik]

No właśnie. Bo mi też się wydawało, że akurat na poziomie bytecode'u
mamy największego powera (i największe szanse strzelić sobie w stopę).
Ale może tylko mi się wydawało.


--
Jakub Nabrdalik
blog.solidcraft.eu

[Irek M]

Np. nie możesz dodać metody w uruchomionej JVM, kto choć raz debugował
wie że przy dodaniu nowej metody trzeba restartować cały program (albo
zapewne wykosztować się na JRebela).

Nie możesz wcale zmodyfikować klas z rt.jar w uruchomionej JVM. Można
to zrobić przed uruchomieniem JVM i ustawić bootclasspath, ale to
wymaga trochę zachodu i powoduje problemy licencyjne.

To czy chcesz modyfikować w czasie pracy JVM musisz ustalić na samym
początku (opcją -javaagent albo pisząc własnego classloadera). Gdy nie
masz uprawnień do zmiany opcji JVM a potrzebujesz zmodyfikować
naprawdę drobiazg, to jest problem.

W Javie nie można dodawać nowych konstrukcji do języka (np. w Scali
można dzięki pluginom a w Clojure podobno dzięki makrom).

Za pomocą bytecodu nie można dodawać nowych metod i klas w jeszcze
nieskompilowanym kodzie tak by kompilator zobaczył te metody/klasy.
Np. głupie generowanie geterów i seterów w Lomboku wygląda tak:
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/core/AnnotationProcessor.java
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/javac/apt/Processor.java
- https://github.com/rzwitserloot/lombok/blob/master/src/eclipseAgent/lombok/eclipse/agent/EclipsePatcher.java
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/javac/handlers/HandleGetter.java
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/javac/handlers/HandleSetter.java
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/eclipse/handlers/HandleGetter.java
- https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/eclipse/handlers/HandleSetter.java

Jest to zaprogramowane fatalnie, ale pod względem technicznym (jak to
w ogóle zrobić) chyba nie da się zrobić tego o wiele lepiej.

[Wojciech Erbetowski]

Np. nie możesz dodać metody w uruchomionej JVM, kto choć raz debugował
wie że przy dodaniu nowej metody trzeba restartować cały program (albo
zapewne wykosztować się na JRebela).

Błąd, pokażemy jak dodawać medoty w runtime. Jedna z bardziej podstawowych rzeczy.

 

Nie możesz wcale zmodyfikować klas z rt.jar w uruchomionej JVM. Można
to zrobić przed uruchomieniem JVM i ustawić bootclasspath, ale to
wymaga trochę zachodu i powoduje problemy licencyjne.

Dla chcącego nic trudnego. Przykład jak PowerMock mockuje klasę System

http://code.google.com/p/powermock/wiki/MockSystem

 

To czy chcesz modyfikować w czasie pracy JVM musisz ustalić na samym
początku (opcją -javaagent albo pisząc własnego classloadera). Gdy nie
masz uprawnień do zmiany opcji JVM a potrzebujesz zmodyfikować
naprawdę drobiazg, to jest problem.

No właśnie nie jest to problem. Te biblioteki opierają się na classloaderach

i nie musisz na nic decydować się na początku.

 

W Javie nie można dodawać nowych konstrukcji do języka (np. w Scali
można dzięki pluginom a w Clojure podobno dzięki makrom).

Zgadzam się, nie ma makr w Javie (i bardzo dobrze), to może urągać metaprogramowaniu w Javie.

 

Za pomocą bytecodu nie można dodawać nowych metod i klas w jeszcze

nieskompilowanym kodzie ...

W jeszcze nieskompilowanym kodzie?  W sensie w plikach źródłowych?

Hmmm, to chyba generate hashCode w IDE jest takim metaprogramowaniem :P

Jest to zaprogramowane fatalnie, ale pod względem technicznym (jak to
w ogóle zrobić) chyba nie da się zrobić tego o wiele lepiej.

Myślę, że Twoje uwagi wynikają głównie z niezrozumienia tematu.

Chodzi o biblioteki pokroju CGLib, które pozwalają na wiele z tych rzeczy,

które wymieniłeś jako niemożliwe do osiągnięcia.

Jeśli chodzi o Classloadery w JVM to są one świetnym rozwiązaniem,

aby oddzielić powtarzalne zachowania od kodu, zastosować AOP,

czy po prostu osiągnąć rzeczy, które trudno osiągnąć samym językiem.

I do tego niesamowicie wydajnie, bo raz wygenerowany bytecode

nie różni się wydajnościowo od skompilowanego.

Nie pozostaje mi nic innego zatem, jak zaprosić Cię tym bardziej na wykład ;-)

Pozdrawiam,

Wojtek

[Irek M]

W dniu 4 stycznia 2013 15:28 użytkownik Wojciech Erbetowski
<wojc...@erbetowski.pl> napisał:

>> Np. nie możesz dodać metody w uruchomionej JVM, kto choć raz debugował
>> wie że przy dodaniu nowej metody trzeba restartować cały program (albo
>> zapewne wykosztować się na JRebela).
>
> Błąd, pokażemy jak dodawać medoty w runtime. Jedna z bardziej podstawowych
> rzeczy.

Nie rozumiesz mnie. Metody w runtime dodawać to możesz (np.
klasa.addMethod). Problem w tym, że nie dodasz tej metody do klasy,
która już została załadowana bez przeładowywania classloadera albo
całej JVM.
Gdyby dało się tak łatwo jak piszesz dawno by ktoś to zaimplementował,
i przy debugowaniu nie trzeba by było restartować JVM albo używać
JRebel.

>
>>
>> Nie możesz wcale zmodyfikować klas z rt.jar w uruchomionej JVM. Można
>> to zrobić przed uruchomieniem JVM i ustawić bootclasspath, ale to
>> wymaga trochę zachodu i powoduje problemy licencyjne.
>
> Dla chcącego nic trudnego. Przykład jak PowerMock mockuje klasę System
> http://code.google.com/p/powermock/wiki/MockSystem

Działa to w taki sposób, że mockowana jest nie "systemowa" klasa
URLEncoder, lecz "moja" klasa SystemClassUser. Pozwala to na
przechwycenie wywołań do URLEncodera pochodzących z "mojego" kodu, ale
nie da się w ten sposób przechwycić wywołań z "systemowego" kodu.
Czasami jest to problemem, np. Terracotta DSO
(http://www.codeproject.com/Articles/18945/Introduction-to-Terracotta-DSO)
używa metody z ustawianiem bootclasspath, bo musi przechwytywać
WSZYSTKIE wywołania na wybranych klasach z rt.jar

>
>>
>> To czy chcesz modyfikować w czasie pracy JVM musisz ustalić na samym
>> początku (opcją -javaagent albo pisząc własnego classloadera). Gdy nie
>> masz uprawnień do zmiany opcji JVM a potrzebujesz zmodyfikować
>> naprawdę drobiazg, to jest problem.
>
> No właśnie nie jest to problem. Te biblioteki opierają się na classloaderach
> i nie musisz na nic decydować się na początku.

- Nie zawsze masz uprawnienia do classloadera, a ty chcesz zrobić
zmianę taką tycią tycią, która nikomu nie zaszkodzi
- Classloaderem nie zmodyfikujesz już działającego kodu, to potrafi
tylko -javaagent

>
>>
>> W Javie nie można dodawać nowych konstrukcji do języka (np. w Scali
>> można dzięki pluginom a w Clojure podobno dzięki makrom).
>
> Zgadzam się, nie ma makr w Javie (i bardzo dobrze), to może urągać
> metaprogramowaniu w Javie.

Nie chodzi mi o makra, bo np. makra w C++ przynoszą więcej złego niż
dobrego, ale ogólnie: za bardzo nie da się rozszerzyć składni Javy bez
przepisywania kompilatora i wszystkich narzędzi

>
>>
>> Za pomocą bytecodu nie można dodawać nowych metod i klas w jeszcze
>> nieskompilowanym kodzie ...
>
> W jeszcze nieskompilowanym kodzie? W sensie w plikach źródłowych?
> Hmmm, to chyba generate hashCode w IDE jest takim metaprogramowaniem :P

- "Generate hashCode" Zostało zrobione nie za pomocą bytecodu, ale za
pomocą API z Eclipse JDT lub innego IDE
- Zmiany nie są automatycznie synchronizowane. Np. dodanie nowego pola
nie włączy go automatycznie do hashCode, a np. po zmianie typu pola z
Integer na int będzie błąd kompilacji
- Pozostawia śmietnik w kodzie. W większości przypadków equals,
hashCode, getery, setery są tak oczywiste, że ich obecność tylko
zaśmieca kod


A w takim JavaScripcie masz po prostu obiekt.metoda = cośtam,
obiekt.metoda.toString() i eval("kod") i możesz metaprogramować do
bólu. W Javie ktoś nie pomyślał i przekombinował.

> Nie pozostaje mi nic innego zatem, jak zaprosić Cię tym bardziej na wykład
> ;-)

Nie da rady. Już nie mieszkam w Warszawie ;-(

[Jakub Nabrdalik]

On 04.01.2013 16:47, Irek M wrote:
> A w takim JavaScripcie masz po prostu obiekt.metoda = cośtam,
> obiekt.metoda.toString() i eval("kod") i możesz metaprogramować do
> bólu. W Javie ktoś nie pomyślał i przekombinował.

W Javie masz Groovy, i możesz metaprogramować bez bólu :)

>> >Nie pozostaje mi nic innego zatem, jak zaprosić Cię tym bardziej na wykład
>> >;-)
> Nie da rady. Już nie mieszkam w Warszawie ;-(

A gdzie się przeniosłeś?

--
Jakub Nabrdalik
blog.solidcraft.eu

[m p]

2013/1/4 Jakub Nabrdalik <jak...@gmail.com>

On 04.01.2013 16:47, Irek M wrote:

A w takim JavaScripcie masz po prostu obiekt.metoda = cośtam,
obiekt.metoda.toString() i eval("kod") i możesz metaprogramować do
bólu. W Javie ktoś nie pomyślał i przekombinował.

W Javie masz Groovy, i możesz metaprogramować bez bólu :)

dopóki nie okaże się że chcesz wejść na kawałek Javowy bo wtedy może zacząć boleć ;)

 

>Nie pozostaje mi nic innego zatem, jak zaprosić Cię tym bardziej na wykład
>;-)

Nie da rady. Już nie mieszkam w Warszawie ;-(

A gdzie się przeniosłeś?

--
Jakub Nabrdalik
blog.solidcraft.eu

[Irek M]

W dniu 4 stycznia 2013 16:51 użytkownik Jakub Nabrdalik
<jak...@gmail.com> napisał:

> On 04.01.2013 16:47, Irek M wrote:
>>
>> A w takim JavaScripcie masz po prostu obiekt.metoda = cośtam,
>> obiekt.metoda.toString() i eval("kod") i możesz metaprogramować do
>> bólu. W Javie ktoś nie pomyślał i przekombinował.
>
>
> W Javie masz Groovy, i możesz metaprogramować bez bólu :)

Tak, ale do tego są przygotowane tylko klasy napisane w Groovym. Z
klasami napisanymi w Javie tak fajnie nie ma.

[Jakub Nabrdalik]

Tak długo jak pozostajesz w Groovym, nie ma znaczenia, gdzie były
napisane klasy:

void "ale do tego są przygotowane tylko klasy napisane w Groovym?"() {
given:
String simpleString = new String()
when:
simpleString.metaClass.supportsNewMethods = {"Yes we can!"}
then:
simpleString.supportsNewMethods() == "Yes we can!"
}

Oczywiście napieprzanie po metaclasie jest strzelaniem sobie z łuku w
lewe jądro, ale się da się.

Maciek Próchniak mi tu nad ramieniem narzeka, że klasy javowe niestety
nie zobaczą nadpisanej metody prywatnej, do której się odwołują, w ten
sposób. True that.

--
Jakub Nabrdalik
blog.solidcraft.eu

[Kuba Kubryński]

W dniu piątek, 4 stycznia 2013 14:58:14 UTC+1 użytkownik Irek Matysiewicz napisał:

Np. nie możesz dodać metody w uruchomionej JVM, kto choć raz debugował
wie że przy dodaniu nowej metody trzeba restartować cały program (albo
zapewne wykosztować się na JRebela).

Irek - popraw mnie o ile się mylę, ale zdecydowaną większość swoich feature'ów JRebel zapewnia poprzez ASM'a, który jest przecież właśnie narzędziem do... manipulacji bytecode'm. M.in. dlatego IMHO nie mogą przeskoczyć modyfikacji superklasy i dodawać/usuwać implementowanych interface'ów - to da się zrobić tylko dziwnymi hackami na innym poziomie runtime'a.

Pozdrawiam,

Kuba

[Irek M]

W dniu 4 stycznia 2013 22:12 użytkownik Kuba Kubryński
<jkubr...@gmail.com> napisał:

Tutaj dali ogólny zarys jak to działa:
http://zeroturnaround.com/labs/reloading-objects-classes-classloaders/
Ale coś takiego zaprogramować, i by to jeszcze szybko działało to jest
kupa ciężkiej roboty, i jak wspomniałeś nie wszystko udało im się
zhakować. Trochę jak wchodzenie do domu przez komin.
W przypadku JavaScriptu taki algorytm przeładowywania ograniczyłby się
do ponownego wykonania pliku ZmienionaKlasa.js i zamiany starej
zawartości ZmienionaKlasa.prototype na nową. Czasem najprostsze
rozwiązania są najlepsze.

[Kuba Kubryński]

No niestety - sam mechanizm ładowania klas w Javie nasuwa nam pewne ograniczenia. Jednak porównywanie JavaScriptu z Javą nie ma jak dla mnie żadnego sensu, bo nie mają ze sobą nic wspólnego poza pierwszym członem nazwy. A same mechanizmy typu generowanie bytecodu dają nam ogromne możliwości i tylko ich poznanie umożliwa faktyczne zrozumienie tego w jaki sposób działają np. transakcje czy lazy-loading w hibernate. Jak dla mnie można uznać, że nawet mechanizm refleksji wykorzystujemy do metaprogramowania. Ważne, że spełnia swój cel - a to, że Java wg mnie nigdy nie była przewidziania jako wsparcie dla metaprogramowania to zupełnia inna sprawa - są w końcu ludzie, którzy ścigają się Kią Piccanto, nie? :)

Pozdrawiam,

Kuba 

[Adam Lider]

Czasem chyba jednak warto spojrzec na (calkiem) inne jezyki, aby zobaczyc jak dany mechanizm powinien dzialac. Podobnie jest z programowaniem funkcyjnym, gdzie pokazywanie jak mozna programowac funkcyjnie w Javie jest sztuka dla sztuki, a nie faktycznym przykladem jak to powinno byc. Jesli nie JS to mozna spojrzec na Ruby, ktory co by nie mowic jest blizszy Javie, bo klasowy. Tutaj metaprogramowanie jest naturalnym mechnizmem, czesto wykorzystywanym, a nie czyms co sie da zrobic. Metaprogramowanie w Javie? no cos tam da sie, ale lepiej nie pokazyc tego specjalistom od tematu ;)

--
Adam Lider

[Irek M]

> metaprogramowania. Ważne, że spełnia swój cel - a to, że Java wg mnie nigdy
> nie była przewidziania jako wsparcie dla metaprogramowania to zupełnia inna
> sprawa - są w końcu ludzie, którzy ścigają się Kią Piccanto, nie? :)

Java też była przewidziana do metaprogramowania - wraz z JVM i JDK
jest dostarczana refleksja, bajtkod, classloadery, javaagent, JDWP,
annotation processing tool. Kupa rozwiązań, a żadne z nich nie jest
kompletne, nawet wszystkie razem nie są kompletne. No i mało kto te
wszystkie mechanizmy dobrze zna.
A tak naprawdę wystarczyłoby by obiekt Klasa.class był edytowalny (tak
jak w JS można edytować Klasa.prototype). Przekombinowali i tyle. A
może przekombinowali by mieli o czym pisać w swoich książkach? :-)

[Irek M]

Dokładnie. Szkoda tylko że w "alternatywnych" językach programowania
jest duuuużo trudniej o pracę i jest dużo gorzej ze wsparciem
narzędzi.


W dniu 5 stycznia 2013 11:43 użytkownik Adam Lider
<adam....@gmail.com> napisał:

[Marcin Piczkowski]

Groovy podobnie jak Ruby dobrze radzi sobie z metaprogramowaniem a ze dziala na JVM jest bliski Javie, co wiecej mozna nawet pisac kod Javy i integrowac z juz istniejacymi klasami. Wsparcie narzedzi pozostaje takie samo jak dla Javy.

[Irek M]

Dopiero co była o tym mowa: Groovy nie zmieni kodu napisanego w Javie
bo JVM na to nie pozwala.
No i mało kto używa Grooviego - w Tiobe index jest dopiero w drugiej
pięćdziesiątce.


W dniu 5 stycznia 2013 15:09 użytkownik Marcin Piczkowski
<marcin.p...@gmail.com> napisał:

[Kuba Kubryński]

W dniu sobota, 5 stycznia 2013 11:44:11 UTC+1 użytkownik Irek Matysiewicz napisał:

Java też była przewidziana do metaprogramowania - wraz z JVM i JDK
jest dostarczana refleksja, bajtkod, classloadery, javaagent, JDWP,
annotation processing tool. Kupa rozwiązań, a żadne z nich nie jest
kompletne, nawet wszystkie razem nie są kompletne. No i mało kto te
wszystkie mechanizmy dobrze zna.
A tak naprawdę wystarczyłoby by obiekt Klasa.class był edytowalny (tak
jak w JS można edytować Klasa.prototype). Przekombinowali i tyle. A
może przekombinowali by mieli o czym pisać w swoich książkach? :-)

Pytanie ile z tych elementów faktycznie było zaprojektowane pod kątem zapewnienia wsparcia dla metaprogramowania a dla ilu był to po prostu dodatkowy featur :)

Moim zdaniem w kontekście samego metaprogramowania są zdecydowanie lepsze języki niż Java i tutaj nawet nie ma co dystukować. Natomiast brak znajomości zasad i technik modyfikowania bytecodu uważam za znaczną lukę w wiedzy programistycznej. I właśnie to próbowałem wyartykułować ;)

Pozdrawiam,

Kuba

[Jakub Nabrdalik]

W dniu 5 stycznia 2013 15:14 użytkownik Irek M <iir...@gmail.com> napisał:

Dopiero co była o tym mowa: Groovy nie zmieni kodu napisanego w Javie
bo JVM na to nie pozwala.

Zależy jak definiować "zmianę kodu". W przykładzie pokazałem, że dodać/nadpisać metodę z klasy javowej można, i w runtime grooviego widzisz ją zamiast oryginału. Nie widać jej z perspektywy metod tej samej klasy (czyli wołania własnej metody - co ma nawet sens, poza problemami technicznymi).
 

No i mało kto używa Grooviego - w Tiobe index jest dopiero w drugiej
pięćdziesiątce.

Nie przejmowałbym się Tiobe indexem, bo popularność Pascala i Delphi (Object Pascal) na pozycjach 14 i 15, wcale nie przekłada się na oferty pracy :D

Według badania firm pracujących na JVMie (robił Zeroturnaround*), Groovy jest najpopularniejszym językiem na JVM'ie za Javą, z penetracją rynku 17% (scala: 11%, closure, 1%, jruby 2%, jython 2%), więc może nie jest tak źle, jak Ci się wydaje. Oferty pracy raczej są.
*[http://zeroturnaround.com/labs/developer-productivity-report-2012-java-tools-tech-devs-and-data/]

--
Jakub Nabrdalik
http://blog.solidcraft.eu

[Irek M]

Jeśli chodzi o Pascala to ciągle pewnie w wielu miejscach rozpoczyna
się naukę programowania od niego, więc się nie dziwię z takich
zawyżonych wyników.

A co do Grooviego to wyniki wyszukiwania np. w pracuj.pl mówią same za siebie:
http://www.pracuj.pl/praca/groovy;kw/informatyka%20programowanie;c,3000015
(jeśli gdzieś się pojawia, to głównie w rubryce "Mile widziane")


Tak więc Tiobe wydaje mi się bardziej wiarygodny niż to badanie ZeroTurnaround.


W dniu 5 stycznia 2013 22:21 użytkownik Jakub Nabrdalik
<jak...@gmail.com> napisał:
>

[Piotrek]

Nie możesz wcale zmodyfikować klas z rt.jar w uruchomionej JVM. Można
to zrobić przed uruchomieniem JVM i ustawić bootclasspath, ale to
wymaga trochę zachodu i powoduje problemy licencyjne.

jakie problemy licencyjne? mozesz powiedziec cos wiecej albo dac linka? nie jest tak, ze po prostu tracimy prawo do nazwy 'java' i to wszystko?

[Wojciech Erbetowski]

Nie można przecież robić bez porozumienia własnych implementacji JVM (zrozumiałe, żeby nie partycjonować rynku nikompatybilnymi rozwiązaniami jak kiedyś M$).

Rozumiem, że chodziło o modyfikacje źródeł czy też bytecodu z rt.jar Irkowi, ale mi chodzi bardziej o podmianę classloaderem klasy z rt.jar (np j.u.Date) na naszą implementację,

co według mojej wiedzy (a nie mam zielonego pojęcia o prawie :-)) z niczym nie koliduje.

--

[Irek M]

W dniu 6 stycznia 2013 11:57 użytkownik Wojciech Erbetowski
<wojc...@erbetowski.pl> napisał:

> Nie można przecież robić bez porozumienia własnych implementacji JVM
> (zrozumiałe, żeby nie partycjonować rynku nikompatybilnymi rozwiązaniami jak
> kiedyś M$).
>
> Rozumiem, że chodziło o modyfikacje źródeł czy też bytecodu z rt.jar Irkowi,
> ale mi chodzi bardziej o podmianę classloaderem klasy z rt.jar (np j.u.Date)
> na naszą implementację,
> co według mojej wiedzy (a nie mam zielonego pojęcia o prawie :-)) z niczym
> nie koliduje.
>

Z niczym nie koliduje bo tak się nie da. :-)


http://docs.oracle.com/javase/6/docs/technotes/tools/windows/java.html#nonstandard
"Applications that use this option for the purpose of overriding a
class in rt.jar should not be deployed as doing so would contravene
the Java 2 Runtime Environment binary code license."

Chyba chodzi o to, że modyfikacji rt.jar można dokonać dopiero na
komputerze docelowym - tak przynajmniej robi Terracotta.

[Wojciech Erbetowski]

W dniu 6 stycznia 2013 12:06 użytkownik Irek M <iir...@gmail.com> napisał:

should not be deployed

Ciekawe stwierdzenie :-)

A więc terracota sobie z tym radzi? 

Hmmm, nie znalazłem wzmianki o tym, że nie da się shadowować klas z rt,

ale w Plastic faktycznie przy próbie przykrycia java.util dostaję pewien illegal cośtam exception.

Właśnie postarałem się wczytać ręcznie i faktycznie już na poziomie wirtualne maszyny dostaję "Prohibited package name: java.util".

Co ciekawe w czasie kompilacji nie stanowi to problemu:

$ cat Date.java 

package java.util;

public class Date {}

$ javac Date.java # actually compiles Date ;-)

a Javie (Groovym dokladniej, ale co tam)

this.defineClass(null, bytes, 0, bytes.length)} // inside ClassLoader, bytes is Date.class content

rzuca przemiłym 

ERROR java.lang.SecurityException:

Prohibited package name: java.util

        at groovysh_evaluate$1.x (groovysh_evaluate:2)

        at groovysh_evaluate$1$x.call (Unknown Source)

        at groovysh_evaluate.run (groovysh_evaluate:2)

        ...

podobnie dla java.lang :-(

Dzięki Irek za zwrocenie na to uwagi.

[Irek M]

>
> this.defineClass(null, bytes, 0, bytes.length)} // inside ClassLoader, bytes
> is Date.class content
>
> rzuca przemiłym
>
> ERROR java.lang.SecurityException:
> Prohibited package name: java.util
> at groovysh_evaluate$1.x (groovysh_evaluate:2)
> at groovysh_evaluate$1$x.call (Unknown Source)
> at groovysh_evaluate.run (groovysh_evaluate:2)
> ...

I ma to bardzo niemiłe, praktyczne konsekwencje. Np. nie od dziś
wiadomo że klasa j.u.Date to kompletna spierdolina (ciągle często
używana), i na przykład ktoś nieświadomy mógłby wywołać na encji
Hibernate: encja.getCośtamDate().setDay/Year/Month(...). Z powodu tego
ograniczenia Hibernate zupełnie nie może obserwować tych seterów by
zapisać zmiany do bazy albo chociaż dać jakieś ostrzeżenie że
programista źle robi.

[Waldek Kot]

W dniu niedziela, 6 stycznia 2013 12:44:36 UTC+1 użytkownik Wojciech Erbetowski napisał:

Hmmm, nie znalazłem wzmianki o tym, że nie da się shadowować klas z rt,

a Javie (Groovym dokladniej, ale co tam)

this.defineClass(null, bytes, 0, bytes.length)} // inside ClassLoader, bytes is Date.class content

rzuca przemiłym 

ERROR java.lang.SecurityException:

Prohibited package name: java.util

        at groovysh_evaluate$1.x (groovysh_evaluate:2)

        at groovysh_evaluate$1$x.call (Unknown Source)

        at groovysh_evaluate.run (groovysh_evaluate:2)

        ...

podobnie dla java.lang :-(

Ale tu chyba o coś innego chodzi - próbujesz dodać własną klasę w pakiecie, którego nazwa zaczyna się od "java" ;-).

Modyfikacje i przykrywanie klas z rt.jar własnymi implementacjami jest możliwe, acz potencjalnie niebezpieczne. Akurat przypadek o którym pisze Irek podpada pod definicję "bardzo trudne", ale nie "niemożliwe". W każdym razie nie ma co generalizować - zależy którą klasę (także metodę/pole), jaka modyfikacja (np. dodawanie pól - zwykle OK, zmiana przodka - często nie). Przypadek o którym też Irek wspomina, czyli przechwytywanie wywołań z "wewnątrz" JDK, też jest trudny, ale "dasię" (nie dla każdej klasy z rt.jar - to na pewno). 

O tym, że się da niech świadczy chociażby to, że np. AspectJ dopuszcza (za pomocą przełącznika) weaving klas systemowych. Domyślnie jest to wyłączone, bo najczęściej nie zadziała (bo następuje tzw. gonienie własnego ogona: wiele klas z rt.jar jest ładowanych przy starcie JVM, następuje ich modyfikacja, w kodzie advice [często] używany jest kod z rt.jar i się zapętlamy). Powodów do wysypania JVM jest zresztą więcej...

Irek strasznie negatywnie jedzie po Java, ale te same problemy z modyfikacją klas systemowych są w innych technologiach (np. .NET) - zaryzykuję, że w każdym "środowisku wykonawczym" (w OS-ach też), bo każde z nich "chroni" wybrany kawałek swojego poletka, by móc bezpieczniej/wydajniej/... działać.

Pozdrawiam,

Waldek 

[Waldek Kot]

W dniu niedziela, 6 stycznia 2013 12:06:19 UTC+1 użytkownik Irek Matysiewicz napisał:

W dniu 6 stycznia 2013 11:57 użytkownik Wojciech Erbetowski

> Rozumiem, że chodziło o modyfikacje źródeł czy też bytecodu z rt.jar Irkowi,
> ale mi chodzi bardziej o podmianę classloaderem klasy z rt.jar (np j.u.Date)
> na naszą implementację,
> co według mojej wiedzy (a nie mam zielonego pojęcia o prawie :-)) z niczym
> nie koliduje.
>

Z niczym nie koliduje bo tak się nie da. :-)

Bez agenta czy modyfikacji bootclasspath, to z "czystym" classloaderem to zgoda - wydaje mi się, że się nie da - tzn. zmodyfikować bajtkod standardowej klasy się da, ale będziesz miał de facto nową klasę (kod wołający "java.util.Date" nie zobaczy tej implementacji - hierarchia classloader'ów się ukłoni i - jako rodzic - klasę dostarczy boot classloader). 

Kodowi który ma skorzystać z tej zmodyfikowanej klasy trzeba by jakoś ją przekazać (via fabryka na przykład albo sprytne wstrzyknięcie zależności). Ewentualnie (np. za pomocą AOP) zmodyfikować te miejsca w których następuje wywołanie standardowego java.util.Date, tak, żeby wskazywały na tę zmodyfikowaną klasę. Z poziomu kodu aplikacji wydaje się to do zrobienia, dla klas JDK (jak Irek wspominał) dużo trudniej (tj. łatwiej o wysyp).

Dlatego też prostsze jest to podejście z modyfikacją bootclasspath, z agentem lub ze statyczną modyfikacją rt.jar - albo najlepiej hybryda tych i jeszcze paru innych tricków. Temat jak robić modyfikacje klas standardowych bezpiecznie, wydajnie (bez narzutu, w tym bez rozrostu wielkości rt.jar), przenośnie i bez ograniczeń jest wałkowany chyba od początku Java (tak jak pisałem, to w zasadzie problem niezależny od języka i technologii, choć na pewno są różnice dla klas języków, np. ze statycznym i dynamicznym typowanie, z/bez refleksji, z/bez wyjątków (w tym checked/unchecked), itd.).

Pozdrawiam,

Waldek Kot

 

[Waldek Kot]

W dniu piątek, 4 stycznia 2013 16:47:44 UTC+1 użytkownik Irek Matysiewicz napisał:

>
>>
>> W Javie nie można dodawać nowych konstrukcji do języka (np. w Scali
>> można dzięki pluginom a w Clojure podobno dzięki makrom).
>
> Zgadzam się, nie ma makr w Javie (i bardzo dobrze), to może urągać
> metaprogramowaniu w Javie.

Nie chodzi mi o makra, bo np. makra w C++ przynoszą więcej złego niż
dobrego, ale ogólnie: za bardzo nie da się rozszerzyć składni Javy bez
przepisywania kompilatora i wszystkich narzędzi

Co do braku rozszerzalności składni języka Java, czy choćby nawet dostępności publicznego API do  kompilatora, pozwalającego dostać się do kodu Java i AST, to zgoda. Chciałoby się móc napisać:

public class Example {

    public static void main(String[] args) {

        System.out.println(

            MCMLXXVII + XXIV         //<- WTF ???

        );

    }

}

Niestety, ale prace nad JSR-269 (dawniej nazywanym Compiler API) zakończyły się na częściowej  implementacji adnotacji (częściowej, bo reszta - też po opóźnieniach [pamiętne "plan A, plan B"]  - ma się pojawić w Java 8). Trzeba więc posiłkować się niepublicznymi API (com.sun.tools.javac)  albo - jak to robi lombok - wpinać się w IDE (Eclipse). Ale uzyskać taki kod jak powyżej  (wyświetla "2001") "dasię" (można znaleźć w sieci) ;-). Do implementacji makr a'la C++ w Java da  radę ;-) Notabene, Microsoftowi też nie udało się do C#/VB jeszcze wprowadzić ich technologii  "Compiler API" (Roslyn). Wciąż jest na etapie developer preview. 

Pozdrawiam,

Waldek Kot

[Waldek Kot]

W dniu piątek, 4 stycznia 2013 14:31:09 UTC+1 użytkownik Irek Matysiewicz napisał:

Często na zupełnie prościutkich rzeczach manipulowanie bytecodem wymięka.

Zaryzykowałbym jednak stwierdzenie, że na poziomie Java bytecode trudno znaleźć jakikolwiek  mechanizm metaprogramowania, którego nie da się zrealizować (może za wyjątkiem tych meta- transformacji, które łamałyby reguły weryfikatora JVM, np. dotyczące typów). Skoro przytaczane  tu przykłady języków z "dobrym" metaprogramowaniem (Ruby, Groovy i JavaScript - dodałbym tu  pewnie jeszcze Clojure, czyli Lisp) mają swoje implementacje na JVM, to widać, że bytecode Java  jest co najmniej "wystarczający". 

Także wydajnościowo jest raczej dobrze: przykład JRuby, który regularnie bije na  głowę wszystkie inne implementacje Ruby (poczekamy jeszcze na nową implementację JavaScript na  JVM (Rhino), ale też "mówi się", że będzie bardzo dobrze).

Dynamiczne dodawanie/usuwanie metod, pól, zmiana hierarchii klasy czy manipulacja constant pool  (i to bez babrania się z własnymi classloaderami) - ma się pojawić w Java 8. Widziałem też, że ma się pojawić API do opcji kompilatora (np. ustawianie flag kompilacji per metoda) - nie ma szczegółów (więc mogę się mylić) - brzmi jednak jak krok w dobrym kierunku. 

Kto wie może to już  w tym roku ;-)

Pozdrawiam,

Waldek Kot

 

[Waldek Kot]

W dniu sobota, 5 stycznia 2013 11:44:11 UTC+1 użytkownik Irek Matysiewicz napisał:

Java też była przewidziana do metaprogramowania - wraz z JVM i JDK
jest dostarczana refleksja, bajtkod, classloadery, javaagent, JDWP,
annotation processing tool. 

Do tej listy mechanizmów wspierających metaprogramowanie w Java dorzuciłbym jakoś mało  dostrzeganą nowość z Java 7, czyli invokedynamic (JSR-292)... 

Co da się zrobić z invokedynamic ? Mieć niemal dowolną kontrolę nad wywoływaniem metod (także  dostępu do pól, konstruktorów, itp). Można w czasie wykonania określać do czego (np. do jakiej  metody) wywołanie będzie przekierowane, co stanie się z parametrami, wynikiem, itd. Można też to  przekierowanie wielokrotnie zmieniać w czasie wykonywania. Bez potrzeby przeładowywania klasy i  bawienia się classloader'ami. 

Czyli - na poziomie bajtkodu można zrobić to co Irek przytaczał z JavaScriptu: obiekt.metoda =  cośtam. Notabene - kompilator/interpreter JavaScript w takim wywołaniu także wstawi coś w  rodzaju dynamicznego wywołania, gdzie na podstawie klasy, obiektu, dziedziczenia, argumentów i  dowolnego innego czynnika określi docelową metodę. W Rhino to dynamiczne wywołanie jest właśnie  realizowane przez invokedynamic (kompilator wstawi bajtkod invokedynamic). Z powodów  wydajnościowych.

 

Invokedynamic (bajtkod, MethodHandle i APIs) to oczywiście tylko jeden mechanizm (i w sumie  niskopoziomowy), ale dodając do niego choćby AOP i generację kodu, bardzo wiele z tych  wyuzdanych rzeczy staje się prostsze i przy bardzo-akceptowalnej wydajności. Ludzie robią takie  rzeczy jak możliwość dynamicznego otwierania klas, AOP, łączenie kodu z wielu języków,  multimethods, virtual static i sporo innych ciekawostek... Niektóre z tego co Irek napisał też  (a przynajmniej z takim efektem końcowym o jaki, wydaje mi się, chodziło).

Oczywiście, problem z instrukcją dynamicznego wywoływania metod (bajtkod InvokeDynamic) _w  języku_ Java w Java 7 jest taki, że nie jest ona "widoczna" na poziomie języka Java. Składnia  była planowana, ale w kontekście lambda expressions została wycofana (bo doszłoby do dublowania  i większego chaosu). Łatwo ten brak składni oczywiście obejść: generując [a jakże ;-)] bajtkod  invokedynamic, natomiast reszta już jest na poziomie języka Java - API do tworzenia "wskaźników"  do metod, manipulacji nimi, zmiany docelowej metody (tj. tej która będzie wywołana), itp.

Pozdrawiam,

Waldek Kot

[Irek M]

Prawie tekst na artykuł. Co ty robisz w środku nocy? :-)


W dniu 7 stycznia 2013 03:03 użytkownik Waldek Kot
<walde...@gmail.com> napisał:

[Wojciech Erbetowski]

Witam,

Proszę wszystkich obecnych o wypełnienie ankiety.

Od teraz będziemy wyniki zbierali jako organizatorzy, 

więc dzięki Waszym opiniom nie tylko prelegenci mają szansę się poprawić,

ale i organizatorzy dopracować formułę i obsadę spotkań.

Ankieta: http://goo.gl/QtHsv

Pozdrawiam,

Wojtek

[Jacek Laskowski]

2013/1/9 Wojciech Erbetowski <wojc...@erbetowski.pl>:

> Ankieta: http://goo.gl/QtHsv

Done. A dodatkowo jeszcze
http://jlaskowski.blogspot.com/2013/01/po-spotkaniu-warszawa-jug-o.html
oraz https://plus.google.com/photos/117348138300416070551/albums/5831820425939147777
(zachęcam do znakowania siebie ku...uciesze innych, którym do nazwisk
zwykle brakuje twarzy).

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Irek Matysiewicz]

@Waldek:

> Dynamiczne dodawanie/usuwanie metod, pól, zmiana hierarchii klasy czy manipulacja constant pool  (i to bez babrania się z własnymi classloaderami) - ma się pojawić w Java 8.

> Niestety, ale prace nad JSR-269 (dawniej nazywanym Compiler API) zakończyły się na częściowej  implementacji adnotacji (częściowej, bo reszta - też po opóźnieniach [pamiętne "plan A, plan B"]  - ma się pojawić w Java 8).

Masz do tego linki? Bo ja nic nie mogę znaleźć, a to co można znaleźć o JSR-269 to tylko to co jest w Javie 6. Może jak zwykle skończyło się na dyskusjach na blogach i nic z tego nie będzie.

Może z kodem JVM i JDK jest tak jak z jądrem Linuksa - powstał taki moloch że trudno to rozwijać. (http://www.zdnet.com/blog/btl/torvalds-calls-linux-bloated-and-scary-is-he-right-poll/24643 )

[Waldek Kot]

Cześć,

Tutaj jest link do swojsko brzmiących JEP-ów, czyli Java Enhancement Proposals, w tym tego dotyczącego redefinicji klas: http://openjdk.java.net/jeps/159. Jak patrzyłem jakiś czas temu, to wydaje mi się, że przy tym JEP-ie było oznaczenie "8", jak patrzę teraz to nie ma :-). W sumie to koniec tego miesiąca będzie ciekawy, bo to planowany termin  na wersję "feature complete", więc okaże się co jest, a co nie (i czy przypadkiem znowu nie pojawi się plan A i plan B - a tak coś czuję).

Działające implementacje wielu rozszerzeń są, ale czy i kiedy znajdą się w danej wersji, niestety nie ich autorzy decydują... 

Z wieści ludzi z zeszłorocznej JavaOne także wynika, że podczas prezentacji mówiono, że łatwiejsza redefinicja klas ma być. Ale wiesz- nie po to prawnicy napracowali się i stworzyli slajd pt. Disclaimer ;-)

W każdym razie popatrz tutaj na m.in.: http://www.myexpospace.com/JavaOne2012/SessionFiles/CON4469_PDF_4469_0001.pdf, czy też http://www.myexpospace.com/JavaOne2012/SessionFiles/TUT4285_PDF_4285_0001.pdf. 

Co do JSR-269, to m.in. z niego urodził się JSR-308 (czyli więcej "miejsc" w kodzie, które będzie można adnotować). Widać, że to otwieranie dostępu idzie, ale dosyć małymi kroczkami. Dostawać się do całego AST (a nie tylko do klas i sygnatur metod) wciąż bez używania prywatnych API się nie da (chyba ?). Z prywatnymi API można na przykład tak się pobawić: http://scg.unibe.ch/archive/projects/Erni08b.pdf

Z tego powstał między innymi ten przykład z rzymskimi liczbami, który przytoczyłem wcześniej: http://www.iam.unibe.ch/~akuhn/blog/2008/roman-numerals-in-your-java/

Pozdrawiam,

Waldek

PS

Czy jest problem z monolitycznością i bloat'em JVM ? IMHO, jest i to duży (zresztą wzorem Linusa do tego przyznają się sami ludzie od JVM: http://mreinhold.org/blog/massive-monolithic-jdk ;-)). Stąd niestety taka jest tragedia z opóźnieniem po raz kolejny Jigsaw, w którym chodziło nie tylko o oddanie nowych konstrukcji dla języka Java (z czym można się zgodzić, że to jakoś tam trudne i ma wpływ zgodność wsteczną), ale także o modularyzację JVM i uporządkowanie kodu w samym JDK. W przypadku jądra Linux'a jest lepiej, bo jednak jest spore wsparcie do określenia przed jego kompilacją które składniki będą włączone/wyłączone. Jak wiele możnaby osiągnąć widać np. po wreszcie wydanym Java SE Embedded (http://www.oracle.com/technetwork/java/embedded/resources/se-embeddocs/index.html#faq), które m.in. jest o połowę mniejsze. Znacznie więcej API w JDK jest też prywatne (przytaczane API do javac-u choćby). 

W każdym razie tutaj też jest sporo ciekawych informacji (i obrazki warte 1000 słów): http://www.myexpospace.com/JavaOne2012/SessionFiles/CON10844_PDF_10844_0001.pdf

 

[Irek Matysiewicz]

Co do monolityczności, życie pokazuje, że największą popularność osiągają te technologie, w których runtime jest minimalistyczne, a wszystko jest rozszerzalne za pomocą bibliotek.

C/C++ - jest wszędzie, od urządzeń mobilnych po megaserwery, przetrwało próbę czasu. Istnieje od groma kompilatorów języka C++. A co takiego jest w standardowych bibliotekach C++? - STL, wrappery na wywołania systemowe, i niewiele więcej.

JavaScript - też jest wszędzie. Jest wiele implementacji JS. A co takiego jest w standardowych bibliotekach JS? String, Date, Function, Array, Number, i obiekty takie jak window, document czy navigator, i nic więcej.

Szkoda że z Javą jest inaczej. Jest megamoloch. Żeby uruchomić zwykły "Hello world" JVM podobno musi załadować ok. 300 klas. :-(

[Konrad Malawski]

A ile headerów jest includowanych aby zrobić hello world (jak się go zawsze pokazuje, z cout <<) w C++? ;-)

Bez przesady, wszystko ma _jakiś_ startup overhead, czy to w headerach czy w klasach do załadowania.

To akurat nie wpływa zupełnie na rozszerzalność _języka_ poprzez biblioteki...

-- 

Pozdrawiam,

Konrad Malawski

--

[Irek M]

> To akurat nie wpływa zupełnie na rozszerzalność _języka_ poprzez biblioteki...

Miałem na myśli nie tyle "rozszerzalność języka przez biblioteki" ale
przenośność kodu między platformami. "Rozszerzalność przez biblioteki"
to ułatwia, bo biblioteka nie jest wtedy ściśle związana z wirtualną
maszyną czy kompilatorem i łatwiej ją przenieść.

Często jest tak że dana aplikacja ma docierać do jak największego
grona odbiorców, i ma działać pod Windows, Windows 8 Modern UI,
Androidem i iOS. Większość kodu w takich wersjach tej aplikacji na
różne platformy byłaby taka sama, różnica dotyczyłaby szczegółów. W
C++ dobrze napisany kod uruchomisz pod Windowsem, Linuksem, Androidem,
iOS, Windows 8. JavaScript - podobnie.
W Javie - Windows, Linux - OK pod warunkiem że ktoś ma zainstalowane
JRE i zechce mu się ściągać; pod Androidem trzeba pamiętać że brakuje
wielu klas i Android ciągle nie wspiera Javy 7, a tu Java 8 już w
drodze; pod iOS zapewne trzeba będzie przepisać kod (jest co prawda
Codename One, ale ma mocne ograniczenia i trochę kosztuje); pod
Windows 8 - ciągle nie da się pisać aplikacji Windows 8 w Javie, też
trzeba przepisywać. Dla mnie przepisywanie kodu na inny język jest
frustrujące jak cholera, a dla firm oznacza to dodatkowe koszty, bo
trzeba to przepisać a potem jeszcze utrzymywać.
Natomiast gdyby Java była mniej pokręcona, tylko kwestią czasu by było
gdyby ktoś stworzył implementacje Javy na te brakujące platformy.

Oryginalne hasło Javy "write once, run everywhere" dawno już diabli wzięli. :-(

[Adam Lider]

Czesciowo tak, ale Java nigdy do konca nie byla i chyba nie bedzie platforma dla tworzenia aplikacji interfejsu uzytkownika. Interfejsy uzytkownika, aby byly dobre, wymagaja scislej integracji technicznej i koncepcyjnej z system i nie da rady zrobic tego generycznie. Podobnie jest z JS na mobile, gdzie teoretycznie mozesz tworzyc app w JS i wdrazac na roznie platformy. Praktyka jednak pokazuje, ze jak robisz cos bardziej powaznego to klania sie prawda "go native or go home" ;)

Adam.

[Irek M]

> Czesciowo tak, ale Java nigdy do konca nie byla i chyba nie bedzie platforma dla tworzenia aplikacji interfejsu uzytkownika. Interfejsy uzytkownika, aby byly dobre, wymagaja scislej integracji technicznej i koncepcyjnej z system i nie da rady zrobic tego generycznie. Podobnie jest z JS na mobile, gdzie teoretycznie mozesz tworzyc app w JS i wdrazac na roznie platformy. Praktyka jednak pokazuje, ze jak robisz cos bardziej powaznego to klania sie prawda "go native or go home" ;)
>

Faktycznie, obecnie jak chcesz napisać aplikację na iOS czy Windows 8,
to nie pozostaje nic innego jak "go native or go home". Przez lata
było tak też ze AWT/Swingiem, ale przez lata to dopracowali, i gdzieś
od Javy 6 nie widać różnicy między aplikacją w Swingu a aplikacją
natywną. To jest kwestia napisania i dopracowania narzędzi.

[Irek Matysiewicz]

Nie interesuję się bezpieczeństwem, ale dziś natrafiłem na coś takiego na temat Javy 7u11:

- Speaking to the news agency, chief security officer of business security company Rapid7 HD Moore estimated that it could take up to two years for Oracle to fix the flaws found in the version of Java used to browse the Internet -- not taking into consideration any further exploits that are developed within this timeframe. 

(http://www.zdnet.com/security-experts-on-java-fixing-zero-day-exploit-could-take-two-years-7000009756/?s_cid=e539 )

2 lata dla dużej firmy IT - jakie oni muszą mieć bagno w kodzie? A najgorsze jest to, że ta dziura dotyczy rzeczy których mało kto używa (java.lang.invoke i MBeany - http://www.kb.cert.org/vuls/id/625617 ), wystarczyłoby nie dołączać ich do Javy, ale pewnie są tam takie cykliczne zależności, że tak się nie da.

Chyba zacznę się przekwalifikowywać na programistę JavaScript albo C#, bo Java zaczyna mi za mocno śmierdzieć. :-(

[Łukasz Lenart]

W dniu 15 stycznia 2013 14:28 użytkownik Irek Matysiewicz
<iir...@gmail.com> napisał:

> Chyba zacznę się przekwalifikowywać na programistę JavaScript albo C#, bo
> Java zaczyna mi za mocno śmierdzieć. :-(

Chyba wszyscy będziemy wtedy szczęśliwi ;-)


Pozdrawiam
--
Łukasz
mobile +48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/

[Irek M]

W dniu 15 stycznia 2013 15:01 użytkownik Łukasz Lenart
<lukasz...@gmail.com> napisał:

> W dniu 15 stycznia 2013 14:28 użytkownik Irek Matysiewicz
> <iir...@gmail.com> napisał:
>> Chyba zacznę się przekwalifikowywać na programistę JavaScript albo C#, bo
>> Java zaczyna mi za mocno śmierdzieć. :-(
>
> Chyba wszyscy będziemy wtedy szczęśliwi ;-)

Cóż za wymiana uprzejmości. :-)
Pomarudzić zawsze można, a nie zamiatać prawdę pod dywan.

[Wojciech Erbetowski]

W dniu 15 stycznia 2013 15:01 użytkownik Łukasz Lenart <lukasz...@gmail.com> napisał:

Chyba wszyscy będziemy wtedy szczęśliwi ;-)

Ufff wreszcie ktoś to napisał :D

[Łukasz Lenart]

W dniu 15 stycznia 2013 15:04 użytkownik Irek M <iir...@gmail.com> napisał:
> Pomarudzić zawsze można, a nie zamiatać prawdę pod dywan.

Oczywiście, toż jesteśmy Polakami i narzekanie mamy we krwi :-)

[Waldek Kot]

W dniu wtorek, 15 stycznia 2013 14:28:54 UTC+1 użytkownik Irek Matysiewicz napisał:

Nie interesuję się bezpieczeństwem, ale dziś natrafiłem na coś takiego na temat Javy 7u11:

- Speaking to the news agency, chief security officer of business security company Rapid7 HD Moore estimated that it could take up to two years for Oracle to fix the flaws found in the version of Java used to browse the Internet -- not taking into consideration any further exploits that are developed within this timeframe. 

(http://www.zdnet.com/security-experts-on-java-fixing-zero-day-exploit-could-take-two-years-7000009756/?s_cid=e539 )

2 lata dla dużej firmy IT - jakie oni muszą mieć bagno w kodzie? A najgorsze jest to, że ta dziura dotyczy rzeczy których mało kto używa (java.lang.invoke i MBeany - http://www.kb.cert.org/vuls/id/625617 ), wystarczyłoby nie dołączać ich do Javy, ale pewnie są tam takie cykliczne zależności, że tak się nie da.

Też niespecjalnie przyglądam się security Java, ale zaciekawiło mnie to co  napisałeś, że problem jest z java.lang.invoke (czyli InvokeDynamic). W  kontekście tematu tego wątku (czyli Metaprogramowanie w Java) to bardzo fajnie  wyszło :-). Polecam każdemu kto interesuje się tematem metaprogramowania  poczytać o co chodzi w tym zagrożeniu. Akurat użyto InvokeDynamic do niecnego  celu położenia na kolanasecurity Java appletów, ale w sumie to wykorzystana  technika ("refleksji na refleksji") może się przydać do lepszego  metaprogramowania. 

Co ciekawe (przynajmniej ja o tym nie wiedziałem) w tych newsach pojawia się  osoba Adama Gowdiaka, który okazał się naszym ziomkiem z Poznania. Przedstawił  on bardzo fajny opis całego problemu (a także innych problemów z implementacją  Java - polecam m.in. prezentację Adama z ostatniego Devoxx (miodna!). Zobaczcie  na strony http://www.security-explorations.com.

Co do tych 2 lat na naprawę - ciężko to ocenić. Fajnie się to w mediach  sprzedaje (szczególnie takich "dla mas", jak ZDNet), ale trochę wygląda jak na  kopanie leżącego.

W każdym razie wczytując się głębiej, wygląda, że nie należy specjalnie łączyć  tych "2 lat na naprawę" z "dziurą w java.lang.invoke i MBeans". Adam (który  jest ekspertem w temacie) raczej zwraca uwagę na to, że architektura Java i  użyte mechanizmy security są OK, natomiast problemy leżą w implementacji  (zarówno Oracle/Sun, jak i IBM, jak i Apple), olewania własnych rekomendacji,  słabe review (zwłaszcza nowego) kodu pod kątem (często znanych i pozamykanych  wcześniej) zagrożeń.

Np. ten "problem z MBean" w skrócie bierze się stąd, że w Java 7 pewien kawałek  kodu woła konstruktor, pozwalający na ustawianie dosyć istotnej flagi.  Wcześniej (tj. Java 6) wołany był inny konstruktor, który zawsze tę flagę  ustawiał na false. Ktoś to ewidentnie implementacyjne zaniedbanie wykorzystał,  przez co stało się możliwe załadowanie dowolnego kodu, pozwalającego np.  wyłączyć security manager kontrolującego co applet może zrobić.

InvokeDynamic - a właściwie jego część związana z pozyskiwaniem  uchwytów/wskaźników do metod (pól, kontruktorów, itp.), czyli MethodHandles,  nazywana w opisach exploit'ów "nowym API do refleksji" - zostało sprytnie użyte  do oszukania zabezpieczeń w JDK i ogłupienia go, tak aby myślało, że wołającym  kod jest kod z klas systemowych (rt.jar, które jak wiadomo są uprzywilejowane).  Tu też wykorzystano błąd w implementacji MethodHandles (doprawdy trywialny,  ktoś zapomniał wstawić kilku case-ów, pewnie podczas kopiowania kodu z innego  miejsca, tj. z Reflection API). 

Połączenie obydwu sprawiło, że kod wyłączający security manager appletów został  wykonany tak, jakby to robił kod uprzywilejowany. Stało się nieważne czy applet  jest podpisany, czy nie, więc kod appletu ma już prawo robić w systemie całkiem  sporo, uruchamiać inne aplikacje (w tym złośliwy kod).

Widać więc, że problemem nie są złe zależności, zła architektura, a po prostu  ludzkie błędy w implementacji wpuszczone "na produkcję".

Z tego co Adam opisuje, wynika też, że rzeczywiście najwięcej takich  niefrasobliwości jest w Reflection API. Ale chyba trudno wyobrazić sobie  dzisiejsze aplikacje i biblioteki Java bez refleksji, więc Irek pomysł z ich  niedołączaniem odpada ;-).

Pozdrawiam,

Waldek Kot 

[Irek Matysiewicz]

@Wojtek @Maciek:

Chciałbym spytać, dlaczego mówiliście akurat o CGLIB i Plastic jak jest wiele innych bibliotek do bajtkodu?

- CGLIB - nierozwijany; ostatnia wersja sprzed prawie 10 lat

- Plastic - poza Javadocami nie mogę znaleźć żadnej oficjalnej dokumentacji

Nie lepszy JBoss Javassist?


W dniu piątek, 4 stycznia 2013 09:19:08 UTC+1 użytkownik Wojciech Erbetowski napisał:

Cześć!

Zapraszamy gorąco w najbliższy wtorek, 8 stycznia o godzinie 18:00,
na Wydziale Matematyki Informatyki i Mechaniki UW (Banacha 2), w sali 3180 (II piętro).

Temat: Metaprogramowanie w Javie

Prelegentami będą Maciej Jankowski i Wojtek Erbetowski

O wykładzie

Ten wykład to absolutny "must" dla wszystkich developerów związanych z Javą (i w ogóle JVM). Początkujący w temacie dowiedzą się podstaw działania większości Javowych frameworków, czyli o manipulacjach na bytecode. Dowiecie się jak narzędzia są w stanie m. in. utworzyć mocki nagrywające wywołania w testach, czy założyć transakcje na naszą logikę biznesową. Mimo, że zaczniemy od podstaw w prezentacji będzie też kilka ciekawostek i uzupełnień wiedzy dla wytrawnych programistów.

Zaczniemy od wprowadzenia do generowania bytecodu, łącznie z pokazaniem, jak zrobić prostą klasę z niczego w czasie działania aplikacji. Następnie zobaczycie jak opakowują to najpopularniejsze biblioteki w używalny kod, oraz kto (jakie popularne frameworki) z tych narzędzi korzysta. Później już bardzo konkretnie opowiemy o CGLib, który w tej dziedzinie jest de facto standardem, a na sam koniec narzędzie, które powstało stosunkowo niedawno, czyli Plastic.

O prelegentach

Maciej od ośmiu lat programuje w Javie. Od pięciu lat komercyjnie. Nie lubi przetartych szlaków. Pasjonat nietypowych rozwiązań. Obecnie pracuje jako programista Java.

Wojtek jest Wam znany jako jeden z organizatorów warszawskiego JUG. W pracy programuje w Groovym, Scali i Javie, a także w Pythonie. Ostatnio stworzył bibliotekę RoboSpock, przy okazji której podszkolił się z tematu ładowania klas w Javie. Po godzinach już rozgląda się za nowym językiem/technologią.

Sponsor

Nasze spotkanie wspiera firma Polidea, dzięki której będziemy mogli się posilić i posłuchać, czym skuszą nas jako programistów, aby pracować z nimi.

A po spotkaniu

Planowany czas prezentacji wraz z dyskusją to 120 min. Następnie wybieramy się do pobliskiego baru, gdzie będzie możliwość kontynuacji tematu z prelegentami o temacie, lub też poznania innych zapaleńców technologii.

Potwierdź obecność

Abyśmy mogli sprawniej przygotować się do spotkania prosimy jedynie o kliknięcie

czy zamierzasz być na spotkaniu czy też nie (zliczamy kliknięcia). Dzięki!

Informacje o spotkaniach zawsze widoczne w kalendarzu grupy oraz na twitterze.

Zapraszamy!

[Piotr Przybylak]

Bo pewnie o tych mieli coś do powiedzenia a o innych nie :D

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam
Piotr Przybylak

[Maciej Jankowski]

Hej,

> CGLIB - nierozwijany; ostatnia wersja sprzed prawie 10 lat

Wersja 3.0 została wydana 25.05.2012

Ja przygotowałem prezentację o bibliotece Cglib głównie, dlatego, że
prawie wszyscy z niej korzystamy. Np. używając springa musimy
podejmować decyzję o tym czy używamy Jdk proxy czy Cglib. Cglib
zawiera wiele mechanizmów i sztuczek, które warto znać żeby rozumieć,
co dzieje się w kodzie frameworków w których piszemy. Nie starałem się
nikogo zachęcić do pisania czegokolwiek w Cglib, nie starałem się
również przekonywać, że Cglib jest lepszy od javaassist. Po prostu
omówiłem API, bo uważam, że trzeba coś o tym wiedzieć.
Moim zdaniem prezentacja była potrzebna, bo dokumentacja jest dosyć
słaba. Nie znalazłem też żadnego dobrego opisu na blogach.
Przygotowywałem się głównie na podstawie czytania kodu javy i
wygenerowanego bytecodu. Nie każdy ma na to czas i nie każdemu się
chce.
Oczywiście, dla kompletności wypadałoby też omówić javaassist o którym
tylko krótko wspomnieliśmy. Być może sam chciałbyś wnieść coś do
tematu przygotowując prezentację?

Pozdrawiam
Maciek


2013/1/22 Irek Matysiewicz <iir...@gmail.com>:

[Wojciech Erbetowski]

Ja z kolei wybrałem Plastic po fajnej prezentacji Howarda Shipa, jej autora.

Chciałem sprawdzić czy coś zasadniczego się zmienia w tym temacie.

Jak się okazuje niewiele. Po innowację zależy zajrzeć raczej do invokedynamic.

Te i inne odpowiedzi Irku były na wykładzie, jak masz więcej pytań, to może zacznij od obejrzenia ;-)

[Irek M]

>> CGLIB - nierozwijany; ostatnia wersja sprzed prawie 10 lat
> Wersja 3.0 została wydana 25.05.2012

Widać coś teraz ruszyło, mimo że strony projektu nie zaktualizowali
(ciągle jest (c) 2002-2004 - i to mnie zmyliło). Oficjalne Javadocs
na stronie też ciągle odnoszą się do wersji 2.0 beta. Co z tego że
teraz zaktualizowali jak nie powiedzieli o tym światu.
W Hibernate kiedyś dali możliwość wyboru między CGLIB a Javassist
właśnie dlatego że CGLIB był nierozwijany.

No i CGLIB to tylko taka fasadka na ObjectWeb ASM. Bardziej
wypasionych rzeczy w samym CGLIB nie zrobisz.

[Irek M]

> Ja z kolei wybrałem Plastic po fajnej prezentacji Howarda Shipa, jej autora.
> Chciałem sprawdzić czy coś zasadniczego się zmienia w tym temacie.
> Jak się okazuje niewiele. Po innowację zależy zajrzeć raczej do
> invokedynamic.

Czy invokedynamic to jakaś innowacja? To tylko metoda optymalizacji
dla języków dynamicznych. Przed Javą 7 mogłeś zamiast instrukcji
invokedynamic dać kod: mójInvokedynamic(obiekt, "nazwaMetody",
parametr1, ..., parametrN), a mójInvokedynamic by znalazł i wywołał
odpowiednią metodę za pomocą refleksji - efekt podobny (tylko dużo
wolniej).

Jakąś innowacją tu może być tylko minikompilator Javy w Javassist.
Zamiast tam męczyć się z pojedynczymi instrukcjami asemblerze Javy po
prostu wrzucasz prawie normalny kod w Javie.

> Te i inne odpowiedzi Irku były na wykładzie, jak masz więcej pytań, to może
> zacznij od obejrzenia ;-)

Po tym jak Ciebie Jacek trochę zjechał na blogu za tą prezentację,
odechciało mi się oglądać. Wolę zapytać. :-)

[Wojciech Erbetowski]

W dniu 23 stycznia 2013 13:42 użytkownik Irek M <iir...@gmail.com> napisał:

Po tym jak Ciebie Jacek trochę zjechał na blogu za tą prezentację,

odechciało mi się oglądać. Wolę zapytać. :-)

Aha, czyli na wykład nie pójdziesz, po złej opinii nie obejrzysz, ale będziesz na grupie wypytywał co było. Sprytnie.

 

[Mateusz Kaczmarek]

Outsourcing-uje pozyskiwanie wiedzy :P Sprytem bym tego nie nazwał...

--

[Michał Karolik]

Kurcze, Irek - jedna prośba - nie zniechęcaj takich ludzi jak Wojtek którzy naprawdę bardzo dużo dają naszej społeczności... jeśli poświęcają swój czas na przygotowanie prezentacji to choć sprawdź czy jest coś w tym dla Ciebie odpowiedniego

[Michal Margiel]

W dniu 23 stycznia 2013 14:44 użytkownik Michał Karolik
<freakm...@gmail.com> napisał:

> Kurcze, Irek - jedna prośba - nie zniechęcaj takich ludzi jak Wojtek którzy
> naprawdę bardzo dużo dają naszej społeczności...

+1, ale jak wiemy "miecz przeznaczenia ma dwa ostrza.". wiec, moim
zdaniem, musimy tez uwazać żeby ludziom którzy mają inne zdanie niż
my, nie zamykać ust. Nie ma nic gorczego niż otoczyć się klakierami :)

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl
http://www.linkedin.com/in/MichalMargiel

[Irek M]

Ja nie chciałem nikogo zniechęcać. W życiu nie zawsze wszystko dobrze
wychodzi. Nie do końca wyszło - trudno, następnym razem będzie lepiej.
Nie popełnia błędów tylko ten co nic nie robi. Ale na pewno nie można
zamiatać sprawy pod dywan i mówić że wszystko było super, bo nie było.

[Piotr Przybylak]

W dniu 23 stycznia 2013 14:01 użytkownik Irek M <iir...@gmail.com> napisał:
> Ale na pewno nie można
> zamiatać sprawy pod dywan i mówić że wszystko było super, bo nie było.

A tak z ciekawości: co nie było? ;)



--
Pozdrawiam
Piotr Przybylak

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam
Piotr Przybylak

[Jakub Nabrdalik]

On 23.01.2013 15:07, Piotr Przybylak wrote:
> W dniu 23 stycznia 2013 14:01 użytkownik Irek M <iir...@gmail.com> napisał:
>> Ale na pewno nie można
>> zamiatać sprawy pod dywan i mówić że wszystko było super, bo nie było.
>
> A tak z ciekawości: co nie było? ;)

Tego niestety się od Irka nie dowiesz, bo nie oglądał prezentacji :)

Chciałbym zwrócić uwagę, że fakt, że Jacek zjechał prezentację, nie
znaczy, że nie warto jej obejrzeć. Oczekiwania Jacka wobec prezentacji
są szalenie wysokie (pewnie dlatego że Jacek ma większe doświadczenia z
prezentacji od nas wszystkich).

Dla przykładu: Jacek zjechał też 33rd Degree, pisząc:

"I’m not saying that the first day at the 33rd degree conference is a
complete failure as far as the presentations are concerned, but am very
close at doing so."
[http://blog.japila.pl/2012/03/1st-day-at-33rd-degree-conference/]

Przy czym Jacek był na 3 prezentacjach z 21 które odbyły się tego dnia.

Patrząc na review, czy to konferencji, czy to pojedynczej prezentacji,
bierzcie pod uwagę, że to jest perspektywa pewnej konkretnej osoby.


PS: Podaję przykład Jacka, bo akurat Irek się na niego powołał, ale
wszyscy popełniamy ten błąd (ja też, ja też!). Ze wszystkich znanych mi
developerów, tylko Paweł Lipiński, po rozczarowaniu prezentacją, zwykle
mówi: "To nie była prezentacja dla mnie", zamiast "To było totalnie do
dupy, bo mnie nie zainteresowała". Uważam, że to bardzo dojrzałe podejście.


--
Jakub Nabrdalik
blog.solidcraft.eu

[Irek M]

W dniu 23 stycznia 2013 15:07 użytkownik Piotr Przybylak
<piotr.p...@gmail.com> napisał:

> W dniu 23 stycznia 2013 14:01 użytkownik Irek M <iir...@gmail.com> napisał:
>> Ale na pewno nie można
>> zamiatać sprawy pod dywan i mówić że wszystko było super, bo nie było.
>
> A tak z ciekawości: co nie było? ;)

Nie byłem na żywo bo nie jestem w Warszawie, ale obejrzałem fragmenty video.

Chociaż temat ciekawy, prezentacja mnie nie porywa. Ja po chwili
zaczynam się nudzić. Niestety retoryki nie uczą w szkołach.
Kodowanie na żywo. To się nigdy nie udaje, tym bardziej że Java
zawiera wiele boilerplate code i trudniej widzowi wychwycić co jest
istotne w kodzie. A co jakby podczas prezentacji laptopa diabli wzięli
i trzeba by było kończyć prezentację na innym bez zainstalowanych
narzędzi? Wg mnie lepiej po prostu wkleić istotny kod do Power Pointa
i zapomnieć o IDE podczas prezentacji.
Czasem wdawanie się w dyskusje - łatwo utracić główny wątek, a na sali
powstaje szum i już nikt nie wie o co chodzi. Pytania chyba najlepiej
zostawić na koniec.
Wybór CGLIB i Plastica do tej prezentacji też chyba nie był najszczęśliwszy.

To oczywiście moja opinia. Komuś akurat to może się podobać.

[Piotr Przybylak]

W dniu 23 stycznia 2013 14:42 użytkownik Irek M <iir...@gmail.com> napisał:
A co jakby podczas prezentacji laptopa diabli wzięli
> i trzeba by było kończyć prezentację na innym bez zainstalowanych
> narzędzi?

Ja od dziś nie robię żadnych prezentacji!
Zdałem sobie sprawę co by było jakbym dostał zawału w trakcie....
Nie ma nikogo z zajebistością osobistą równą mojej żebą ją ewentulanie
dokończyć.
Także, sorry chłopaki i dziewczyny :/

--
Pozdrawiam
Piotr Przybylak

[Irek M]

> A co jakby podczas prezentacji laptopa diabli wzięli
>> i trzeba by było kończyć prezentację na innym bez zainstalowanych
>> narzędzi?
>
>Ja od dziś nie robię żadnych prezentacji!
>Zdałem sobie sprawę co by było jakbym dostał zawału w trakcie....

Rób prezentacje w tym co się da uruchomić na każdym laptopie, to
zawału nie dostaniesz. :-)

[Tomasz Janczewski]

Mi tam podobała się prezentacja o metaprogramowaniu,

co więcej byłem na niej osobiście i uważam że wypowiadanie się na podstawie czyjejś opinii

i nie do końca obejrzanych filmów nie jest najlepszym pomysłem.

Choć chętnie posłuchałbym też o javassist :-) jeśli Irek masz chęć opowiedzieć o tym...

Co do programowania na żywo to pamiętam taką fajną prezentację o twitter bootstrap i tam

to się udało bardzo fajnie.

Pozdrawiam serdecznie

Tomek 

[Irek M]

> Choć chętnie posłuchałbym też o javassist :-) jeśli Irek masz chęć
> opowiedzieć o tym...

Może kiedyś. Teraz nie jestem w Warszawie.

[Waldek Kot]

W dniu środa, 23 stycznia 2013 13:42:49 UTC+1 użytkownik Irek Matysiewicz napisał:

Czy invokedynamic to jakaś innowacja?

W porównaniu do reszty zmian w Java 7 - tak.

W porównaniu do innych maszyn wirtualnych - tak.

 

To tylko metoda optymalizacji dla języków dynamicznych.

Nie.

 

Przed Javą 7 mogłeś zamiast instrukcji
invokedynamic dać kod: mójInvokedynamic(obiekt, "nazwaMetody",
parametr1, ..., parametrN), a mójInvokedynamic by znalazł i wywołał
odpowiednią metodę za pomocą refleksji - efekt podobny (tylko dużo
wolniej). 

Wszystko da się jakoś zrobić inaczej (dodając nową warstwę, itd.). W tym sensie w IT nie wymyślono niczego nowego od lat 60-tych (?) ;-).

Przed Java 7 robienie takich rzeczy jak uzyskiwanie wskaźników do metod, składanie ich, czy wystawienie "dziury" w kodzie w którą można dynamicznie wpinać własne rzeczy (=patchować kod) wymagało całkiem sporo zachodu. I wydajnościowo też kosztowało dużo - może dlatego tak rzadko w Java wchodzono na to terytorium. Innowacje, których koszt jest bardzo wysoki, są mało praktyczne.

Pozdrawiam,

Waldek Kot 

[Jacek Laskowski]

2013/1/23 Irek M <iir...@gmail.com>:

> No i CGLIB to tylko taka fasadka na ObjectWeb ASM. Bardziej
> wypasionych rzeczy w samym CGLIB nie zrobisz.

Po to właśnie powstał Cglib i nikt tego nie kwestionuje/-wał (była
nawet o tym wzmianka podczas spotkania). Ma być nakładką na asm, abyś
nie musiał schodzić na poziom zanurzenia, na którym ciśnienie rozrywa
płuca :-)

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jacek Laskowski]

2013/1/23 Irek M <iir...@gmail.com>:

> Po tym jak Ciebie Jacek trochę zjechał na blogu za tą prezentację,
> odechciało mi się oglądać. Wolę zapytać. :-)

Oooo tam, zaraz zjechał. Po prostu wyraziłem swoją opinię słowami,
których złożenie sprawiły inny odbiór u Ciebie. Mi się prezentacja nie
podobała, ale czy to oznacza, że Ty nie znalazłbyś tam czegoś dla
siebie? Tego się nie dowiemy bez Twojego zaangażowania.

[Jacek Laskowski]

2013/1/23 Jakub Nabrdalik <jak...@gmail.com>:

> Patrząc na review, czy to konferencji, czy to pojedynczej prezentacji,
> bierzcie pod uwagę, że to jest perspektywa pewnej konkretnej osoby.

+1

Z jednym zastrzeżeniem, przy braku innych recenzji moja jedna mogła
stanowić 100% wszystkich dostępnych, a jak tu nie formować swojego
zdania, kiedy przeczytało się właśnie wszystkie dostępne?! :-)
Podobnie działają recenzje książek, gadżetów elektronicznych, itp.
Stąd apel, aby inni wyrażali swoje zdanie, aby można było coś
konstruktywnego zbudować.

[Jacek Laskowski]

2013/1/23 Irek M <iir...@gmail.com>:

> Wg mnie lepiej po prostu wkleić istotny kod do Power Pointa
> i zapomnieć o IDE podczas prezentacji.

Tego niestety nauczyłem się po latach próbowania z kodowaniem na żywo,
które niestety nigdy nie było tak porywające jak początkowo się mi
wydawało. Najlepiej wtedy nagrać skrinkast.

Ech, jak mi się marzy zobaczyć Irka w akcji podczas prezentacji, aby
to i inne tricki wykorzystać później przy swoich publicznych
występach. Nie będę ukrywał, że podniosłeś poprzeczkę na taki poziom,
że jedno potknięcie i zarzucilibyśmy Cię pomidorami :-)

[Jacek Laskowski]

2013/1/23 Irek M <iir...@gmail.com>:

> Może kiedyś. Teraz nie jestem w Warszawie.

Jeśli wciąż w Polsce, to na pocieszenie/zachętę napiszę, że nie takich
się sprowadzało i dawaliśmy radę. Pociągi nie kursują u Ciebie?!
Hoteli w Warszawie nie ma?! Ogłoś temat, a my zajmiemy się na fundusze
na przyjazd THE Irka!

[Irek M]

> Nie będę ukrywał, że podniosłeś poprzeczkę na taki poziom,
> że jedno potknięcie i zarzucilibyśmy Cię pomidorami :-)

Może bym nie robił takich błędów jak Wojtek, ale na pewno robiłbym
dziesiątki innych, i daleko mi do poziomu twojego czy Wojtka. Na 100%
bym został obrzucony pomidorami. :-)
Po prostu napisałem to co moim zdaniem źle wygląda i tyle.

[Irek Matysiewicz]

Jeszcze wrócę na chwilę do tematu metaprogramowania: czy ktoś z Was używał JBoss AOP?

No bo java.lang.reflect.Proxy czy Spring AOP mało potrafią, od AspectJ czasem zawału można dostać, a Byteman jest nastawiony raczej na testowanie a nie na zwykły kod. Po przejrzeniu dokumentacji JBoss AOP wygląda nieźle, czy może tylko mi się tak wydaje?

[Andrzej Goławski]

Ja się zraziłem jak dowidziałem się, że nie działa z JBoss 7AS. W dodatku projekt nie jest już rozwijany. Wcześniej używałem sporo z JBoss'em 5 i 6 i było całkiem spoko.

W dniu 21 lutego 2013 13:10 użytkownik Irek Matysiewicz <iir...@gmail.com> napisał:

Jeszcze wrócę na chwilę do tematu metaprogramowania: czy ktoś z Was używał JBoss AOP?

No bo java.lang.reflect.Proxy czy Spring AOP mało potrafią, od AspectJ czasem zawału można dostać, a Byteman jest nastawiony raczej na testowanie a nie na zwykły kod. Po przejrzeniu dokumentacji JBoss AOP wygląda nieźle, czy może tylko mi się tak wydaje?

--

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
 

---
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „Warszawa Java User Group (Warszawa JUG)”.
 
Aby anulować subskrypcję tej grupy i przestać otrzymywać z niej wiadomości, wyślij e-maila do warszawa-jug...@googlegroups.com.
Więcej opcji znajdziesz na https://groups.google.com/groups/opt_out
 
 

[Irek M]

Faktycznie, nie zauważyłem że już nierozwijany. Lipa.

[Krzysiek]

+1