Microsoft geeft preview van eigen OpenJDK-release vrij

Microsoft maakt de Microsoft Build van OpenJDK beschikbaar, een long-term support-distributie van de Java-developmentkit met onder andere de binaries van Java 11. De build wordt later dit jaar de standaarddistributie van Java 11 voor Azure-diensten.

Met de release wil Microsoft de Java-ondersteuning voor zijn klanten en ontwikkelaars verbeteren. OpenJDK is de opensourceimplementatie van Java. De Microsoft Build van OpenJDK is open source op basis van een GPLv2+CE-licentie en bevat binaries voor Java 11 die gebaseerd zijn op OpenJDK 11.0.10+9. De distributie is beschikbaar voor x64-server- en -desktopsystemen op Windows, macOS en Linux. Daarnaast kondigt Microsoft een vroege binary van Java 16 voor Windows op Arm aan, gebaseerd op OpenJDK 16+36.

Microsoft claimt de afgelopen achttien maanden met meer dan vijftig patches te hebben bijgedragen aan OpenJDK, waarbij onder meer verbeteringen voor Windows packaging voor macOS zijn doorgevoerd. Verder zou het bedrijf intern een half miljoen Java Virtual Machines gebruiken, waaronder voor gameservers; 140.000 daarvan zouden al op de Microsoft Build van OpenJDK gebaseerd zijn.

Het bedrijf wil feedback verwerken voor de release van een productieversie en Java 11 vervolgens tot in ieder geval 2024 ondersteunen. Later dit jaar moeten ook OpenJDK 17-binaries verschijnen. Nog dit jaar moet de Microsoft Build van OpenJDK de standaarddistributie voor Java 11 op Azure worden. Ondersteuning voor Java 8 is er ook voor Azure, maar Microsoft adviseert klanten over te stappen naar Java 11 of latere versies.

Reacties (102)

[Robert-Jan]

Zal ook een financieel voordeel aan zitten voor Microsoft. De Oracle versie is technisch misschien de beste, maar zij zijn experts in het uitbuiten van licenties. Ervaring uit het verleden...

[bzzzt]

Er zijn nauwelijks voordelen om OpenJDK te vervangen door de standaard Oracle JDK. Wat Oracle wel doet is security patches voor lang geleden obsolete verklaarde versies uitbrengen, dus als je nog een Java 6 applicatie hebt die echt niet gemigreerd kan worden kan je daar nog terecht.

Oracle investeert behoorlijk in "next gen" Java met GraalVM. (native compilatie en veel agressievere optimalisatie). De "enterprise versie" van GraalVM zou volgens Oracle ook betere performance hebben, maar ze zullen wel weer niet toestaan dat je benchmarks publiceert.

[TheVivaldi]

Oracle investeert behoorlijk in "next gen" Java met GraalVM. (native compilatie en veel agressievere optimalisatie). De "enterprise versie" van GraalVM zou volgens Oracle ook betere performance hebben, maar ze zullen wel weer niet toestaan dat je benchmarks publiceert.

In dat geval is Phoronix in overtreding
https://www.phoronix.com/...Vaw3IYtXckRyK2o8It-jBpuqQ
https://www.phoronix.com/...Vaw2Xm2MFgm1nun0xU7j9LfvH

[bzzzt]

Ik zie geen enkel artikel over Oracle op die links, dus vast niet
Weet het ook niet zeker van GraalVM, maar in de voorwaarden van de Oracle database staat expliciet dat je geen benchmarks mag publiceren zonder toestemming van Oracle.

[TheVivaldi]

O, de links zijn om een of andere reden kapot gegaan. Hier alsnog één van de twee: https://www.phoronix.com/...lvm201-openj920-jvm&num=1

[bzzzt]

Daar gaat het dus om de 'community edition' van GraalVM. De "enterprise" versie van Oracle zou sneller moeten zijn, maar kan je niet vrij downloaden.
Vind die Phoronix tests vaak compleet nietszeggend en over veel te veel pagina's verdeeld om maar advertentiegeld te cashen. Ze zetten veel testjes op, maar als er dan iets interessants uitkomt kunnen ze niets meer melden dan wie de 'winnaar' is terwijl het vaak toch wat genuanceerder ligt.

[Killemov]

De Oracle-versie is in ieder geval het meest gelicenceerd. Er zijn technisch gezien nauwelijks redenen om niet voor de OpenJDK te kiezen.

[supersnathan94]

De oracle versie is technische de beste omdat dat letterlijk de OpenJDK is. Oracle onderhoud al jaren geen eigen JDK meer maar heeft dat belegd in de Open source versie.

Het enige wat er bij oracle bij zit zijn wat gelicenseerde dependencies. De basis is openJDK.

[THA_ErAsEr]

En support

[supersnathan94]

Ja maar de vraag is dan hoe interessant dat is. Er zijn maar weinig momenten dat ik iets maak wat echt specifiek alleen afhankelijk is van support op Java gebied en dan al helemaal niet specifiek oracle spul.

Dus dat is dan een afweging die je moet maken als bedrijf right?

Support voor iets als spring of axon is handiger.

