[java] Java 6.0 (Mustang) wie gebruikt het al?

[Verwijderd]

Ondanks het feit dat nog bijna niemand Java 5 lijkt te gebruiken, schiet Java 6 ook al weer een eind op. Ik heb vanavond eens een snapshot build gedownload en geinstalleerd. Ik verwachte een snelle crash, maar dat viel behoorlijk mee. Sterker nog, zelfs de grotere applicaties leken na een snelle test gewoon te draaien. Zelfs the mother of all critical apps (Eclipse) starte op en ik kon er concreet dingen mee doen zonder een crash te zien.

M.a.w. de VM lijkt in deze hele prille fase toch al behoorlijk stabiel. Ik heb het dan nog niet over het gebruik van nieuwe library classes, maar gewoon de stabiliteit van de VM opzich.

Zijn er meer mensen hier die al wat met 6.0 hebben gespeeld?

[.oisyn]

Kon een list met nieuwe features er verder niet meer van af?

[Macros]

Ik denk dat die lijst nog niet compleet is
Ik heb het al een keer kort geprobeert een aantal weken geleden. Werkte goed, alleen ik wilde weten het al betere hotswap ondersteunde, wat het niet deed. Ik moet code schrijven dat onder Windows, Linux en MacOS X moet werken, dus dan mag ik niet verder dan Java 5, al denk ik niet dat de code erg verschilt tussen 5 en 6.

[Alarmnummer]

Ik geloof dat in Java 6 geen nieuwe taalfeatures meer komen (althans niet in de hoeveelheid zoals bij java 5) maar voornamelijk gericht is op api uitbreidingen/verbeteringen en vm verbeteringen. Ik heb het zelf nog niet geprobeerd en ik denk ook niet dat dat er voorlopig van zal komen.

[ Voor 20% gewijzigd door Alarmnummer op 30-11-2005 09:15 ]

[momania]

Hier een kleine opsomming van (geplande) verbeteringen in java 6: http://java.sun.com/devel...ktop/Mustang_build39.html

---

Vooral in de core vind ik de volgende wel interessant:

Many developers will recognize this requirement from the JDC bug parade. Finally, java.io.File is updated with methods to determine both partition sizes and usage and the amount of free space on each partition.

Voor applicaties die veel I/O produceren is dit wel een hele interessante. Vind het al verbazend genoeg dat dit nu pas beschikbaar gaat worden.

---

Op security gebied is de 'Smart Card I/O API' een leuke toevoeging, aangezien het gebruik van smart cards volgens mij steeds populairder wordt bij grote bedrijven, icm met single-sign-on systemen.

---

En nog in development:

JSR 199, the Java Compiler API, will define a framework for compiling source files from within applications.

Zeer interessant om volgens mij ook real-time applicaties te kunnen updaten.

[edit]

Hier nog een overzicht van verschillende builds met changelist:
https://mustang.dev.java....ocumentList?folderID=2855

[ Voor 8% gewijzigd door momania op 30-11-2005 09:53 ]

[Eelke Spaak]

Ik heb op java.net laatst gelezen (maar kan het nu niet meer terugvinden) dat de javac compiler meer werk gaat overnemen van de JIT compiler. Dit zorgt uiteraard voor een flink snellere Client VM.

Edit: het gaat om de Type Checking Verifier, en dit is het artikel.

[ Voor 25% gewijzigd door Eelke Spaak op 30-11-2005 10:59 ]

[.oisyn]

momania schreef op woensdag 30 november 2005 @ 09:51:
Zeer interessant om volgens mij ook real-time applicaties te kunnen updaten.

Heeft dat niet altijd al gekund? Ik dacht dat de compiler gewoon in de standaard class tree zat.

[ Voor 13% gewijzigd door .oisyn op 30-11-2005 10:56 ]

[Verwijderd]

.oisyn schreef op woensdag 30 november 2005 @ 10:56:
[...]

Heeft dat niet altijd al gekund? Ik dacht dat de compiler gewoon in de standaard class tree zat.

java.lang.Compiler
The Compiler class is provided to support Java-to-native-code compilers and related services. By design, the Compiler class does nothing; it serves as a placeholder for a JIT compiler implementation.

nee dus

[mbravenboer]

Een ander interessant onderdeel is de standaardisatie van het annotation processing tool, wat al als preview beschikbaar was in 5.0. apt is nu geintegreerd in javac en de interne representatie van Java source is een stuk beter uitgewerkt, waardoor het mogelijk moet worden om compiler plugins te maken die ook op compilers van andere vendors kunnen werken. Een hele interessante ontwikkeling!

[-Lars-]

Ik, als beginner, hoop dat de problemen met de Windows (XP) look&feel eindelijk fatsoenlijk worden aangepakt (Will Mutsang Obsolete WinLAF? en Update: Desktop Java Features in Mustang). Het is gewoon vaag dat je bent aangewezen op aparte pakketen (winlaf, jgoodies, etcetera) om in Windows bijvoorbeeld niet telkens te zitten klikken op een gedisabled tekstveld (winlaf issue 95).

[misfire]

