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

5

http://jdk7.java.net/

Pobierać i cieszyć się ;)

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) ;)

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.

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.

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.

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ć).

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?

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.

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.

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.)

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