Nieuwe Java-versie beschikbaar als release candidate

Oracle heeft een eerste release candidate van Java SE 7 uitgebracht. Een bètaversie was al langer beschikbaar en de final versie wordt eind juli verwacht. Java SE 7 is de eerste grote update voor Java sinds eind 2006.

Java Standard Edition 7 komt waarschijnlijk op 28 juli uit, maar nu kan de eerste release candidate al worden gedownload. Een bètaversie was al langer beschikbaar. Nieuw in Java SE 7 is ondersteuning voor dynamische scripttalen zoals Ruby. Deze talen konden al worden gebruikt in de Java Virtual Machine, maar in de nieuwe release moeten niet-Java-talen fors beter presteren.

Ook bevat Java SE 7 betere ondersteuning voor processors met meer dan één core en er is een nieuwe api voor bestandsbewerkingen, die snellere toegang tot het bestandssysteem mogelijk moeten maken. Java SE 7 kent daarnaast een aantal nieuwe features.

Expertpanellid Misja Alma noemt de nieuwe versie van Java een 'versie die vooral erg lang op zich heeft laten wachten en die maar een beperkt aantal verbeteringen meebrengt'. Collega-panellid en -ontwikkelaar Jan Willem Harmelink noemt de verbeteringen 'niet wereldschokkend, maar zeer welkom'. "Ik ga ze in de nabije toekomst veel gebruiken", aldus Harmelink. Wel tekent hij aan dat Oracle veel geplande features heeft doorgeschoven naar versie 8.

Reacties (112)

[Semt-x]

Het wordt nog erger als 1 applicatie een specifieke versie eist. en dat dat niet de enige app is die java gebruikt maar er 4 andere zijn.
alleen bij kleine apps? welnee, Oracle EBS was er 1 van, niet iets dat je zo even tussen de bedrijven door helemaal kan testen. en gemiddeld elke 2 maanden komt er een nieuwe.

Je kan een doos met technische virtualsatie oplossingen opentrekken om het toch te laten werken. en dat allemaal omdat coders geen flauw benul hebben waar ze mee bezig zijn. ze zijn "klaar" als het in hun Lab functioneel werkt.

Java heeft bij een klant zoveel tijd gekost dat we daar niet langer spreken van versies maar van pogingen, Java 6 poging 26. en dat is alleen de 6e generatie het zelfde geld nog voor generatie 5. De laatste generatie 4 applicatie is begin dit jaar uitgefasseerd. Dus hoog tijd om weer een nieuwe generatie in het leven te roepen!

Laat ik deze gelegenheid niet liggen om java te bedanken voor hun consistente silent installation parameters en update bloatware. Het feit dat normale gebruikers geen rechten hebben om software updates zelf te installeren is blijkbaar nog een bijzondere situatie bij java. je moet echt moeite doen om dat update mechanisme helemaal uit te schakelen.
bijv een minder geinformeerde klant had het update mechanisme niet helemaal uitgezet op een terminal server. Gevolg; elke gebruiker die inlogde startte 2 update exe's van java. 20% minder capaciteit door java. ligt dat aan die klant? deels denk ik, java moet zijn klanten "beschermen" tegen verkeerd gebruik, dan is dit nog al een quick win.

Ik vraag me af waarom de versie hel bij .net applicaties niet bestaat of ik kom het iig nooit tegen, ook niet waar veel custom apps in .net zijn geschreven.

[SPee]

Het is mogelijk om verschillende java versies naast elkaar te hebben. Enkel de juiste java.exe of javaw.exe starten en de systeem/user variabele JAVA_HOME naar die juiste directory zetten. Bij vele applicaties gebeurd dat in het startup script. En het "installeren" van Java hoeft niet eens via de installer. Je kan gewoon de directory kopieren!

En klanten die automatische updates op een terminal server (voor welke applicatie dan ook) aanzetten

Waarom je het bij .NET niet tegenkomt:
Updates worden automatisch door MS op Windows geinstalleerd. Ook daar; meerdere versies naast elkaar. Bij het starten van de applicatie wordt de versie bepaald en de juiste versie gebruikt. De applicatie is bij MS (veelal) een exe, terwijl bij Java dit een zip is. Hierdoor werkt de .net applicatie alleen op Windows, terwijl bij Java dit door (onkunde/foutief gebruik/bewuste keuze van) de programmeur wordt bepaald.

[flowerp]

Leuk verhaal, maar dat gaat allemaal over Windows desktop gebruik zo te horen. Dit is wel een niche markt die Java 'veroverd' heeft, maar niet de primaire markt.

Op de server heb je een JDK in /opt/jdk staan met een symlink naar de juiste versie. Nooit problemen mee. Werkt recht toe recht aan en werk goed.

En voor de Linux desktop kun je bij apt based systemen een vaste versie pinnen als je dat graag wilt, en anders komt gewoon de laatste goed geteste versie met apt-get binnen. Ik gebruik niet dagelijks grote client-side enterprise apps op Windows, maar wel dagelijks grote server-side enterprise apps op Linux en OS X (die dan in mijn geval lokaal draaien omdat ik developer ben).

Zoals eerder gezegd hier, die gevoeligheid van de versies ken ik gewoon niet. Wij hebben in ons team ook minder goede programmeurs, maar ik zou werkelijk niet weten wat voor gekke dingen je zou moeten doen om iets te programmeren dat zou breken tussen zeg JDK 6 update 24 en update 25.

[Bastiaan V]

Het is idd erg lastig om even in te loggen als admin, het java control panel te starten en het vinkje voor automatisch update uit te zetten.


Automatisch updaten is JUIST om de klanten te beschermen!

[gimbal]

Java is dan ook twee dingen: de taal en het platform (de JVM voornamelijk). Aan de taal gebeurd niet zoveel en dat hoeft ook niet; het is prima zo met de kleine wijzigingen die doorseipelen.

Aan het platform wordt echter hard gewerkt, maar dat is technische prietpraat wat niet lekker op een feature lijst staat. Wie kan het schelen dat er een nieuwe garbage collector is toegevoegd die nog beter presteert in high concurrency omgevingen bijvoorbeeld? (noem maar wat, dat is alweer oud nieuws).

Nu zit het nog in een transitiefase. Je kunt duidelijk merken dat Oracle de riem enorm strak aan het trekken is via de updates die uitkomen; security VOOR backwards compatibility, voor het eerst breken minor versie updates ineens applicaties (met name applets). Vaak terecht overigens, maar het is wel vervelend voor de mensen die het moeten onderhouden.

[flowerp]

Java is historisch gezien zelfs 3 dingen:

1. De JVM
2. De taal Java
3. De JDK/standard Java library

[Dreamvoid]

Voor het eerst? Die versie update ellende is er al jaren, ook voor de Oracle overname.

[YopY]

Mwa, wat er in Java als taal gebeurt is voor versie 7 en 8 niet echt wereldschokkend, mijns insziens. Ik zie meer in talen die ook op de JVM gebouwd zijn, zoals Scala, Clojure, Groovy, en ga zo maar door. Vooral Scala lijkt een zeer goede taal te zijn als vervanger voor Java.

[Cristan]

Eindelijk! Het was eigenlijk voor midden 2009 aangekondigd en alsnog hebben ze een aardig aantal features naar Java 8 moeten doorschuiven. Hoe dan ook: ik ben er blij mee dat er eindelijk vaart achter zit en features als multiple exception catch block zijn echt dingen waar ik gelukkig van word

[YopY]

Mja, de nieuwe taalfeatures zijn leuk en hebben de potentie om je code net een beetje netter te maken... Maar ik geloof er niet zo in. Het heeft niet een heel erg grote impact op de taal Java, het lost slechts kleine irritaties van developers op.

Nee, ik zie meer toekomst in alternatieve talen op de JVM. Vooral Scala is veelbelovend. En het grote voordeel is dat het helemaal compatible is met zaken die je in Java gemaakt hebt, dus Java en Scala kun je in één project gebruiken. (beide compileren naar bytecode, vergelijk het met de CIL van .NET die op dat concept gebaseerd is).

itt tot Java doet die wél volledig nieuwe dingen, veel handigheidjes, minder code, etc etc. En ik moet me er nog in verdiepen, kun je nagaan.

[flowerp]

Scala is zeker wel een interessante taal, maar vergeet niet dat deze het erg moet hebben van de hype van het afgelopen jaar.

Het bestaat al sinds 2003 en niemand die er ooit om maalde. Tot dat er een poosje geleden een groepje fans onder diverse namen zeer agressief over aan het bloggen is geslagen, en opeens heeft iedereen het erover.

En dan nog zeggen dat reclame je niet beïnvloed

Ook is Scala niet alleen maar mooi. Er zijn ook wat mindere dingen. Binary compatibility is bij Java ondanks wat klagende mensen bij deze news posting toch wel heel erg goed. Bij Scala is dit 1 en al drama en ellende.