Als jij een bug tegenkomt in java en anderen hebben daar geen last van of gebruiken het niet dan is de vraag of je niet veel te specifiek bezig bent. In sommige gevallen is dat nodig, maar in de meeste gevallen niet.

Daarnaast staat het je natuurlijk vrij de bug zelf te fiksen en in te dienen bij OpenJDK.

Als ik supportkosten bekijk kan dat eigenlijk altijd wel uit.

[kozue]

De Oracle versie is niet beter. Sinds java 7 of 8 ofzo is Oracle JVM gebaseerd op OpenJDK en biedt dus geen voordelen meer. Tenzij je applicaties wilt schrijven die vast zitten aan hun extra gesloten toevoegingen en op geen enkele andere JVM meer kunnen draaien. Maar dan zet je jezelf vrijwillig vast in een vendor lock-in...

[Mellow Jack]

Misschien zien ze de Amazon variant wel overall in Azure draaien en hebben ze op deze manier meer controle op optimalisaties (speciaal voor Azure )

[Anoniem: 162126]

Ik snap niet zo goed waarom ze dit doen. Ze zijn al vertegenwoordigd in de AdoptOpenJDK community. Ik zie nog even niet wat de toegevoegde waarde is van deze binaries.

https://adoptopenjdk.net/about.html

[ari3]

De waarde voor Microsoft is Java op een Windows OS. Ik denk dat Microsoft haar OS en hosting (Azure) moeilijk kan slijten voor het draaien van Java applicaties. Ik doe veel consultancy in Java-technologie (applicatieservers) en zie eigenlijk nergens dat applicatieservers gehost worden op Windows. Het is voornamelijk Linux en een enkele keer *BSD of Z/OS mainframe. Java applicatieservers hosten op Windows ben ik nog nooit tegengekomen.

[Anoniem: 162126]

Behalve de grootste gemeente van Nederland daar zit ik nu zelf als ontwikkelaar.

Oh we draaien daar trouwens gewoon AdoptOpenJDK 8 en 11.

[Reactie gewijzigd door Anoniem: 162126 op 23 juli 2024 05:58]

[RobinJ1995]

"De grootste gemeente van Nederland" heeft op gebied van IT op wereldschaal best wel weinig te betekenen, echter

Ik vind het overigens wel soort van komisch dat een gemeente eigen ontwikkelaars in dienst neemt, in plaats van dat ze outsourcen. Is dat common practice, of enkel het geval bij "de grootste gemeente"?

[bkor]

Ik vind het overigens wel soort van komisch dat een gemeente eigen ontwikkelaars in dienst neemt, in plaats van dat ze outsourcen.

Waarom zou dat onlogisch of komisch zijn? Het lijkt me een stuk handiger om mensen zelf in dienst te hebben namelijk.

[davince72]

Omdat een gemeente andere taken zou moeten uitvoeren ipv softwarehousje spelen😊 neem iets als WOZ beschikking...zelfs dat besteden gemeentes meestal uit... als het daarvoor al geldt dan denk ik dat het ook moet gelden voor software ontwikkeling. Gemeente zou gewoon standaard pakketsoftware moeten kopen.

[gimbal]

Welke standaard pakketsoftware? Microsoft RunAGov? Interne productontwikkeling is de normaalste zaak op aarde en een uiterst geschikte strategie om kennis van die software te bewaken.

[davince72]

Alleen jammer dat het de burger klauwen met geld kost. Maar goed, overheden in’t algemeen zijn natuurlijk net sociale werkplaatsen 😂
Ik kan het weten, ben het zelf.

[Carn82]

tja, is outsourcing dan per definitie "goedkoper"? Om nog maar niet te spreken over de hele mallemolen mbt aanbestedingen..

[davince72]

Nee outsourcen is niet perse goedkoper... Maar als je het op juist manier uitbesteed dan kan het zeker goedkoper zijn, omdat
- je het kunt uitbesteden aan partij die juiste expertise heeft (niks trial and error)
-ze niet de beperkingen hebben die vaak heersen binnen grote bedrijven, bijv.: geen cloud, verplicht soap, etc etc.
- niet 30 zogenaamde architecten die er iets van moeten vinden maar het niet snappen

[Anoniem: 162126]

Deze software is niet als pakket te koop. Thans heb ik nog geen milieuzone software pakketten gezien.

[Kwistnix]

Nee, zoiets moet je gewoon custom bouwen en dan liefst met een of ander esoterisch framework voor instant legacy en vendor lock-in, Aurelia of zo

[Anoniem: 162126]

Maar aurelia is opensource

[davince72]

Hahah precies. Wij zitten op 1 lijn, maar niet iedereen durft zo kritisch te kijken

[davince72]

Maken jullie ook afweging tussen kosten en baten ?
Maar ach...het is leuke werkverschaffing en burger betaald wel wat meer belasting. Gemeentes zouden eens wat zuiniger met geld moeten omgaan.

[Anoniem: 162126]

Op welk vlak? Wij doen dat wel op ons deel van het technisch vlak. Of doel je op het beleid? Want op technisch vlak ben ik dan wel benieuwd hoe je van afstand tot deze conclusie komt.