Java 6 krijgt zeker mijn aandacht. Mustang lijkt een stevige opruimactie te zijn van Sun: weinig grote nieuwe veranderingen, maar vooral de losse eindjes in de bestaande API's, tooling en virtual machine aanpakken. Ik vind dat erg positief, want er zijn losse eindjes genoeg, en de acceptatie van Java 5 is toch nog relatief laag. Er zijn denk ik veel bedrijven die Java 5 lekker overslaan en pas de overstap zullen maken bij Java 6. Tegen die tijd is de markt weer bij qua opleidingen, tooling, certificeringen en ervaring, en zullen de Java Enterprise 5 producten beginnen te landen.

Voor Java 5 is de geautomatiseerde testsuite flink uitgebreid om compatibiliteitsproblemen met eerdere versies van Java te beperken. Het mooie hieraan is dat ze nu voor Java 6 flink kunnen sleutelen aan de virtual machine, zonder bang te hoeven zijn dat straks alles kapot gaat. Eén van de meest interessante ontwikkelingen vind ik "escape analysis" (zie dit en dit artikel). Dat zorgt voor een aantal flinke performance optimalisaties, en laat je als programmeur focussen op het schrijven van veilige, onderhoudbare code. Dankzij deze en andere optimalisaties laat Java 6 significant betere cijfers zien, en betere performance is altijd een goede nieuwe feature.

[Verwijderd]

misfire schreef op woensdag 30 november 2005 @ 20:39:
Java 6 krijgt zeker mijn aandacht. Mustang lijkt een stevige opruimactie te zijn van Sun: weinig grote nieuwe veranderingen, maar vooral de losse eindjes in de bestaande API's, tooling en virtual machine aanpakken.

Dat is inderdaad een erg goed punt. Op nogmaals grote veranderingen zitten mischien niet al te veel mensen te wachten. Vooral de taal veranderingen maakt mensen op de een of andere manier toch een stuk banger dan je zou verwachten van enkele (kwa gebruik) toch wel simpele toevoegingen.

Kwa Java Enterprise Edition 5 (die dus met name SE 5 target), zal dit ook voor een gedeelte zijn terug te vinden. De servlet en jsp specs ondergaan weinig grote veranderingen. JSF 1.2 verschilt ook weinig van 1.1. Voornamelijk bug fixes en wat integratie verbeteringen.

Voorderest is het erg interesant dat ze direct op de JVM zelf focussen, hoewel dit dingen zijn die je niet direct terug vind in de zichtbare API of language spec. Wat dat betreft kan "escape analysis" dus net zo goed in een VM worden toegepast die de Java 5 spec implementeerd. Volgens mij doet IBM dat ook met hun eigen versie 5 VM (die waarschijnlijk ongeveer omstreeks dezelfde datum uitkomt als Sun met 6 komt).

Een klein puntje van kritiek vind ik echter de versie nummering. Als ze telkens een major nummer omhoog gaan dan zit je over een paar jaar wel erg hoog. Zou een 5.1 niet beter gepast hebben?

[Stephan Oudmaijer]

-Larz- schreef op woensdag 30 november 2005 @ 16:31:
Ik, als beginner, hoop dat de problemen met de Windows (XP) look&feel eindelijk fatsoenlijk worden aangepakt (Will Mutsang Obsolete WinLAF? en Update: Desktop Java Features in Mustang). Het is gewoon vaag dat je bent aangewezen op aparte pakketen (winlaf, jgoodies, etcetera) om in Windows bijvoorbeeld niet telkens te zitten klikken op een gedisabled tekstveld (winlaf issue 95).

Ook wel leuk dat je nu eindelijk in Java 6.0 gebruik kan gaan maken van de system tray. Werd tijd....

[Verwijderd]

CK schreef op donderdag 01 december 2005 @ 10:28:
Ook wel leuk dat je nu eindelijk in Java 6.0 gebruik kan gaan maken van de system tray. Werd tijd....

Zullen mensen met een Mac echt blij mee zijn. Net zoals partitie informatie is het vrij logisch dat dit er niet standaard in zit. Ik vind ook java op dat vlak niet zo interessant. Als ik de system-tray wil gebruiken schrijf ik wel een native windows app...

[Verwijderd]

Verwijderd schreef op donderdag 01 december 2005 @ 10:54:
[...]
Zullen mensen met een Mac echt blij mee zijn.

De toolbar icons in je menu balk rechtsbovenin?

Net zoals partitie informatie is het vrij logisch dat dit er niet standaard in zit. Ik vind ook java op dat vlak niet zo interessant. Als ik de system-tray wil gebruiken schrijf ik wel een native windows app...

Het idee is dat Java een common set of GUI en OS functionaliteit abstraheerd. Voor een groot gedeelte is dat gebasseerd op hoe die GUI en OS er in omstreeks 1995 uitzagen. Zoals ik het begrepen heb is een gedeelte van de nieuwe OS integratie gewoon een update voor dingen die anno 2005 'common' in een OS zijn.