Elke )(#&)#& versie weer mag je alles overnieuw compileren en werkt niets samen met binaries die reeds gecompileerd zijn. Heel leuk als je niet overal de source van hebt!

Daarnaast is compileren in Scala weer ouderwets langzaam. Java compiled -instant-. Het is zo ontzettend snel dat het net lijkt of je gewoon je .java bestanden real-time kunt executen. Als ik iets save in b.v. Eclipse is het -onmiddelijk- beschikbaar om te runnen.

Bij Scala helaas niet.

Zelfs op een bloedsnelle machine mag je een flinke poos wachten. En vergeet het maar om 1 class te hercompileren. Niet zelden wordt je gedwongen om je hele project overnieuw te builden. Hoewel het bij Java zelden nodig is, is een full build van honderd duizende regels code nog steeds nagenoeg instant tot hooguit enkele secondes. Bij Scala zit je dan toch wel tegen een half uur aan te kijken.

Ook de IDE support wil maar niet van de grond komen bij Scala. De Java support die b.v. Eclipse je biedt is echt enorm veel en veel beter. Als Scala nu nog een hele jonge taal was, okay. Maar het is dus van 2003! Na 8 jaar mag er toch wel eens iets beters komen.

Daarnaast is Scala helaas toch wel wat buggy. Het taal concept is in 1 woord -schitterend- te noemen, maar de implementatie toch wel wat minder. Als mensen al klagen over de bugs in de JDK (wat er eigenlijk al te veel zijn en waar sommige te lang open blijven staan), maak dan je borst maar nat als je naar Scala gaat. Dat is de JDK bug parade in het kwadraat. Nogmaals, voor een gloednieuwe taal is dat nog acceptabel, maar voor een taal die al 8 jaar bestaat toch wel wat discutabel.

[Verwijderd]

Als ik iets save in b.v. Eclipse is het -onmiddelijk- beschikbaar om te runnen.

Wacht ff hoor, je hebt gelijk dat je Java apps onder Eclipse/NetBeans instant kan runnen, maar dat komt omdat de IDE op de achtergrond constant parset and compilet (en feedback geeft op de fouten.)
Scala mist dus misschien een goede IDE, maar is niet persee een langzame taal ofzo.

[flowerp]

Wacht ff hoor, je hebt gelijk dat je Java apps onder Eclipse/NetBeans instant kan runnen, maar dat komt omdat de IDE op de achtergrond constant parset and compilet (en feedback geeft op de fouten.)

Nee, het zijn 2 dingen samen:

1. Incrementeel compileren werkt echt.
2. Compileren is heel snel.

Ook een net uitgecheked en nog niet gecompileerd project is bij Java heel snel gecompiled. Als ik een ultra-simpele app van 1 class heb dan speelt incrementeel compileren eigenlijk geen rol. Bij Java kan ik na saven het ogenblikkelijk runnen, bij Scale niet.

Ook de commandline, ik kan javac ... && java ... in 1 regel opnemen. Er zit geen merkbaar verschil tussen het eerst compilen en dan meteen runnen, of het daarna runnen van de eerder gecompilde class.

[momania]

Wij gebruiken scala nu al in meer dan 50% van onze software, verdeeld over zo'n 15 systemen denk ik en het hart van alle applicaties is scala (al dan niet met een kleine java api erover) vanwege gedeelde infrastructuur code.
Ik herken de klachten wel, maar ik kijk toch liever naar de vele voordelen.

Er komt nu allemaal heel snel verbeteringen in trouwens. Binaire compatibiliteit is vanaf 2.8 redelijk geregeld en vanaf 2.9 gewoon prima. Ook compilen is fink verbeterd als je tools als SBT gebruik die alleen de echt diffs opnieuw compileerd (zoals javac dat ook doet eigenlijk, waar door het snel lijkt).

Ook de productiviteitswinst puur in het schrijven van code zelf, maakt dat de gebrekkige (maar snel verbeterende) tools ondersteuning nog te verwaarlozen is.

Nu hebben wij misschien ook de mazzel dat we het in productie systemen mogen en kunnen gebruiken en er dus heel snel veel ervaring mee op kunnen doen. Ook doen we zelf actief mee door contributies aan de gebruikte tools als de scala-plugin en sbt-plugin voor IntellJ en/of andere open-source scala projecten als Akka, Scalaz en SBT

[flowerp]

Ik herken de klachten wel, maar ik kijk toch liever naar de vele voordelen.

Dat kan ik begrijpen. De bovenstaande post komt misschien te veel als een rant over, maar was meer bedoeld om het plaatje iets te balanceren. Met Scala krijg je veel voordelen van een elegantere taal, maar het is geen silver bullet en er komen ook een paar nieuwe problemen bij die je met Java niet of minder had.

Ook de productiviteitswinst puur in het schrijven van code zelf, maakt dat de gebrekkige (maar snel verbeterende) tools ondersteuning nog te verwaarlozen is.

Ben ik gedeeltelijk wel mee eens, hoewel ik graag toch beide heb

Een sentiment wat ik ook heb gehoord (maar zelf niet deel), is dat met name de wat 'simpelere' programmeurs Scala te complex vinden. Bij ons hebben we een "new techologies" group waar mensen zich kunnen aanmelden, en toen Scala op het programma kwam zaten een aantal van de wat 'mindere' programmeurs hier meteen bovenop.

Het gerucht ging namelijk dat je minder regels hoefte te coden, wat ze meteen interpreteerde als "ik hoef minder na te denken, Scala doet meer automatisch". Na korte tijd gingen deze lui echter weer snel terug naar Java en juist de betere, meer ervaren programmeurs gingen door met Scala.

[Dreamvoid]

De ontwikkeling van .NET is idd veel sneller gegaan dan Java, maar dat kwam mede door geldgebrek bij Sun. Onder de vleugels van Oracle is er financieel in elk geval meer mogelijk.

[humbug]

Net zoals anderen in je gelinkte pagina snap ik het nut niet echt.
Als ik twee totaal verschillende excepties heb wil ik die ofwel verschillend afhandelen of ik catch gewoon een generieke Exception. (Of bijvoorbeeld een IOException)

Zelfde geldt voor een switch op basis van strings. Klinkt leuk maar met een if then else if ... constructie kun je precies hetzelfde bereiken.

Dit soort verfijningen van de taal zijn leuk maar niet de meest essentiële verbeteringen. Ik zie meer voordeel in de concurrency en performance verbeteringen.

[Robtimus]

Als ik twee totaal verschillende excepties heb wil ik die ofwel verschillend afhandelen of ik catch gewoon een generieke Exception. (Of bijvoorbeeld een IOException)

Tenzij je er ook nog generieke exception handling wilt. Probeer het volgende maar eens te doen zonder multiple exception catch block of code in twee catch blocks te dupliceren:

catch (IOException e)
{
// stuk code
}
catch (SQLException e)
{
// zelfde stuk code
}
catch (Exception e)
{
// heel ander stuk code
}

Ja, je kunt de code in een private method stoppen. Ja, je kan in het generieke Exception catch block een instanceof gebruiken. Maar dan vind ik een multiple exception catch block toch netter.

Zelfde geldt voor een switch op basis van strings. Klinkt leuk maar met een if then else if ... constructie kun je precies hetzelfde bereiken.

Wat dan weer complexer wordt zodra je met fall-throughs te maken krijgt.

[apokalypse]

Wat wel grappig is, is dat de multiple exception catch block een ander soort type-polymorfisme is dan dat we gewend zijn in Java. Het is polymorf, want het werkt op meerdere types, maar het is geen parametric polymorfisme (generics), of subtype polymorfisme.

Al hoewel het wel lijkt op de bounds met generics, is dit het zeker niet. Nu geven we een lijst op van types waaraan het kan voldoen, dit doe je niet met bounds (daar geef je beperkingen/verplichtingen van een type op).

Meest interessant is dus ook, waarom op deze manier. Totaal niet consistent, maar wellicht wel het mooist vanuit syntaxis gezien.

[killingdjef]

Wat dacht je van Switch cases op basis van String.... dit had nooit zo lang -mogen- duren.

[erikdenv]

Wat moet je er mee, het gebruik van een switch is meer iets voor procedurele talen en niet voor OO. Je hebt ook al de enums die je kunt gebruiken in een switch.

Ik zie het nut er niet zo van in. Wat wil je er mee?

[Reactie gewijzigd door erikdenv op 23 juli 2024 10:40]

[Verwijderd]

Reactie op bepaalde invoer?

[Verwijderd]

Je kunt altijd terugvallen op else if... ik zou het niet dreict missen,
Language support for collections is denk ik veel belangrijker, maar dan nog..... Misschien dat het sneller is dan gebruik van de 'oude' methode?

Automatic Resource Management is dan wel de belangrijkste feature denk ik...
Ik kan wel een probleem voorzien dat Java code geschreven voor 7 ook werkt op versie 6.

zoals
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
vs
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}

Code op 7 geschreven zullen dus wat minder fouten bevatten kwa resource management...


