'Oracle begint met aanspreken klanten om licentiekosten Java'

Zes jaar na de overname van Sun Microsystems begint Oracle met het aanspreken van klanten om overtreding van de Java SE-licenties. Het bedrijf heeft de licentiemanagementafdeling uitgebreid om klanten te vragen achterstallige betalingen te voldoen.

De site The Register sprak met verschillende personen die in de tweede helft van dit jaar door Oracle zijn benaderd en verwacht dat het bedrijf in 2017 meer ondernemingen zal benaderen. Veel bedrijven zouden niet weten dat Java SE voor 'algemene doeleinden' gratis is, maar dat er voor andere toepassingen betaald moet worden. Daaronder vallen onder andere toepassingen in smartphones, handhelds en blu-rayspelers. Het onderscheid is echter moeilijk te maken, omdat er geen aparte downloads bestaan voor de twee versies, aldus The Register.

Zo maken Java SE Desktop, Advanced en Suite allemaal deel uit van Java SE, maar ze zijn niet gratis. De ceo van compliance-bedrijf Palisade Compliance legt aan de site uit dat er wordt gedacht dat Java gratis is omdat het opensource is. Een andere expert, die anoniem wil blijven, zegt dat het begrip 'algemeen gebruik' vaag is gedefinieerd, waardoor er veel conflicten ontstaan. Als een bedrijf Java bijvoorbeeld doorgeeft aan eindgebruikers wordt dit niet meer gezien als algemeen gebruik en wil Oracle betaling.

De licentiekosten variëren van 40 tot 300 dollar per gebruiker en van 5000 tot 15.000 dollar per processor. Volgens The Register groeide de licentiemanagementafdeling van Oracle dit jaar met twintig man en onderneemt het bedrijf nu pas actie omdat het lang duurde om zijn klanten in beeld te brengen.

Reacties (209)

[killingdjef]

Even een kleine nuance aan het artikel welke hier mist:

Om gebruik te maken van de features waarvoor betaald moet worden, moet expliciet "-xx unlockCommercialFeatures" aangeroepen worden. Dit zit al in Java sinds 1.7.0_04-b20 (15 mei 2012 !)

Features waarvoor betaald moet worden zijn bijvoorbeeld geavanceerde profiling tools. Dit artikel laat het net klinken alsof Java SE niet meer gratis is maar dat is onjuist. Stemmingmakerij en jammer dat dit niet dieper uitgezocht is.

Bron:
http://www.oracle.com/tec...7u4-relnotes-1575007.html
http://www.oracle.com/us/...suite/overview/index.html

[slaapkopje]

Nee, dit gaat niet alleen om de commercial feature, dit gaat echt over commercieel gebruik van een JVM. De nuance klopt dus wel en de stemmingmakerij komt van Oracle.

[Mr_Light]

