Oracle brengt eerste OS X-versie van Java Development Kit uit

Oracle heeft de eerste versie van zijn eigen Java Development Kit voor Mac OS X beschikbaar gesteld. De release van de eerste OS X-versie valt samen met het uitkomen van de Java SE 7 Update 4 en de JavaFX 2.1-versies.

In de versie voor Mac OS X heeft Oracle de sdk JavaFX, versie 2.1, inbegrepen. Oracle had in oktober vorig jaar, op de JavaOne-keynote, al beloofd Java voor OS X uit te brengen. De Java SE 7 Update 4 heeft een beter garbage-collection-algoritme, genaamd Garbage First. Ook zou Oracle verbeteringen hebben toegevoegd in de Java Virtual Machine, door de Oracle Java HotSpot JVM en de Oracle JRockit JVM samen te voegen. JavaFX 2.1 ondersteunt nu ook audio en video in h264/avc- en aac-formaat.

De vierde update van Java Runtime Environment 7 voor OS X, de virtuele machine die nodig is om Java-code uit te voeren, is er nog niet. Die zou later dit jaar verschijnen. Sinds Mac OS X 10.7 levert Apple standaard geen Java meer mee, maar was het wel te downloaden via Apples software-updater. Het bedrijf wil dat softwareontwikkelaars native code gebruiken in plaats van cross-platform-Java-code. Waarom er zo veel tijd zit tussen de laatste versie van Apple en de eerste van Oracle is niet bekend.

Reacties (35)

[Madcat]

Zal weer een boost worden om nieuwe malware te maken voor OSX.

Ben ik de enige OSX gebruiker die eigenlijk zo min mogelijk nog met Java te maken wilt hebben?
Heb zelf twee weken geleden juist Java compleet verwijderd van mijn macs zodat er geen nieuwe malware binnen kan komen, de enige manier om het gat echt te dichten

[TvdW]

Och, alles dat je installeert kan fouten hebben. Java heb je nou eenmaal nodig voor bepaalde dingen. Wat ik echter wel doe is Firefox gebruiken (bèta) met in about:config een instelling waardoor Java-applets eerst mijn toestemming nodig hebben. Datzelfde geldt ook voor Flash en andere plug-ins. Stukken veiliger

-edit-
De instelling die je bij [url=about:config]about:config[/url] daarvoor kunt vinden heet "plugins.click_to_play". Helaas is dit niet compatibel met websites die een Flash- of Java-plugin gebruiken op de achtergrond. 't zijn er niet veel, maar ze zijn er wel.

[Reactie gewijzigd door TvdW op 25 juli 2024 09:51]

[BoringDay]

tja ik weet ook niet wat Adobe aan het doen is maar die flash player zuigt echt werkelijk.
meer dan de helft van youtube filmpjes werken hierdoor niet meer.

Dan heb ik ook van dan maar niet! laat HTML 5 maar komen

[johnkeates]

Je weet dat click2flash en click2plugin achtige dingen al jaren bestaan?

[David Mulder]

De java browser plugin staat alles behalve gelijk aan java in het algemeen waar je iedere paar minuten mee in aanrijking komt. Open Google = > u just touched java, Open 1 van de vele desktop applicaties die in java zijn gemaakt = > u just touched java, Open android => u just touched java. Maja, point is, 80% zeker ofzo dat je nog steeds java op je pc hebt staan, want op mac levert (net zoals op windows) iedere applicatie z'n eigen libraries mee vaak (zoals java).

[johnbetonschaar]

Onduidelijk verhaal, volgens mij haal je een paar dingen door elkaar.

Er zijn best nog wel wat applicaties in Java geschreven tegenwoordig, maar het worden er wel steeds minder. Vooral als je zelf Java ontwikkelt zal je veel Java tools tegenkomen, maar op de desktop voor de rest niet vaak meer, vooral niet op Windows of OS X. Op Linux iets meer maar ook niet veel.

Java applets voor in de browser zijn ook al een zeldzaamheid inmiddels, dus daar zul je er ook weinig meer mee in aanraking komen.

Javascript in de browser heeft helemaal niks met Java te maken.

