Pobierać i cieszyć się ;)
5
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/viewdoc/download?doi=10.1.1.63.6386&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.org/mod_mbox/lucene-java-user/201107.mbox/%[email protected]%3E
http://mail.openjdk.java.net/pipermail/hotspot-compiler-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/javase/7/docs/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.)
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.
0
A orientujecie się czy coś się zmieniło w nowym wydaniu Javy w kwestii multimediów ? Tj. np można już mp3 odtwarzać (a nie tylko MIDI,AU,WAV) ?? :) Czy może jakoś lepiej Java integruje się z Java FX ?
0
Nie sądzę, żeby kiedyś można było odtwarzać MP3 od tak. Z prostej przyczyny - MP3 nie jest otwartym formatem. Z tego co się orientuje to za komercyjne wykorzystywanie tego formatu trzeba płacić, ale mogę się mylić.
http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues
0
A propos bibliotek JDK7 - czy ktokolwiek z was dokopał się może do możliwości uzyskania przez nową Javę informacji o ograniczeniach wiekowych konta użytkownika w systemie?
Pewnie będę zmuszony dołożyć to przez JNI, ale jeżeli taka możliwość została cichaczem dorzucona do nowej edycji to skróciłoby mi to cierpień z przenośnością. ;)
0
Hell yeah
0
W najnowszym darmowym magazynie SDJ właśnie piszą najciekawsze zmiany w wersji 7.
Oprócz kosmetycznych zmian, ponoć prędkość działania aplikacji się poprawiła.
0
Tylko uważajcie tam żebyście w tej javie 7 jakiejś pętli nie zapętlili za mocno :>
0
Zrobiłem taki mały benchmark: symulacja czasowa układu RLC podłączonego do sinusoidalnego źródła napięcia.
Na stdout była wypisywane liczba obliczonych punktów (wektorów) na sekundę podawana co sekundę oraz czas zmierzony po każdym teście składającym się z 500000 punktów.
java -server, 64bit, ustawienia domyślne, Core i5 @ 2.6 GHz, Windows 7 Professional
Wyniki:
Java 6 update 26:
Simulation performance pts/s: 1
Simulation performance pts/s: 2371
Simulation performance pts/s: 8209
Simulation performance pts/s: 15751
Simulation performance pts/s: 39246
Simulation performance pts/s: 34950
Simulation performance pts/s: 41692
Simulation performance pts/s: 43911
Simulation performance pts/s: 43859
Simulation performance pts/s: 43943
Simulation performance pts/s: 43846
Simulation performance pts/s: 44016
Simulation performance pts/s: 43717
Simulation performance pts/s: 43638
Simulation performance pts/s: 44211
14.240377077 s
Simulation performance pts/s: 42663
Simulation performance pts/s: 38008
Simulation performance pts/s: 41868
Simulation performance pts/s: 42144
Simulation performance pts/s: 42155
Simulation performance pts/s: 41223
Simulation performance pts/s: 42831
Simulation performance pts/s: 42899
Simulation performance pts/s: 42735
Simulation performance pts/s: 42535
Simulation performance pts/s: 42739
Simulation performance pts/s: 42986
11.904730364 s
Simulation performance pts/s: 43221
Simulation performance pts/s: 42826
Simulation performance pts/s: 42642
Simulation performance pts/s: 42495
Simulation performance pts/s: 41560
Simulation performance pts/s: 43457
Simulation performance pts/s: 43849
Simulation performance pts/s: 43600
Simulation performance pts/s: 43591
Simulation performance pts/s: 43566
Simulation performance pts/s: 43566
11.610982254 s
Simulation performance pts/s: 42655
Simulation performance pts/s: 42505
Simulation performance pts/s: 41495
Simulation performance pts/s: 43020
Simulation performance pts/s: 42548
Simulation performance pts/s: 42754
Simulation performance pts/s: 42595
Simulation performance pts/s: 42788
Simulation performance pts/s: 43104
Simulation performance pts/s: 42866
Simulation performance pts/s: 43012
Simulation performance pts/s: 42425
11.740413788 s
Java 7:
Simulation performance pts/s: 1
Simulation performance pts/s: 1256
Simulation performance pts/s: 5383
Simulation performance pts/s: 7478
Simulation performance pts/s: 34277
Simulation performance pts/s: 37591
Simulation performance pts/s: 40700
Simulation performance pts/s: 46821
Simulation performance pts/s: 46547
Simulation performance pts/s: 46541
Simulation performance pts/s: 46179
Simulation performance pts/s: 46861
Simulation performance pts/s: 46541
Simulation performance pts/s: 46902
Simulation performance pts/s: 46799
15.242918744 s
Simulation performance pts/s: 43785
Simulation performance pts/s: 36187
Simulation performance pts/s: 43974
Simulation performance pts/s: 44391
Simulation performance pts/s: 42963
Simulation performance pts/s: 45212
Simulation performance pts/s: 45355
Simulation performance pts/s: 45192
Simulation performance pts/s: 45199
Simulation performance pts/s: 45304
Simulation performance pts/s: 45516
11.381108938 s
Simulation performance pts/s: 45702
Simulation performance pts/s: 45305
Simulation performance pts/s: 45105
Simulation performance pts/s: 45182
Simulation performance pts/s: 45457
Simulation performance pts/s: 46484
Simulation performance pts/s: 46595
Simulation performance pts/s: 46146
Simulation performance pts/s: 46285
Simulation performance pts/s: 45011
Simulation performance pts/s: 46163
10.936893744 s
Simulation performance pts/s: 45238
Simulation performance pts/s: 45005
Simulation performance pts/s: 45240
Simulation performance pts/s: 45281
Simulation performance pts/s: 45204
Simulation performance pts/s: 45014
Simulation performance pts/s: 45714
Simulation performance pts/s: 44167
Simulation performance pts/s: 45297
Simulation performance pts/s: 45350
Simulation performance pts/s: 45421
11.081033702 s
Widać, że jest różnica, ale niewielka, jeśli weźmiemy pod uwagę najlepszy z każdych przebiegów, to wychodzi, że różnica w tym teście jest ok. 6% na korzyść JDK7.
Oczywiście to jest tylko jeden test, więc daleko idących wniosków wyciągać nie należy, ale przynajmniej nie jest to microbenchmark (bo tam jest tego kodu dość dużo). Dzięki temu fajnie widać, jak się HotSpot rozpędza.
Dla -client nie sprawdzę, bo chyba nie ma Javy client dla 64 bitowego systemu (albo u mnie nie działa - nie widzę różnicy między client a server na tym sprzęcie).
Aktualizacja:
Sprawdziłem jak się zachowuje ten nowy wynalazek G1 GC. Na ustawieniach domyślnych, tj. java -server -XX:+UseG1GC jest cienko:
Simulation performance pts/s: 1
Simulation performance pts/s: 1295
Simulation performance pts/s: 4844
Simulation performance pts/s: 7846
Simulation performance pts/s: 19222
Simulation performance pts/s: 33578
Simulation performance pts/s: 28646
Simulation performance pts/s: 32418
Simulation performance pts/s: 35742
Simulation performance pts/s: 35511
Simulation performance pts/s: 35657
Simulation performance pts/s: 35381
Simulation performance pts/s: 35548
Simulation performance pts/s: 35300
Simulation performance pts/s: 35265
Simulation performance pts/s: 35686
Simulation performance pts/s: 35577
Simulation performance pts/s: 35433
18.713036112 s
Simulation performance pts/s: 35626
Simulation performance pts/s: 31817
Simulation performance pts/s: 26987
Simulation performance pts/s: 33687
Simulation performance pts/s: 33649
Simulation performance pts/s: 33937
Simulation performance pts/s: 33599
Simulation performance pts/s: 34024
Simulation performance pts/s: 33848
Simulation performance pts/s: 34004
Simulation performance pts/s: 33901
Simulation performance pts/s: 33971
Simulation performance pts/s: 33661
Simulation performance pts/s: 33726
Simulation performance pts/s: 34312
15.000313021 s
Simulation performance pts/s: 34848
Simulation performance pts/s: 34568
Simulation performance pts/s: 34249
Simulation performance pts/s: 34109
Simulation performance pts/s: 33957
Simulation performance pts/s: 34085
Simulation performance pts/s: 34517
Simulation performance pts/s: 34934
Simulation performance pts/s: 34857
Simulation performance pts/s: 34741
Simulation performance pts/s: 35029
Simulation performance pts/s: 35186
Simulation performance pts/s: 34651
Simulation performance pts/s: 34452
14.485670516 s
Dobre ponad 20% wolniej. Dodanie większego heapa wcale nie pomaga. Być może trzeba ten G1 trochę inaczej ręcznie ustawić.
Inaczej, jeżeli GC daje 20% narzut, to ja za taki GC dziękuję. Na CMSie narzut GC nie przekracza 1% (wg. VisualVM).
0
Jak już mówimy o zmianach w Java 7 to niedawno ukazał się krótki artykuł na ten temat, dolepiam więc linka Tutaj . Całkiem ciekawe, ale co tak na prawde sie zmieniło to zobaczymy przy kodzeniu :D
0
O jakiej chmurze obliczeniowej jest mowa w planowanym Java SE8 ?
0
Chodzi chyba o to: http://en.wikipedia.org/wiki/Multitenancy , tzn odpalanie wielu Javowych procesów na jednej instancji JVM. Tak mi się wydaje przynajmniej.
0
wiecie może jak podpiąć nowe jdk pod eclipse? Zainstalowałem javke, zaktualizowałem ide, ale jak testowo robię switcha na stringach to podkreśla i erroruje :/
0
Window => Preferences => Java => Instaled JREs. Dalej sobie poradzisz.
0
Dokumentacja API Java 7 jest podana jako URL. Jednak jeżeli ktoś ma internet bezprzewodowy z limitem transferu lub po prostu podłe, albo bardzo podłe połączenie i chce mieć tę dokumentację w swoim Eclipse, Netbeans lub po prostu lokalnie w przeglądarce, to podaję niżej najprostszy z możliwych przepis na upichcenie takiego zipa.
Tutaj przy pomocy Netbeans:
- Z katalogu root JDK 7 bierzęmy plik src.zip i wypakowujemy całą jego zawartość do jakiegoś katalogu
- Z tego katalogu usuwamy katalogi com, sunw oraz launcher wraz ze wszystkimi ich podkatalogami.
- Tworzymy w NB nowy projekt "Java Project with Existing Sources". Nazywamy go jakoś sensownie np. Java 7 API.
- Kiedy pojawi się w kreatorze wybór listy katalogów źródłowych oraz testowych, niczego nie dodajemy i kończymy tworzenie projektu.
- We właściwościach utworzonego projektu Build/Compiling wyłączamy opcję "Compile on Save", żeby nie marnować czasu i nie tworzyć ton śmieci na dysku.
- W opcjach Build/Documenting ustawiamy Browser Windows Title najlepiej tak samo jak nazywa się Java API 7 online. Pod "Generate:" zaznaczymy wszystkie lub wybrane rodzaje wygenerowanych plików html.
- W "Additional Javadoc Options" ustawiamy: "-J-Xmx850m". Na Windows XP powinno wystarczyć "-J-Xmx750m" jeżeli ktoś nie ma zbyt wiele pamięci fizycznej.
- Odhaczamy "Preview Generated Javadoc", żeby nie marnować czasu.
- Przechodzimy do pozycji sources, gdzie ustawiamy jeden katalog ze źródłami jako katalog gdzie wcześniej wypakowaliśmy i okroiliśmy src.zip.
- Zatwierdzamy zmianę projektu i zaczynamy robić na drutach, żeby NB spokojnie przemielił wszystkie te źródła w swojej bazie.
- Na projekcie wybieramy z menu kontekstowego "Generate Javadoc", nie przejmujemy się 1,5k ostrzeżeń o nieznanych tagach bo w tym czasie kończymy sweter i nie lampimy się bez potrzeby na okienko Output skoro mamy lepiej widoczną czerwoną lampkę aktywności dysku.
- Kiedy w okienku Output zobaczymy wreszcie zakończenie generowania. Przechodzimy się do katalogu projektu, w nim do katalogu dist, gdzie powinien sobie leżeć śliczny katalog javadoc.
- Katalog ów przenosimy do jakiegoś bezpiecznego miejsca. Odpalamy jakiegoś zipa i pakujemy go do archiwum o treściwej nazwie (na przykład docs.zip dla równowagi z src.zip) z maksymalną kompresją. Archiwum przenosimy do katalogu JDK. Projekt w Netbeans kasujemy wraz z katalogiem z wypreparowanymi źródłami.
Jeżeli do przeglądania (np. kontekstowego) będziemy używać wyłącznie IDE, to katalog javadoc z wygenerowanymi plikami html można sobie skasować (dużo bardzo małych plików) i pozostać tylko przy zipie.
Aby podłączyć taką dokumentację w Netbeans trzeba wejść do menu Tools/Java Platforms, wybrać JDK 1.7, obok zakładkę Javadoc (Classes i Sources są już zazwyczaj poprawnie wypełnione), wybrać "Add Zip/Folder..." i dodać utworzony plik docs.zip.
Po zamknięciu JPM możemy przełączyć notebooka na tryb samolotowy, przejść do swojego wypasionego fotela w klasie business i spokojnie pisać soft aż do przerwy na miskę lub lądowania. ;)
ps. Post powstał ponieważ download dokumentacji API JDK 7 przekierowywał mnie wciąż na wersję online. Obecnie udało mi się wreszcie ściągnąć wygenerowane API.
0
Wrzuciłem na przekleja oficjalne API offline do Javy 7, ostatnie które udało mi się zachować na dysku: http://www.przeklej.pl/plik/jdk-7-fcs-bin-b147-apidocs-27-jun-2011-7z-0032a69k8bq4
0
Zauważyłem dzisiaj wielką zaletę Javy 7, na mojej maszynie znów działają aplety w Operze i Firefoksie. Otwiera się również konsola Javy w tych przeglądarkach. Aplety w Firefoksie przestały działać począwszy od wersji 3.53, na forum Mozilli spotkałem się z mocnym niedowierzaniem, rady które dostawałem (reinstalacja, nowy profil) nie pomagały. Pomagała instalacja wcześniejszej wersji (3.51).