JDK 7 właśnie zostało wydane!

Odpowiedz Nowy wątek
2011-07-28 20:21
5

http://jdk7.java.net/

Pobierać i cieszyć się ;)


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Pokaż pozostałe 6 komentarzy
no to Wibowit się do tego nie nadaje bo od razu wyciągnie scale z rękawa i tyle z porównania javy i cpp :D - byku_guzio 2011-07-29 01:48
Nie ma to jak framework we frameworku ;p - O_o 2011-07-29 01:56
Benchmarki zwykle nie odzwierciedlają rzeczywistego zastosowania, a w rzeczywistych zastosowaniach nigdy jeszcze nie zdarzyło mi się, aby Java była przyczyną zbyt powolnego działania aplikacji. Np. nasz silnik symulatora elektroniki napisany w Scali działa znacznie szybciej niż kod SPICE 3 napisany w C, więc Java/Scala na pewno należą do kategorii szybkich języków, tak jak C++ i C. - Krolik 2011-07-29 09:44
Cieszcie się, cieszcie :> Btw. O_o -> Java przeprowadza optymalizacje o których C++ owcom się nawet nie śni... A C# (jeszcze) nie potrafi. - msm 2011-08-06 21:36
Ciekawe optymalizacje to się zaczną jak zoptymalizują invokedynamic w sposób opisany tutaj: http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem. Dzięki temu wszędzie tam, gdzie C++ dla osiągnięcia pełnej wydajności trzeba było używać szablonów i rezygnować z powolnych wywołań wirtualnych, w Javie wystarczy pozostawić wirtualne tak jak były, JVM dokona specjalizacji ze względu na typ automatycznie, ale lepiej niż kompilatory szablonów w C++ bo z mniejszym narzutem na rozmiar kodu. - Krolik 2011-08-07 19:14

Pozostało 580 znaków

2011-07-28 21:49
0

O_o muszę przyznać, że się nie spodziewałem dotrzymania terminu. Jak zapowiedzieli wydanie 28go tak wyszło. Jest coś nowego poza nio, dodatkowych rzeczy związanych z concurrency i switch'a obsługującego stringi? Nie mam jakoś teraz siły szukać info o tym ;)

//edit: dobra, nie było pytania:
http://openjdk.java.net/projects/jdk7/features/

//edit2: i już nawet zapowiedź odnośnie JDK 8: podoba mi się "JSR 296: Swing application framework" - NetBeans Platform nie bardzo się nadaje do drobnych aplikacji(jest raczej wytaczaniem baterii dział na muche) ;)


edytowany 4x, ostatnio: byku_guzio, 2011-07-28 21:55
Pokaż pozostałe 11 komentarzy
Ja C++ starałem się omijać jak najdłużej, znajomość gołego C bardzo się przy tym przydawała :D - O_o 2011-07-28 22:19
Pomijając jakąś krótką przygodę z pascalem to c++ był moim pierwszym językiem(i niestety za długo jedynym - przez to uważałem, że jest osom, wypas i w ogóle najlepszy <facepalm>) no ale początki były grube lata temu :) - byku_guzio 2011-07-28 22:26
Każdy ma jakies wady :> - O_o 2011-07-28 22:29
"W JDK 7 domyślnie jest G1 GC zamiast dotychczasowego CMS GC" - zwariowali?! Jeszcze nie widziałem aplikacji, w której G1 działałby lepiej niż CMS. - Krolik 2011-07-29 09:54

Pozostało 580 znaków

2011-07-28 22:40
0

ROFL, nie mogę własnego postu zedytować. Tak więc, na testy trzeba poczekać. Tu: http://citeseerx.ist.psu.edu/[...]386&rep=rep1&type=pdf jest bardzo stary test G1 GC, wynika z niego, że pauzy są znacznie mniejsze niż w przypadku CMS GC. Poza tym możecie sobie wyguglować frazę "dual pivot quicksort", czyli wariacja quicksorta, która będzie użyta w JDK 7. Wydaje mi się, że kilka eksperymentalnych (tzn o takim statusie) rzeczy z JDK 6 będzie domyślnie włączone w JDK 7.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Pauzy są mniejsze, ale G1 jest bardzo łatwo wtrącić w taki tryb pracy, że co 0.001 sekundy robi pauzy trwające 0.002 sekundy. Poza tym dla wielu aplikacji G1 wymaga bardzo dużego narzutu pamięciowego, inaczej powoduje znaczny narzut CPU. - Krolik 2011-07-29 09:56

Pozostało 580 znaków

2011-07-28 22:45
0

"wynika z niego, że pauzy są znacznie mniejsze niż w przypadku"
to dobrze. Chociaż imho w Javie nie tyle jest ważna optymalizacja co maksymalna wysokopoziomowość. Mogę się okrutnie mylić(brak doświadczenia - ot tak obserwacja), ale wydaje mi się, że w zastosowaniach w których używa się javy wydajność nie jest priorytetem: w systemach real-time i tak nie bardzo się nadaje, a w systemach biznesowych, czy dla zwykłych użyszkodników się sprawdza.