Waar nog wel heel veel Java gebruikt wordt is aan de server kant, maar voor desktop toepassingen is het min of meer passe, Microsoft heeft zijn eigen runtimes, op OS X gebruikt iedereen Cocoa.

Wat mij betreft een goede ontwikkeling, Java applicaties vielen altijd enorm uit de toon wat integratie met de rest van het systeem betreft, en door hun lelijke en trage user interfaces die zich totaal niet aan de UI guidelines hielden. Ik zal het zeker niet missen op de desktop.

Helaas moet ik er voor het werk nog regelmatig dingen mee ontwikkelen omdat er nog zoveel legacy spullen voor zijn en omdat je voor bepaalde cross-platform server taken niet zo veel betere alternatieven hebt, vooral niet als er legacy code bij komt kijken.

@ash42
Indien goed ontwikkeld zien Java applicaties er inderdaad vaak net zo uit als native applicaties, maar daarmee integreren ze nog steeds minder goed met het OS. Denk aan keyboard shortcuts, hoe dingen als drag & drop werken, hoe dialog boxes opgebouwd zijn, enzovoorts. Java applicaties die daar helemaal voor aangepast zijn voor verschillende OS-en zijn zeldzaam.

Ik ben verder geen Java GUI expert (probeer zelf zo veel mogelijk van Java weg te blijven want ik vind het een erg onprettige ontwikkeltaal om mee te werken), maar is Swing een paar jaar geleden niet ook alweer vervangen door SWT? Swing heb ik zelf nog wel gebruikt, en dat was ook niet bepaald een feest, traag en omslachtig vooral.

[Reactie gewijzigd door johnbetonschaar op 24 juli 2024 23:51]

[Anoniem: 456683]

Wat mij betreft een goede ontwikkeling, Java applicaties vielen altijd enorm uit de toon wat integratie met de rest van het systeem betreft, en door hun lelijke en trage user interfaces die zich totaal niet aan de UI guidelines hielden.

Dit gold inderdaad voor de eerste Java desktop GUI library, AWT, die als een soort after-thought aan Java is toegevoegd. Al sinds versie 1.2 uit 1998 (!) is de standaard GUI library Swing, die voor ieder platform gewoon gebruik maakt van de native widget set. Java applicaties zien er op de Mac dan ook gewoon uit als MAC applicaties, op Windows gewoon als Windows applicaties, etc. Dat je 14 jaar na dato nog steeds bij zo'n beetje ieder artikel over Java dit soort opmerkingen tegenkomt zegt dan ook genoeg over de impact die AWT heeft gehad

Dat gezegd hebbende zie je volgens mij inderdaad niet veel desktop Java applicaties meer. Dat is verder ook niet erg, Java is vooral groot op het gebied van enterprise applicaties die op servers draaien en op het gebied van embedded software (veel smartcards draaien bv op Java). Eindgebruikers hoeven Java dan meestal ook niet meer op hun machines te hebben staan. Maar dat gaat over de Java runtime. Dit artikel gaat over de SDK en ik weet dat Mac gebruikende Java developers dan ook blij zijn met dit nieuws.

[GewoonWatSpulle]

Open Google you just touched java? Script? Je weet dat dat geen Java is hè?

[TvdW]

Ik denk dat hij bedoelt dat Google in Java geschreven is.

[latka]

Delen van Google wellicht, verder python, C++ en nog wat zaken. Maar wat is de relevantie van dit bericht met betrekking tot de technologie die op de server gebruikt wordt. Dat is de echte vraag natuurlijk.

[Vinand]

Malware te vermijden voor MacOS door java te verwijderen is hetzelfde als internet afsluiten om zo malware te vermijden voor windows.

Zo een beetje bijna alles draait gedeeltelijk of grotendeels op Java. Dus je hebt zomaar een grote functionaliteit uit je Macbook gesloopt.

Het is Apple die met OSX Java (die ze zelf onderhouden) een slecht update beleid volgde waardoor die flashback op macbooks zijn grote ronde heeft kunnen doen. De gaten waren al maanden gedicht voor Windows...

[arjankoole]