[davince72]

Het begint glad ijs te worden. Ik ben zeer kritisch...ook op mezelf...ik heb geen ervaring met gemeente Amsterdam...maar wel veel ervaring met overheid...de bureaucratie viert nog steeds hoogtij en alles is log en traag en niet innovatief....maar als jij de uitzondering bent met Amsterdam....dan bravo...dan zijn jullie uniek dat jullie belastinggeld wel efficiënt en goed weten in te zetten

[Anoniem: 162126]

ik snap het beeld dat je er bij hebt wel, en het beleid laat zeker wel wat te wensen over. Het goede, al zeg ik het zelf, is dat er niet een grote dienstverlener is ingehuurd om dit te bouwen. Ik gok dat de kosten dan minimaal drievoudig zouden zijn.

[Joop]

Dat is volledig normaal. Een gemeente met 100.000 inwoners heeft zo maar 1000 medewerkers in dienst, gemeente Amsterdam heeft er zelfs 16.000.

Dergelijk grote organisaties kunnen vandaag de dag niet zonder ontwikkelaars. En alles outsourcen is ook zeker niet ideaal. Standaard software moet je natuurlijk van de plank kopen, maar op gespecialiseerd gebied moet je vaak toch zelf ook wat doen. Al is het maar de vele customisation op standaard pakketten met plugins of anderszins. Software ontwikkeling is er natuurlijk ook in vele soorten en maten.

[Anoniem: 162126]

Ik ben ingehuurd.

[JustFogMaxi]

Ok true, maar dat kan ook met bestaande openjdk binaries?

[metalmania_666]

Mwah,

Ik ken sowieso een paar provincies en waterschappen die alles op Windows hebben staan:

Provincie Noord-Brabant, Overijssel, Waterschap De Dommel, Wetterskip Fryslan

[david-v]

Meer dan de helft wat op Azure draait is Linux, dus wat hosting betreft is dat geen argument, wel om het op het eigen os te draaien, en daar mikken ze denk ik meer op onpremise waar ze toch al Windows draaien.

[i-chat]

support,

ze willen deze versie in hun azure cloud uitrollen. Zoals het er staat, lijkt het allemaal, niet veel meer dan een, 'unofficial branch-off' omwille van: 'Long Term Support'.

[gimbal]

Dat is inderdaad het hele punt van dit soort praktijken. Er zijn veel builds van OpenJDK te vinden, je kunt ook Zulu pakken bijvoorbeeld in plaats van AdoptOpenJDK. Het is maar welke voorwaarden er geboden worden wat voor een organisatie interessant kan zijn; wellicht is een Azure met ingebouwde LTS support voor OpenJDK nu net dat lokkertje waar organisaties op zaten te wachten om de keuze voor Azure te rechtvaardigen.

[Wouterie]

Nice! Oracle zag al dollartekens bij onze inventarisatie. Dit kan wel wat schelen.

[FreezeXJ]