Od dawna wiadomo że wydajności to tu nie ma więc jako zaletę trzeba wypychać wysokopoziomowość ;) - O_o 2011-07-28 22:51
no ale chyba twórcy javy nie myśleli sobie(te kilka lat temu jak to ustrojstwo tworzyli), że język na tak wysokim poziomie dorówna wydajnością językom aka c/c++. Po prostu inna domena problemów jest przeznaczona dla tych języków. I chyba tak powinno być w myśl zasady: co jest do wszystkiego jest do niczego :) - byku_guzio 2011-07-28 22:55

Pozostało 580 znaków

2011-07-28 22:56
0

Java jest kilkadziesiąt procent wolniejsza od C++, więc aby uzyskać taką samą wydajność wystarczy podwoić liczbę procesorów. Stara prawda głosi, że koszt sprzętu jest nieporównywalnie niższy niż koszt programistów, więc i tak biznes wychodził by na plus. Javy się jednak w systemach real-time zbyt często nie używa ponieważ JVMy zżerają kilkanaście/ kilkadziesiąt MB RAMu na starcie, a do wydajnej pracy wymagają wielokrotnie więcej oraz dlatego (to jest największy powód), że oprócz kilku pewnie eksperymentalnych i płatnych JVMów, żaden nie daje ścisłej gwarancji na długość pauzy przy odśmiecaniu. Ciężko więc stosować Javę np w komputerach pokładowych samochodów.

O_o:
Podaj mi jakiś problem w którym 100 % Javowy kod jest drastycznie wolniejszy od 100 % C++owego kodu.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2011-07-28 22:59
Problem gdzie Java jest wolniejsza hmmm, uruchomienie się choćy :> Nie robię w Dżabie więc nic niekawego nie podam ale sam chyba znasz takich przykładów sporo ;) Ja to tak tylko z pozycji obserwatora odczuwam przymuły. - O_o 2011-07-28 23:08
dopiero odpalenie aplikacji w netbeans platform zajmuje czas. To jest masakra :D - byku_guzio 2011-07-29 00:31
No ale z drugiej strony programy w C++ są zwykle mniej funkcjonalne. No i JVM dostarcza mnóstwa własnych mechanizmów, dublujących niejako te, które są w systemie czyli start JVM to tak jakby start systemu. Tu: http://www.excelsior-usa.com/java-startup-time.html jest małe porównanie czasu odpalania, chociaż nie wiem jak się prezentuje funkcjonalność RSSOwl na tle konkurencji. Po odpaleniu jednak aplikacje Javowe dają radę :) - Wibowit 2011-07-29 00:58
Dodatkowym problemem z Dżabą są jej programiści, platforma ta odczuwa "efekt Delphi", jak już znajde jakiś program w javie który mi się przydaje ( ostatnio kalkulator do funkcji wielu zmiennych z wizualizacją ) to po pierwszym szoku "to działa! I nawet da się używać!" nadchodzą pierwsze bugi i wkrótce nieunikniony "division by zero" ... - O_o 2011-07-29 01:09
Tia, bo liby w C++, to błędów nie mają... W Javie przynajmniej dostajesz w takiej sytuacji pełny stacktace a nie "segmentation fault". Średnia jakość programistów jest podobna - tzn. większość jest kiepska, i nie ma znaczenia czy C++ czy Java. Większość się uczy C++/Javy/C# bo musi na studiach, albo bo liczą na kasę, a nie dlatego że lubią. - Krolik 2011-07-29 10:50

Pozostało 580 znaków

2011-07-29 00:31
0

Tyle, że ta słabsza wydajność nie jest raczej problemem. Przynajmniej w zwykłych biznesowych aplikacjach. To jest po prostu odpowiedni wybór języka biorąc pod uwagę koszt kodu, sprzętu i wymagania, ograniczenia.
W jednym przypadku lepiej się sprawdzi Java w innym C++, a w innym jeszcze coś innego - i to by było na tyle z filozofii i fanboizmu ;)

Ostatnio pisałem coś w c++ co raczej w javie byłoby ciężej zrobić. Ot taka drobna app z 5 kontrolkami na krzyż, ale musiała wywoływać funkcje czystego WinAPI - zdenerwowałem się na typa w robocie, bo od roku czekaliśmy na poprawki do aplikacji dla działu helpdesk, to sam dopisałem funkcjonalności(typowi nawet się głupiego zapytania do bazy nie chciało poprawić).