Zo een beetje bijna alles draait gedeeltelijk of grotendeels op Java. Dus je hebt zomaar een grote functionaliteit uit je Macbook gesloopt.

Dat is niet geheel waar, standaard komt Lion al niet meer met Java.

Maar de keerzijde is weer dat als je ook maar iets doet wat java nodig hebt, Lion wel volautomatisch Java installeert voor je. (Cyberduck, een propulaire (s)FTP tool uit de Mac App Store bijvoorbeeld -> Java)

De gaten waren al maanden gedicht voor Windows...

Ik weet uit ervaring dat een gat op platform 1 (windows) nog niet hoeft te betekenen dat dat gat er ook is op een ander platform (Linux, BSD, OS X). D'r was in de tijd een hele nare worm die zich een weg naar binnen vrat op Linux systemen met Apache 1.3.6, iets waar veel Cobalts door sneuvelden, maar dat Wormpje kwam niet binnen op FreeBSD systemen, Sun systemen, etc.

Niet dat Flashback lek niet geplugd had moeten worden, maar het kan zijn dat het daardoor onderschat is, omdat het niet direct en niet zo makkelijk te detecteren was op OS X. Laten we hopen dat ze er van geleerd hebben.

[n4m3l355]

Ik weet uit ervaring dat een gat op platform 1 (windows) nog niet hoeft te betekenen dat dat gat er ook is op een ander platform (Linux, BSD, OS X).
Uiteraard een voorbeeld is niet voor iedereen zo laat het alleen zo zijn dat Apple constant eigenlijk wel constant achter de feiten aanloopt met het pluggen van gaten. Om het nog mooier te maken, je weet nooit wanneer gaten geplugd worden of wanneer een patch uitkomt wat deze precies doet. Vervelend voor jou als thuisgebruiker, nog vervelender voor je netwerk admin.

D'r was in de tijd een hele nare worm die zich een weg naar binnen vrat op Linux systemen met Apache 1.3.6, iets waar veel Cobalts door sneuvelden, maar dat Wormpje kwam niet binnen op FreeBSD systemen, Sun systemen, etc.
En dit is eigenlijk ook de essentie, zoals onlangs nog aangegeven werd, Apple ligt een kleine 10 jaar achter op de rest. Of het nou MS, Apache of de Linux gemeenschap. Die weten allemaal heel goed wat de consequenties kunnen zijn zeker MS heeft dit hardleers moeten ondervinden omdat ze vroeger interessant waren.
Nu kun je stellen dat Apple weinig problemen ondervind de vraag is enkel komt dit vanwege de security (hoogst onwaarschijnlijk) of doordat ze nog niet aantrekkelijk zijn. Het is dan ook te hopen dat Apple sneller leert problemen op te lossen dan ze tot op heden doen. Nu accepteerd de klant het tegen beter weten in maar zeker als je corporate klanten wilt werven dien je het toch wel beter te doen.

[arjankoole]

je weet nooit wanneer gaten geplugd worden of wanneer een patch uitkomt wat deze precies doet. Vervelend voor jou als thuisgebruiker, nog vervelender voor je netwerk admin.

Da's niet waar, iedere Apple update/patch wordt begeleid door een KB artikel, met een link naar een seperaat KB artikel wat uitsluitend de security related aanpassingen behandeld.

[TvdW]

Zo een beetje bijna alles draait gedeeltelijk of grotendeels op Java.

Als dat zo is, waarom levert Apple standaard dan geen Java mee?

[johnkeates]

Om dat Apple wil dat ontwikkelaars Objective-C gebruiken.

[Carbon]

Zo een beetje bijna alles draait gedeeltelijk of grotendeels op Java.

Niets in OSX is afhankelijk van Java!
Daarnaast zijn er maar een handjevol desktop programma's die geschreven zijn in Java.

[Reactie gewijzigd door Carbon op 25 juli 2024 09:51]

[BoringDay]

Ik heb java uit en mijn internet werkt
En als ik er ook nog geen eens malware door krijg (wat ik overigens nog werkelijk nooit heb mee gemaakt op mijn OSX machines) .... waarom zou ik het dan nog willen gebruiken!