Je zag dit ook bijvoorbeeld met AWT. Hier zitten een aantal classes in die native geimplementeerd moet zijn en direct corresponderen met native widgets. Het probleem is echter dat dit weer gebasseerd is op de common widgets zoals ze in 1995 bestonden. Helaas is het voor Sun heel moeilijk gebleken om AWT wat betreft de native widgets te updaten. IBM zag dat, en het is hun wel gelukt om een nieuwere native widget set voor Java te bouwen. Tevens lukt het hun wel om die daadwerkelijk up te daten. (de SWT toolkit).

Je zou dus kunnen verwachten dat Sun, vanwege het bewijs dat er licht dat je native widgets WEL kunt updaten, ook eens AWT gaan reviseren. Vanwege Swing doen ze dit mischien niet...

[Verwijderd]

Wat ik bedoel te zeggen is dat ik het allemaal niet interessant vind wat er op GUI gebied verbeterd wordt. Andere talen blijken nou eenmaal geschikter voor het werk. Java heeft zich als geen ander bewezen in de webservices wereld daar waar inderdaad het onderliggende platform er vaak niet veel toe doet. Ik vind dat daar de meeste aandacht op gevestigd moet worden en dus niet het manusje alles moet willen zijn. Alleen al een 10mb jre is de meeste mensen nou eenmaal al teveel gevraagd.

[Verwijderd]

Verwijderd schreef op donderdag 01 december 2005 @ 13:10:
Wat ik bedoel te zeggen is dat ik het allemaal niet interessant vind wat er op GUI gebied verbeterd wordt. Andere talen blijken nou eenmaal geschikter voor het werk.

Ok, ik snap wel wat je bedoeld maar even mierenneuken. De -taal- heeft niks met het GUI gebied te maken, daar de taal alleen de syntax en semantiek van je constructies voorschrijft. Het is het -platform- wat er toe doet (library, framework, toolkits, etc)

Java heeft zich als geen ander bewezen in de webservices wereld daar waar inderdaad het onderliggende platform er vaak niet veel toe

De server side kant is inderdaad waar Java het sterkst is geworden. Dat betekent echter niet dat de desktop kant opeens niet meer bestaat. Het is mischien niet -de- focus, maar enige verbeteringen in Swing/AWT zijn natuurlijk altijd mooi meegenomen, ook al zal mischien maar 10% van de java programmeurs dat ooit gebruiken.

Het is net zoals de ME classes. Die gebruik je ook niet server-side, maar toch is het handig dat ook die updates krijgen.

Ik vind dat daar de meeste aandacht op gevestigd moet worden en dus niet het manusje alles moet willen zijn.

Er zijn gewoon verschillende dingen die Sun doet met Java. De server-side markt is de belangrijkste, maar daarnaast bedient Sun ook een sloot andere markten waaronder (marginaal) de desktop en wat meer dan marginaal de mobile en embedded devices.

Andere fabrikanten doen niet anders. Microsoft gebruikt .NET ook voor een reeks aan toepassingen, gewoon omdat er niet echt een reden is omdat niet te doen. Kijk je alleen naar taal dan zie je dat C# het uitstekend doet op de desktop (met de juiste desktop classes) en ook uitstekend geschikt is voor server-side toepassingen (met gedeeltelijk weer andere classes). De algemene utility classes (collections, parsers, etc) die kunnen gedeeld worden tussen de desktop en server omgeving. Ik zie daar nix inherents evils aan.

Het enige wat ik kan bedenken is dat het een verzonnen PHP argument tegen Java en .NET is. Omdat PHP het niet op die manier doet (PHP is eigenlijk alleen server-side) is het feit dat anderen het niet zo doen automatisch slecht. Dat lijkt me een beetje een non-argument.

Alleen al een 10mb jre is de meeste mensen nou eenmaal al teveel gevraagd.

Dat is een vreemde bias die nog van heel vroeger afstamt. Als je alleen voor het web bekijkt downloaden mensen met het grootste gemak een ongeveer even grote flash plug-in, maar als het java heet mag het opeens niet?

Kijk je naar de desktop, dan downloaden mensen met het grootste gemak even een 20MB codec pack om 1 lullig filmpje te bekijken van 3 minuten. Maar als ze een JRE van 10MB moeten downloaden om een handige applicatie te draaien dan mag het opeens niet? Want, het is Java, en voor Java mag je nix downloaden?

Vraag me dan toch af hoe zo vreselijk veel mensen Azureus aan de praat gekregen hebben aangezien volgens jou mensen nooit een JRE willen downloaden...

[Verwijderd]

Verwijderd schreef op donderdag 01 december 2005 @ 14:12:
Vraag me dan toch af hoe zo vreselijk veel mensen Azureus aan de praat gekregen hebben aangezien volgens jou mensen nooit een JRE willen downloaden...

Dat zeg ik helemaal niet
De constatering is dat mensen nog steeds huiverig zijn voor het installeren van het stukje software. Azureus is geen product om ook maar enige goede statistische uitspraken te kunnen doen over de algemene penetratiegraad van java. Maar als je wilt dat java ook op de desktop markt doorbreekt zul je moeten zorgen dat de jre daar een zeer hoge penetratie graad heeft ala macromedia flash.

[Verwijderd]

Verwijderd schreef op donderdag 01 december 2005 @ 14:55:
[...]
Dat zeg ik helemaal niet
De constatering is dat mensen nog steeds huiverig zijn voor het installeren van het stukje software.