Forumowy kolega lipkerson zajmuje się zabawą w WinAPI z poziomu Javy i dobrze mu to idzie. Choć niekoniecznie jest to dobry sposób postępowania. - Wibowit 2011-07-29 00:59
Zło. Wołanie funkcji natywnych z frameworku jest z definicji złe. Ale że czasem trzeba to inna sprawa ;) - O_o 2011-07-29 01:10
No ale jak tych funkcji masz wywołać 3 na krzyż(jakieś findwindow, sendmessage...) to zaprzęganie do tego takiego JNI to przesada. ;) - byku_guzio 2011-07-29 01:43
Niekiedy ianczej trudno to zrobić, np pobranie bramy domyślnej z jakiegoś powodu w żabie nie występuje x.x - O_o 2011-07-29 01:51

Pozostało 580 znaków

2011-07-29 01:17
O_o
0

W tym porównaniu szybkości uruchamiania jedna aplikacja jest zoptymalizowana.
Z tego co wyczytałem to jest to optymalizacja pod daną platformę więc wyklucza możliwość przenoszenia, zgadza się? Cięzko mi się połapać trochę w informacjach o Javie stąd kolejne pytanko: Jest to optymalizacja pod daną rodzinę procesorów czy konkretnie dany sprzęt? Słyszałem kiedyś pogłoski że daje radę w tym zoptymalizować pod konkretny model ale tematu jakoś nie zgłębiałem.

Masz może jakiś pdfik dla laika w dziedzinie Dżaby który opisał by takie ciekawostki w miarę przystępnie?

O! Bo ciężko mi coś użytecznego wygoglować, jest jakaś przystępna paczuszka pozwalająca na normalną obsługe ekranów dotykowych w J2ME czy ni hu hu?


O̾..͠o
edytowany 1x, ostatnio: O_o, 2011-07-29 01:22

Pozostało 580 znaków

2011-07-29 11:22
::.
0

http://mail-archives.apache.o[...][email protected]%3E
http://mail.openjdk.java.net/[...]ler-dev/2011-July/005971.html

Bardzo podoba mi sie zdanie:
"(...) it contains hotspot compiler optimizations, which miscompile some loops (...)"

Prawdopodobnie jest wiele kodu ktory na jdk7 kleka. Miejmy nadzieje ze bug zostanie napawiony szybciej niz poprzedni glosny bug z parsowaniem flatow ktory sie nie konczyl bo wpadal w nieskonczona petle.

Pozostało 580 znaków

2011-07-29 11:38
0

O_o:
Gdzieś ty takie rzeczy wyczytał? Kod Javowy jest kompilowany do bajtkodu, który jest w zasadzie kodem natywnym dla pewnej maszyny i są nawet procesory, które wykonują bezpośrednio bajtkod Javowy. Tyle, że to rozwiązania niszowe i eksperymentalne, wykonywanie bajkodu wprost jest i będzie wolne. Dlatego tworzy się maszyny wirtualne, które są tak jakby emulatorami tego Javowego procesora. Owa maszyna wirtualna tłumaczy bajtkod na kod natywny procesora na której jest odpalana i ma za zadanie jak najbardziej zoptymalizować kod pod ten procesor. Nie słyszałem natomiast o optymalizacji bajtkodu pod jakiś procesor :P

"W JDK 7 domyślnie jest G1 GC zamiast dotychczasowego CMS GC" - zwariowali?! Jeszcze nie widziałem aplikacji, w której G1 działałby lepiej niż CMS.

Masz jakieś benche? W sumie to nie jest pewne, czy od razu G1 zastąpi CMS, chyba przesunęli terminy i G1 będzie domyślny w którymś tam updacie. Tak przynajmniej wynika z: http://www.slideshare.net/myfear/introducing-java-7 (slajd 42)
http://download.oracle.com/ja[...]s/technotes/guides/vm/G1.html - tu też jest napisane, że G1 ma docelowo zastąpić CMS w JDK 7.

::.
Widać, że zapomnieli zatrudnić Egona.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2011-07-29 11:42
Pisałem że w Javie to ja noob jestem ;) Dlatego się pytam speców ;) - O_o 2011-07-29 16:23
JVM potrafi wykonywać wiele optymalizacji, których kompilatory C i C++ nie potrafią - np. inline'ować wywołania wirtualne (niebawem również megamorficzne), albo usuwać niepotrzebną synchronizację wątków. Stąd bardzo trudno stwierdzić, co jest szybsze - prosty kod benchmarków raczej nie używa synchronizacji czy wirtualnych wywołań, stąd Java dostaje trochę w plecy, ale w realnym, dużym kodzie, gdzie liczy się odpowiedni poziom abstrakcji, te optymalizacje mają duży wpływ. Porównaj sobie np, wydajność javowego H2 i C++ MySQL, MySQL dostaje bęcki. - Krolik 2011-07-30 11:50

Pozostało 580 znaków

2011-07-29 12:47
1