Dan zou ik toch eens naar de OpenJDKs gaan kijken, die zijn al tijden gratischsch, en worden wel gebakken door Oracle. Je hebt alleen niet de officiele support, dus management moet even afstappen van het idee dat alles 'gecovered' wordt door contracten (en da's best lastig, merk ik elke keer weer).

[sspiff]

Bij mijn weten heb je geen binaire OpenJDK distributie van Oracle zelf. Wel zijn er tal van andere die gratis te gebruiken zijn, en optionele betslende support hebben van andere grote spelers zoals Red Hat en IBM, of kleinere gespecializeerde partijen zoal Azul.

Zelf gebruik ik als developer al heel lang persoonlijk die van Azul (Zulu) en op het werk AdoptOpenJDK, beiden zonder de optionele betalende support, zonder problemen.

[Reactie gewijzigd door sspiff op 23 juli 2024 05:58]

[Robtimus]

Bij mijn weten heb je geen binaire OpenJDK distributie van Oracle zelf.

Toch wel: https://jdk.java.net/. Dit zijn OpenJDK versies, dat zie je aan de filename als je ze download.

[Kewne]

Minpunt: daar zijn geen LTS versies te vinden die daadwerkelijk onder LTS ondersteuning krijgen. Die worden namelijk als onderdeel van jdk-updates gemaakt, maar daar zijn geen officiële binaries van beschikbaar (hoewel ze wel naar Adoptium wijzen). Resultaat is dat de downloads dus zeer waarschijnlijk insecure zijn, zeker die van de LTS versies Java 8 & 11.

[Wouterie]

We hebben een externe expert die ons aan het helpen is om te migreren. Schijnt nogal een gedoetje te zijn, maar ik kan me zo voorstellen dat een Microsoft oplossing iets makkelijker te implementeren is, vooral omdat alle leveranciers gecertificeerd en zo moeten zijn.

[elmuerte]

We hebben een externe expert die ons aan het helpen is om te migreren. Schijnt nogal een gedoetje te zijn

Wat is een gedoetje? Het uitrollen en updaten van de Java runtime op Windows machines?

[bzzzt]

Er zitten kleine verschillen tussen Oracle Java en OpenJDK. Eigenlijk nauwelijks meer sinds Java 11, maar toen mijn werk een paar jaar geleden overstapte hebben we 1 serieuze bug gevonden waarbij de alternatieve implementatie van de lettertype renderer in OpenJDK in sommige gevallen een JVM crash triggerde. Niet fijn in een webapplicatie.

[Reactie gewijzigd door bzzzt op 23 juli 2024 05:58]

[elmuerte]

Ik ben echt nog nooit tegen dat soort problemen aangelopen. Op de server draaide ik altijd Linux distro releases (wat vanaf 6 gebaseerd was op openjdk). En op de desktop de Sun/Oracle builds (todat Oracle de stekker er uit trok, nu alleen nog openjdk builds).

De runtime crashes die ik gehad heb waren gewoon bugs die zowel in OpenJDK builds als in Oracle builds zaten, mits je natuurlijk dezelfde builds pakte. En dat zijn dan 2 van dat soort bugs in 10+ jaar.

Sinds Java 8 is trouwens OpenJDK de officiële reference implementatie voor Java. Daar was men tijdens Java 7 al mee bezig om naar over te stappen. Sinds Java 11 is er geen speciale Oracle "branch" meer. Wat met vroeger als commerciële features verkocht (e.g. Flight Recorder) zit vanaf Java 11 allemaal in de OpenJDK repo.

[supersnathan94]

Euhm. Niet om het een of ander hoor, maar wordt het dan niet eens tijd om je front- en backend te scheiden? Ik snap dat je met een legacy applicatie te maken hebt en dat lastig is, maar je krijgt er zoveel meer voor terug dat het echt wel de moeite waard is.

[bzzzt]

Dit was een paar jaar geleden, nu geen probleem meer.
Een crashende JVM is wel een redelijke zeldzaamheid, dus was meer een voorbeeld dat niet alle code 'zonder meer' perfect draait.

[supersnathan94]

Nee dat snap ik, maar dat komt vaak ook doordat men met 8 in principe nog twee gescheiden distro’s had. OracleJDK is met 9 gestart om volledig over te gaan naar OpenJDK. Sinds 11 zijn ze 1 op 1 hetzelfde. Met java 11 is het dan ook gewoon niet meer verschillend op de extra packages van Oracle na (maarja, heb je die nodig is de vraag dan).

[Alfa1970]

Een Web Applicatie in Java?
Onder welke steen zijn ze vandaan gekropen?
Er geen serieuze web browser meer die Java ondersteund!

[bzzzt]

Java webapplicaties zijn server-side en worden nog volop gebruikt. Niet ieder bedrijf vervangt applicaties volledig om de 5 jaar.

[ta_chi79]

Installeren en updaten van OpenJDK is met 3 klikken gebeurd, dus dat is het probleem niet.

Support krijgen van je leveranciers is het grote probleem.
Merk dat langzaam aan nieuwe versies van software worden uitgebracht met OpenJDK support, maar dan mag je wel al 1,5 jaar aan het "zeuren" zijn voordat ze zover zijn. En de klant ondertussen weer (blindelings?) allerlei software aanschaffen en eisen dat alles veilig is (geverifieerd door qualys/nessus scans), maar niet willen betalen voor Oracle licenties (want die zijn nooit meecacalculeerd voor de aanschaf), maar wel supported willen zijn vanuit de leverancier.

[phizzie]

Misschien een beetje flauw, maar migratie noemen we het nou eenmaal in de IT industrie als je van het ene naar het andere platform beweegt. Aangezien je je hele hebben en houden in zulke situaties overzet is er flink wat mee gemoeid om het 'gegarandeerd' werkend over te zetten. (Er is een limiet aan wat je verantwoord en economisch gezien kan testen).

Het 'gedoetje' zit in de test dekkingsgraad. Ga je ALLE soorten testen toepassen? Frontend, backend, integraties? Moet je alleen alle bestaande testgevallen (als die al bestaan, maar ik ga hier wel even van uit) succesvol laten zijn? Of zijn er nog testgevallen buiten de bestaande scope(s) die je moet introduceren? Bijvoorbeeld server upgrades, configuraties en diens bestanden, deployments, rollbacks, backups terugplaatsen, hardware configuratie wijzigingen om maar wat te noemen?

Qua extremen: is er voldoende dekkend bewijs dat de Random Number Generator voldoende entropie heeft, voor de Oracle Java naar Microsoft OpenJDK oplossing? Vaak nogal een gewild dingetje rondom encryptie. En die noemde je al wel, maar de voorgaande situaties mag men zeker ook rekening mee houden

[aikebah]

[...]
Wablief?

Hangt er natuurlijk vanaf wat die migratie behelst.

Is dat Oracle Java 8 >> OpenJDK Java 8, dan ben ik geneigd om met je mee te gaan. Maar een veel waarschijnlijker migratiescenario vind ik Oracle Java 8 >> OpenJDK Java 11. En dat kan best een dingetje zijn (afhankelijk van hoe goed de diverse vendors weggebleven zijn van de non-public APIs (maar dat ligt dan dus meer aan de migratie 8 >> 11 dan aan Oracle >> OpenJDK).

Voor 11 >> 11 migraties mag Oracle >> OpenJDK dat zeker geen probleem meer opleveren, want daar bouwt Oracle op basis van de OpenJDK sources en verkoopt het enkel support)

Enige andere hobbel die ik me kan voorstellen is vendors voor hun software alleen support bieden als een probleem optreedt met de applicatie draaiend op Oracle danwel RedHat binaries.

[NTS]

Amazon had ook al lang zo'n zelfde OpenJDK distributie beschikbaar gesteld. Dus leuk dat Microsoft er nu ook eentje maakt maar voor Oracle verandert er niet zo veel.

[RoestVrijStaal]

Verder zou het bedrijf intern een half miljoen Java Virtual Machines gebruiken, waaronder voor gameservers; 140.000 daarvan zouden al op de Microsoft Build van OpenJDK gebaseerd zijn.

Sinds Microsoft de gamestudio achter de game MineCraft heeft overgenomen, is dat nogal logisch.

Best ironisch dat Microsoft weer een met een eigen smaak van Java komt omdat decennia geleden bij de vorige keer dat Microsoft dat deed, rechtzaken aan haar broek kreeg hangen door Sun Microsystems (= dat is het bedrijf wat Java heeft ontwikkeld).

Larry Ellison, don't sue Microsoft

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 05:58]