[curumir]

Overdrijven is ook een kunst. Zonder Internet kun je nog maar bar weinig, zonder Java kun je nog vrijwel alles. Zelf heb ik het nodig voor development, maar zowel op het Internet als als standalone app mis je weinig.
Desondanks vind ik het ook nogal een paardenmiddel om Java er dan maar helemaal uit te slopen.

Het meeste dat op Java draait is server based. Heeft geen Java op je client nodig.

Apple onderhoudt Java niet zelf, ze integreren wel Java zelf in het systeem. En die laatste stap duurt vaak te lang. Dit is nu veranderd en is Oracle degene die zelf verantwoordelijk is.

En om nog maar een keer de "maanden verschil"-mythe te proberen te verduidelijken. Het is zeven weken (ik dacht zes, maar ja). En zoals je ziet, Oracle heeft de bug gefixt. Niet Microsoft. Door de stap die hierboven beschreven is, heeft Apple een vertragende factor uit de loop gehaald: zichzelf. In de huidige situatie zou OS X even snel gepatched zijn als Linux en Windows.

http://www.slashgear.com/...an-removal-tool-11222462/

Oracle had issued the patch to Windows and Linux machines seven weeks prior to when Apple, which does its own Java maintenance, released the update for Macs.

[elhopo]

Java != mallware. Java is een programmeertaal, net als alle anderen. De meeste virussen zijn gemaakt in C++, dan kun je beter de runtime's van C++ verwijderen. Als je malware op je Mac krijgt, dan moet je niet overal zomaar op klikken. Het voordeel van Java is dat je (althans in theorie) je applicatie maar eenmaal hoeft te ontwikkelen, en het werkt overal op. Als je je Java versie een beetje goed bijhoud is er niets aan de hand. Daarnaast gaat het hier om de SDK, niet om de runtime omgeving.

Wat ik overigens wel vind is dat in Java ontwikkelen onder OSX voor mijn gevoel net wat stroever gaat dan onder Windows, maar dat komt in mijn geval ook doordat Eclipse voor OSX weer net wat andere sneltoetsen gebruikt dan de Windows versie.

[AntBond]

Het grote verschil tussen Java en C++ zit hem in dat Java de Java VM nodig heeft om in te kunnen draaien. De code wordt door middel van een JIT-Compiler op runtime gecompileerd naar machinetaal (gecompileerde vorm van assembly). Zonder Java VM valt er dus niks uit te voeren. Op elke machine wordt dezelfde java-code op een andere manier gecompileerd zodat het op verschillende machines uitgevoerd kan worden. Elke processor-architectuur heeft een andere vorm van assembly.

C++ daarentegen wordt direct naar machinetaal (via assembly) gecompileerd. Hierdoor kan het zonder tussenkomst van een Virtual Machine uitgevoerd worden. Dit betekent echter wel dat voor elke machine de code aangepast en opnieuw gecompileerd moet worden. Elke processor-architectuur heeft immers een verschillende instructieset en elk besturingssysteem heeft andere functie voor het lezen van bestanden enz.

Het grote voordeel van Java is dat de code maar één keer geschreven hoeft te worden en dat het op elke machine uitgevoerd kan worden, zolang daar maar een Java Virtual Machine voor bestaat.

Met programma's geschreven in Java dient men even voorzichtig te zijn als met andere programma's. Het enige wat mij dwars zit met Java is dat er een significant prestatieverlies optreedt doordat de java-(byte)code eerst gecompileerd moet worden voordat het uitgevoerd wordt.

[curumir]

Afgezien van de processor afhankelijke assembly zijn de systeemlibraries ingewikkelder om gelijk te trekken. Java zelf werkt prima, is iets trager inderdaad, maar ik denk dat dat voor de meeste algoritmen niet zo veel uitmaakt. Als je over UI's gaat hebben is het een ander verhaal, behalve de VM zitten daar nog zware libraries omheen die roet in het eten gooien.
Volgens mij zit de grootste moeilijkheid van Java dan ook bij de UI-libraries, iets wat ook duidelijk wordt uit de hoeveelheid pogingen die hiervoor gedaan zijn. Het blijkt dat een generieke UI-library gewoon erg moeilijk te maken is, en al helemaal om de performance soepel en de look & feel passend te krijgen met de native apps.