Ikzelf heb geen problemen met java compatibiliteit, de code die ik maak op mijn OSX machine werkt feilloos op de productie machines die Linux draaien. Natuurlijk wel de JDK en JRE van Oracle gebruiken... Sommige applicaties die eens in het verleden op PHP waren gemaakt, werken ook veeel sneller in Java, wat toch wel een voordeel is.

Het belangrijkste waarom bedrijven graag java gebruiken is type checken tijdens compileer tijd. het was met bv PHP nooit mogelijk is, je haalt gemakkelijk veel fouten tijdens de compileer slag en het zorgt ervoort je goede klassen en code schrijft, het wat in PHP veel minder wordt geforceerd.

[hackerhater]

Wat is er bah aan constanten?
MIts je het gebruikt waar het voor bedoeld is : vaste waardes die voor hele runtime gelden zoals bepaalde paden ed

[Verwijderd]

ietsje mager voor een major release, maar toch een aantal fijne features.

Ben ook benieuwd naar performantie verbeteringen, ff deze effectief merkaar zullen worden in grote productie omgevingen. Toch misschien al wat Jmeter tests klaarzetten.

leuk overzichtje :
http://inebium.com/post/java-7-new-release-performance-code

[Loller1]

Als je naar de oude versienummering kijkt is het eigenlijk geen major...

[Niet Henk]

Ben benieuwd wanneer deze nieuwe versie voor smartphones uitkomt, multicore support is daar intussen best wel nodig.

Het werd ook echt wel tijd dat java de boel eens goed verbeterd.

[hostler]

Volgens mij heeft u werkelijk geen idee waar u over praat. Java kan prima draaien op een single core smartphone.

Overigens is Java een product van Sun Oracle.

edit: typo

[Reactie gewijzigd door hostler op 23 juli 2024 10:40]

[XNL073]

Java was van Sun,
Tegenwoordig is Sun overgenomen door Oracle en is ook Java verder gegaan onder de vlag van Oracle. En ik dacht te menen dat Oracle aan het proberen is om Java te gaan verkleinen of zelf helemaal afschaffen.

[Omegium]

Vergeet niet dat Java heel groot is in de bedrijfssoftware, zoals de interne administratie systemen van banken, verzekeraars, etc.

Dat is ook een grote markt voor de databases van Oracle. Zonder Java zou .Net het meest voor de hand liggende platform zijn voor dat soort systemen, en dan drijf je mensen natuurlijk rechtstreeks naar MSSQL toe.

Oracle wil Java absoluut behouden, ze zijn alleen wat meer gebrand dan Sun om er ook geld aan te verdienen, zoals het vragen om royalties voor mobiele telefoons.

[Dreamvoid]

Sun is idd kapot gegaan aan het gratis weggeven van al hun technologie. Google verdient nu miljarden met Android (Dalvik = Java kloon), maar Sun zag er geen cent voor terug. Die fout wil Oracle niet maken, Java *moet* een succes worden, en er *moet* geld uit komen rollen. Als het niet lukt, wie steekt er dan nog geld in de ontwikkeling van Java? Adobe en Microsoft staan niet stil, en ook Apple schuift met hun Cocoa/Obj-C ecosysteem steeds meer in Java's vaarwater.

[flowerp]

Apple schuift met hun Cocoa/Obj-C ecosysteem steeds meer in Java's vaarwater.

Eigenlijk niet.

Cocoa/Obj-C heeft nu 2 markten in handen: de OS X desktop en iOS mobile (iPhone, iPad). Dit zijn theoretisch wel 2 markten die Java getarget heeft, maar zowel op de desktop als op mobile speelt Java slechts een bescheiden rol. De consument kent Java op de desktop amper eigenlijk. Voor interne corporate apps heeft het wel een beetje een niche markt, maar die wordt A) langzaam vervangen door webbased dingen en dat is een markt die Apple tot op heden niet kan of wil betreden.

Oracle probeert qua desktop wel terug te slaan met JavaFX 2.0, maar gezien dat Java al zo lang op de desktop geen rol van betekenis heeft gespeeld, kun je amper spreker dat Cocoa/Obj-C in Java's vaarwater komt. Eerder andersom!

Voor de ultra-simpele mobieltjes van een paar generaties geleden heeft Java ME wel even een grote rol gespeeld. Ondanks de botweg stupide simpelheid is Java ME toch nog wel even redelijk groot geweest. Op smartphones voor de -echt- serieuze apps heeft Java ME nooit ook maar enige rol gespeeld.

Tenzij je natuurlijk Android bedoeld, maar dan is het weer zo dat Apple eerder was en Android meer in Apple's vaarwater zit dan andersom.

Nee, waar Java echt heer en meester is, is de enterprise serverside. Dat zijn web applicaties van grote bedrijven (banken, verzekeringen, vliegtuigmaatschappijen, etc) maar ook veelal backend systemen van web sites die in eerste instantie PHP of RoR lijken. Twee van zo'n beetje de grootste web sites van dit moment, Facebook en Twitter hebben een behoorlijke hoeveelheid Java code draaien. Dit is dan absoluut geen legacy dingen die er toevallig nog zijn, maar juist heel bewust nieuwe state of the art development. Als je kijkt naar dingen als Lucene/Solr, Hadoop, Casandra, Blender (van Twitter) dan is dat allemaal Java.

Cocoa/Obj-C doet hier echt helemaal niets. Je kunt denk ik dus niet echt spreken van dat Apple in Java's vaarwater komt hier.

(het had trouwens heel anders kunnen zijn, daar NextStep wel degelijk een pionier is geweest in de serverside wereld met Web Objects, iets waar zowel .NET als Java diverse dingen van afgekeken hebben)

[Dreamvoid]

Je kunt denk ik dus niet echt spreken van dat Apple in Java's vaarwater komt hier.

Ja en nee. Op de enterprise markt heb je gelijk, daar zit Apple gewoon niet. Maar toen OS X uitkwam werd Java wel degelijk door Apple gemarket als 'first class citizen': Apple ging de Java VM bouwen, en het idee was bij veel devs dat Java net zo'n rol zou krijgen als .NET op Windows: wil je managed code dan Java, wil je ouderwets met native code gaan spelen dan Cocoa. Maar in de loop der tijd werd wel duidelijk dat Apple maar weinig aandacht besteedde aan hun Java VM, en dat Cocoa+Obj-C echt de prioriteit had. Het is zelfs zo erg dat Oracle nu de OS X Java VM ontwikkeling van Apple gaat overnemen (net zoals op Windows gebeurde!).

Op OS X-for-ARM (iOS) is Java niet eens meer aanwezig, vervangen door een veel strenger gesandboxede Cocoa+Obj-C omgeving. Je hoeft geen helderziende te zijn om te zien dat OS X ook steeds meer de kant van iOS op gaat. Hoe meer en rijkere API's Cocoa krijgt, hoe meer het op Java en .NET begint te lijken. Een laatste stap zou zijn dat alleen nog maar LLVM als compiler gebruikt kan worden, en dan is het helemaal gebeurd: een volledige managed code omgeving voor applicaties. Nu is dat nog lastig (legacy code, performance) maar de Wet van Moore lost dat wel op. En anders een paar security schandalen wel, want de gretig gebruikte exploits in de (native code) iOS apps (Safari, Mail, en in de laatste hack, de PDF reader) zullen Apple toch aan het denken zetten.

Google heeft met Dalvik in feite Java geforked vanaf 1.5, en gaat zijn eigen gang. Waar ligt dan de toekomst van Java? Enterprise apps uiteraard, en dat betekent steeds vaker: GNU/Linux. Dat komt goed uit, want dat heeft nog geen ander modern en volwassen managed code framework. Linux devs zijn nu nog fanatieke native code aanhangers, maar de wereld schuift langzaam maar zeker verder. Niet voor niets gebruikt Google voor Android alleen de Linux kernel, en gooit een compleet ander userland erbovenop: als je de kans hebt om een nieuw OS te starten, dan pak je een stabiele kernel, maar blijf je verder niet in het verleden hangen.

En dat wordt het einde van cross-platform droom: .NET op Windows (Phone), Cocoa+Obj-C+LLVM op OS X/iOS, Dalvik op Android en Java op GNU/Linux servers (en een handjevol desktops). Allemaal moderne frameworks, geen van allen volwaardige platforms op de ander. Na de wereld met een Windows monopolie en tien telefoon OSsen komt de nieuwe wereld bestaande uit vier ecosystemen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 10:40]

[flowerp]

Maar toen OS X uitkwam werd Java wel degelijk door Apple gemarket als 'first class citizen': Apple ging de Java VM bouwen, en het idee was bij veel devs dat Java net zo'n rol zou krijgen als .NET op Windows:

Dat was bij de introductie van OS X nog mee-varende op de gedachte dat Java een zeer belangrijke rol op de desktop zou gaan spelen. Alle desktop Java apps die er toen zogenaamd zouden gaan komen, zouden dan meteen op OS X kunnen draaien.