Gaat om dat specifieke stukje software? Hebben mensen bij hun cursus Windows het matra te horen gekregen:

"Je moet bang zijn voor JRE te installeren"
"Je moet bang zijn voor JRE te installeren"
"Je moet bang zijn voor JRE te installeren"
"Je moet bang zijn voor JRE te installeren"
...

???

Mischien als ze JRE gewoon hernoemen naar "Funky Sunny Super Codec" dat iedereen het dan wel opeens durft te downloaden en dat het, net zoals Flash, voor niemand meer een probleem is om op die download button te clicken?

Azureus is geen product om ook maar enige goede statistische uitspraken te kunnen doen over de algemene penetratiegraad van java.

106,560,555 downloads!

Dit gaat dan nog maar over 1 enkel programma wat de JRE gebruikt. Zelfs al we ervan uitgaan dat mensen 10 keer overnieuw downloaden (wat onzinnig is, want Azureus update zichzelf via z'n eigen netwerk), maar stel dat mensen dat doen, dan nog is het ongelooflijk veel.

Tenminste al deze mensen hebben dus de moed gehad om gewoon de JRE te downloaden. Ik maak uit jouw verhaal op dat het alleen maar om de moed gaat. Technisch is het geen probleem: downloaden, dubbel clicken, en het is gebeurd. Ook kwa groote stelt het nix voor. 10MB is echt helemaal nix vandaag de dag. Zolang miljoenen(!) mensen films van 4GB downloaden en Apple een ongelooflijk succesvolle winkel kan opzetten die volledig gebasseerd is op downloads, waarbij de gemiddelde CD een MB'tje of 60 is, kun jij mij niet wijsmaken dat er een grote groep mensen is die geen 10MB kan downloaden.

Volgens mij ben je nu gewoon bezig puur en alleen FUD te verspreiden. Mischien dat je 8 jaar geleden nog een punt had met 10MB, maar anno 2005 dus gewoon niet.

[Verwijderd]

Begrijp me niet verkeerd. Ik vind 10 MB ook nergens over gaan. Maar feit blijft dat java lang niet de penetratie graad heeft als een product als macromedia flash. Die 100.000.000 downloads van Azureus stelt relatief gezien echt helemaal niets voor. Het is een product dat inspringt op een fenomeen wat alleen bekend is bij mensen met een digitaal rijbewijs (dat is bij lange na niet bij jan en alle man). Tevens wordt er makkelijk 10 keer per persoon gedownload, denk alleen al maar aan instituten waar dit op publieke computers wordt gebruikt. Dus nogmaals: Azureus is statistisch gezien helemaal niet interessant. Ik zou het veel interessanter vinden om de vraag te zien beantwoord waarom java nog steeds niet gemeengoed is op de desktop pc

[flowerp]

Verwijderd schreef op donderdag 01 december 2005 @ 14:55:
[...]
Dat zeg ik helemaal niet
De constatering is dat mensen nog steeds huiverig zijn voor het installeren van het stukje software.

Op mijn computer hoefde ik helemaal geen java te installeren. Versie 1.4.2 stond er gewoon al op toen ik mijn computer kocht. Bij een groot aantal kenissen en vrienden was dit ook het geval.

[misfire]

Verwijderd schreef op donderdag 01 december 2005 @ 01:04:
[...]
Voorderest is het erg interesant dat ze direct op de JVM zelf focussen, hoewel dit dingen zijn die je niet direct terug vind in de zichtbare API of language spec. Wat dat betreft kan "escape analysis" dus net zo goed in een VM worden toegepast die de Java 5 spec implementeerd. Volgens mij doet IBM dat ook met hun eigen versie 5 VM (die waarschijnlijk ongeveer omstreeks dezelfde datum uitkomt als Sun met 6 komt).

Sun heeft aangegeven een aantal VM verbeteringen ook te "backporten" naar Java 5. In de update 5 van Java 5 is bijvoorbeeld een simpele vorm van "lock coarsening" toegevoegd. IBM deed lock coarsening al in de 1.4 VM, en zal de strijd om de snelste VM niet zo maar opgeven in de ontwikkeling van Java 5. Helaas schijnt IBM veel moeite te hebben om Java 5 te releasen, waarschijnlijk wordt daarom een aantal van de VM verbeteringen uitgesteld naar de eerste update voor hun Java 5.

Een klein puntje van kritiek vind ik echter de versie nummering. Als ze telkens een major nummer omhoog gaan dan zit je over een paar jaar wel erg hoog. Zou een 5.1 niet beter gepast hebben?

Sun wil graag de namen wat frisser en eenvoudiger maken. Het is daarom Java 6, niet 6.0, want .0 is te technisch. Het is natuurlijk ook marketing: 6 klinkt nieuwer dan 5.1. Ik vind het wel goed om Java een wat minder technisch image te geven. Ik hoop alleen dat ze voorlopig nu wel dezelfde strategie aanhouden. Ik kom nu nog steeds mensen tegen die niet snappen waarom het verschil tussen 1.4 en 5 zo groot is qua versienummer. Sun heeft nu al 2 keer gewisseld van uiting, laat ze nu dit even aanhouden. Want het verschillen tussen 1.4 en 5.1 uitleggen wordt helemaal verwarrend.

[momania]

Volgens mij heeft java 5 gewoon als versie nummer 1.5.x hoor.
Dus java 6 zal wel gewoon 1.6.x worden.

Ik zie het probleem met de versie nummering dus niet.

[DaCoTa]

Verwijderd schreef op donderdag 01 december 2005 @ 01:04:
Een klein puntje van kritiek vind ik echter de versie nummering. Als ze telkens een major nummer omhoog gaan dan zit je over een paar jaar wel erg hoog. Zou een 5.1 niet beter gepast hebben?

Ik vind de single digit versienummering het eigenlijk wel duidelijk, alle informatie die daar achteraan komt, is idd technische informatie, daar hoef je de eindgebruiker niet mee lastig te vallen. Daarnaast, hoge versienummers hebben tegenwoordig blijkbaar geen negatief image meer (Office 12?), en de periode van de 200x versienummeringen is ook wel voorbij, 2000 is niet modern meer.

Over Java 6, wij hebben toevallig gisteren een productieupdate gedaan, waarbij we - naast een grote redesign - ook zijn overgetapt naar Java 5. Al met al vond ik het best vlot, wat is het nu, een jaar en nog wat na de release van Java 5. Maar aangezien dit geweld net voorbij is, zal het bij ons iig nog wel een tijdje duren voor ik het idee van een overstap naar Java 6 ga opperen

[flowerp]

Op een Linux machine heb ik ook Mustang geprobeerd en het draait verbazend stabiel. Eclipse blijft inderdaad gewoon draaien zonder crashes.

Sterker nog, de machine waarop ik draaide was een AMD 64. Zoals bekend draait Java 5 daar erg instabiel op. Over het algemeen houdt een java sessie het niet langer dan een half uur tot hooguit een uur vol (rara VM crashes, of out of memory meldingen ondanks het gebruik van -Xmx1024mb etc). Met Mustang heb ik Eclipse een gehele werkdag gedraait zonder 1 enkele crash (fingers crossed).

Wel jammer dat je op de Mac nooit met dergelijke beta versies van Java kunt experimenteren.

[Gert]

Mja, ik vraag mij dan altijd af of ik zo'n bijzonder systeem heb of dat de rest zit te prutsen. Eclipse, en andere java apps/servers, draaien hier prima op een x86_64 linux machine met 64bits Java 5 jdk.

[flowerp]

Gert schreef op zaterdag 03 december 2005 @ 20:41:
Mja, ik vraag mij dan altijd af of ik zo'n bijzonder systeem heb of dat de rest zit te prutsen. Eclipse, en andere java apps/servers, draaien hier prima op een x86_64 linux machine met 64bits Java 5 jdk.

De application servers (we gebruikten met name Tomcat 5.5.9 en Orion 2.02) draaien prima met de 64 bits Java 5 JDK. Eclipse is vanaf dag 1 al huilen geweest op 64 bits. Begonnen met 3.0 en Java 5 update 1 heb ik alle combinaties geprobeerd tot en met Eclipse 3.1.1 en Java 5 update 5. Alleen het eergister uitgekomen 6 nog niet geprobeerd.

De Linux distributie is Debian GNU/Linux.

Op het net zijn er ongelooflijk veel reports over dit probleem. Het is te wijten aan het feit dat Sun "per ongeluk" de JDK heeft gecompileerd met een versie van GCC die foutieve code genereerd op x86-64. GCC heeft dit snel gefixed, maar het probleem is dat een JDK altijd strong dependencies heeft op een exacte GCC versie. Je kunt dus niet zelf de JDK compileren met een GCC versie die ook maar een minor.minor point release afwijkt van die gene die de JDK in kwestie 'target'. (hoe dat technisch mogelijk is snap ik ook niet, wellicht dat Sun interne API's/structuren van GCC aanspreekt ofzo, maar dat is puur giswerk aangezien dergelijk materie mijn kennis ver te boven gaat).

Iniedergeval is het zo dat Mustang dus wel met een nieuwere GCC is gecompileerd, en dat feit alleen al geeft dus die enorme stabiliteits toename op 64 bits systemen.

[Verwijderd]

Ik heb ook last van die slechte compatibiliteit ivm Eclipse/64bit JDK.
Daarom gebruik ik nu NetBeans 5 beta2 en die lijkt wel goed te werken met de 64bit Sun JDK.

[flowerp]

Verwijderd schreef op zondag 04 december 2005 @ 21:48:
Ik heb ook last van die slechte compatibiliteit ivm Eclipse/64bit JDK.
Daarom gebruik ik nu NetBeans 5 beta2 en die lijkt wel goed te werken met de 64bit Sun JDK.

Het stomme van het hele verhaal is dat het stukje code wat de crashes veroorzaak in feite niks bijzonders is. Je kunt de source van Eclipse in kijken, en het is echt een gewoon loopje. Het is gewoon toeval dat dit stukje (icm met de toestanden waarop het aangeroepen wordt etc) net de Sun bug triggered.

Alternatief is nog de nieuwe IBM JDK 5 te proberen, maar die is ook nog steeds in beta. Duurt wel heel erg lang. Voorlopig echter lijkt Mustang wel redelijk stabiel.

[Verwijderd]

Zou het misschien helpen om één van de nieuwe Eclipse 3.2 milestones te gebruiken?

[JaWi]

[lichtelijk offtopic]
Hmm, da's grappig; ik heb destijds -voordat Eclipse 3.1 definitief uit was- ook vreemde VM errors gehad op m'n AMD64. Echter toen 3.1 uitkwam, en ik m'n workspace opnieuw had aangemaakt, verdwenen de problemen allemaal en draait Eclipse even stabiel als op m'n 32-bit bak. Het jammere was alleen dat ik m'n projecten opnieuw moest aanmaken cq. importeren...
[/lichtelijk offtopic]

[flowerp]

Verwijderd schreef op maandag 05 december 2005 @ 09:52:
Zou het misschien helpen om één van de nieuwe Eclipse 3.2 milestones te gebruiken?

Mischien, maar het is geen oplossing om van beta af te zijn daar Eclipse 3.2 ook weer beta is. Dan kun je net zo goed Mustang draaien als die het ook al oplost. (lijkt op te lossen)

[Verwijderd]

De early draft spec is uit en te downloaden:

http://jcp.org/aboutJava/communityprocess/edr/jsr270/

Volgens het oorspronkelijke schema had deze er al bijna een jaar geleden moeten zijn. Zou dit betekenen dat Mustang zelf ook een jaar later uit komt? We moeten dus nog de public review en de final release krijgen (geen final draft in JSR 270) en dat lijkt me toch minimaal een jaar, zeker gezien die oorspronkelijke planning.

[PhoneTech]

Vandaag is de eerste Beta release uitgekomen van Mustang en ik kan niet wachten op de final!

download -> http://java.sun.com/javase/6/download.jsp

Wat voor mij echt een wereld van verschil gaat maken is de desktop integratie. de JDIC libary is nu standaard deel van de JRE wat de integratie alleen maar ten goede gaat komen. Ook de vele vernieuwingen (geintegreerde drag and drop support voor JTree met orderring bijvoorbeeld) maken het leven van een Swing developer een stuk makkelijker.

Het is alleen wel jammer dat veel van onze partners nog op 1.4.2 draaien en een migratie project nogal veel werk is...

Ik hoop dus echt dat er voor een hoop dingen back-ports komen.

[qless]

Ik hoop dat ik met 6 eindelijk weer alle corba zaken kan gebruiken. Met 5 werken sommige dingen wel, andere dingen niet...die met 1.4 keurig werken...

[zwippie]

Lekkere kick:

Ik merk dat de Mustang (beta 2) VM echt veel sneller is dan de 1.5 VM. In een console applicatie waar ik mee bezig ben scheelt het zo'n 25%. Netjes!

[Verwijderd]

zwippie schreef op dinsdag 05 december 2006 @ 11:19:
Lekkere kick:

Ik merk dat de Mustang (beta 2) VM echt veel sneller is dan de 1.5 VM. In een console applicatie waar ik mee bezig ben scheelt het zo'n 25%. Netjes!

Waarom gebruik je nu nog de beta 2? De RC is al een tijdje uit (build 104) en die is echt stukken beter; sneller en stabieler.

Ik merk vooral dat de opstart tijd van Tomcat enorm afneemt. Op mijn machine gaat dit van meer dan 20 seconden tot iets minder dan 10 seconden. Dat is dus meer dan 100% winst. Ik vraag me wel af wanneer die final nu eens gaat uitkomen. De overkoepelende JSR is een maand geleden ofzo goedgekeurd, dus in principe staat de weg naar een release nu open.

De oorspronkelijke datum was herfst 2006. Om dat nog te halen hebben ze nog slechts 2 weken. Ben benieuwd.

Van Java 7 zijn ook alweer enkele builds uit. Het belang daarvan in deze thread is natuurlijk dat Java 6 pas echt gebruikt mag worden zodra 7 uit is. Tot die tijd zal 6 voor velen helaas niets meer zijn dan een speeltje voor in de hobby sfeer.

[flowerp]

Verwijderd schreef op woensdag 06 december 2006 @ 00:06:
De oorspronkelijke datum was herfst 2006. Om dat nog te halen hebben ze nog slechts 2 weken. Ben benieuwd.

Het is ze dus na 1 week gelukt! Technisch hebben ze het dus inderdaad in de herfst van 2006 uitgebracht!

Zijn er hier al mensen die het nu ook al echt gaan gebruiken nu de final er is?

Zelf zit ik toch wel een beetje te kijken naar de pluggable annotations en runtime code generation. Het voelt een beetje weer zoals de Macro magic in C++ en de good ol' days of self modifying code die je in assembly vroeger vaak deed. Hier zijn vast hele krachtige dingen mee te maken, maar introduceerd ook weer veel 'magie' in het geheel.

Zo had je vroeger in bijvoorbeeld MFC van die message maps die op geheel eigen manier een soort virtual functions implementeerde, maar met een geheel eigen syntax. Nu was dit in MFC een enkel welbekend mechanisme, maar mischien dat het hek wel van de dam is als elke toolkit op willekeurige manier dergelijk technieken gaat gebruiken.

Dingen die je nu bijvoorbeeld kunt doen is inheritten van een niet bestaande class (de class in kwestie wordt dan build time gegenereerd) of de input van een user runtime compileren naar iets waar je dan weer verder mee werkt.

[Verwijderd]

Ik heb vandaag even onze applicatie onder java 6 aangezet, en bleek dat ze de Statement en Connection interface hebben aangepast met extra methodes. Geen probleem zeg je, wel als die parameters nemen die niet in java 5 zitten, en je classes dus niet meer onder 5 compilen. Jammer, voorlopig kan ik dus alleen maar mijn eclipse draaien onder 6, en dan compilen en coden met 5 tot we op alle servers in één keer naar 6 overgaan. *zucht*

[Gerco]

Verwijderd schreef op dinsdag 12 december 2006 @ 22:29:
Jammer, voorlopig kan ik dus alleen maar mijn eclipse draaien onder 6, en dan compilen en coden met 5 tot we op alle servers in één keer naar 6 overgaan. *zucht*

Prijs jezelf gelukkig. Ik zit nog vast aan 1.4.2_06 en op sommige servers zelfs nog op 1.3.1

Voorlopig is er geen verandering op komst ook, dat duurt nog wel een jaartje. Kun je vertellen wat er precies veranderd is waardoor je code niet meer compileert op 5 ?

[flowerp]

Verwijderd schreef op dinsdag 12 december 2006 @ 22:29:
Ik heb vandaag even onze applicatie onder java 6 aangezet, en bleek dat ze de Statement en Connection interface hebben aangepast met extra methodes. Geen probleem zeg je, wel als die parameters nemen die niet in java 5 zitten, en je classes dus niet meer onder 5 compilen.

Hey dat klinkt vreemd. Ik ben 1 van onze applicaties nu aan het test draaien onder Java 6. We maken veel gebruik van Statement en Connection (uit JDBC) en de applicatie draait gewoon. Nu heb ik gewoon met een java 5 compiler (jdt van eclipse) de classes compiled en op java 6 gedraaid en dan gaat (tot nu toe) alles gewoon goed.

Ik zal morgen eens kijken wat er gebeurd als ik met Eclipse in java 6 mode een full rebuild doe.

Prijs jezelf gelukkig. Ik zit nog vast aan 1.4.2_06 en op sommige servers zelfs nog op 1.3.1

Werk je dan aan software voor banken oid?

[ Voor 8% gewijzigd door flowerp op 12-12-2006 22:46 ]

[Gerco]

flowerp schreef op dinsdag 12 december 2006 @ 22:44:
Werk je dan aan software voor banken oid?

Nee, ik implementeer Sonic ESB als consultant/programmeur. Daarvoor moet nogal eens een stuk(je) Java geprogd worden en Sonic ondersteunt alleen 1.4.2_06 als JVM, zelfs in de nieuwste major versie die afgelopen april is uitgekomen. Op sommige servers die als JMS client optreden staat 1 of andere prehistorische RedHat versie die alleen de 1.3.1 JVM geinstalleerd heeft en niet geupgrade mag worden vanwege de company policy aldaar.

Helaas wist ik niet van die 1.3.1 versie en had ik vrolijk JDK 1.4 logging gebruikt in de client die erop moest gaan draaien . Commons-logging to the rescue!

[ Voor 12% gewijzigd door Gerco op 12-12-2006 22:57 ]

[JKVA]

Gerco schreef op dinsdag 12 december 2006 @ 22:56:
[...]
Commons-logging to the rescue!

Lol, dat is ook voor het eerst dat ik iemand positief hoor over commons-logging.

[Verwijderd]

flowerp schreef op dinsdag 12 december 2006 @ 22:44:
[...]


Hey dat klinkt vreemd. Ik ben 1 van onze applicaties nu aan het test draaien onder Java 6. We maken veel gebruik van Statement en Connection (uit JDBC) en de applicatie draait gewoon. Nu heb ik gewoon met een java 5 compiler (jdt van eclipse) de classes compiled en op java 6 gedraaid en dan gaat (tot nu toe) alles gewoon goed.

Ik zal morgen eens kijken wat er gebeurd als ik met Eclipse in java 6 mode een full rebuild doe.

een voorbeeldje:

http://java.sun.com/javas...ql/PreparedStatement.html
Onderaan die @since 1.6 methodes

bv die nclob methods nemen NClob en die is natuurlijk ook pas @since 1.6
http://java.sun.com/javase/6/docs/api/java/sql/NClob.html

[Gerco]

JKVA schreef op woensdag 13 december 2006 @ 07:18:
Lol, dat is ook voor het eerst dat ik iemand positief hoor over commons-logging.

Het is erg dun en goed compatible met JDK 1.4 logging. Ik hoefde er dus zowat geen regel code voor te veranderen. Voor log4j had ik meer moeten aanpassen en een grotere dependency geïntroduceerd. Log4j was en is enorme overkill voor dat simpele dingetje.

[Verwijderd]

Gerco schreef op woensdag 13 december 2006 @ 08:28:
Het is erg dun en goed compatible met JDK 1.4 logging. Ik hoefde er dus zowat geen regel code voor te veranderen. Voor log4j had ik meer moeten aanpassen en een grotere dependency geïntroduceerd. Log4j was en is enorme overkill voor dat simpele dingetje.

vertel dat graag ook even aan de kerel (of vrouw) die commons-logging in de maven2 repo heeft gezet...

[Gerco]

Verwijderd schreef op woensdag 13 december 2006 @ 09:05:
vertel dat graag ook even aan de kerel (of vrouw) die commons-logging in de maven2 repo heeft gezet...

Heeft 'ie daar zoveel deps dan? In mijn client gebruik in alleen commons-logging.jar en verder helemaal niets. Dat ding logt natuurlijk ook alleen naar console en file, dus het doet weinig, maar veel deps is zeker niet synoniem voor commons-logging.

[edit]
Alle deps van commons-logging zijn optional in maven2, behalve junit, die alleen nodig is als je het zelf wilt compilen en testen. Ik zie het probleem nog niet, maar dat zou aan mij kunnen liggen.

[ Voor 17% gewijzigd door Gerco op 13-12-2006 09:18 ]

[Verwijderd]

Helaas is dit een voorbeeld waarbij praktijk en documentatie niet gelijk zijn. De deps worden wel degelijk meegenomen namelijk.

edit:
niet in de maven scope, maar andere plugins die niet scope aware zijn (zoals bijvoorbeeld idea of eclipse) linken dergelijke deps. Vandaar dat er zoiets bestaat als depManagement en een optional element...

[ Voor 45% gewijzigd door Verwijderd op 13-12-2006 09:50 . Reden: uitleg ]

[ari3]

momania schreef op woensdag 30 november 2005 @ 09:51:
Hier een kleine opsomming van (geplande) verbeteringen in java 6: http://java.sun.com/devel...ktop/Mustang_build39.html
Vooral in de core vind ik de volgende wel interessant:
Many developers will recognize this requirement from the JDC bug parade. Finally, java.io.File is updated with methods to determine both partition sizes and usage and the amount of free space on each partition.
Voor applicaties die veel I/O produceren is dit wel een hele interessante. Vind het al verbazend genoeg dat dit nu pas beschikbaar gaat worden.

Ik vind het een flutoplossing. Het opvragen van de beschikbare schijfruimte is een moment-opname. Als je een bestand wilt schrijven en vooraf controleert of er voldoende ruimte beschikbaar is dan kan op het moment dat het bestand geschreven wordt de ruimte al niet meer beschikbaar zijn.

Een betere oplossing is dat als je weet dat het bestand 200MB wordt moet je gewoon een bestand van 200MB aanmaken i.p.v. dat je het bestand on-the-fly laat groeien. Op deze manier ben je verzekerd van die 200MB.

[Wolfboy]

ari3 schreef op woensdag 13 december 2006 @ 11:25:
[...]
Ik vind het een flutoplossing. Het opvragen van de beschikbare schijfruimte is een moment-opname. Als je een bestand wilt schrijven en vooraf controleert of er voldoende ruimte beschikbaar is dan kan op het moment dat het bestand geschreven wordt de ruimte al niet meer beschikbaar zijn.

Een betere oplossing is dat als je weet dat het bestand 200MB wordt moet je gewoon een bestand van 200MB aanmaken i.p.v. dat je het bestand on-the-fly laat groeien. Op deze manier ben je verzekerd van die 200MB.

Ben ik het niet geheel mee eens, als je kan detecteren dat een gebruiker nog maar 100MB vrij heeft dan is het overbodig om te proberen of je 250MB te schrijven. Sowieso wil Windows nog weleens flink moeilijk doen/hangen op het moment dat de schijf helemaal vol zit, en dan heb ik het nog niet eens over programma's die crashen omdat ze niet meer kunnen schrijven naar de schijf. Het blijft uiteraard een momentopname, maar het geeft in ieder geval de mogelijkheid te waarschuwen voor het probleem optreedt.

[Marcj]

Ik ga het zeker bij mijn afstuderen direct in gebruik nemen. Uit vroege tests hier van mij zijn synchronized methodes tot wel 10x zo snel geworden! Daarnaast is over het algemeen ook methodeaanroepen sneller geworden. Aangezien ik voor dit project snelheid nodig ben ga ik direct met Java 6 aan de gang

[MetroidPrime]

ari3 schreef op woensdag 13 december 2006 @ 11:25:
Een betere oplossing is dat als je weet dat het bestand 200MB wordt moet je gewoon een bestand van 200MB aanmaken i.p.v. dat je het bestand on-the-fly laat groeien. Op deze manier ben je verzekerd van die 200MB.

Volgens mij is dat al sinds Java 1.2 mogelijk? Je kunt een RandomAccessFile object voor een bestand maken en vervolgens dit bestand een specifieke grootte geven met de setLength methode.

[ Voor 4% gewijzigd door MetroidPrime op 15-12-2006 01:45 ]