Dit is ook de reden waarom Java wel erg goed aangeslagen is voor server werk (geen/nauwelijks UI), en is het voor applicaties en web-spullen nooit écht van de grond gekomen.

[elmuerte]

Er zijn ook genoeg Java compilers die naar "native" compilen. GNU's GCJ is er bijvoorbeeld een. En voor LLVM is er ook een project die Java bytecode naar LLVM bytecode (en dus machine code) kan omzetten.

[DeuTeRiuM]

Voor de lol heb je het ook niet. Pycharm is bijvoorbeeld een Python IDE geschreven in java. De beste IDE, ondanks java heel erg snel. Maarja, wel java nodig dus.

[Onno]

Meh, de installer roept dat ie Lion nodig heeft... dat is nou ook niet handig.

Na het handmatig extracten van de bestanden lijkt alles prima te werken in 10.6 overigens... zal wel weer een commercieel ideetje zijn geweest om Lion verplicht te stellen.

[Reactie gewijzigd door Onno op 25 juli 2024 09:51]

[terje7601]

Om volgende reden dus (zie hier):

Can I use the Oracle JDK on older OS X versions?
Probably not. The underlying issue here is that the Oracle JDK requires certain APIs that Apple introduced in Lion. The functionality introduced in these new APIs did to some extent exist in older OS X versions but were not official APIs.

What if I want a 32-bit JVM, or support for older PPC-based Macs?
There are community efforts based on OpenJDK to build JDK 7 for other configurations, easily found using your favorite search engine. We applaud these efforts! :-)

OS X 10.7 is ook de enige "Certified System Configuration" (zie hier).

Veel logischer kan m.i. niet: t.e.m. 10.6 gebruik je de Apple-supported Java 6, vanaf 10.7 gebruik je de Oracle-supported Java 7. En zoals hierboven al staat: als je Java 7 op oudere OS X versies wil draaien, gebruik je best een OpenJDK build, zoals bijv deze

[eamelink]

Dat werd tijd, want Java 6 is over een half jaartje eol

Het begon een beetje krap te worden . Er zijn ontzettend veel JVM ontwikkelaars die op MacOS ontwikkelen, als ik zo een beetje rondkijk op Java en Scala conferenties.

[Reactie gewijzigd door eamelink op 25 juli 2024 09:51]

[BoringDay]

Ik heb het uitgeschakeld en merk op dat ik het ook helemaal niet mis of nodig heb.
Daarbij kan ik me goed indenken dat een OS maker (ongeacht welk OS) het liefst de Applicaties in native heeft draaien.

Met ontwikkel omgevingen als Real Basic kan je immers ook programmeren en per gewenste OS laten compileren.

[dgompie]

Ik ben een kleine ontwikkelaar en ontwikkel in Java, waarom?

- Goede ontwikkelomgevingen
- Snel te ontwikkelen
- Redelijk fout-vrije software mogelijk
- Goede bibliotheken
- Ik kan dezelfde taal gebruiken voor zowel server als desktop applicaties
- Java Webstart voor heel erg makkelijk applicaties "deploying"
- Vrijwel alles werkt tegelijkertijd op Apple, Linux en Windows (er zijn soms wel wat kleine probleempjes, maar geen "show-stoppers")

Tja, dus wat Apple vindt zal me worst wezen (en ja, ik "spreek" assembler, C, C++, Pascal/Deplhi en zo nog wat talen, dus dat is het probleem niet)!

[Anoniem: 282252]

In OSX is het volgens mij voldoende om je je browser even java uit te zetten en je bent veilig.
Ikzelf heb dat uitgezet en klaar, ik ben veilig wat java problemen betreft.

Overigens, deel ik de rest met je en we spreken dezelfde talen (alhoewel mijn assembly en pascal erg roestig is). Ikzelf ben ook dagelijks met java en server gerelateerde zaken bezig en het is gewoon fijn om te zien dat als je een jar maakt op je eigen machine, je deze zo op een server kan zetten en draaien maar.