Zo'n rol als .NET op Windows klopt trouwens niet helemaal. Toen OS X uitkwam waren er net beta versie van .NET. Pas een goed jaar later kwam .NET 1.0 (wat qua desktop apps ook niet echt een instant hit was, daar mensen nog een flinke poos MFC/C++ of Win32/c bleven gebruiken).

Om verschillende redenen echter zijn die desktop Java apps er eigenlijk nooit echt gekomen. De plannen waren er wel degelijk. Legendarisch is natuurlijk de Java versie van Wordperfect: http://drdobbs.com/java/184415588 , maar zoals we nu weten is dat nooit een success geworden. Java was destijds te traag, en de GUI tool-kit had te veel quirks op diverse platforms. Ik kan me goed herinneren dat ik grafische Java 1.1 aps (AWT) toch flink moest tweaken om op al onze test platforms goed te werken (OS 9, OS X, Windows 95, Windows 2000 en Solaris something).

(aan de andere kant, voor de grap start ik nog wel eens een een oude Java 1.1 app die ik toen gemaakt had op, en op de nieuwste hardware, OS en JVM draait het nog helemaal correct. Dit kan ik helaas niet van al mijn Windows/MFC apps van destijds zeggen)

Maar in de loop der tijd werd wel duidelijk dat Apple maar weinig aandacht besteedde aan hun Java VM

Dit omdat de gigantische desktop apps markt die Apple en anderen ooit voorzagen er nooit gekomen is. Met stipt de grootste gebruikers van Java op OS X zijn developers die er Eclipse of Netbeans mee draaien en er serverside Java EE applicaties mee ontwikkelen.

Dit is een markt waar Apple geen behoefte aan heeft om actief te ondersteunen. Het enige puntje van belang dat ze hebben in Java is dat handjevol Java apps die wel door consumenten gebruikt worden en het feit dat developers relatief gezien vrij zeldzaam blijven en dat bijna elk platform die graag wil binnenhalen. Java developers op OS X gaan gemiddeld gezien natuurlijk vaker spontaan een Cocoa/Obj-c app ontwikkelen dan Java developers die op Windows zitten.

Hoe meer en rijkere API's Cocoa krijgt, hoe meer het op Java en .NET begint te lijken.

Klopt, het is grotendeels nu steeds meer aan het worden wat Java initieel heeft ingezet, maar het Java desktop schip heeft de haven amper verlaten, terwijl het Cocoa schip nu met volle zeilen midden op de oceaan vaart. Dat is dus nogmaals wat ik bedoel met dat Cocoa niet in Java's vaarwater zit. Hooguit kun je zeggen dat het in Java's "beoogde" vaarwater zit.

Waar ligt dan de toekomst van Java?

Sowieso nog steeds de serverside. Daar is het al heer en meester en ik zie dat alleen maar meer worden i.p.v. minder. Zoals gezegd, Facebook en Twitter die steeds meer Java gaan gebruiken en in NL b.v. iets als marktplaats dat op Java overgaat. Er is ook enorm veel ontwikkeling in deze sector voor Java. Kijk alleen eens naar wat Java EE 6 voor nieuwe dingen heeft, wat er op stapel staat voor Java EE 7, wat voor concurrentie er is (Spring 3.x, Wicket, GWT) en dan nog eens het hele NOSQL, document store, key/value store verhaal dat ook huge is op Java.

Daarnaast heb je nog een markt waar Java een beetje een verstopt succes is, en dat is in de embedded sector in de vorm van BD-J (wat helaas wel een beetje obscure, antieke JVM is, maar toch).

Of Java nog terug kan komen met Applets en op de desktop valt te bezien.

JavaFX 2.0 is in ieder geval een enorme stap in die richting en vanwege de vele kritieken op Flash ligt er op de RIA markt heel misschien weer een kansje voor Java. Vanaf JDK6u10 is er op dat vlak veel verbeterd en dingen die bij de oude Applets voor veel problemen zorgde (grote JVM download, wazige updater die tien-tallen verschillende versies op je systeem zette, trage opstart) zijn nu veel beter geregeld.

[Reactie gewijzigd door flowerp op 23 juli 2024 10:40]

[Dreamvoid]

Waar ligt dan de toekomst van Java?
Sowieso nog steeds de serverside.

Klopt, maar dat betekent steeds vaker dus alleen maar GNU/Linux. Op Windows servers (en dat zijn er ook veel) is .NET een veel logischer keus. Wie nu met C#/.NET ontwikkelt zal niet over gaan naar Java: de .NET trein gaat veel sneller, is ook mega in de enterprise markt, en heeft veel minder de (overal hier genoemde) versie-hell te maken. Java komt steeds meer in een server ghetto terecht, en dat is niet waarom mensen ooit zo optimistisch over de toekomst van Java waren:
- tien jaar geleden waren Java applets de manier om RIA's te maken. Die markt is, zo kunnen we wel concluderen, verloren aan Silverlight, Flash en, vooruit, HTML5.
- de markt voor desktop apps is ook al verloren, doordat de twee grote desktop platforms Windows en OS X met Cocoa en .NET veel sneller doorontwikkelen. De meeste Linux desktop software wordt niet in Java gedaan: echte kerels hacken de boel native aan elkaar, en niemand krijgt al die onafhankelijke neuzen in 1 (Java) richting. Google heeft het niet eens geprobeerd.
- de markt voor J2ME mobile apps is met de opkomst van smartphones ook weg. Hun laatste moderne mobile platform (Blackberry OS) stapt met BBOS 8 over op Adobe's Air framework.
- Android heeft dankbaar alle werk van Sun gratis opgepikt en zijn eigen fork begonnen met Dalvik, en kijkt niet meer om. Oracle probeert er via de rechtbank achteraf nog wat geld uit te slepen, maar het is duidelijk dat Google geen cent voor Java wil betalen. Bovendien, echte kerels (daar zijn ze weer) coden Android native.

Het is jammer wat er met Java is gebeurd want het is een prachtig platform. Sun heeft de boel laten versloffen: geldgebrek. Dat gebeurt er als je alles gratis weggeeft. Of Oracle te laat is, ik weet het niet. Hun focus is duidelijk serverside, dus ik ben bang dat Java inderdaad de komende jaren alleen achter de schermen op servers een toekomst heeft. Dat is gevaarlijk, want je moet wel een kritische massa aan nieuwe devs blijven trekken. Apple heeft met Cocoa/Obj-C goud in handen: iedere jonge developer (met een Macbook, iPhone en iPad) vindt het sexy as hell en wil erin coden.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 10:40]

[flowerp]

Klopt, maar dat betekent steeds vaker dus alleen maar GNU/Linux. Op Windows servers (en dat zijn er ook veel) is .NET een veel logischer keus

Dat is waar, maar ik zou het iets anders formuleren. Een server is sowieso logischer om op GNU/Linux te hebben draaien (niet alleen Java, maar ook PHP, Ruby, whatever). Windows is een prima OS voor de desktop, maar voor de server heeft het eigenlijk (IMHO) alleen zin voor .NET.

Java komt steeds meer in een server ghetto terecht

Ik weet niet of je dat echt een ghetto kunt noemen. Er verschuift steeds meer en meer naar de server. De meeste developers doen ondertussen serverside development. Misschien dat mobile dat tij nog iets kan keren, maar de server is dus tegenwoordig alles behalve een zielig plekje waar uitgerangeerde technieken nog een mogelijk kans hebben.

Als je als programmeur bij een hippe startup terecht komt, is de kans zeer groot dat deze een of andere web applicatie aan het maken zijn.

Apple heeft met Cocoa/Obj-C goud in handen: iedere jonge developer (met een Macbook, iPhone en iPad) vindt het sexy as hell en wil erin coden.

Absoluut waar, maar voor mobile biedt "Java" toch wel flink wat weerstand via Android. Okay, dit is dus zoals je zelf ook al zegt niet officieel Java, maar praktisch gezien toch wel. 99% van de Java skills van mensen en de meeste tools vertalen zich direct naar Android. Qua gevoel is Android voor velen net zoiets als b.v. Spring op de serverside. Het is dan wel niet van Oracle zelf, maar het is wel degelijk Java.

Apple lijkt tot dusver (in tegenstelling tot MS met .NET), geen enkele poging te doen om Cocoa/Obj-C iets op de server te laten doen. Ze concentreren zich volledig op desktop/mobile. Waar Sun juist voor die markt de boel heeft laten versloffen, doet Apple dat voor de serverside. Ze hadden wat troeven en potentie in handen, maar hebben dat stuk voor stuk laten vallen.

Eigenlijk zijn beide dus grotendeels bij hun roots gebleven. Sun is altijd een network/server bedrijf geweest, en dat is ook waar ze met Java het grootste succes hebben gehaald. Voor Oracle geldt dat ook.

Apple is van oudsher juist een desktop bedrijf dat sinds eind jaren 90 zich volledig is gaan focussen op de consumenten markt. En dat is dan ook precies de markt waar ze met Cocoa/Obj-C het grootste (en dus enige) succes hebben.

[Dreamvoid]