[kozue]

Dit is geen eigen "smaak van Java". Dit is een build van OpenJDK, zoals er al velen zijn. Onder andere die op mijn Ubuntu systeem, die de vendor identificeert als "Ubuntu" (niet Canonical, vreemd genoeg).

$ java -version
openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)

jshell> System.getProperty("java.vm.vendor");
$1 ==> "Ubuntu"

[SuperDre]

tja, echt een eigen smaak is het niet zo, in iedergeval niet veel anders dan al die andere OpenJDK versies.

[Anoniem: 162126]

Pas op, je lekt informatie over je leeftijd met deze uitspraken!

[Kwistnix]

Misschien komen zo ook nog wel met een plugin voor Edge, waarmee je rechtstreeks Java in de brow...oh wacht, dat was niet zo'n briljant idee

[Anoniem: 162126]

Als alternatief voor aurelia

[joost00719]

Microsoft java is nu dus echt een ding

[field33P]

Nu weer een ding. Voor 2003 hadden ze ook een eigen Java-implementatie, maar daar werd Sun indertijd niet zo blij van omdat Microsoft het idee opgevat had om er non-standaard functies in te zetten.

[FreezeXJ]

Da's hun standaard-tactiek, EEE, alleen werkte het (gelukkig) niet bij Java. Ik vraag me af wat het dit keer voor 'voordeel' moet opleveren, en voor wie. Als ik wil betalen ga ik naar Oracle, als ik een werkende Java wil pak ik de OpenJDK.

In de Azure-cloud zal het wel hun 'standaard' worden, maar ook dan heb ik liever zelf controle over welke JDK ik draai, om spontane upgrades te vermijden...

[hottestbrain]

EEE is al tijden niet meer hun standaard tactiek, dit zijn echt (in technologie-termijnen zeker) oude koeien uit de sloot halen.

[batjes]

Dat is het nog steeds, wordt alleen op een ander niveau gespeeld. Microsoft is momenteel de FOSS wereld aan het embracen, de extend phase is al een tijdje afgerond. Heel Linux is met WSL praktisch gedegradeerd tot een Windows Feature en Microsoft plaatst zich steeds prominenter in de Open Source wereld, GitHub onder de vier- kantige/kleurige vlag.

Zelfs als een van de lokale Microsoft 'fanboys' heb ik toch wel zorgen over het nieuwe 3E hoofdstuk dat Microsoft een paar jaar geleden open geslagen heeft. Want de volgende stap is extinguish, het is wachten op wat er mogelijk gaat gebeuren als Microsoft defacto standaard wordt binnen de FOSS wereld. 20 jaar geleden zou je je dat onmogelijk achten dat Microsoft uberhaupt zo bezig zou zijn gegaan met FOSS, ondertussen hebben ze FOSS helemaal omarmt.

[Relief2009]

Als je alleen maar op WSL focust dan lijkt het inderdaad alsof EEE nog bestaat. Totdat je oogkleppen afdoet en realiseert dat Linux groter is dan dat en dat het blijkt dat het Microsoft het niet boeit dat Linux groeit. FYI: Windows speelt tegenwoordig maar een kleine rol in de omzet van MS.

[batjes]

Dit gaat ook verder dan alleen Linux. GitHub was/is de grootste hoster van Open Source software. OpenJDK wordt nu ook door Microsoft gebuild. Microsoft is steeds meer dev tools aan het open sourcen. Microsoft neemt in steeds meer Open Source projecten deel. Je ziet Microsoft's naam ondertussen vaker voorbij komen in de FOSS wereld dan die van Red Hat en/of Canonical.