Het gaat niet over java, het gaat om een Runtime en tooling en specifiek die van Oracle. Deze license is onveranderd sinds het nog van Sun was en dat is dat de JDK van (Sun/Oracle) vrij gebruikt mag worden op general purpose devices (PC's) en dat voor embedded een licentie afgenomen moet worden. Daarnaast zijn er nog de tools die standaard meegeleverd worden maar die door unlockCommercialFeatures flag expliciet enabled moeten worden - zoals Mission Control.

De OpenJDK mag iedereen vrijgebruiken en valt hier helemaal buiten en is de official reference implementation. (als sinds 2012)

Daarnaast zijn er nog andere distributies onder andere van Azul die ook een embedded versie heeft en redhat geeft nog specifieke builds van openjdk voor windows. etc.

Het originele artikel van the register is express vaag en geeft niet echt een heel waarheidsgetrouw beeld met de hele history in het achterhoofd. Het is nieuws is dat er een gerucht is dat Oracle voornemens is nu eindelijk aan het werkt gaan, 6 jaar nadat het heeft still gelegen.

//EDIT
in dat ding dat iedereen wegklikt staat het ook gewoon duidelijk:
http://www.oracle.com/tec.../terms/license/index.html
A. COMMERCIAL FEATURES. You may not use the Commercial Features for running Programs, Java applets or applications in your internal business operations or for any commercial or production purpose, or for any purpose other than as set forth in Sections B, C, D and E of these Supplemental Terms. If You want to use the Commercial Features for any purpose other than as permitted in this Agreement, You must obtain a separate license from Oracle.
Last updated 02 April 2013

[Reactie gewijzigd door Mr_Light op 22 juli 2024 16:23]

[SCiENTiST]

Alleen als je gebruik maakt van features uit Desktop, Advanced of Suite.

[jimshatt]

Bron? Ik zeg niet dat je ongelijk hebt, maar killingdjef komt met enigszins overtuigende links, en jij met niets.

Verder vind ik het hilarisch dat Oracle zijn eigen FUD aan het creëren is. Dit komt me erg over als een SCO-move. Of ze willen java bewust doodmaken, of ze zitten erg krap bij kas.

[Verwijderd]

of ze zitten erg krap bij kas.

mwaa valt wel mee.. ze hebben 58 miljard dollar op de rekening staan.

[jimshatt]

Dan is de enige mogelijkheid dat ze java dood willen. Of ten minste, dat het ze niet zoveel kan schelen wat er met java gebeurd. Ze hebben het hoertje Java van Sun gekocht en zullen elke cent eruit slaan. Tot nu toe heeft het ze weinig opgeleverd, dus het is een poging waard.

[OddesE]

Tja noem me cynisch maar ik denk dat je teveel 'bewustzijn' aan Oracle toekent. Ik vraag me af of er überhaupt in het Oracle management iemand is die zich beseft dat Java dood zou kunnen gaan.

Ze willen het niet dood hebben, ze willen gewoon geld zien. Linksom én rechtsom. Alles zoveel mogelijk uitwringen. Zit een beetje in het Oracle DNA. Zit verder weinig denkwerk / strategie achter ben ik bang.

[Stoelpoot]

Ik denk dat niemand ook verwacht dat Java dood kan gaan. Het is een van de weinige cross-platform languages en een van de meest gebruikte talen ter wereld.

[kidde]

OpenOffice, Solaris en SPARC zijn ook dood of aan het doodgaan; OpenOffice was het meest gebruikte cross-platform office pakket ter wereld.

LibreOffice is nu populairder dan de dode Oracle variant, misschien lukt dat OpenJDK ook. En bedrijfsmodel van je eigen klanten aanklagen moet haast wel fout gaan, zie oa de Microsoft/Ballmer hetze tegen Linux.

[ToolkiT]

Ik denk dat je de spijker op de kop slaat.
Java is niet iets wat erg in de picture is binnen Oracle heb ik het idee. En het dood maken heeft geen enkel nut... als ze er niks mee will dan doeken ze wel de hele afdeling op en klaar.. Het is gewoon een centenkwestie.. het gaat om sofware waar licentie voor nodig is, dus word dat enforced.. de enforcement van licenties is Oracle altijd erg streng in geweest..

disclaimer: ik werk sinds kort voor Oracle..
Wat ik tegenwoordig wel zie is dat met de nieuwe cloudwereld er een cultuuromslag aan de gang is.. Men moet telkens meer denken als een services bedrijf ipv een licentiebedrijf.. Dat is een langzaam process, maar er is wel degelijk verandering qua mentaliteit..

[Verwijderd]

Ik denk niet dat ze dat "willen" maar Oracle is niet echt vooruitstrevend en goed omgegaan met haar overname. Als Oracle echt wou hadden ze met JAVA echt zo veel meer kunnen doen. Heck.. "Powers Minecraft!" zou zo een Slogan kunnen zijn, nooit gebruik van gemaakt .

[pven]

'Powers the internet!' had er ook een kunnen zijn

[i-chat]

powers just about anything, even your teacup if you prefer....

ik hoop dat daar nu een eind aan komt, gewoon zodat die vreselijke troll naar de haaien gaat...

[ToolkiT]

je mist geloof ik de verwijzing van pven naar de slogan van oracle van 'software powers the internet' en 'java powers the internet'
http://ihub.co.ke/blogs/16227

[RetroMan]

Vanwaar de negatieve connotatie? Bedrijven moeten geen klanten plezieren of mooie dingen maken; ze moeten geld verdienen.

[Accretion]

Het punt zit hem in het klanten plezieren, die tactiek is goed op lange termijn.

Op korte termijn kun je heel veel geld vragen aan je klanten, maar reken er maar op dat ze dan de eerstvolgende kans pakken om over te stappen op je concurrent.

[i-chat]

het punt is gewoonterecht, je kunt niet bedrijven jaren lang 'gratis' gebruik laten maken van iets, om dan ineens na de verkoop van het bedrijf als nieuwe eigenaar komen met... ja u moet nog zo en zoveel betalen...

als oracle zegt dat ze per 1 januarie 2017 geld gaan vragen voor alle nieuwe devices (en/of alle devices die een update krijgen met daarin een scherning van hun rechten... staan ze mijns inziens volledig in hun recht... ook (en voornamelijk) omdat iedereen dan in staat is gesteld er iets aan et doen (namelijk een migratie naar opjdk of desnoods zelfs een heel andere tooling...

wat men nu doet is gewoon wat oracle altijd al heeft gedaan en willen doen... de 'patent troll' uithangen.

[mphilipp]

Oracle wil Java dood hebben? Dat is grootste nonsense die ik ooit gehoord heb. Check your facts voordat je onzin uit gaat kramen aub.

Feit is dat Oracle jarenlang heeft samengewerkt aan de ontwikkeling van Java (Larry & Scott zijn dikke vrienden). Oracle had zelfs een eigen variant van de JVM die ietsje voor liep voor zijn eigen Oracle Applications suite.

Feit is dat de hele applicatie strategie van Oracle inmiddels rond Java is gebouwd. Het zou heel erg raar zijn als ze dan Java ineens dood willen hebben. Dus ja, het is misschien onhandig van Oracle, maar dat doen ze wel vaker. De juridische afdeling gaat soms wat voortvarend aan het werk. Vooral als ze denken veel geld op te kunnen halen...

[jimshatt]

Rustig maar, ik was maar aan het brainstormen. Ik heb het niet echt als feit neergelegd volgens mij (zou ik nooit doen zonder bronvermelding).

[martenjacobs]

Maar toch lijkt er een nuance te missen in het artikel van Tweakers... Er wordt gesteld dat
"De licentiekosten variëren van 40 tot 300 dollar per gebruiker en van 5000 tot 15.000 dollar per processor."
en onder de niet-gratis licenties "vallen onder andere toepassingen in smartphones, handhelds en blu-ray-spelers."

Ze verwachten toch niet dat een leverancier van telefoons straks 20.040,- dollar gaat overmaken voor elk quad-core mobieltje dat wordt verkocht?

[lezzmeister]

Ik zou denken dat ze dan $40 per apparaat willen zien? Alsnog erg veel als je voor een mobieltje van €100 gaat.

En zoniet, er staat niet dat per processor gelijk staat aan per core.

Ik vermoed dat het express heel vaag word gehouden zodat ze zo veel mogelijk moolah per klant kunnen halen.

[martenjacobs]

Goed, 5040 dollar per mobieltje dan, klinkt al een stuk redelijker

[Myri]

Inflatie... we krijgen er allemaal mee te maken...

[Verwijderd]

Wat betekent dat nu? Als ik een desktop applicatie heb gemaakt en die commercieel gebruik, zou ik dan moeten betalen?

[elmuerte]

Nee, alleen als je gebruik maakt van de commerciële features die je expliciet moet enablen, of als je gebruik maakt van embedded versie van Java.
Maar verwacht niet dat Oracle dit minder vaag gaat maken.

[sgrinovero]

Je vergist jet: dat is juist wat niet klopt in het artikel van The Register. Een hoop FUD.

[dashorst248]

Waar Oracle op uit is, is niets nieuws. Dat er voor de commerciële features van Java betaald moest worden is al op z'n minst bekend sinds 2010, maar voor wanneer je in de industrie bekend bent, had je al moeten betalen als je deze features uit JRockit gebruikt had.

De aankondiging van Henrik uit 2010 over de strategie van Oracle met betrekking tot Java:
- https://blogs.oracle.com/henrik/entry/oracles_jvm_strategy

En een jaar later beantwoord hij veel gestelde vragen over Java 7 en de samenvoeging met JRockit, en de daaruit voortvloeiende onduidelijkheid met betrekking tot de commerciële features:
- https://blogs.oracle.com/.../java_7_questions_answers

En natuurlijk kan je ook gewoon de officiële bron lezen waar Oracle (on)duidelijk maakt waar nu wel en niet betaald moet worden:
- http://www.oracle.com/tec...terms/products/index.html

Ik ben geen advocaat, maar als je op je server Java draait van Oracle, heb je, zolang je geen XX:+useCommercialFeatures gebruikt, geen probleem. Distribueer je Java naar je klanten of maak je gebruik van die vlag, dan mag je waarschijnlijk de portemonnaie trekken en jouw bijdrage aan de jacht van Larry doen. Lees in elk geval de licentievoorwaarden, en als je daar niet uitkomt, vraag dan aan iemand die dat wel doet wat het voor jou betekent.

Of gebruik OpenJDK.

[OddesE]

Distribueer je Java aan klanten

Tja ik ken wel wat software bedrijven die dat doen ja. En je hebt natuurlijk gelijk dat Oracle deze voorwaarden hanteert maar wat een onzin weer toch?

Als je nu een installer bouwt die gewoon Java downloadt van de Oracle website en dan installeert... distribueert die installer dan Java of Oracle zelf? En als we erkennen dat dan Oracle zelf de distributeur is, betekent dat dan dat dat is hoe die bedrijven die distributie voortaan gaan doen? Lijkt me een eenvoudige wijziging voor die bedrijven en meer kosten voor Oracle.... Niet echt slim?

[atlaste]

Voor de mensen die niet zo veel zin hebben om nu ineens te gaan betalen en bezig zijn met een migratie heb ik wel een serieuze oplossing: .NET

Nee, serieus. Met IKVM ( https://www.ikvm.net/ ) kan je Java binaries hercompileren naar .NET binaries. Dit werkt niet voor complete Java applicaties (AWT en Tomcat werkt vast niet 1 op 1), maar een hoop backend spul werkt er wel gewoon mee. Een aantal grote projecten zoals Lucene, OpenNLP en Weka zijn bekende libraries die op deze manier standaard geport worden naar .NET.

Voor de mensen die denken dat dit niet toekomstvast is: de coreclr en core libraries van .NET zijn tegenwoordig open source onder de MIT licentie.

[martijn_brinkers]

OpenJDK is ook open source. Voor alle Windows liefhebbers is er zelfs een OpenJDK 8 die wordt onderhouden door RedHat. Ik vertrouw RedHat toch meer dan Microsoft.

https://developers.redhat...ow-available-for-windows/

[atlaste]

Vertrouwen...? De MIT licentie spreekt gewoon voor zichzelf hoor.

[MrFax]

OpenJDK is dan een goed gratis alternatief op Oracle Java SE(GPLv2). Het is alleen niet voor Windows beschikbaar en moeilijker mee om te gaan.

[novasurp]

Het is wel voor Windows, er zijn onnoficiële builds te vinden.

[elmuerte]

Nope, officiele builds van RedHat: https://developers.redhat.com/products/openjdk/overview/

[sgrinovero]

Wat bedoel je? Heb je wel naar die link gekeken?

Red Hat maakt juist builds van OpenJDK beschikbaar, inclusief voor Windows.

Zou ik wel iets van moeten weeten, ik werk op dat team..

[novasurp]

Sorry, ik had zijn tekst verkeerd begrepen en had niet op de link geklikt. Opnieuw, sorry! Dat ik +1 krijg.

[Reactie gewijzigd door novasurp op 22 juli 2024 16:23]

[sgrinovero]

np, ben blij dat het nuttig was. Dank je voor de feedback!

[Verwijderd]

Dit plaatje is volgens mij al meer dan 10 jaar oud...

http://www.bonkersworld.n...organizational_charts.png

...en nog steeds relevant. Oracle is een advocatenkantoor, geen software bedrijf. Ze hebben overigens hetzelfde met MySQL geflikt: bedrijven ineens opbellen dat het geld kost, maar waarom en hoeveel is niet duidelijk.

[hylke45]

Dat is wel typisch Oracle ja.
Vreemd genoeg blijft mijn hogeschool alles van Oracle maar naar ons pushen, ook zeer verouderde dingen. Het verkrijgen van een Oracle server schijnt ook nogal een vreemde wereld te zijn, kan vaak een stuk goedkoper als je maar de juiste mensen kent blijkbaar.

[FreezeXJ]

Vermoedelijk omdat ze een mooi contract hebben met Oracle... Overheden zijn dolblij met Oracle, omdat ze alle certificaatjes hebben, totaal-oplossingen leveren, en een hele goeie sales-afdeling hebben die zelfs de grootste aap (die vaak toch de leiding heeft daar) nog kan overtuigen. Ja dat kost je een hoop geld (minder als je lief bent voor bepaalde mensen), maar dat is wel het laatste waar grote partijen zich druk om maken.

[ToolkiT]

Niet de juiste mensen kennen maar het process kennen en kunnen onderhandelen..
Binnen oracle heeft iedereen van zelfde nivo de zelfde bevoegdheden ...

[Reactie gewijzigd door ToolkiT op 22 juli 2024 16:23]

[SinergyX]

En de volgende stap van het einde, al eerder gingen er diverse platformen stoppen met java (ING, DNB etc), dat zal nu nog meer redenen geven om helemaal te stoppen met Java.

[TheGhostInc]

Iedere (redelijke) programmeur kan in elke taal wel iets werkend krijgen,

De kracht van Java heeft weinig met Java zelf te maken, maar met de mensen die Java kunnen programmeren. Een groot deel van de Javanen zitten in de 'Business'-software. Daar maakt het eigenlijk geen drol uit in welke taal het geschreven wordt, maar WEL dat iets functioneel klopt.

Java kent veel domein specialisten, die meer weten van het domein dan van Java. Wat misschien niet de mooiste code oplevert (of nodig heeft!), maar wel uiteindelijk de business case vervult die al die ontwikkeltijd verantwoord.
Dan is het leuk dat je het in .Net in de helft van de tijd zou kunnen, of in Python met de helft van de code, maar als die programmeurs geen idee hebben WAT er moet gebeuren. Dan kunnen ze in de helft van de tijd en met de helft van de code helemaal niks.

Overigens zie je daarom zoveel MS Access en VBA en andere ellende in het veld. Geschreven door mensen die weten wat er moet gebeuren, maar niet weten hoe het moet. De programmeur die het moet opruimen heeft net zoveel tijd nodig om het te herschrijven omdat alle uitzonderingen en ellende eerst moeten worden gedocumenteerd om daarna 'snel' te worden geïmplementeerd.
Je kunt soms beter de 'schuldige' een programmeer cursus geven dan te proberen de requirements boven water te krijgen.

[BikkelZ]

Het wordt een beetje de nieuwe COBOL. Het is wachten op wat Google doet met Android. Dat zal de nagel aan de doodskist zijn de dag dat die overstappen. Als je kijkt hoe snel developers naar Swift over gingen bij iOS toen Apple het roer om gooide, mensen staan ook te trappelen om iets moderners over te stappen bij Android.

[Boy]

Ik hoop echt dat dat Kotlin wordt

[BikkelZ]

Ik heb nog nooit iets met Kotlin gedaan maar wat ik er van gezien heb is erg interessant.

[Boy]

Ik gebruik het nu in een project. Alle nieuwe code die ik schrijf doe ik in Kotlin, naast mijn bestaande Java code. Leuker om te doen, minder code, dingen als Butterknife gewoon niet nodig...Ik moet nog veel leren erover, maar je kan al aardig snel aan de slag als je gewoon begint!

[EchoWhiskey]

"Het wordt een beetje de nieuwe COBOL"

Er zijn nog mega veel (legacy) applicaties in COBOL geschreven.
Deze ontwikkelaars hebben nog jaren werkgelegenheid.

[Accretion]

Dat klopt.

Zo zal het waarschijnlijk ook met Java gaan dan. Op een keer heb je als Java ontwikkelaar alleen nog de functie van het onderhouden of uberhaupt werkend houden van oude code van anderen.
Code die ver in de business geduwt is en te kostbaar of "oud" is om nog te kunnen vervangen.

[Leejjon]

Dat betwijfel ik. Java is gewoon een zeer volwassen taal waar je heel veel mee kan. Er zijn zoveel talen uitgekomen de laatste jaren, maar hoeveel zijn er nou echt populair geworden?

[Leejjon]

Daarvoor heb je nu de Optional class sinds Java 8. Verder kan je met Nullable en NotNull annotaties aangeven of er null in argumenten meegegeven mag worden. Ik geef toe dat als er nu een nieuwe taal gemaakt word dat mooier opgelost zou kunnen worden, maar backwards compatibility is ook wel een kracht van Java. En als je wel veel waarde hecht aan syntax sugar zijn er andere JVM talen.

[Reactie gewijzigd door Leejjon op 22 juli 2024 16:23]

[BikkelZ]

Het zijn allemaal dingen die een programmeur vooral niét moet vergeten en die nergens afgedwongen worden. Bovendien ook nog eens niet 100% waterdicht net zoals notnull in Objective-C. En ook nog eens performance hogs terwijl nullable pointers al trager zijn dan non-nullable pointers als je die gewoon vanaf het begin had gebruikt.

Het is gewoon een hele klasse aan zeer vaak voorkomende bugs waar je constant zélf aan moet denken in plaats van dat je er direct aan herinnerd wordt door de de compiler.

In Swift moet je force unwrappen voordat je een crash krijgt die lijkt op een null pointer exception, dát kost moeite. Het is vrij prettig om iets in productie te hebben staan waar een foutje in zit wat niet gelijkt de hele app laat crashen omdat je een niet gezette optional negeert met bijvoorbeeld een early return omdat de taal je dwingt er iets mee toe doen. Zeker in het geval van een iOS app die je normaliter maar maximaal één keer per maand kan pushen.

[latka]

Een belangrijke reden om Java te verkiezen boven andere omgevingen is de ontzettend rijke omgeving. De taal is nauwelijks interresant. De bibliotheken (de veelvoud, de uniformiteit en de vindbaarheid) is echt een plus geweest (en nog steeds). XML naar Edifact omgezetten: 2 library calls en wat domeinobjecten en boem. Ik ken geen enkele andere omgeving waar dit ecosysteem zo volwassen is. Ja ik doe ook .Net en nee, komt niet eens in de buurt. Nuget is leuk, maar een rommeltje qua inhoud.
MS Access (en nog veel meer Excel) herken ik ook wel als: doet wat het moet doen en is niet fraai "but it works". Wat veel erger is zijn de C# oplossingen die als next-step verschijnen: 100% not-invented-here syndroom spagethi.

[OddesE]

Ik heb meer dan 10 jaar Java development gedaan en je hebt helemaal gelijk; het heeft een zeer uitgebreid ecosysteem met voor vrijwel alles wat je kunt verzinnen meerdere goede open source implementaties.

Ik ben inmiddels overgestapt op Node JS en kan je aanraden daar ook eens naar te kijken. NPM (de package manager van Node) heeft één gigantisch voordeel boven alles wat er in Java is: het is de de facto standaard package manager voor Node met 80.000 packages en zowel het consumeren van packages als het publiceren ervan is doodsimpel. Ik heb inmiddels wel 20 packages op NPM gepubliceerd, gewoon omdat dat zo simpel is en lekker werkt. In Java is consumeren lastiger en publiceren al helemaal (ik heb ooit een package op Maven central gekregen maar makkelijk is dat niet).

Node JS ligt nog duidelijk achter op Java wat betreft eco systeem maar ze zijn bezig met een inhaalslag en lopen elke dag verder in. Bovendien heeft het (voor mij) weer plezier in het programmeren opgeleverd. Probeer het eens uit zou ik zeggen.

Edit: 80k packages zeg ik? Inmiddels al 387.850!

[Reactie gewijzigd door OddesE op 22 juli 2024 16:23]

[supersnathan94]

Sorry maar consumptie is met Java echt wel eenvoudig hoor. Als je alleen al kijkt naar de 5,68 miljoen gepubliceerde artefacts geeft dat op zoch wel aan dat er meer dan zat depencies zijn voor een willekeurig probleem. Snel even een json conversie doen is bijvoorbeeld een eitje.

Met Maven hoef je niet per se je oackages te publiceren. Je kan namelijk de meeste packages gewoon zelf hosten en daar een aangepaste POM met locatie voor leveren. Hierdoor zit de rest van de wereld niet opgescheept met jouw custom code die alleen in jouw case werkt. Ik neem aan dat dit met NPM ook gewoon kan.

[OddesE]

Ja consumptie is redelijk eenvoudig. Veel projecten staan op Maven Central en dan is het een kwestie van een fragmentje XML copy-pasten.

Maar toch. Vergeleken met NPM is het echt een stuk minder handig. Ten eerste omdat er zoveel verschillende toolsets zijn voor Java. Veel projecten maken geen gebruik van Maven maar van iets anders. Vaak moet je gewoon de JAR downloaden.

Bij Node JS is NPM echt een standaard geworden en dat is heel krachtig. Ook is de configuratie file simpeler en de CLI makkelijker in het gebruik. `npm install --save my-dependency` type ik gewoon uit mijn hoofd. Het toevoegen van een dependency aan een Maven project deed ik meestal door de XML te copy-pasten want het CLI commando daarvoor is gewoon veel te lang.

En het is moeilijk om te overschatten hoe belangrijk het is dat het publiceren van packages een fluitje van een cent is. Er vanuit gaande dat je een unieke naam voor je project gekozen hebt is het een kwestie van `npm publish` en bam het staat op NPM. Doordat dat zo makkelijk is ga je je programmeerstijl aanpassen. Die module in je project, dat wordt een apart project met aparte tests die je published op NPM. Onbewust vermijd je het in Java om je code te modulair te maken omdat je de overhead van het maken van een apart project niet wilt. Dat merk ik nu voor mezelf tenminste.

[latka]

Ik ken geen serieus project wat niet bouwt op Maven central (of via Maven of via Graddle of whatever de build tool du-jour). Probleem van Javascript: geen strong typing. Sorry, 1960 wil zijn typesysteem terug ;-) En NPM: ik begreep dat er nogal wat zooi tussenzit (slecht onderhouden etc.) dus geen curation. Op maven central ook niet, maar de drempel is iets hoger en tools als Nexus geven wel aan hoe vaak een library in gebruik is (en daarmee de 'robuustheid' index). Dus NodeJS: naaah. Ik wacht wel op de volgende hype ;-)

[OddesE]

Tja hype. Aangezien Javascript de enige taal is die out-of-the box beschikbaar is op vrijwel elk device en ook nog eens een van de 3 basic building blocks van het web is lijkt het me niet dat het zomaar weggaat of zo. Als je typing belangrijk vind ben je niet de enige! Kijk eens naar TypeScript, wat eigenlijk type informatie toevoegt aan Javascript.

[martijn_brinkers]

Klepel klok? Ik denk dat je Java Applets en Java op de back-end door elkaar haalt. Java Applets zijn al jaren geleden een stille dood gestorven. Java server side is een heel ander verhaal. Tweakers maakt voorzover ik begrijp ook gebruik van Java voor de back-end (reviews: Tweakers 7: waarom een eigen Java-back-end?)

[Paul - K]

Waar zijn die nu op overgegaan dan?

[SinergyX]

ING zakelijk gebruikte Java uitsluitend voor in te loggen met die ID-kaart/machine, die is volledig vervangen door nieuw model met challenge/response principe zonder enige vorm van Java.

[joco]

wat bedoel je precies met dit? jij hebt het denk ik weer dat je op je laptop/desktop een java app nodig was? En nu doe je het gewoon in de browser?

[sjongenelen]

Java kan ook een webservice hosten en http compliant antwoorden. Java is wel veel meer dan de cliënt software.

[joco]

precies maar dat wou ik eigenlijk even uit SinergyX krijgen

binnen ING is bijna alles java en scala schijnt nu ook flink terrein te winnen
Maar ja waar draait scala op? juiste op de java vm. Dus het platform is nog steeds gelijk alleen de programmeer taal is anders.

[OddesE]

Maar ing.nl draait (i.i.g. deels) op Java; het JSESSIONID cookie is een dead giveaway.

[supersnathan94]

De backend van ING en zowat iedere andere bank, is vrijwel kompleet gebaseerd op Java in combinatie met microservices voor uptime, load balancing en continuous integration. Dikke kans dat er gewoon een spring framework achter hangt wat ook weer kompleet Java is.

[Rarz]

.Net Core. De timing had niet beter kunnen zijn.

[OMX2000]

Swift en golang zijn de twee talen die je ECHT in de gaten moet houden. .NET Core is heel gaaf, maar het ".NET reimagined" wat het had moeten zijn is het niet meer. Het .NET core team is bezig met gekissebis terwijl de concurrentie full steam ahead bezig is om talen/platformen te maken die geschikt zijn voor de huidige microservices/containerized in de cloud oplossingen.

[uiltje]

Swift is Apple only en blijft dat daarom ook.

Golang heeft geen excepties, iets wat je zou missen in een business taal. Alleen het versnellen van compileren en tegenhouden van buffer overruns is niet voldoende .

Golang zal minder makkelijk bij te houden zijn. Vergeet niet dat veiligheid en (nog belangrijker) onderhoudbaarheid zeer belangrijk zijn - of horen te zijn - bij bedrijfstalen.

Er bestaat een enorme hoeveelheid rommel die in Java is geprogrammeerd. Meestal kost het me niet veel tijd om die rotzooi te identificeren (zeker vergeleken met C/C++ meuk).

[OMX2000]

Swift is open-source. IBM gaat ermee aan de haal voor Enterprise development bijvoorbeeld: https://developer.ibm.com...le-ibm-swift-development/

[uiltje]

Java is ook Open Source. Maar om het werkelijk goed te kunnen gebruiken ben je vaak aan Oracle overgeleverd.

Bij Apple is dat nog sterker aanwezig, vooral omdat Xcode de enige IDE voor Swift is. En omdat Apple te sterk het roer in handen heeft zal niemand zo gek zijn om een tweede ecosysteem op te zetten.

[SCiENTiST]

ING stoppen met Java? Vrijwel hun hele systeem draait op java...

[Verwijderd]

De nagel aan de doodskist van Java. Dit gaan heel veel bedrijven niet leuk vinden, en dus overstappen op betere platformen zoals .NET of Swift.

[Verwijderd]

Java is niet hetzelfde als .NET en Swift.

Met Java kan je bijvoorbeeld hard-realtime systemen maken. Op een RTOS .NET en Swift zijn meer general purpose met een bepaald doel. Java is veel breder. Of je moet naar C++ gaan.

[BikkelZ]

C++ en Swift zijn sterk vergelijkbaar, Swift is iets minder direct dan Rust en C++ maar wel directer dan Java met garbage collection. Voor Swift kwam Objective-C(++) en Swift is daar 100% compatible mee. Het grote verschil tussen C/C++ en Objective-C/C++/Swift is dat het de laatsten met Automatic Reference Counting werken, wat een performance penalty heeft maar wel een zeer constante.

[Jonathan-458]

Laten we hopen dat het het einde van Java inluid.

[Reactie gewijzigd door Jonathan-458 op 22 juli 2024 16:23]

[Myri]

Waarom? Met Java ben ik onmiddelijk cross-platform?

[Sando]

Waarom?

Is dat een serieuze vraag? Ik dacht dat iedereen dat sentiment van Jonathan-458 wel deelde. Oracle is berucht om zijn aggresieve praktijken en jaagt verschillende communities (eigen devs, open source community, andere bedrijven, regering en FBI*) tegen zich in het harnas. Meest bekend waarschijnlijk de Google/Android affaire, daar waar Google eerst nog werd aangemoedigd door Sun om Java op deze manier te gebruiken.

Een andere bekende case is het "oneindig veel geld" contract dat Oracle met de staat Oregon had voor de zorgverzekeringportaal Cover Oregon. De FBI onderzoekt de zaak nu.

Verder ben ik alleen bekend met de open source praktijken. Daar waar Red Hat miljarden om kan zetten en teruggeeft aan de community, lijkt Oracle de community te vervreemden en devs die het op deze projecten had zitten dwars te bomen, anders in te zetten, of te ontslaan. Daarom zijn ook hun eigen werknemers ontevreden, en zoals Red Hat bewijst is het niet omdat ze anders geen boterham verdienen.

Meestal kopen ze iets op wat GPL is, veranderen de licentie naar iets wat incompatibel is met open source maar wat gratis is voor hun eigen Oracle Unix (Solaris) of Oracle Linux. Verder werken ze vrije software wat ze in handen krijgen zo hard tegen, soms niet helemaal duidelijk waarom, dat hun eigen devs opstappen en ook de vrijwillige community er geen zin meer in heeft.

Denk aan:

• Open Office. Kwam in handen van Oracle. Deze liet het doodbloeden, en 'doneerde' het vervolgens aan de Apache Foundation, daar waar open source projecten heengaan om te sterven. Geforked naar LibreOffice.
• MySQL. Erg populair maar de gratis versie een doorn in het oog van Oracle's enterprise producten. Geforked naar MariaDB door ontevreden devs.
• OpenSolaris. Bewust dood laten bloeden door Oracle. Geforked naar OpenIndiana door ontevreden devs.
• Gijzelen van andere Enterprise-type open source projecten als dtrace en ksplice.
• OpenDS, geforked naar OpenDJ en main developer vertrokken
• Hudson CI, geforked naar Jenkins CI. Oracle liet Hudson doodbloeden en doneerde het aan de Eclipse Foundation.

Met Java ben ik onmiddelijk cross-platform?

Dus? Ook met Golang. En met Scala ook. Die laatste is zelfs JVM compatible.

[Reactie gewijzigd door Sando op 22 juli 2024 16:23]

[Jonathan-458]

Veiligheid

[latka]

Zucht. FUD in actie. Java op de server is een stuk veiliger dan C of C++ op de server. Geen buffer overflows, geen memory leaks etc. Java op de desktop is een ander verhaal, maar vergelijkbaar met Flash, ActiveX, Internet Explorer en Microsoft Office (allemaal zeer onveilig). Maar het is heel hip om dit te roepen. Dat snap ik wel.

[OddesE]

Java zelf was nooit onveilig. Het was de browser plugin (niet geschreven in Java maar in C++!) die onveilig was.... omdat die geschreven was in C++.

Je hoeft als Java dev maar heel even door de issue tracker van bijv. Firefox te bladeren om meteen weer genezen te worden van een eventuele sentimentele hang naar vroegere tijden. Schrikbarend veel harde crashes (potentieel allemaal security exploits), buffer problemen en alle soorten ellende die je krijgt als je handmatig geheugenmanagement moet doen.

Ik ben geen fan van Java als taal maar het is echt stukken makkelijker veilig te maken als C++, gewoon omdat de taal je voor veel fouten behoed. Natuurlijk kun je er nog steeds ook heel makkelijk onveilige zooi mee maken maar het heeft echt een hele categorie aan fouten geëlimineerd.

EDIT: sorry latka was als reactie op Jonathan bedoeld

[Reactie gewijzigd door OddesE op 22 juli 2024 16:23]

[servies]

Java zelf was nooit onveilig. Het was de browser plugin (niet geschreven in Java maar in C++!) die onveilig was.... omdat die geschreven was in C++.

Ook iets te kort door de bocht. Software is niet onveilig vanwege de gebruikte taal, Software is onveilig vanwege de fouten die de ontwikkelaar maakt...

[OddesE]

Ja veel te kort door de bocht inderdaad... Maar dat helpt soms om een punt te maken

Je hebt helemaal gelijk natuurlijk; software is onveilig doordat de ontwikkelaars fouten hebben gemaakt. Probleem is dat ontwikkelaars mensen zijn en dus (aan de lopende band) fouten maken. Wij mensen zijn erg fout-tolerant. En we maken ook veel fouten. Het een is nodig om het ander te compenseren. C++ als taal is niet erg fout-tolerant. Het laat je de meest gekke dingen doen zonder je te laten nadenken of het wel klopt. Daarbij is de syntax voor hoe het wel moet soms even angstaanjagend als de syntax voor hoe het niet moet... een PCHAR **variable .... ehm dat is dus (sterretje is pointer) ehm een pointer.. naar een pointer... ehm .. naar een PCHAR wat weer een pointer is naar een CHAR array ennneh... Damn!

Je ziet dat zelfs geoefende programmeurs regelmatig 'beginnersfouten' maken met C++... en die zijn dan al snel gevaarlijk ook.

Voorbeeld: Alloceer je in C++ een array en loop je er fout doorheen (waarbij je langs het einde gaat) is een subtiele geheugenfout met (hoop je dan) een crash het gevolg.

Doe je hetzelfde in Java, dan krijg je gegarandeerd een IndexOutOfBoundsException voor je kiezen, met een nette stacktrace die precies laat zien in welke regels code het fout gaat.

Wat met C++ per ongeluk een hele tijd 'goed' kan gaan en dan leidt tot een sluimerend security issue is in Java gewoon elke keer precies dezelfde exception, guaranteed. En dat maakt Java zoveel veiliger. Maar uiteindelijk blijft het mensenwerk en kan de compiler/taal maar zoveel voor je doen.

[latka]

vorige week nog: https://technet.microsoft...library/security/MS16-148 inclusief remote code execution exploits in Excel. Ga er maar vanuit dat iedere applicatie minimaal 1 security issue per Mb geinstalleerde programmatuur bevat. Dan kom je redelijk in de buurt (uiteraard geld dit voor software die mature is, anders is het veel meer). Office is een paar honderd Mb aan software, dus ze zijn nog wel even bezig (en iedere release begint het feestje weer opnieuw). Is niet vreemd, hoort er helaas bij.

Oh, en als dat een reden is om software liever te willen zien verdwijnen kun je dus nog even doorgaan. Een lege harde schijf is redelijk veilig te noemen

[Reactie gewijzigd door latka op 22 juli 2024 16:23]

[Jonathan-458]

Okey, daar heb je wel gelijk in.

[Myri]

Veiligheid? Waarom zou ik niet net zo secure kunnen werken in Java als in eender welke andere taal?

Kan je dat wat verduidelijken?

[BikkelZ]

Swift is niet echt een platform en dus geen vervanger. Wel een mooie taal, en hopelijk vanaf versie 4 écht stabiel qua ABI.

Maar .Net maakt juist de omgekeerde beweging die Oracle maakt, van klote bedrijf met een gesloten omgeving naar alles open source en multi-platform met een vriendelijke benadering naar de community. Java heeft de slag om mobile ook al verloren, het kan niet lang duren voordat Google een alternatief gaat bieden terwijl C# juist de sterkste multi-platform taal is.

[Leejjon]

Mijn ervaring is anders. Microsoft heeft zeker een aantal goede stappen gemaakt door Xamarin te kopen (en daarmee RoboVM wat ze daarbij kregen de nek om te draaien) is het chill dat er Android/iOS support geboden word. Maar voor het grootste deel is C# gericht op Windows only.

Kijk eens welke taal het meest gebruikt word op Github (zegt natuurlijk ook niet alles aangezien bedrijven wellicht vaker team foundation server gebruiken):
http://githut.info/

Libgdx bijvoorbeeld gebruikt een setup waar je een Java code base kan gebruiken voor Windows/Linux/Mac/Android/iOS/Html(door middel van GWT). Met een gradle (of maven) build script kan je je project zo configureren dat hij voor al deze platformen bouwt.

iOS support werkt via het 'Multi OS' project van intel.

[Reactie gewijzigd door Leejjon op 22 juli 2024 16:23]

[BikkelZ]

Kijk eens welke taal het meest gebruikt word op Github (zegt natuurlijk ook niet alles aangezien bedrijven wellicht vaker team foundation server gebruiken):
http://githut.info/

Qua selectief shoppen in gegevens heb ik ook een goeie:
http://stackoverflow.com/research/developer-survey-2016

Microsoft heeft altijd in Visual Studio geïntegreerde CVS'en gehad die voor veel gebruikers en organisaties goed genoeg waren. Pas sinds een paar jaar wordt Git steeds meer omarmd. Nog los van het feit dat Sun een open source cultuur voedde en Microsoft dat vroeger niet deed, voordat die cultuuromslag voor beiden in omgekeerde richting is voltooid zal er nog wel wat tijd over heen gaan.

[Leejjon]

Dus in je eigen link heeft C# 7% meer bij "full stack". Bij alle andere opties scoort Java hoger.

[BikkelZ]

Prima, ik spreek je over vijf jaar nog eens.

[Snake]

.NET is een Framework, Swift een taal. Je kan die 2 niet samengooien.

[uiltje]

Mja, een beetje wel. Beide bieden een API en een platform. De taal mist voor .NET inderdaad. Maar merk op dat de taal VB aangepast werd om te kunnen werken met .NET. In andere woorden, .NET is een manier om met ontwikkeling om te gaan, hoewel het de daadwerkelijke taal mist. De taal moet wel aangepast zijn op .NET om te kunnen runnen (juiste type support etc.).

C# is natuurlijk de taal die het dichtst bij .NET aan ligt; verder zijn alleen de specialistische talen erg interessant. Ik zie weinig C/C++ op .NET managed draaien, er is weinig reden voor VB behalve de installed base. En daarna kom je bij de functionele talen aan.

[P1nGu1n]

Veel bedrijven overstappen? Absoluut niet. Nieuw personeel werven of je personeel omscholen en je gehele codebase herschrijven naar een andere taal zal veeel meer geld kosten.

[crazyx]

Het hangt er vanaf, bedrijven die hun software in een andere taal geschreven hebben, zouden nu een groot voordeel kunnen hebben.

Ik zou nu ook niet meer zo snel een nieuw project opstarten met Java.

[MrFax]

Is er duidelijk wanneer je "klant" bent van Oracle/Java SE en moet je er voor betalen? Zoals het nu verwoord is moet je dus voor Java betalen op het moment dat bedrijven Java SE op computers installeren ipv de eindgebruiker. Hier zou je dus makkelijk omheen kunnen door medewerkers het zelf te laten installeren?

[Reactie gewijzigd door MrFax op 22 juli 2024 16:23]

[slaapkopje]

Oracle heeft aan het bedrijf waar ik werk gevraagd om een voorstel, ze weten het zelf ook niet precies en ze hebben ook niks duidelijk op hun website omschreven. Bij ons komt de licentie neer op een betaling per vm en per virtual cores voor de virtuele servers in de productie omgeving. Het komt wordt voor ons een paar duizend dolars, maar de manier waarop ze al sinds 2014 hun SE licentie model aan het vormgeven zijn is absoluut niet transparant.

Het gaat dus niet om client installaties of voor intern gebruik, maar om VM's die onze klaten een service aanbieden. Voor tientallen procenten extra krijgen we dan wel support en de niet-publieke versies van oude software

[Reactie gewijzigd door slaapkopje op 22 juli 2024 16:23]

[djwice]

Als het zo door gaat ga ik java uitfaseren. Wat een onzin allemaal.

[Jeanpaul145]

Goed idee! Sterker nog, ik ben al bezig, ook vanwege technische redenen (Garbage Collectors zijn zo 2009, en daarnaast heb ik gemerkt dat Exceptions een extreem slecht mechanisme zijn om errors op een sane manier te managen, wat verergerd wordt door Java's checked/unchecked scheiding).
Nu er ook financiële en juridische redenen bijkomen is de maat vol en moet ik niets meer hebben van de JVM.

Dat gezegd hebbende zit ik in de 'luxe' positie dat ik geen noemenswaardige legacy had om te porten van Java, wat natuurlijk niet voor iedereen geldt. Ik heb alleen een paar Clojure projecten die ik tzt moet porten.

[teunw]

en daarnaast heb ik gemerkt dat Exceptions een extreem slecht mechanisme zijn om errors op een sane manier te managen,

Wat is jou mechanisme voor error management dan?

[Jeanpaul145]

Composable Error Values (CEVs), iets dat niet goed door Java wordt ondersteund btw, maar wel door talen als Rust en Haskell. Het idee is dat als een gegeven Error E1 veroorzaakt wordt in een functie F1, en de oorzaak daarvan is een Error E2 die door een diepere functie F2 wordt geretourneerd*, dat dan F1 zoiets kan retourneren:

E1 {
cause: E2 { /* relevente data voor E2 */ },
/* andere relevante data voor E1*/
}

Door dit consistent te doen krijg je errors die direct traceerbaar zijn naar de code
die het gegenereerd heeft. Ook heb je een human-readable representatie voor elke error, ongeacht of er mooie stack traces zijn (die sowieso behulpzaam zijn, ongeacht of je nu CEVs gebruikt of niet).

Nu, zoals ik eerder aangaf heeft Java hier geen goede support voor. Een taal die dit wel heeft is Rust, die heeft om het simpel te houden** een enum systeem, en een switch-case expression on steroids waarmee je niet alleen op complexe structuren kan matchen dmv destructuring, maar die ook compileren laat falen zodra je niet alle enum varianten hebt afgehandeld. De combinatie hiervan is extreem krachtig, en niet alleen voor errors.

* niet gethrowd, er is geen forced stack unwinding of andere control flow magick gaande hier los van het poppen van een stack frame door de return zelf
** Er is veel meer gaande hier, en dit is een high level overview

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 16:23]

[supersnathan94]

Dat is precies wat je zou moeten doen met exception handeling in Java, maar developers vertikken het vaak dit goed uit te werken omdat je al redelijk prima de errors kunt nagaan.

Je weet precies waar iets fout gaat. Daar heb je namelijk unittests voor. Schrijf je je cases goed, dan kun je iedere error direct traceren inclusief alle relevante data.

[Jeanpaul145]

Waar het fout gaat in Java is wanneer je van een Exception wil recoveren (iets dat ik niet vaak zie gebeuren in Java en ik denk precies om deze reden), door de stack unwind kan je zomaar data kwijtraken die daarvoor noodzakelijk was. Je kan die informatie vaak in een derived Exception class stoppen om composition te bewerkstelligen, maar dat heeft z'n grenzen in Java land.

Ook is het zo dat RuntimeExceptions in principe *overal* kunnen worden gethrowed dus tenzij je de javadocs/code afstruint naar plekken waar die gethrowed worden (immers je kan 't niet zien aandacht en fn signature) zal je heel defensief om moeten gaan met try/catch, iets dat syntactisch gruwelijk lelijk is en daarbovenop ook nog eens veel handmatig werk is.

Composed Error Values hebben al deze problemen niet, en zijn normale values, geen speciale inheritance hierarchy noodzakelijk.

[misterbennie]

On Error GoTo

[MacWolf]

Een C-stijl van foutcodes terugsturen is natuurlijk een optie. Of wat Apple in Objective-C vaak doet bij methodes die fout kunnen gaan: een resultaat terugsturen of een error object (met code, gelokaliseerde foutmelding, etc...). Go heeft een vergelijkbaar model en bij Go heeft men expliciet gekozen geen exceptions handling in de taal te zetten. Objective-C heeft overigens ook exceptions, maar die worden slechts in zeer uitzonderlijke gevallen gebruikt.

De Swift manier is ook wel fijn trouwens, waarbij het nog wel erg lijkt op Exceptions als in Java, maar de ontwikkelaar moet expliciet functies die errors kunnen "throwen" aanroepen met try. Dus de ontwikkelaar kan nooit vergeten om niets met een mogelijke error te doen, de ontwikkelaar moet altijd expliciet zijn (ofwel de try in een do/catch plaatsen, ofwel fouten bewust negeren met try!, waardoor de app zou kunnen crashen, ofwel het resultaat converteren naar een optional met try?, waarbij het resultaat nil is als er een fout is opgetreden, maar het programma niet crashed).

[Reactie gewijzigd door MacWolf op 22 juli 2024 16:23]

[latka]

Oeh, die laatste klinkt wel aardig. De alternatieven zijn natuurlijk gewoon helemaal 1980 (error codes of optionals).

[supersnathan94]

In java moet dat ook. Een method met een throwable erin kan je alleen in een Try-catch aanroepen tenzij je de error handling centraal wil doen. Dan gooi je hem verder de hierarchie in en wordt hij op het hoogste niveau gepakt. Java gaat daarin nog verder door te zeggen dat een melding altijd afgevangen moet worden en hoe specfieker hoer beter.

[MacWolf]

Als ik me niet vergis kunnen in Java ook exceptions optreden die niet als throwable zijn aangemerkt op een methode? Zo ja: in Swift kan dat niet.

[supersnathan94]

Ja dat klopt. Een nullpointer bijvoorbeeld, of een list index OOB.

Exceptions kunnen voorkomen, maar alles wat je zelf opgooit moet ook weer naar beneden komen.

[FreezeXJ]

Geldt alleen voor checked exceptions, en de uncheckeds kun je gewoon lekker overal rondgooien, en daar zitten een paar hele gevaarlijke in (ClassCasts, Divide-by-zero, array out of bounds).

[supersnathan94]

Alle drie worden als het goed is een keer opgegooid als jij je Unit tests goed hebt gemaakt. Een OOB ga je trouwens heel snel tegenaan lopen maar als je een arry gaat gebruiken voor data manipulatie dan ga je er van uit dat zoiets kan gebeuren toch? De drie exceptions die je opnoemt zijn aan drie specfieke cases te hangen waarbij je ze kunt verwachten.

[OddesE]

Tja anders moet je bij *elke* method

`throws OutOfMemoryError`

erbij zetten.... zulke fouten kunnen immers overal voorkomen.

[Verwijderd]

on error resume next?

[novasurp]

Je kunt ook gewoon OpenJDK gebruiken

[uiltje]

Inderdaad, maar vergis je niet: de ondersteuning van Java SE bevat ook update management. OpenJDK komt standaard zonder dat soort ondersteuning: het is binair gezien een executable. Dat kan je wel verkrijgen, maar dan moet je naar een 3e partij zoals Red Hat.

[lordfragger]

Welkom bij Oracle, daar zijn ze echt briljant in het verzinnen van licentieovereenkomsten.

Bij heel veel van hun producten kan je zonder enige waarschuwing betalende opties beginnen gebruiken zonder dat er een optie is om die te blokkeren. Vooral bij de oracle database zijn ze daar sterk in. Zowat elke betalende feature wordt standaard geinstalleerd en is zonder meer bruikbaar, tot je een audit krijgt en plots enkele miljoenen extra kan ophoesten (en daar zit je zeer snel aan met hun prijzen).

Het blijft me verbazen hoe dat bedrijf klanten kan houden met zo'n houding.

[JAVE]

Ik heb nog geen enkele functie gevonden die betaalt... Ze kosten allemaal geld

Ga ook maar nooit over van een fysieke machine naar een virtuele met een Oracle database; de licentiekosten zijn ineens heel anders. (Zelfde product, zelfde gebruik)

[FdG]

Sterker nog, als je dat wel doet met een oudere versie van Vmware is er niks aan de hand. Als Vmware dan ineens features toevoegt zoals een betere vmotion/storage vmotion past Oracle ineens een andere policy toe: je moet niet langer alleen de cores licenteren waar Oracle op draait, maar alle cores waar Oracle mogelijk op zou kunnen draaien. Zo kan het best zijn dat je met Vmware 4 t/m 5.1 wel compliant bent, maar na een upgrade naar 5.5 of hoger ineens niet meer.
Ik snap werkelijk niet dat een bedrijf juist achter hun (trouwe) betalen klanten aan gaat, op een aanvallende en dreigende manier in plaats van te investeren in het vergroten van hun klantenbestand. Simpel: door deze houding raken ze ons als klant kwijt, en opportunities voor nieuwe verkopen bij ons Is uiteraard van de baan.
Lijkt me niet de juiste manier...

[Doetje]

Dat soort licentiemodellen in virtuele omgevingen is nu ook niet echt uniek aan Oracle. Microsoft doet net hetzelfde. Draai je Windows servers in een high availability scenario moet je op alle hosts waar een Windows VM mogelijks op kan draaien licenties hebben voor die Windows machine.

Alleen heeft MS dan wel een - goed verstopt - duidelijk document dat dat beschrijft...

[JaQ]

Heeft Oracle ook beschreven: http://www.oracle.com/us/...g/partitioning-070609.pdf

[ToolkiT]

Elk voordeel heeft ook zijn nadeel..
Op deze manier heb je geen logistieke beperkingen als je een nieuwe feature wil gebruiken.. als je anders eerst weken moet wachten op de licentie is dat ook niet ideaal..
Verder heb ik bij Oracle ook gezien dat ze behoorlijk coulant zijn bij overconsumption van services.. dat ze pas bij de service reviews ter sprake komt en er een gelegenheid word gegeven om het gebruik binnen de contract waardes te krijgen voordat er over extra geld gesproken word..

Traditioneel kon Oracle behoorlijk streng op licenties zijn, maar ik zie op het moment een behoorlijke cultuuromslag ten positieve.. maar zoiets gaat niet over 1 nacht ijs..

[WickedStealthy]

Maar zoals bij alle bedrijven is ongeveer alles onderhandelbaar
Als je dezelfde features wil, hardware etc betaal je zowat bij iedereen je blauw als je niet onderhandeld. IBM, Oracle, emc, ... noem ze maar. Ik zie dagelijks kortingen van 50% en meer hier rondvliegen.

[Kevinp]

Ik heb het gevoel dat het iets is om gewoon extra geld te verdienen.

Jaren lang hebben ze er niks aan gedaan. En nu doen ze zoiets. Ze willen bedrijven niet wegjagen, en proberen wel extra geld binnen te krijgen.

Voor grote bedrijven is 10.000 euro niet super veel geld voor software licenties. Verder is dat met veel bedrijven tussen de 1000 en 10.000 euro aan inkomsten zit je zo op een aantal miljoen aan extra "winst".

[downtime]

Natuurlijk niet. Een medewerker is een medewerker. Compleet oninteressant of die medewerker voor de IT-afdeling werkt of eindgebruiker is. Daarom zijn adminrechten voor eindgebruikers vanuit compliance-oogpunt zo riskant. Als de medewerker zelf illegaal Photoshop of AutoCAD installeert, dan mag het bedrijf toch in de buidel tasten als er een audit wordt gedaan, ook al heeft niemand dat goedgekeurd.

[iAR]

Schijnbaar zijn ze er nu achter. Ik vind het maar een vaag verhaal...

[Verwijderd]

Nou, stel een bedrijf ontwerp een handheld. Voor de software bouwen daarvan ze iets in java dus dat zetten ze erop. Daarna zetten ze hun product in de markt. Dan weet je toch wel dat je commercieel bezig bent? Als zo'n kluns als ik dat weet dan lijkt me dat een fabrikant dat ook wel weet...

Niet dat ik het een goed plan vind, daar niet van. Het zal nu wel dezelfde kant op gaan als met Flash.

[mashell]

Heeft Google al een winstwaarschuwing afgegeven? Want die zullen dan toch wel een gepeperde rekening voor al die Android devices kunnen verwachten?

[jj71]

Android is geen Java. Alleen de programmeertaal Java wordt gebruikt om Android apps te maken. De Android runtime is niet Oracle's Java runtime; Google heeft de Android runtime zelf ontwikkeld (of overgenomen). Google heeft nooit een licentie genomen op Oracle's Java implementatie. Dit artikel heeft dus niets te maken met Google en Android.

De rechtszaak tussen Google en Oracle die tot een tijdje geleden speelde ging ook over iets heel anders; Google zou namelijk gepatenteerde ideeën en API's hebben gekopieerd uit Oracle's Java implementatie.

[Reactie gewijzigd door jj71 op 22 juli 2024 16:23]

[mashell]

Vandaar ook mijn vraag. Google had Java min of meer gekopieerd. Daarmee worden ze mogelijk wel licentieplichtig.

[jj71]

Het zit zo: je mag je eigen implementatie maken van de Java SE standaard, maar je mag het pas "Java" noemen als je implementatie voldoet aan Oracle's Java TCK (Technology Compatibility Kit, een uitgebreide set van tests om te zien of je implementatie voldoet aan de standaard) en als je Oracle betaalt voor een licentie.

Android is niet een implementatie van de Java SE standaard. Je kunt de programmeertaal Java gebruiken om Android apps mee te maken, en de standaard library van Android bevat een reeks classes die hetzelfde zijn als in Java SE (bijvoorbeeld classes uit de packages java.lang en java.util). Maar het implementeert lang niet alles wat in Java SE zit en voegt er heel veel eigen API's aan toe.

Het is ook nooit de bedoeling geweest dat Android een implementatie van Java SE zou zijn, dus testen met de TCK en een licentie van Oracle kopen om het "Java" te kunnen noemen zijn niet van toepassing.

Oracle, en ook Sun vroeger, hebben in andere gevallen wel moeilijk gedaan over de TCK en licenties. Er was bijvoorbeeld het project Apache Harmony, wat een volledig open source implementatie van Java SE had moeten zijn van Apache, maar Sun en later Oracle weigerde om Harmony de tests van de TCK te laten doorlopen.

Andere bedrijven zoals IBM en HP hebben wel eigen implementaties van Java voor hun eigen serversystemen (bijvoorbeeld Java voor HP-UX, HP's versie van Unix) die voldoen aan de TCK en waar ze licentiekosten voor aan Oracle (moeten) betalen.

[Reactie gewijzigd door jj71 op 22 juli 2024 16:23]

[SCiENTiST]

Android devices draaien niet op Java SE.

[Sandermvdb]

Ik snap niet dat iedereen zo negatief is op de Java programmeertaal! Sinds een half jaar ben ik voor mijn werk overgestapt op .NET en ik moet zeggen dat ik eigenlijk voornamelijk teleurgesteld ben. Java lijkt veel meer de focus te hebben op object-georienteerdheid en er is geprobeerd om de taal simpel te houden. Mijns inziens moet de focus liggen op het functionele probleem en niet hoe fancy features van een taal daar goed op aansluiten. Het eindproduct is waarschijnlijk uiteindelijk toch complex, zeker met een complexere taal! Enkele voorbeelden: structs, delegates, extension methods, nullables, operator overloading. Daarnaast is de default binnen C# dat een methode niet overridden kan worden wat ingaat tegen het open/closed principe (minimale performance winsten vind ik trouwens totaal niet relevant).

Wat betreft het ontwikkelplatform:
- VisualVM is een geweldige profiling tool waarbij ik bij .NET nog geen tegenhanger gevonden heb
- Java logt altijd regelnummers bij een stacktrace, er bestaat geen release build of iets dergelijks
- vaker wazige problemen met Visual Studio dan met eclipse die spontaan zijn opgelost na een herstart
- community die er om heen onstaan is (Spring, Maven, git, ...). MS's filosofie lijkt te zijn om te wachten tot een andere partij het ontwikkeld heeft en die dan op te kopen.
- er hoeft geen losse tool gestart te worden om remote te kunnen debuggen

Bij C# heb ik gewoon veel meer het beeld dat een stel marketing lui de features bedacht hebben om een checklist compleet te krijgen en dat er bij Java een elegant idee achter zit.

Ik geef absoluut toe dat ik misschien nog te weinig .NET ervaring heb opgedaan (wil ook zeker geen flamewar starten...)

[Virtlink]

C# is zeer sterk geïnspireerd op Java, en heeft dus veel van dezelfde features en dezelfde tekortkomingen. Daar waar C# afwijkt hebben ze vrijwel altijd een betere keuze gemaakt. Zo is C# minder verboos, ondersteunt het échte generics (in plaats van die halfbakken type erasures die Java heeft), en werkt de taal algeheel functioneler, en met de introductie van C# 7 en 8 zal dat alleen nog maar toenemen.

Als platform heeft .NET ook uitstekende tools, zoals de tools van JetBrains, en support, zoals NuGet (zeg maar de Maven Central van .NET). En qua IDEs kan je behalve in Visual Studio en Visual Studio Code natuurlijk ook in Rider of SharpDevelop werken.

En nu Microsoft recentelijk de open-source-weg is ingeslagen, DotNet Core heeft geïntroduceerd, en over het algemeen grote stappen maakt om .NET op meerdere platformen te krijgen, wordt .NET steeds meer een geduchte concurrent voor Java in plaats van een gimmick die alleen op Windows werkt.

[latka]

Ik dacht ook altijd dat C# de betere keuzes had gemaakt. Tot ik het weer eens ging gebruiken. De notatie voor een property is werkelijk te obscuur voor woorden.

Java met Lombok: @Getter @Setter private int size;
C#: private int size { get; set; }

Naamgeving: lokale variabele met een kleine letter starten, instance variabelen met een hoofdletter. Net als classes. Is het nu een class of een instance variabele?

Debug build versus release build? Hallo 1980 wil zijn C compiler terug. Verschil los je maar in runtime op, niet in compile time. Nu moet ik in Dev een andere build draaien dan in QA en er is altijd wel een idioot die een relevant side effect erin heeft weten te stoppen.

Dan de runtime performance van .Net. Meestal wel ok. Maar als het mis gaat: veel plezier.

[uiltje]

Kotlin is dat ook en gaat verder dan C# op veel gebieden. Naar mijn mening is dat pas echt de juiste richting vanuit Java. De generics zijn veranderd. Natuurlijk is het er nog lang niet, maar als er een uber-Java is kan Kotlin nog wel eens de belangrijkste verandering zijn.

[Verwijderd]

Ik sta er neutraal in, heb geen belang bij beiden. Maar ik wil wel even opmerken dat object-georienteerd niet per definitie een pluspunt is. Ik draai al 20 jaar mee in enterprise software development, en moet nog de eerste codebase tegenkomen waarbij eventuele voordelen van OO behaald worden, of waar het een daadwerkelijk probleem oplost.

Sterker nog, OO nodigt uit tot het introduceren van heel erg veel problemen. Oneindige abstracties tig lagen diep die alleen de originele bedenker begrijpt. Of zoals het gezegde luid:

"I had a problem so I used Java. Now I have a problem factory"

[elmuerte]

Het probleem is dat je mee draait in de enterprise software business. Deze business bestaat voor een heel groot deel slechte software developers, en dus nog slechtere software development praktijken. Omdat Java nogal toegankelijk is vergeleken met C of C++ is het aantal actieve slechte developers heel groot. Dan heb je nog eens de enterprise kant die over het algemeen het idee heeft dat software development iets simpels is, en waar je dus niet veel geld voor een developer neer gaat leggen. (neefje is ook goed met computers e.d.)

In de .NET enterprise software wereld ga je echt niet veel anders meemaken.

[Verwijderd]

Ja en nee. Ik heb genoeg slechte developers gezien die fouten op laag niveau maken. Echter, het zijn zeker ook de goede, intelligente en ervaren developers die nog veel grotere problemen veroorzaken door hun ingewikkelde bedenksels.

[jimshatt]

Ongenuanceerd vs ongenuanceerd

Nooit geweest is sowieso niet waar want java bestond eerder dan C# en was toen dus per definitie beter.

• ASP.NET 1.0 was een gedrocht terwijl er voor java al meerdere zeer goede frameworks bestonden.
• Java had eerder generics (type erasure suckt, maar dat terzijde) en annotations / attributes dan C#.
• Het JCP proces zorgde ervoor dat verbeteringen door iedereen (met enigszins een bekende organisatie achter zich) aangedragen konden worden, in de vorm van JSR's. C# / .Net is een MS-only feestje, met alle voor- en nadelen vandien. Ondertussen is JCP een waardeloze instantie, maar dat was in het begin niet zo.
• Java is eerder Open Source geworden dan .Net

Ook in IDE-land was java in het voordeel naar mijn mening. Eclipse, NetBeans en IntelliJ zijn (waren) prima mee te werken toen Visual Studio nog bij elke scheet die je liet je broncode door de war schopte ('verbeteren', volgens MS).

Wel ben ik van mening dat C# / .Net Java op een gegeven moment keihard heeft ingehaald. Ook Visual Studio is de concurrentie voorbij gegaan, al vermoed ik dat het ook een kwestie van wennen is.

Het is niet voor niets zo dat de meeste grote Open Source frameworks oorspronkelijk in java ontwikkeld zijn en pas later in naar .Net geport zijn.

Overigens heb je naast java en C# nog een hoop andere talen die de moeite waard zijn en te draaien op de JVM of de .Net runtime.

[Myri]

Hangt niet alles af van je ontwikkelaars dan?
Je kan net zogoed zooi schrijven in .net als java als go als ...
Net zoals je enorm knappe dingen kan doen, alles afhankelijk van het ontwikkelteam dat je tot je beschikking hebt.

[Macshack]

Ik zou ook niet met C# beginnnen maar met een taal als F#. Als je dan toch een andere taal gaat leren neem dan meteen een functionele taal. Ik ben het met Fledder2000 dat OOP nou niet noodzakelijk een pluspunt is. Wat wat veel mensen als pluspunten zien hebben helemaal niks met OOP te maken. Plus dat OOP je uitnodigd om veel in objecten te proppen waardoor je een web krijgt aan afhankelijkheden en state (als programmeur ben ik Enemy of State). Zo ga je van spaghetti code naar een web van objecten. OOP lijkt mij een logische stap als je een interface beschrijft (knop, lijst, combobox). Maar verder zijn het grotendeels procedures die je schrijft met hier een daar een service of heel misschien een factory. Alles daar tussen zijn berichtjes of records die je door procedures heen schiet om van UI naar DB te komen en weer terug etc. Bij OOP heb je de neiging om overal verbanden te zien tussen objecten die er vaak niet zijn. En die verbanden kunnen je later parte spelen omdat het ene deel verder ontwikkeld of andere eisen heeft en het andere deel hetzelfde blijft of nog andere eisen krijgt. Het is een lang verhaal. Maar OOP is wat mij betreft niet automatisch een pluspunt. Bij OOP heb je in iedergeval 1 vriend heel hard nodig en dat is dependency injection en het programmeren tegen interfaces. Niet het hele verhaal en andere kunnen gerust aanvullen als ze denken dat ik iets belangrijks ben vergeten.

[rko4u]

ik zal maar duidelijk zijn, object georienteerdheid is een beetje uit. Waar vroeger OO het codewoord was (zo'n 10 jaar geleden) is nu vooral testbaarheid en microservices de trend. Wanneer je met microservices gaat werken, wordt het nut van logge brokken code met overerving een stuk minder aantrekkelijk.