Een server is sowieso logischer om op GNU/Linux te hebben draaien (niet alleen Java, maar ook PHP, Ruby, whatever). Windows is een prima OS voor de desktop, maar voor de server heeft het eigenlijk (IMHO) alleen zin voor .NET.

Dat kan je vinden (en daar ben je zeker de enige niet in op T.net), maar de kopers denken er helaas anders over. Windows servers zijn inmiddels 75% van de totale server markt (in aantallen) en net onder de 50% in omzet (logisch, want de doorsnee Windows server is goedkoper dan bv een IBM z/OS mainframe). Je kan over die cijfers bakkeleien, maar zelfs al was het maar de helft dan zijn dat een hoop platforms voor .NET development.

En ja, de kip of het ei: wordt er zoveel in .NET gedaan omdat de Windows servers worden gekocht voor de native applicaties, of vinden devs .NET zo mooi dat ze Windows servers willen? Koopt iedereen Linux servers voor Apache/etc en hangt daardoor voor serverside applicaties al snel aan Java, of pushen verstokte Java fans Linux als serverplatform? Ik durf het niet te zeggen.

Maar goed, Java is net als .NET als een server en client platform begonnen. .NET is dat nog steeds, maar Java zit alleen nog op de server. En dat is zonde. Al heb je wel gelijk dat voor elke hippe startup met een HTML5 webservice of iOS App een backend in Java nodig is. Dat zou de toekomst van Java veilig kunnen stellen, maar gaan dat soort bedrijfjes niet eerder met Ruby On Rails (ook nieuw en hip) klooien?

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 10:40]

[flowerp]

Maar goed, Java is net als .NET als een server en client platform begonnen. .NET is dat nog steeds, maar Java zit alleen nog op de server. En dat is zonde

Microsoft heeft het natuurlijk niet verkeerd gedaan. C# is sterk verbeterd sinds het is afgesplitst van Microsoft's Java versie en zowel in .NET als het ASP.NET gedeelte zitten veel mooie dingen.

Aan de andere kant is de situatie met Cocoa en .NET voor op de desktop toch wel heel anders als Java.

Zowel Apple als Microsoft hebben Cocoa resp. .NET groot gemaakt op hun eigen platform. Apple heeft simpelweg Cocoa/Obj-C verplicht gesteld voor ontwikkeling op de iPhone en iPad en als primaire 'native' toolkit voor OS X. Ook Microsoft heeft .NET als primary toolkit voor Windows apps bestempeld. Waar er alternatieven zijn (b.v. Qt op OS X en Windows). lopen deze altijd achter op de laatste look 'n feel van nieuwe versies van het OS.

Het zou beter te vergelijken zijn als Apple en MS hun toolkits ook op andere platforms populair hadden weten te maken, maar dat is dus absoluut niet gebeurd (het is niet eens geprobeerd).

Sun had geen eigen populair desktop product. Er was Solaris, maar dat werd op de desktop alleen nog in enkele labs gebruikt. Het was dus niet echt mogelijk om Java als native of default desktop toolkit te bestempelen ergens.

Al heb je wel gelijk dat voor elke hippe startup met een HTML5 webservice of iOS App een backend in Java nodig is. Dat zou de toekomst van Java veilig kunnen stellen, maar gaan dat soort bedrijfjes niet eerder met Ruby On Rails (ook nieuw en hip) klooien?

Ruby zelf is trouwens zeker niet nieuw. Het is van 1995, nagenoeg even oud als Java dus. RoR is flink nieuwer (2005) maar de hip-heid lijkt toch flink tanende. Aangezien je voor RoR toch Ruby nodig hebt, lijkt me de Tiobe language index voor Ruby een maat voor RoR populariteit: http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html

Je ziet ook dat Twitter grotendeels afstapt van Ruby. Dit terwijl juist Twitter zo rond 2007/2008 RoR toch een flinke boost van coolheid gaf. Ironisch gezien stapt Twitter voor een gedeelte juist over naar Java, maar ook naar Scala.

Maar goed, een gedeelte van de hippe bedrijfjes zullen inderdaad Ruby gebruiken, een gedeelte Scala en een gedeelte Java. Klaarblijkelijk is Java tot op heden toch nog steeds de meest gebruikte techniek voor zo'n backend. Het heeft wel wat marktaandeel moeten geven aan diverse andere technieken (waaronder .NET servers), maar de markt is groot genoeg en nog geen van deze andere technieken heeft echt een significant marktaandeel weten te veroveren.

Ik zie de toekomst van Java in het blijven veiligstellen van het serverside martkaandeel wat ze nu hebben (en dat is al moeilijk genoeg, want de concurrentie is moordend en de bloggers die Java onderuit proberen te halen zijn meedogenloos en vlijmscherp).

Wellicht kan Java zelfs een stukje aandeel terug veroveren, want na enkele jaren komen veel mensen er ook wel achter dat de blogs van destijds "Ruby is 100x meer productiever dan Java, want Java is absolutely crap", op z'n minst toch wat overdreven waren. Als een Ruby project eenmaal gegroeid is heeft het ook gewoon de problemen waar men Java van beschuldigde destijds en deze problemen lost Java zelfs een (flink) stukje beter op.

[Dreamvoid]

Het zou beter te vergelijken zijn als Apple en MS hun toolkits ook op andere platforms populair hadden weten te maken, maar dat is dus absoluut niet gebeurd (het is niet eens geprobeerd).

Op servers niet, maar op de desktop wel: Microsoft neemt de Silverlight client op OS X duidelijk erg serieus. Het is bijna de wereld op zijn kop, maar als ik nu een desktop-gerichte RIA zou moeten bouwen die op OS X en Windows moet werken (=99% van de desktop markt), dan zou ik 'm in Silverlight maken, niet in Java, Flash/Air of HTML5. Andersom doet Apple niets aan crossplatform, maar met hun explosieve groei en hun sterke gesloten ecosysteem concept denk ik niet dat ze dat heel erg belangrijk vinden.

Maar begrijp me niet verkeerd, ik ben geen Java basher, ik ben alleen bezorgd voor de toekomst. Oracle moet er echt werk van maken, want deze trend is toch niet hoopgevend, en dat is *ondanks* het megasucces van Android. Ik vind Java op het moment misschien nog wel het beste framework dat er is: het heeft zijn slechte kanten maar IMO wordt een goed security model het allerbelangrijkste voor de komende jaren, en Java heeft het beste (met .NET als goede tweede). Ik houd mijn hart vast voor HTML5: crossplatform is leuk, maar blind de browsers vertrouwen dat ze code goed sandboxen heeft nog nooit gewerkt. Cocoa heeft op iOS laten zien dat het zo lek als een mandje is en serieus verbeterd moet worden. Java heeft op de Blackberry daarentegen al tien jaar een fantastische track record qua security, en ik hoop dat RIM zich goed realiseert wat ze riskeren door naar Air over te stappen.

Interessant trouwens dat Ruby alweer stagneert. Zie ook dat Python (ook zo'n belofte) en PHP ook wat terugvallen. Overhyped, groeipijnen?

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 10:40]

[flowerp]

, ik ben alleen bezorgd voor de toekomst. Oracle moet er echt werk van maken, want deze trend is toch niet hoopgevend

Klopt, het is al een jaren lange langzaam neergaande trend, met enkele pieken maar telkens een volgende dal wat weer iets lager is.

Aan de andere kant kun je de graph ook lezen als dat begin 2000 er weinig alternatieven voor Java (en destijds C++) op de markt waren en deze samen dus een vrij hoog marktaandeel hadden.

De laatste 10 jaar is er meer (gezonde) concurrentie in de markt gekomen, waarbij Java zich nu aan het stabiliseren is rond de 19%. Geen alleenheerser meer, maar nog wel steeds de grootste.