Microsoft is via de Open Source route een heel groot deel van het development wereldje naar zich toe te trekken. Ze zijn het nu aan het Embracen. Nadat ze jaren geleden wat uitstapjes deden de FOSS wereld in (Extend).

[Ventieldopje]

Oke, hoe werkt het laatste E'tje dan volgens jou?

Als ze ook maar iets negatiefs doen met Github dan kunnen ze inpakken. Alle FOSS projecten verdwijnen en een hoop betaalde accounts zullen ook snel volgen. Zij zijn niet de enige op de markt, niet voor Git en niet voor CI. Bovendien is Git decentraal by-design.

Zie bijvoorbeeld de PHP devs die overstappen van hun eigen Git servers naar GH. Even de remote aanpassen en gaan met die banaan. Zo heb ik zelf ook meerdere keren gewisseld.

[Blaise]

Veel projecten kunnen helemaal niet makkelijk switchen. Github projecten zijn vaak veel meer dan een remote git server. Het is een community met contributors, waarnaar talloze links verwijzen, met issue tracking, releases met binaries en CI. Het is fijn is om alles geïntegreerd te hebben en op één plek, tot je weg wil...

[Ventieldopje]

Dat is niet hoe FOSS werkt. Bovendien zou Microsoft zich enorm in de voet schieten als ze wat aan Github vernaggelen voor FOSS projecten, aan het begin stonden al heel veel projecten in de startblokken om te verkassen.

[84hannes]

Ik vind het jammer dat mensen soms lijken te denken dat FOSS een garantie is tegen al je problemen. Microsoft wilde DirectX ondersteuning opnemen in de kernel maar dat zou alleen werken als je op WSL draait. Dat zou een deur wagenwijd openzetten voor Linux-applicaties die niet op Linux werken; ik kan dat alleen als EEE zien.

[84hannes]

Ik zie niet in hoe dit EEE is en op de linux kernel slaat want dit heeft 0 invloed er op.

Ik begrijp niet wat je bedoelt. Code die aan de kernel wordt toegevoegd heeft geen invloed op de kernel?

[Ventieldopje]

Zij zijn vrij om hun eigen proprietary kernel modules te maken of om een eigen kernel uit te rollen zover de licentie dat toestaat.

Verder hebben zij niks te zeggen over of iets in de mainline kernel wordt opgenomen maar ze zijn vrij om iets aan te bieden.

[84hannes]

ze zijn vrij om iets aan te bieden.

Dat heb ik nergens in twijfel getrokken. Als zij een kernelwijziging aanbieden in een poging om Linux uiteindelijk kapot te maken, dan is dat toegestaan. En EEE.

[hottestbrain]

Microsoft is diensten gaan verkopen. Het interesseert ze geen bal of je open source draait of closed, zolang je maar gebruik maakt van github, azure, M/O365, game pass en dergelijke. Nadala interesseert bovendien uitsluitend datgene waar hij abonnementen kan verkopen, wat denk ik ook mijn gevoel verklaard dat windows een ondergeschoven kindje was (dat is met het aanstellen van Panay en Groene gecorrigeerd).

3E heeft in groot aantal devs weggejaagd van Windows (en IE), wat op zijn beurt heeft bijgedragen aan slechte adoptie van developers voor zowel web als mobile binnen het MS eco-systeem. Het is duidelijk dat Nadala dat in ziet en daarom in ieder geval wil pogen die developers naar azure te krijgen, door het ze zo makkelijk mogelijk te maken. Embracen dus en daar geld aan verdienen. Het gegeven dat ze het zowel omarmen als er actief geld aan verdienen zegt al genoeg: Ze zouden gek zijn daar iets aan te veranderen.

Ik denk dat visual studio code exemplarisch is voor hoe microsoft tegenwoordig houding neemt ten opzichte van open source. Het is een product door hun gelanceerd, van meet af aan al FOSS en cross platform beschikbaar. Voor quantum doet MS (voor zover bekend natuurlijk) niets closed source.

Ook .net, windows Terminal (Inclusief het oude conhost.exe!) en Powershell zijn cross platform FOSS en ik eet nog net niet mijn schoen op als het open sourcen van de windows rekenmachine, winUI, winForms en WPF niet de opmaat is naar uiteindelijk open sourcen van grote delen van Windows zelf...

[Reactie gewijzigd door hottestbrain op 23 juli 2024 05:58]

[Remenic]

Zo is dat, kans op herhaling is nihil, dus niet meer over praten. /s

[Xudonax]

Dit is dus OpenJDK Alleen dan ingepakt door Microsoft in plaats van bijv. Red Hat. De code is hetzelfde, alleen de leverancier anders. Er zullen vast een paar specifieke patches in zitten, maar denk dat die vooral zijn om beter op Windows te draaien. En omdat alles onder de GPLv2+CE valt moeten wijzigingen openbaar gemaakt worden. Ik zie dit echt wel anders dan hun oude EEE strategie.

[Killemov]

De Microsoft versie zal nu nog gelijk zijn, maar het ligt zeker voor de hand dat ze in de loop van de tijd Microsoft-specifieke zaken gaan implementeren. Bijvoorbeeld code om beter gebruik te maken van de Azure-architectuur.