[gimbal]

Voor developers (de echte end-users van Java) is Java ook prima.

Het is meer voor de end-users van software geschreven in Java dat het overlast geeft. Puntje bij paaltje is de deployment van de runtime niet in orde. Foutgevoelige installatie, veel te technisch van aard, 32 bits/64 bits gezeur, zeikerige updater... Daar bovenop ook nog eens JavaFX dat als aparte runtime geinstalleerd wordt (dat is vanaf Java 8 niet meer het geval gelukkig).

Java 8 gaat dan ook de held worden. De focus gaat meer naar Java bundelen met je applicatie in plaats van zelf een runtime te moeten installeren - zodat het bijvoorbeeld ook gaat werken in zoiets als een Apple appstore. Koppel dat met het vervangen van het sterk ouderwetse classpath door modules en het compleet uitfaseren van de "permgen space" (met name voor web devs een reden om en stuk uit de tafel te bijten) en het gaat al flink de goede kant op.

Oracle (de java afdeling, niet Oracle inc.) snapt het wel, het duurt alleen eventjes voordat het weer op gang komt.

[johnbetonschaar]

De voordelen van Java die je opnoemt waren 10 jaar geleden inderdaad grote pluspunten, tegenwoordig zijn er veel betere ontwikkelomgevingen/talen te vinden die op al deze punten even goed of beter scoren, en ook nog eens veel prettiger zijn om in te ontwikkelen. Denk aan Python of Scala bijvoorbeeld.

Wat ontwikkeltaal is Java echt behoorlijk achterhaald en onnodig complex en frustrerend om in te ontwikkelen, het mist gewoon enorm veel features die modernere talen wel hebben, en de taal zelf is veel te statisch en rigide.

Ik zou je aanbevelen om Scala eens uit te proberen, dat is een soort 'Java done right' taal die op de Java VM draait, bytcode compatible is (je kunt dus elke Java library direct gebruiken), elimineert alle boilerplate code die je in Java moet schrijven, en bevat vele features die Java mist, zoals closures en first-class lambda functions.

Mensen die nu nog krampachtig aan Java vasthouden zijn wat mij betreft gewoon een beetje vastgeroest, het is inderdaad een krachtig en compleet platform, maar het is op geen enkel aspect meer beter dan de vele alternatieven die nu beschikbaar zijn.

[BoringDay]

Daar noem je het al!
"- Redelijk fout-vrije software mogelijk"

Als programmeur kan ik met die term nooit tevreden zijn, maak gewoon fout vrije software.
Met redelijke fout-vrije kan je toch niet tevreden zijn?

Daarbij XCode prachtige omgeving met veel mogelijkheden.
Voor Windows Delphi (of Linux Kylix) is hiervan 1 met de snelste compilers en heeft een goed GUI systeem (jaren mee gewerkt).


Pak je realbasic heb je ook alle platformen zonder java nodig te hebben.
Daarbij draaien ze dan voor elk OS native.

Maar als ik ontwikkel omgeving waarbij ik "redelijke fout vrije" software kan maken, dan wil ik er al niet eens mee werken.

Degene die software maken en verkopen dienen namelijk fout-vrije software te maken.
Daar heeft een betalende klant recht op.

Redelijke fout-vrije auto's wil ook niemand in rijden.

[curumir]

As je doelt op:

"Het bedrijf wil dat softwareontwikkelaars native code gebruiken in plaats van cross-platform-Java-code."

Dan ben ik wel benieuwd naar een objectieve bron, anders dan de mening van de auteur...

[MacWolf]

Waarom er zo veel tijd zit tussen de laatste versie van Apple en de eerste van Oracle is niet bekend.

Dat lijkt me wel duidelijk, eigenlijk. Tot en met 10.6 verzorgde Apple zelf haar Java releases en was het Apple's zorg dat de Java Virtual Machine (JVM) voldeed aan de standaard. Na 10.6 heeft Apple geen zin meer gehad om zelf de release te onderhouden, dus viel de verantwoordelijkheid bij Oracle om de meest recente versie van de JVM naar Mac OS X te poorten.