Interessant trouwens dat Ruby alweer stagneert. Zie ook dat Python (ook zo'n belofte) en PHP ook wat terugvallen. Overhyped, groeipijnen?

Idd, deze meest directe concurrentie voor het 'populaire/hippe' nieuwe web applicaties segment (Ruby, Python en PHP dus) zag je allemaal eerst vrij snel stijgen maar nu allemaal net zo hard weer dalen. Tiobe had vorige maand hierover nog een klein stukje geschreven dat deze "web talen" idd in populariteit aan het afnemen waren.

Andere leuke trend die je er in kan lezen is dat C-achtige talen (C, Objective-C, C++, Java, C#) samen verreweg het populairst zijn. Dat is eigenlijk ook gunstig voor Java, want het betekend dat mensen relatief makkelijk op Java kunnen overstappen vanaf de andere populaire talen.

Ik houd mijn hart vast voor HTML5: crossplatform is leuk, maar blind de browsers vertrouwen dat ze code goed sandboxen heeft nog nooit gewerkt.

Dit is inderdaad even afwachten. Gaan het hele web echt naar client applicaties zoals nu op mobile m.b.v. HTML5 (waarbij de naam HTML eigenlijk niet meer van toepassing is) met de server slechts als 'data leverancier'? Gaat Silverlight of Java Applets hier nog een grotere rol in spelen?

Het zou een beetje de doodsteek zijn voor traditionele web frameworks zoals RoR, ASP.NET, JSF, Wicket en velen anderen. GWT valt hier dan een beetje tussen: hier schrijf je de client-side applicatie weliswaar in Java, maar deze wordt dan gecompiled naar Javascript en in de toekomst wellicht naar HTML5+javascript.

Of willen mensen hoe dan ook direct in HTML5 gaan programmeren en willen ze het niet gedegradeerd zien worden tot 'assembly taal' van het web?

In het laatste geval zou de rol van Java nog iets teruggedrongen worden en zou het hele web framework gebeuren weg vallen, maar dingen als JAX-RS, CDI, EJB, JPA, JMS, Bean Validation etc nog steeds zeer actueel blijven. Maar goed, dat blijft koffiedik kijken, want voor het zelfde geld gaat maar een percentage van de web apps voor rich clients en blijft een ander belangrijk percentage gewoon 'simpele' HTML uitserveren.

[Leejjon]

Dreamvoid: Apple heeft met Cocoa/Obj-C goud in handen: iedere jonge developer (met een Macbook, iPhone en iPad) vindt het sexy as hell en wil erin coden.

De hippe web designer die indruk wil maken met hoe mooi zijn mac eruit ziet misschien. Ik zat in een technische informatica klas (HBO) en de meeste deden .net, c/ c++ of java. Slechts een paar hadden een macbook.

[Reactie gewijzigd door Leejjon op 23 juli 2024 10:40]

[Verwijderd]

iOS = een gestripte OSX

[arjankoole]

En ik dacht te menen dat Oracle aan het proberen is om Java te gaan verkleinen of zelf helemaal afschaffen.

Alles behalve. Voor Oracle is java inmens belangerijk. als Oracle java zou schrappen, zou dat betekenen dat ze IBM de ruimte geven om ermee aan de haal te gaan, en dat is nou precies wat ze niet willen.

[mphilipp]

Lijkt me niet. Oracle heeft altijd meegewerkt aan de ontwikkeling van Java. Ze hadden ook hun eigen JVM (Jinitiator) zodat ze vooruit konden lopen. Die jini werd dan voornamelijk gebruikt voor hun eigen Java programmatuur. Het lijkt me nogal sterk dat ze van Java af zouden willen.

Volgens mij is dat weer zo'n stuk FUD uit het anti-Oracle kamp. Gelukkig zijn dat soort onzinnige uitspraken snel onderuit te halen.

[Joshua]

Tegenwoordig Oracle.

[YopY]

Multicore-support zit al sinds jaar en dag in Java en de standaard library (JDK?); dat het niet ondersteund wordt in de API's die voor smartphones enzo zit is niet de schuld van de Java taal.

[erikdenv]

Java ondersteunt misschien wel multicore maar de JVM waarbinnen de applicatie draait moet dat ook doen.
De JVM is wel platform-afhankelijk.

[latka]

Ja, en ook daar is het als sinds het begin ok. De meeste JVMs beelden een Java thread 1-op-1 af op een OS thread en bieden synchronisatie primitieven. Als je multithreading support dus niet in orde is dan is of je OS ruk of je applicatie is niet multithreaded gebouwd. Meestal het laatste dus (en daar kan een JVM niets aan veranderen).

[GrooV]

Android is java 1.5 compatible, dmv van Dalvik. Ik denk persoonlijk niet dat er snel een implementatie voor 1.7 (of 1.6) aangezien er features in zitten die voor Android gewoon niet relevant zijn.

[majoh]

Nieuwe versies waar het programmeren makkelijker en sneller wordt zijn altijd welkom. Al duurt het waarschijnlijk heel lang voordat ik er op mijn werk mee aan de gang kan. Op mijn werk zit ik nog lekker met 1.4 te kloten, omdat ze echt alleen upgraden als de servers waar de applicaties op draaien out of support raken...
Waarschijnlijk mag ik volgend jaar naar Java 5.

[flowerp]

1.4 is anno 2011 toch wel een beetje triest

Wat dat betreft kun je soms toch beter bij de iets kleinere bedrijven zitten waar men wel de agility heeft om redelijk up to date te kunnen blijven.

[DaSt1986]

Ohneeeee.... Beslist dat mijn werkgever wilt gaan upgraden naar deze nieuwe versie en dat resulteert altijd in slecht nieuws; in het begin lijkt het te werken, totdat iedereen ineens begint te roepen dat zijn of haar applicatie weer niet werkt, en dan moeten we weer JAVA combinaties gaan vinden die voor iedereen werkt. Dat hele JAVA zorgt hier iedere dag weer voor problemen

[YopY]

Joh? Wat voor problemen loop je tegenaan dan? Aangezien nieuwere Java versies meestal gewoon bytecode-compatible zijn met oudere versies, en je in de compiler aan kunt geven voor welke versie van Java je wilt compilen.

Andersom (Java 1.4 code op een Java 6 runtime draaien) moet ook geen probleem zijn.

[Reactie gewijzigd door YopY op 23 juli 2024 10:40]

[DaSt1986]

Ze zouden compatible moeten zijn inderdaad, maar heel veel applicaties (die we gecompileerd installen, niet zelf compilen) geven toch problemen. We hebben hier verschillende combinaties lopen momenteel: sommige computers hebben 1.6.22, sommige 1.6.22 en 1.5.26, andere week 1.6.22, 1.5.26 en 1.4.24, en ik ben er heilig van overtuigd dat we daar straat 1.7 bij gaat komen.

En ja, het wordt wel getest, maar in je kunt nooit de gehele productieomgeving nabootsen waardoor je zeker niet alle problemen kunt uitsluiten.

[swel]

Dat gebeurd alleen wanneer programmeurs de java code niet goed toepassen in hun project. Ik snap ook wel dat het lastig kan zijn om veel te moeten rewriten maar dat bespaard toch veel geld als later blijkt dat het anders mis gaat op de werkvloer.

[DaSt1986]

Nadeel is dat het over het algemeen geen homebrow software is Zelf opnieuw schrijven is dus helaas niet altijd mogelijk. Persoonlijk ben ik tegen het gebruik van Java binnen een productieomgeving, voornamelijk vanwege dit soort problemen. Backwardscompatibility is altijd al een probleem geweest, niet alleen bij JAVA trouwens, en zal (in mijn visie) ook nog wel een flinke tijd een probleem blijven. Misschien toch maar langzaam tijd dat alles overgaat op Webappjes.

[Thundy]

Het lijkt er toch een beetje op dat je gewoon niet weet waar je over praat.
Zeker als je stelt dat je "tegen Java in een productie omgeving" bent terwijl iedereen die echt iets van Java af weet, weet dat de echt grote jongens van deze wereld juist Java-based solutions gebruiken voor hun servers om aan de kwaliteitseisen/non-functionals te kunnen voldoen waar andere platformen gewoon niet tegenop kunnen.

Wat betreft jou posts lijkt het erop dat je uit een soort van desktop beheer achtergrond in aanraking met Java bent gekomen, maar zelfs een beetje fatsoenlijke Java desktop app levert gewoon een eigen private VM mee waardoor je nul komma nul versie problemen kan krijgen. Bij mijn weten is het juist .NET die .dll bestanden centraal plaatst/registreert.

Als je echt een gefundeerde mening over Java wilt ventileren ga dan eerst eens wat echt onderzoek naar verschillende platformen doen en baken dit op zijn minst af tot een doelgebied zoals embedded/mobile/desktop/server.

[dwilmer]

Webapps zijn bijna net zo erg: alles moet in Chrome, Firefox, Safari en vier versies van IE werken. De server heb je wel onder controle, maar van de frontend wordt ook veel verwacht, in veel verschillende omgevingen.

[Dreamvoid]

...en dus schuift binnen bedrijven de ontwikkeling steeds vaker naar C#/.NET. Least of all evils.

[freaky]

Het schuift daar vooral naar toe omdat het makkelijker is dan VB/C++.

Het is nl. niet zo hard te stellen dat het 'least of all evils' is. Verre van. Wat MS cross-platform noemt is cross-platform binnen windows zelf. Mono is best aardig, maar veel van de Windows .NET apps draaien er niet (behoorlijk) in en je verliest dus de compatibiliteit met andere OS'en die java wel heeft.

[Fuzzillogic]

Ja dat werkt ook zo lekker op non-windows-machines.

[Ce tan]

Dat is een veel gehoord argument tegen .NET maar in feite niet zo'n groot probleem. Het is niet zo dat bedrijven jaarlijks overstappen van Windows naar Unix of Linux en weer terug ...

Als een bedrijf kiest voor Windows dan is .NET inderdaad een relatief prettige, goed werkende keuze.

[Verwijderd]

Dat is een veel gehoord argument tegen .NET maar in feite niet zo'n groot probleem. Het is niet zo dat bedrijven jaarlijks overstappen van Windows naar Unix of Linux en weer terug ...

Als een bedrijf kiest voor Windows dan is .NET inderdaad een relatief prettige, goed werkende keuze.

Klopt wel.. Maar je moet niet naar volgend jaar kijken maar ver in de toekomst en dan zie ik dat linux wel degelijk als een optie voor bedrijven.. En dan is het wel belangrijk zoveel mogelijk crossplatform te houden en dan is java toch de beste oplossing..

[SuperDre]

LOL, alsof Webappjes geen compatabiliteits problemen hebben, hell de kans is zelfs dat daar meeeer problemen optreden dan bij java zelf.. want vergeet niet dat veel browsers verschillende javascript-engines gebruiken welke allemaal ook dus niet alles hetzelfde interpreteren..

[Verwijderd]

LOL, alsof Webappjes geen compatabiliteits problemen hebben, hell de kans is zelfs dat daar meeeer problemen optreden dan bij java zelf.. want vergeet niet dat veel browsers verschillende javascript-engines gebruiken welke allemaal ook dus niet alles hetzelfde interpreteren..

Wil niet veel zeggen maar als ze HTML5 gebruiken + java dan kom je al een heel eind.
Ten tweede kan je voor een goede browser kiezen aka firefox.. en daar javascript en dergelijke op coden..
Dan heb je een goed crossplatform applicatie

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:40]

[ath92]

Totdat Firefox met een nieuwe versie komt (en dat gebeurt nogal vaak de laatste tijd) en er toch een aantal dingen net iets anders blijken te werken. Want hoe goed een browser ook is, op dit moment voldoet geen enkele aan alle standaarden.

HTML5 wordt bijvoorbeeld in nog geen enkele browser volledig ondersteund, dus ook dat zal later voor problemen gaan zorgen.

[dasiro]

probeer jij maar eens als klant van een grote keet waarvan je verplicht bepaalde software moet gebruiken om een wijziging te bekomen. Je krijgt dan gewoon als antwoord: dit zijn de vereiste specificaties en iets anders wordt niet ondersteund.

ik heb atm een versie van de laatste 3 generaties op m'n deployed machines staan: een 1.4.x een 1.5.x en een 1.6.x
het is sneller en makkelijker om ze allemaal te installeren, dan alle mogelijke fouten te gaan troubleshooten en herleiden tot een bepaalde versie

[Verwijderd]

Helemaal mee eens. Wij maken zelf geen software en kunnen dus ook niets aanpassen. Dit resulteert in 4 verschillende java versies en allerlei workarounds zodat al je applicaties maar blijven werken.

Java is gewoon de eerst applicatie die we gaan virtualiseren en packagen bij de behorende app.

Compatabiliteit is gewoon écht ruk bij java. Ik ben echt heel veel tijd kwijt om dit te troubleshooten, meer nog dan met stukke Windows updates...

[eijckron]

Ik bouw al 10 jaar Java applicaties en herken dit helemaal niet. Maar als je issues hebt met software en Java versies dan rol je toch gewoon applicatie en JRE samen uit. Je kunt zonder problemen een JRE samen met de applicatie packagen en distribueren. Eventueel kun je nog gebruik maken van een van de tools waarmee je een launcher kunt samenstellen die de applicatie opstart met de bijbehorende JRE.

Succes met packagen.

[alt-92]

Ik bouw al 10 jaar Java applicaties en herken dit helemaal niet.

Dan mag je ook eens bestaande apps gaan onderhouden in enterprise omgevingen, lijkt me een leerzame ervaring want dáár kom je wel degelijk het soort problemen tegen waar Mecallie aan refereert.
Die miljoenen genererende LoB Enterprise solution van diezelfde Oracle kun je niet zomaar overzetten naar een nieuwe Oracle 11 database en dus zit je vast aan een lagere JRE versie omdat die app - nota bene van hetzelfde Oracle - dat weer niet vreet.

[pgussow]

Dat Oracle zelf problemen heeft met Java versies kun je niet vergelijken met de Java stream. Ook ik herken de problemen niet. De enige plek waar ik dit zie is software van IBM en van Oracle.

[Ortep]

De enige plek waar ik dit zie is software van IBM en van Oracle.

Juist, en laat dat nu juist de software zijn die door allerlei multinationals wordt gebruikt. Ik ken zat IT mensen uit die wereld die groen worden als ze het woord Java horen. De HR afdeling heeft de ene versie nodig, de Finance afdeling weer een andere en Inkoop weer een 3e versie. En dan komt er iemand op het idee een urenverantwoordings systreem uit te rollen voor alle mederwerkers...oeps...dat heeft weer een andere versie nodig. En natuurlijk werkt dat niet allemaal samen en kan je dus niet je HR systeem gebruiken als je ook nog wat inkoop te maken hebt.
En die software kan je niet 'even aanppassen' in een bedrijf met 300 vestigingen over heel de wereld

[Reactie gewijzigd door Ortep op 23 juli 2024 10:40]

[latka]

Ik ken het probleem alleen als er standalone applicaties gebruikt worden (dus met een GUI lokaal). Omdat de standaard look'n feel vaak net niet helemaal je van het is gaan ze de GUI 'opleuken' vaak via ongedocumenteerde APIs en ja, dat werkt de volgende keer niet meer.
Server side Java (web-apps dus) gemaakt voor J2EE 1.3 draaien hier nog steeds vrolijk op Java 1.5/1.6 zonder problemen. Geen hacks en truuks met classloaders gewoon code die alleen de requirements implementeerd en niet probeert allerlei fancy truuken in Java te doen om 2 regels code en een SQL statement te besparen. Nu Java een beetje het nieuwe Cobol is zie je ook steeds meer een trend naar behoudend programeren en aandacht voor de kwaliteit van de software ipv. de time-to-market. Hopelijk helpt dit ook om de workarounds/hacks e.d. in de perken te houden.

[eijckron]

Ik heb mijn JEE aandeel echt wel gezien. Maar als je vast zit aan een lagere JRE versie vanwege de gebruikte database zie ik het probleem dus niet. Het is gewoon geen enkel probleem om eindeloos veel verschillende JRE versies te gebruiken. Bepaal wat werkt met de applicatie en gebruik die versie. Updaten doe je alleen als een andere JRE versie je voordelen geeft in de vorm van performance, betere security etc.
Zeker JEE applicaties zijn zeer eenvoudig met een specifieke Java applicatie te draaien, simpelweg de JAVA_HOME referentie van de applicatie server goed zetten.

[Dreamvoid]

Het gebruik van oude Java versies brengt wel de nodige risico's met zich mee - je mist allerlei gefixte lekken.

[alt-92]

Het is gewoon geen enkel probleem om eindeloos veel verschillende JRE versies te gebruiken. Bepaal wat werkt met de applicatie en gebruik die versie.

Side by side gaat niet sinds J2RE 1.60_12 .
Is een echte versieupgrade.

[latka]

Niet de installer gebruiken. Heb hier gewoon een directory met alle JVMs sinds het jaar nul (van Sun, IBM en JRockit) en met het veranderen van JAVA_HOME switch je de hele boel over.

[alt-92]

En dat kan een standaard enduser (dus niet devver) in enterprise land niet.

[Xorsist]

Probleem lijkt in deze op te treden bij een werkgever welke bleeding edge wil volgen. Dan heeft het weinig zin om een JRE te packagen.
Dat je inderdaad met de filosofie zoals je aanhaalt deze problemen kunt voor komen is zeker waar.

[flowerp]

Ze zouden compatible moeten zijn inderdaad, maar heel veel applicaties (die we gecompileerd installen, niet zelf compilen) geven toch problemen.

Er bestaat software die inderdaad niet op nieuwere Java versies wil draaien, maar het is toch wel zeldzaam hoor.

Zelf draai ik ons gehele platform (enkele 100.000'en tot 1000.000 LOC) al een poosje op de beta builds van Java 7 en alles draait gewoon en alle unit testen gaan goed.

Met JDK 6 destijds het zelfde, vanaf de hogere builds (ongeveer 110+) draaide alles gewoon en vanaf de eerste release versies dus helemaal.

Just to be sure testen we wel altijd met een hele specifieke versie van Java SE (bv JDK6u24) en gebruiken we ook precies die waarmee is getest in productie, maar eigenlijk slaat het nergens op want het is heel erg lang geleden dat we een echte incompatibiliteit mee hebben gemaakt veroorzaakt door de JDK. In principe draait het gewoon op elke versie.

[FireFly]

Flowerp:
Zo zeldzaam zal het niet zijn, maar het ligt meestal wel aan de programmeur die een of andere truuc gebruikt die dan eerder bij toeval werkt binnen een bepaalde versie. Soms gebruiken ze zelfs een exploit om iets te doen werken, dit zal dan ook niet meer werken bij een andere versie waar dit gefixt is.

Verder heb je ook nog nieuwe OS'en die roet in het eten kunnen gooien met oudere Java versies of die ene call niet meer toelaten (door UAC bv). Ik ben zelf geen programmeur voor Java maar ik ken wel de gevolgen van zulke apps die niet meer werken na een versie upgrade.

We hebben recent nog een terugdraai moeten doen naar 6u12 omdat er toch weer een app was die niet met een recentere versie wou werken (net een app die door een groot aantal mensen in het park gebruikt werd, de ontwikkelaars gaven ook geen support op nieuwere versies). Dus als sysadmin sta je er wel bij te kijken natuurlijk en kan je niet anders dan terugdraaien en hopen dat de ontwikkelaars (inhouse of outhouse, maakt al niet uit) toch eindelijk eens die speciale functies er uit slopen zodat upgraden wel altijd blijft gaan.

Zoals Dreamvoid aanhaalt, upgraden is wel een noodzaak in oogpunt van beveiliging, waar we als sysadmin ook aan moeten voldoen. Talk about being between a rock and a hard place :-)

[Neverwinterx]

De backwards compatibility issues tussen versies zijn meestal miniem. Als je er vaak tegenaan loopt, ben je 9 van de 10 keer bezig met gore code (reflectie dingen bvb of op verkeerde wijze de versie van java checken) of schrijf je code die steunt op bugs die ondertussen gefixt zijn. Schrijf degelijke code en je hebt zelden problemen met compatibility.

[Reactie gewijzigd door Neverwinterx op 23 juli 2024 10:40]

[MegaTronics]

Wij gebruiken op de zaak Prisma voor het aansturen van diverse printers en mooi dat die niet meer werkt met de laatste java 6 build 26. Terug naar build 25 en het werkt allemaal weer.

[YopY]

Zoiets had ik ook, soms worden er inderdaad in minor versies bugs geïntroduceerd, om wat voor reden dan ook.

[latka]

Klinkt meer als een ranzige applicatie dan een JVM regressie. Als je de release notes bekijkt is er precies 1 regressie opgelost voor Filemaker. Verder zijn de timezones files ge-update en is het versienummer verhoogt. Deze regressie zat in .24 en .25 dus als je app werkt op .23 en .25 maar niet op .26 dan heb je te maken met een wel heel bijzondere applicatie. Vendor inlichten (issue aan laten maken) en geen genoegen nemen met 'die ondersteunen we niet' want .26 is de security release die Oracle aanraad als je support wilt hebben. Dus tenzij de vendor bereid is JDK .25 te ondersteunen ga je nu zonder support door het leven.

[MegaTronics]

We mogen al blij zijn dat Prisma 4.02/4.04 werken met Java 6 build 25. De vorige versie, Prisma 3, werkt nog het beste met Java 4 build 8.

[Reactie gewijzigd door MegaTronics op 23 juli 2024 10:40]

[joco]

wij deployen ook over heel veel klanten uit, en ik moet zeggen dat gemiddelde gezien de java updates prima doen,
Soms heeft Sun/Oracle iets "gefixed" dat zeer grote effecten heeft/had op onze applicatie bv java 6_u19.. Dat kwam hard aan voor een update release! (niks werkte meer, webstart behavior is totaal veranderd toen)

Maar meestal is het totaal geen probleem, Ik draai zelf onze software nu al een tijdje met Java 7 en het draait prima, wel moest ik 1 ding fixen maar dat was een bug in onze eigen code die in java 6 niet te voorschijn kwam..

[Verwijderd]

in het begin lijkt het te werken, totdat iedereen ineens begint te roepen dat zijn of haar applicatie weer niet werkt, en dan moeten we weer JAVA combinaties gaan vinden die voor iedereen werkt.

Dat heet Early Adapter zijn en dat doet pijn, dat weet iedereen

Noem is een stuk software waar het upgrade traject niet zo gaat als je de latest en greatest bleeding edge meteen gaat draaien in je productie omgeving. Windows ? Linux ? FreeBSD ? Microsoft Office ? Internet Explorer ? Firefox ? .NET Runtime ? Allemaal hetzelfde risico.

Je moet zulk soort dingen altijd eerst testen. Je weet nooit van te voren hoe jouw combinatie van software gaat reageren op een nieuwe versie van een bepaald component.

[Verwijderd]

Vooral vroeg beginnen met testen, zoals met een RC dus, voordat je werkgever weet dat ie uit is :-)!