Tak, mam benche swojej aplikacji (silnik numeryczny na ok. 5 tys. linii kodu) - po włączeniu G1 GC, o ile nie dam jej 100% więcej RAMu, chodzi wyraźnie wolniej.
Na CMS nie widać spowolnienia, nawet jeśli sterta jest tylko o 30% większa niż rozmiar żywych danych. Poza tym G1 GC ma tę samą wadę co CMS, i tak wcześniej czy później będzie musiał zrobić full-gc, to że to nastąpi później lub z mniejszym prawdopodobieństwem niż w przypadku CMS to żadna pociecha (a zapewne nastąpi, ponieważ blokujący kod full-gc nadal tam jest w G1, jeśli ten kod nie miałby być nigdy wywołany to po co tam jest?). Mimo to, teraz jak wyszło JDK7 dam szanse G1 jeszcze raz i wrzuce jakieś benchmarki.

StackOverflow napisał(a)

I've been testing it out with a heavy application: 60-70GB allocated to heap, with 20-50GB in use at any time. With these sorts of applications, it's an understatement to say that your mileage may vary. I'm running JDK 1.6_22 on Linux. The minor versions are important-- before about 1.6_20, there were bugs in G1 that caused random NullPointerExceptions.

I've found that it is very good at keeping within the pause target you give it most of the time. The default appears to be a 100ms (0.1 second) pause, and I've been telling it to do half that (-XX:MaxGCPauseMillis=50). However, once it gets really low on memory, it panics and does a full stop-the-world garbage collection. With 65GB, that takes between 30 seconds and 2 minutes. (The number of CPUs probably doesn't make a difference; it's probably limited by the bus speed.)

edytowany 4x, ostatnio: Krolik, 2011-07-29 12:59
Właśnie wyczytałem przed godzinką, że G1 nie fragmentuje wolnej pamięci tak jak CMS, więc być może nie trzeba w ogóle full-gc robić. - Wibowit 2011-07-29 12:51
To po co jest tam ten kod? G1 nie fragmentuje, ale ma inne problemy, patrz cytat z SO. - Krolik 2011-07-29 12:57
Może jakiś tuning parametrów by pomógł. Albo w kolejnym updacie to rozwiążą. - Wibowit 2011-07-29 13:10
Może i by pomógł, ale nie zmieni to faktu, że fallback do STW nadal tam jest. Oracle się musi trochę lepiej postarać, bo inaczej nikt nie będzie poważnie Javy traktował do zastosowań wymagających 50GB lub więcej RAM. Ja chcę GC bez ani jednej linijki kodu blokującego wątki aplikacji! Azul takie oferuje i chodzi miodzio (tylko kosztuje $$$), więc niech Oracle nie mydli oczu, że G1 to takie rewelacyjne osiągnięcie, bo technologicznie jest w tyle. :P - Krolik 2011-07-30 11:01
A jak z wydajnością tego Azul JVM? G1 jest soft real-time po to, aby nie zmniejszyć drastycznie wydajności (docelowo oczywiście ma tak być). - Wibowit 2011-07-30 12:34
Wydajność jest bardzo zbliżona do CMS - bo to jest normalny dwugeneracyjny mark & compact GC, tyle że działający ciągle, bez zatrzymań, na osobnym rdzeniu (rdzeniach). - Krolik 2011-07-30 12:52

Pozostało 580 znaków

2011-08-01 17:23
0

Z nowości można jeszcze wymienić reakcję na rolkę poziomego przewijania myszy:D Java 6 nie reagował w ogóle, natomiast Java 7 przy przewijaniu poziomym ciągle narzeka:
MEvent. CASE!

Problem jest w nowym java.awt.MouseEvent. Dokopałem się w źródłach, że tam poza oznaczeniem wyjęcia buttonu z modyfikatorów, czy co to miało tam być, jest zwyczajny println do stdout. Sam MouseEvent też dość wydłużony: 891 linii do 1171. Fragment odpowiedzialny za sypanie niewiele mówiącego kodu (jeden z konstruktorów MouseEvent, linia 761):

            if (getModifiersEx() != 0) { //There is at least one more button in a pressed state.
                if (id == MouseEvent.MOUSE_RELEASED || id == MouseEvent.MOUSE_CLICKED){
                    System.out.println("MEvent. CASE!");
                    shouldExcludeButtonFromExtModifiers = true;
                }
            }

Niby drobnostka, ale trochę to utrudni debugowanie stdouta czasami, mam nadzieję że to zakomentują, albo usuną.

Co prawda myszki z poziomą rolką nie mam (są one dla mnie trochę niewygodne i niepraktyczne), ale na touchpadzie mam włączone poziome przewijanie, które w firefoxie i innych programach działa normalnie.

Ciekawe ile jeszcze takich baboli jest w kodzie nowej siódemki... :\ - Olamagato 2011-08-01 18:02

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0