[bzzzt]

Je bedoelt net als Amazon met hun Corretto OpenJDK distributie?

[SuperDre]

En het probleem daarvan is? Is toch logisch dat als je Azure gebruikt dat je dan ook een voor Azure geoptimaliseerde versie wilt gebruiken.

[supersnathan94]

Het is logischer dat Azure zijn shit optimaliseert voor standaard Java dan andersom. Zodat je vrijheid hebt om zelf te kiezen wat je draait. Als ik adoptOpenJDK-Hotspot wil gebruiken of de oracle versie is dat een keuze die ik moet maken voor mijzelf. Gewoon omdat m’n images misschien niet alleen op Azure staan omdat het een open source applicatie/framework is.

“Only works on Azure” kun je dan gewoon niet verkopen.

Optimalisaties zijn goed, maar houd daarbij dan wel de interface intact.

[aikebah]

Optimalisaties zijn goed, maar houd daarbij dan wel de interface intact.

Eens met die laatste zin, maar bij de rest toch zo mijn kanttekeningen. Azure heeft ongetwijfeld zo zijn nukken net als dat native ARM en native x64 zijn nukken heeft (on top of de nukken van Linux/Windows/MacOS kernels).

Azure moet 'hun eigen shit' optimaliseren voor virtualized cloud omgevingen op een taal-onafhankelijke manier en zich dus niet voegen naar de nukken van een momenteel toevallig sterk aanwezige programmeertaal + virtual machine specificatie (waar ik met alle liefde in codeer overigens)

Een Azure-specifieke optimalisatie van de JVM implementatie lijkt me prima, zolang er maar niet getornd wordt het volledig conformeren aan de JLS en de JVMS. Als dat de uitkomst is van deze Microsoft build... prima zo. Als ze enkel en alleen een clone van de openJDK source compilen om er een Microsoft supported stempeltje op te zetten kunnen ze het mijns inziens beter houden bij participatie in AdoptOpenJDK ipv het JVM binaries landschap verder te versnipperen met nog een vendor-build.

[downtime]

Geoptimaliseerd betekent in dit geval voornamelijk dat Microsoft nu de garantie heeft dat Azure-specifieke patches ook echt in de JDK komen en niet om bedrijfspolitieke reden eruit worden gelaten. Een grote dienstverlener als Microsoft wil niet afhankelijk zijn van een grote concurrent die zelf ook een Cloud dienst aanbiedt.

[supersnathan94]

Als dat zo is heeft het dus niet eens zin om een geoptimaliseerde versie te maken aangezien de openJDK varianten dezelfde optimalisaties bevatten. Men kan gewoon een PR indienen op de main repo en gas daar heb je geen eigen binary release voor nodig.

Een grote dienstverlener als Microsoft wil niet afhankelijk zijn van een grote concurrent die zelf ook een Cloud dienst aanbiedt.

En over wie hebben we het dan?

[downtime]

Oracle

[supersnathan94]

Mwah. Volgens mij is Oracle nou niet echt een “grote” concurrent op dat gebied hoor. Die bieden wat specifieke hybrid spullen aan, maar hebben bij lange na niet het platform wat microsoft en Amazon hebben. Al helemaal niet qua marketshare.

[downtime]

Die bieden wat specifieke hybrid spullen aan, maar hebben bij lange na niet het platform wat microsoft en Amazon hebben. Al helemaal niet qua marketshare.

En jij denkt dat Oracle dat marktaandeel niet wil laten groeien? Ze zijn nu het 1 na grootste softwarebedrijf in de wereld. Nu de wereld richting cloud beweegt zullen ze vroeg of laat ook in die markt een grote leverancier willen zijn. En geen betere manier om dat te doen dan door Java te optimaliseren voor je eigen platform en optimalisaties van "de concurrent" achterwege te laten.

Zelfs als ze dat niet zouden doen moet Microsoft iets doen om te voorkomen dat het uberhaupt mogelijk is. Zoals IE ooit gratis werd uitgedeeld om Netscape (geen concurrent van Microsoft) kapot te maken en Google juist miljarden aan Mozilla en z'n eigen browser uitgaf om juist niet afhankelijk van Microsoft te zijn, zullen ook de cloudproviders moeten anticiperen.

[Ventieldopje]

Ik dacht dat het hele "open" verhaal en forks er juist voor waren omdat iedereen er mee kan doen wat hij wil (voor zover de licentie toestaat).

Dat iets niet een slimme zet is volgens mensen.. tsja.

[84hannes]

Microsoft java is nu dus echt een ding

Weer een ding.

https://en.m.wikipedia.or...soft_Java_Virtual_Machine
https://en.m.wikipedia.org/wiki/Visual_J%2B%2B
Het was in de jaren negentig een ding van Microsoft om concurrerende technologieën na te maken en dan incompatibel te maken om verwarring te strooien en de concurrentie kapot te maken. Helaas voor Microsoft was de rechter het met Sun Microsystems eens dat Microsoft het copyright van Sun op die manier schaadde, dus toen heeft Microsoft de taal wat meer aangepast, de namen van functies, classes, modules etc aangepast, andere keywords geïntroduceerd en een totaal getransformeerd pakket op de wereld gebracht met de naam ‘c#’. Volgens mij is dit slechts theorie, maar iedereen die van C# op Java is overgestapt of andersom zal dit vermoeden kunnen ondersteunen.