[Verwijderd]

Al de lekken die in het artikel dat je aanhaalt worden genoemd zijn uiterlijk in versie 1.6.0_20 opgelost, welke uitkwam in april 2010. Het artikel komt uit oktober van hetzelfde jaar, en alle problemen waren dus ruim voor de publicatie van het artikel opgelost.

Alle niet triviale software heeft bugs, en een deel daarvan zijn veiligheidsrisico's. Als je per-see geen software wil gebruiken die wel eens beveiligingsproblemen bevat, en stel ik voor je computer bij het grof vuil te stallen.

[hellfighter87]

dit is dan java 1.7? of zit ik weer verkeerd te kijken want ik weet nog dat we met 1.4 programmeerden op school en 1.5 halverwege het jaar uitkwam.

in ieder geval gebruikt java maar een wazige versie nummering

[Reactie gewijzigd door hellfighter87 op 23 juli 2024 10:40]

[Cristan]

Ze hebben 1.5 hernoemd naar Java 5 en dit vanaf dat moment aangehouden. Maar als je "java -version" in je command line uitvoert, krijg je alsnog weer de oude notatie

[Robtimus]

De interne versies zijn inderdaad gewoon 1.5, 1.6 en nu 1.7. De externe versies zijn 5.0 (met .0), 6 en nu 7.

[johnydoe]

Valt wel mee hoor, ze hebben de 1. ervoor gewoon laten vallen. Dus ja, dit is in principe 1.7, maar daar heeft niemand het meer over. Java 7 bekt gewoon ook lekkerder

[Stannieman]

Ik was altijd voorstander van het gebruik van de laatste versies van software etc.
Nu denk ik wel dat het, zolang je niet online gaat of er risico is voor malware, je beter bij oudere goed geteste versies kan blijven.
Sinds deze week werk ik als jobstudent bij het distributiecentrum van nike en op onze afdeling alleen staan al minstens 30 computers. Allemaal voorzien van iets dos-achtigs van IBM (enkel letteres op scherm, geen grafische pracht), copyright 2005.
Die computers draaien 24/24 6/7, en er is deze week nog geen enkele geweest die iets abnormaals deed, alle printers en systemen worden altijd perfect aangestuurd, en de computers hebben altijd gelijk. Als er iets mis is is het altijd iets menselijk of mechanish.
Ik ben er zeker van dat dit geldt voor elk bedrijf waar soortgelijke toepassingen zijn.

In zulke gevallen is het dus beter om met een soort oud dos gedoe te blijven zitten wat er ooit specifiek voor ontworpen is.

[Frank-NL]

Wat heeft dit met Java te maken dan? Waarschijnlijk bedoel jij AS/400 en daar kunnen net zo goed bugs in zitten.

Nieuwe software kan je ook gewoon testen voordat je die in productie neemt. Sterker nog, je zou wel gek zijn als je het niet deed.

Dat er oude productiesystemen zijn die goed werken is geen argument tegen nieuwe software.

[iMispel]

Ik hoop van harte dat die PC's niet aan een netwerk hangen. Systemen van 6 jaar geleden => zo lek als een zeef. Anderzijds: Op oude hardware nieuwe software draaien is ook niet ideaal, zoals bij ons het geval: Computers moeten op het netwerk (logging), en mogen niet vernieuwd worden - anders krijgen we timing issues met onze sequenties (waarvan de oorspronkelijke maker natuurlijk al elders werkt ) => gevolg: Systeem zo traag als dikke kak door een trechter en frustratie alom als er iets gewijzigd moet worden (en dat gebeurt dikwijls... )

Ik kan best geloven dat men in productieomgevingen weigerachtig staat tov updates...

[Stannieman]

Alles van het hele centrum hangt aan elkaar, maar ik denk dat het wel afgezonderd is van de buitenwereld.
Zijn eigenlijk allemaal terminals waarop je snel kan zoeken waar een bepaald product is, of de doos waarin het hoort te zitten.

@ Frank-NL: heeft niks met java te maken, ik wou gewoon zeggen dat het inderdaad zo is dat het in sommige gevallen veel beter is niet te updaten.
Als er aan de installatie niet enorm veel verandert zal het waarschijnlijk binnen 10 jaar nog steeds werken met hetzelfde systeem.

[r2504]

Grappig hoe mensen IBM i (aka AS/400) omschrijven... trouwens de machine kan ook perfect Java draaien (meerdere JVM's simultaan), heeft verder ook Apache, PHP, MySQL, ... maar is inderdaad een stom oud ding

[Stannieman]

Sja ik had het nog nooit met eigen oogen gezien, en het beeld is daar volledig opgebouwd uit tekst (al dan niet met kleur), dus zeg ik maar iets "DOS-achtig".

Ik ben er vandaag zelfs achtergekomen dat die dingen screensavers hebben , vergelijkbaar met de standaard in Vista.

[manuarmata]

een AS/400 sessie die kuren krijgt is nochtans geen uitzondering hoor. zeker de laatste cliënt software heeft bij ons geregeld vastlopers tijdens het inloggen.