[Reactie gewijzigd door 84hannes op 23 juli 2024 05:58]

[downtime]

Het simpele feit dat Oracle nooit een rechtzaak tegen Microsoft is gestart, maar wel tegen Google, zegt wel genoeg. De ontwerpers van C# waren zeker niet origineel (maar dat waren de ontwerpers van Java ook niet) maar de code is 100% Microsoft.

[84hannes]

De ontwerpers van C# waren zeker niet origineel (maar dat waren de ontwerpers van Java ook niet) maar de code is 100% Microsoft.

Klopt, en op sommige fronten is C# ook gewoon beter want ze hadden gekeerd van de fouten van Java (en J++). Over C# is naar mijn weten dan ook nooit een rechtszaak geweest. Over Microsoft Java wel.

[Eonfge]

Maar waarom? Ik begrijp dat Microsoft in OpenJDK investeert omdat dit zakelijk natuurlijk super waardevol is, maar om vervolgens een versie uit te rollen, is weinig nuttig.

Er zijn heel wat Open JDK vendors, en Microsoft is ook daar bij betrokken. Bij ons op kantoor heb ik AdoptOpenJDK gekozen omdat ze veel verschillende images en containers ondersteunen, en tovallig is Microsoft daar ook sponsor van:

https://adoptopenjdk.net/

Hoogstens is dit handig om jouw slecht onderwezen werkgever bij Oracle weg te krijgen, maar in dat geval kun je misschien beter kijken naar een andere werkgever.

Andere leveranciers zijn trouwens: Red Hat, Canonical, IBM, AWS, Azul, Suse en SAP, dus je kunt je geluk niet op... Voor makkelijk JDK management raadt ik trouwens SDKMan! aan:

https://sdkman.io/

[Reactie gewijzigd door Eonfge op 23 juli 2024 05:58]

[SuperDre]

Maarja, als je al overstapt op azure, wat is er dan niet makkelijker dan dat je de versie die daarvoor geoptimaliseerd is gebruikt?

[Eonfge]

Java, de standaard libraries en de JVM zijn allemaal onder GPL 2.0 beschikbaar. Als Microsoft een verbetering wilt maken aan JVM en deze wilt geven aan ontwikkelaars, dan moeten ze die verbetering delen.

In de praktijk betekend dat dus dat Microsoft gewoon zijn code toevoegt aan het hoofdproject:
https://blogs.oracle.com/...up/the-arrival-of-java-15

Hier kun je zien dat die aanpassingen van Microsoft in de praktijk maar weinig voorstellen. Die Azure Optimalisaties zullen waarschijnlijk dan ook niets anders zijn dan wat geheugen configuratie tweaks.

[Reactie gewijzigd door Eonfge op 23 juli 2024 05:58]

[divvid]

Java heeft w.m.b. teveel bomen, ik zie het 'boss' niet meer...

[Hoopje]

Java heeft niet te veel bomen, maar te veel bonen! .

Maar even serieus, ik vind eerder dat Java te weinig verschillende implementaties heeft: alles is een afgeleide van OpenJDK. Concurrentie is goed, ook bij programmeertalen. Het garandeert dat de programmeertaal blijft leven, ook als de interesse afneemt en/of aanbieders wegvallen. Maar van de populaire programmeertalen ken ik er eigenlijk maar twee die echt verschillende goede implementaties hebben: C en C++. O ja, Javascript nog, maar dat is geen programmeertaal, dat is een bak ellende .

[uiltje]

Ik denk dat dit komt omdat Java heel veel functionaliteit biedt en het schrijven van een compatibele class library heel veel tijd kost. En Sun heeft dat met Apache Harmony redelijk de nek omgedraaid ze onmogelijke voorwaarden stelden aan Apache. Hierdoor werd dit nooit een geteste compatibele Java versie.

Sun had hun test platform ook moeten Open Sourcen. Want zonder dat ben je puur op API beschrijvingen aangewezen (en die zijn erg goed, maar de devil is in the details).

Daar krijg je dan wel weer een stabiel ontwikkelplatform met weinig incompatibiliteit voor terug.

[Reactie gewijzigd door uiltje op 23 juli 2024 05:58]

[aikebah]

Dan wordt het tijd om je rode hoed op te zetten, dan komt de Java boss vanzelf weer in zicht.

[uiltje]

Wel handig om in het artikel te melden dat zowel Java 8 als Java 11 Long Term Support (LTS) releases zijn, waarbij Java 11 de laatste LTS release is. Java SE 16 is in Maart van dit jaar uitgebracht. Java 17 is de volgende LTS release in September.

Het lijkt erop dat je dat als lezer maar moet weten. Dat is iets te veel veronderstelt.