Rechter geeft Oracle gelijk, gebruik van Java door Google was geen fair use

Oracle heeft een beroepszaak gewonnen, waardoor Google mogelijk alsnog moet betalen voor het gebruik van Java in Android. Oracle zei eerder recht te hebben op een schadevergoeding van 8,8 miljard dollar.

Het Amerikaanse hof van beroep heeft Oracle in het gelijk gesteld, meldt Bloomberg. Volgens de rechter is Google te ver gegaan met het gebruik van Java in Android om dat aan te merken als fair use. In de langlopende rechtszaak wist Google tot nu toe met dat argument weg te komen, maar Oracle tekende daar in begin vorig jaar beroep tegen aan. De zaak tussen Oracle en Google loopt al sinds 2010.

De rechter heeft Oracle nu gelijk gegeven, maar de zaak wordt weer doorverwezen naar een federale rechtbank in Californië om te bepalen op welk bedrag Oracle recht heeft. In 2016 claimde Oracle in de copyrightrechtszaak dat Google met Android 22 miljard dollar winst had gemaakt. De gewenste schadevergoeding van 8,8 miljard dollar was op dat bedrag gebaseerd.

Oracle eist een schadevergoeding van Google omdat bepaalde Android-api's op Java zijn gebaseerd. Google zegt in zijn verweer dat er maar een klein deel van de software gebruikt is in een fair use-context en dat het bedrijf daarom niets verschuldigd is aan Oracle. De ontwikkelaar van Java stelt dat de software vrij beschikbaar is voor gebruik in apps, maar dat dit niet zo is als deze gebruikt wordt in een concurrerend platform of als deze ingebed wordt in een elektronisch apparaat.

Het hof van beroep stelt dat het gebruik van Java door Google in Android niet als niet-commercieel kan gelden, ondanks dat Android gratis is. Google heeft volgens het hof 42 miljard dollar aan omzet uit advertenties binnengehaald via Android. Verder zegt het hof dat er 'niets eerlijk is aan het letterlijk overnemen van auteursrechtelijk beschermd werk en het te gebruiken voor hetzelfde doel als het origineel in een concurrerend platform'.

Reacties (148)

[TechSmurf]

Ik snap dat argument van Oracle niet helemaal over dat concurrerende platform ... Ik dacht dat het juist de kracht van Java was dat het op alle platformen zou draaien? Dat is een van de redenen dat Java ooit groot is geworden (overigens lang voordat Oracle er zelf een vinger naar uitgestoken had).

[pk128934]

Ook bij Sun was er al een duidelijke limitatie op het "gratis" (zeker niet vrij) gebruik van Java. Als je Java VMs commericieel doorverkoopt of op embedded devices implementeert, dan is er de vereiste om een licentie aan te schaffen. In het geval van Android is het beide van toepassing.
Daar doet de architectuur van de JVMs en de Bytecode niets aan af.

[P1nGu1n]

Ook bij Sun was er al een duidelijke limitatie op het "gratis" (zeker niet vrij) gebruik van Java. Als je Java VMs commericieel doorverkoopt of op embedded devices implementeert, dan is er de vereiste om een licentie aan te schaffen. In het geval van Android is het beide van toepassing.
Daar doet de architectuur van de JVMs en de Bytecode niets aan af.

Is dat wel zo? Daar gaat de rechtzaak onder andere over.

Android draait niet de JVM maar de ART/Dalvik en die interpreteert Dalvik bytecode, geen Java bytecode. Google is van mening dat ze geen licentie nodig hebben omdat ze geen code van Oracle gebruikt hebben. Ze gebruiken wel de Java API (als in de 'interface', niet de implementatie), Google vindt dat fair use. Oracle is het niet niet mee eens met beide. Geen licentiekosten is één van de hoofdredenen geweest om niet de JVM te gebruiken.

[Reactie gewijzigd door P1nGu1n op 22 juli 2024 23:55]

[Anoniem: 636203]

Maakt allemaal niet uit want de rechter zegt dat die paar regels code geen fair use zijn en dus commerciële voorwaarden van toepassing zijn. Dat betekent dat Oracle schadevergoeding kan gaan eisen.

Ik voorspel dat Oracle misschien wel jaren gaat procederen om het maximale uit de schadevergoeding te halen. Ze zullen roepen dat Android eigenlijk van hen is en dat zij door Google wel $50 miljard aan inkomsten zijn misgelopen en dat soort klinkklare onzin. Reken maar dat een gedeelte ervan toch blijft plakken en dat de boete niet misselijk zal zijn.

[i-chat]

Ook bij Sun was er al een duidelijke limitatie op het "gratis" (zeker niet vrij) gebruik van Java. Als je Java VMs commericieel doorverkoopt of op embedded devices implementeert, dan is er de vereiste om een licentie aan te schaffen. In het geval van Android is het beide van toepassing.
Daar doet de architectuur van de JVMs en de Bytecode niets aan af.

en juist DAT valt te betwijfelen, vooral die bytecode is erg dubieus als het gaat om copyright en patenten. In beginsel zijn talen namelijk niet patenteerbaar. en java (het deel dat begint met:

public class HelloWorld {
public static void main(String[] args) {
// Prints "Hello, World" to the terminal window.
System.out.println("Hello, World");
}

is een taal...

bytecode, lees, de machine code die die taal omzet in gedragingen van de hardware is dat in principe wel, lees: x86, ARM, mips etc zijn allemaal patenteerbaar evenals de manieren om van print:'hello world' een werkelijke regel tekst te maken.

Het geval wil hier echter dat JUIST die bytecode (het patenteerbare deel) door google zelf is ontwikkeld, grotendeels (naar eigen zeggen) om android te optimaliseren voor bepaalde hardware.

het zou een beetje het zelfde zijn als: een patent op de uitleg die stelt dat ik een programma wil die 1+1 kan optellen tot 2, dat kan vermenigvuldigen met 2 tot 4, en dat kan delen door 8 tot 0,5 - terwijl we hier alleen maar over menselijke taal/tekst praten net zo meselijk als het stukje java hierboven.

[Anoniem: 636203]

Het gaat er om of de API's copyrightable zijn. Daar is men het niet eenduidig over eens. Voorheen werd gesteld dat dit niet zo was, nu blijkt dat dit weer wel zo is. Dit alleen al kan enorm gevaarlijk zijn voor de software industrie.

[Anoniem: 636203]

Dan kan je toch wel stellen dat het een strategische misser was van Google om Sun niet te kopen. Je weet immers dat de kans aanzienlijk is dat in de toekomst het gebruik van Java aan banden kan worden gelegd of dat je zelfs klem wordt gezet met allerlei onzinnige eisen in de licentie.

Als ze veroordeeld worden dan is er kans dat ze miljarden aan schadevergoeding moeten betalen. Dat is bijna zoveel als wat Sun zou hebben gekost. Stom, stom, stom!!

Oracle heeft $5,6 miljard betaald voor Sun inclusief Java en eist nu $9 miljard schadevergoeding. Ook al zouden ze daar maar de helft van krijgen dan is het dik kassa voor Oracle. Dan hebben ze de hele overname er al dik uit.

Ik voorspel dat Google Android gaat ombouwen op Go of Dart of een andere taal (C#?). Dat gaat jaren duren en heel veel geld kosten, maar ze zullen alles doen om weg te komen van Oracle's Java, want het bedrijf blijft hen achtervolgen tot in de hel. Ze zullen continu de voorwaarden veranderen en daarna weer een rechtszaak aanspannen om weer geld af te troggelen.

Als Google Sun had gekocht dan hadden ze ook Java kunnen gebruiken zonder enige aanpassing en hadden ze geen eigen JVM hoeven te bouwen.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 23:55]

[watercoolertje]

Het is alleen geen java wat Google gebruikt

[Anoniem: 636203]

Ze gebruiken in ieder geval delen van Java, anders was er ook geen rechtszaak.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 23:55]

[Alfa1970]

Het gaat niet om het concurrerende platform, het gaat om het maken van een "1 op 1 kopie", doen alsof het van jezelf is, en vervolgens er niets voor te betalen. (1 op 1 kopie tussen haakjes, er zit nuance in maar voor de uitleg is dit het makkelijkst).

[David Mulder]

Het is totaal geen 1 op 1 kopie, het is juist een compleet nieuw systeem waar enkel de interface gelijk is. Dat is zo iets als het maken van een deur met een handvat op dezelfde plaats als bij een andere deur, en hetzelfde formaat deur. Of het maken van een compleet huis met op dezelfde plaatsen muren en deuren, zodat iemand zich daar thuis voelt, maar verder van ander materiaal en compleet andere maker en architect.

[SuperDre]

Nou, er waren wel degelijk 1 op 1 kopieen van api's.. alleen google vond dus dat ze die als fair use gebruikte, oracle niet omdat de licentie vannjava dat blijkbaar niet toestaat om het in een commercieel product over te nemen..

[coolmos]

16 regels. Dat was alles.

[Anoniem: 636203]

Maakt niet uit. Dan is dat de duurste vergissing ooit per regel code, want dit kan ze miljarden gaan kosten.

[David Mulder]

Een sort functie en een andere vergelijkbare simpele functie. Gezien het aantal simpele functies en het beperkte aantal manieren om die functies te implementeren is het niet zo verbazend dat er twee waren die hetzelfde waren.

[84hannes]

Als ik een architect tienduizenden euro's betaal om voor mij een huis te ontwerpen, en jij maakt vervolgens ,'alleen maar de look-and-feel' na (zonder bijvoorbeeld de mozaïekvloer in exact hetzelfde patroon te leggen) dan vind ik dat jij de rechten van het ontwerp hebt geschonden.

[David Mulder]

Behalve dat als je een houten huis van beton maakt met deuren en ramen op dezelfde plaatsen, dan schend je geen enkele copyright of 'ontwerprecht'. Je kopieert altijd wel dingen, copyright is als je exact hetzelfde doet, niet als je 1 aspect van velen kopieert.

[84hannes]

Ik wens jouw heel veel succes als je tegen de rechter zegt: 'Ik heb dat boek niet gekopieerd, welliswaar heb ik alle woorden overgenomen, maar u kunt duidelijk zien dat het op katoenvezels is gedrukt'.

[coolmos]

En dat is nou net wat Google niet heeft gedaan. Ze hebben het boek compleet herschreven (op 1 gigantisch klein stukje na), maar de namen vsn elk hoofdstuk hetzelfde gehouden. En waarom? Omdat die namen volstrekt logisch zijn. Ze hebben dus een deur een deur genoemd, een raam een raam, etc. En dan meent Oracle recht te hebben op dit bedrag? Drie tientjes zou nog teveel zijn.

[84hannes]

Omdat die namen volstrekt logisch zijn.

Die namen zijn natuurlijk volstrekt logisch omdat ontwikkelaars ze al decennia gebruiken in Java. Toen Microsoft Java kopieerde (C#) hadden ze nog het fatsoen om System.out.println() te veranderen in Console.WriteLine(). Daardoor kan je niet je Java code kopiëren en in het .Net framework draaien, je zult het echt (marginaal) moeten herschrijven.

[aldieaccounts]

Horen die namen bij de programmeertaal java? Of zijn ze onderdeel van een niet vrij te gebruiken 'platform library'? Daar gaat het om.

De beloften waarmee java ooit aan de man gebracht is (write once, rune everywhere) deed vermoeden dat de standard library (interface) deel was van de taal. Oracle ruikt geld en beweert nu van niet. Ikzelf vond de licentie altijd al iets te vrij (voor sun/oracle) geformuleerd. Nooit begrepen waarom heel de wereld zo happig was op het gebruiken van een taal die (in de kleine lettertjes) door 1 bedrijf gecontroleerd wordt.

Aan de ene kant denk ik ' tsja google, wie zijn billen brandt moet op de blaren zitten, had dan geen java gebruikt'. Aan de andere kant doet Oracle als opvolger van Sun aan 'bait and switch' en vind ik sowieso het patenteren/copyrighten van een interface iets wat strict verboden zou moeten zijn. Als je die geest uit de fles laat dan ben je als programmeur je leven(sonderhoud) al helemaal niet meer zeker. De bende met software patenten is al erg genoeg.

[Niemand_Anders]

C# heeft (veel) overeenkomsten met Java, maar heeft geen onderdelen van Java overgenomen.
Android zit anders in elkaar. Programma's worden geschreven in java (taal). Echter gebruikt Android een andere compiler waardoor er geen JVM bytecode uitrolt, maar Dalvik/ART bytecode..

Wat Google hier in feite doet is vergelijkbaar met Microsoft eind jaren 90 welke Windows specifieke API's wou toevoegen aan aan de class library. Dat was volgens Sun niet toegestaan omdat daardoor die java applicaties niet meer Linux zouden kunnen draaien. Java applicaties geschreven voor Android kun je ook niet zonder meer draaien onder Linux..

Daarbij is de java taal alleen gratis als deze voor het java platform wordt gebruikt. In dit geval wordt de taal gebruikt voor een ander concurrerend platform. In tegenstelling tot Sun heeft Oracle wel de financiele middelen om een reus zoals Google aan te pakken.

Maar je kunt niet claimen dat als je je totale platform baseert op de java taal, dat dat gebruik dan fair-use is..

[Anoniem: 80910]

Je vergeet de argumenten hebben ze ook hetzelfde gemaakt. met daarmee de classes etc zodat je op dezelfde manier door het boek heen kan, volledig compatible. Als programmeur is dit zeker interessant om te volgen. ik vind heel goed dat oracle plagiaat aankaart, ben benieuwd wat dit als gevolg is in code land. met name met de code die op github staat. moeten ze (grappig) de zoekmachine van google is op zetten om dezelfde classes te vinden op github. Het moet maar is duidelijke gemaakt worden, wat wel en wat niet door de beugel kan.

[mae-t.net]

Dat mag je uitleggen aan de auto-importeurs die geen Chinese modellen op de markt mochten brengen die "toevallig" op bestaande Westerse modellen leken. Die waren toch echt vrijwel helemaal anders - waarschijnlijk was zelfs het plaatwerk niet overzetbaar, maar het zag er toch wel zo zeer hetzelfde uit dat het auteursrecht geschonden was.

[incapable]

Even om weer terug te gaan vanaf het metaforische, je praat hier over een daadwerkelijke gelijkenis, de ontwerpen lijken sterk op elkaar. En ik ben het er absoluut mee eens dat dit auteursrechtenschending is. Dit zou ook hier waar zijn, als de taal zelf patenteerbaar zou zijn, welke hij niet is. Als de implementatie van de taal grotendeels overgenomen is, of er sterk op lijkt, dan zou er sprake zijn van auteursrechtenschending. Dit houd in principe in dat in dat geval ofwel de dalvik/art bytecode sterk moet lijken op oracle's jvm bytecode, en/of dat de onderliggende vm sterk moet lijken op oracles eigen vm.

Dus, simpelweg dezelfde api opzetten, maar deze een andere implementatie geven, zou in die zin geen auteursrechtenschending zijn, puur omdat dit niet kan plaatsvinden op een taal. Als ze daarnaast nog andere zaken hebben overgenomen, word het een heel ander verhaal

[David Mulder]

Maar waar je het het beste mee kunt vergelijken is dat Google een bepaald vervoersmiddel koos (auto => java) en een vervoersmiddel maakte wat ook een stuur heeft linksvoorin, ook vier wielen in iedere hoek, een dashboard midden voorin, etc. met het doel dat iemand die in een auto kan rijden, ook in de auto van Google kan rijden. Ze hadden natuurlijk ook een ander vervoersmiddel kunnen kiezen, maar ze kozen voor Java. De motor die er in zit is compleet anders, veel knoppen zitten op dezelfde plaatsen, maar er zijn ook compleet nieuwe knoppen... en mogelijk heeft het niet eens 4 wielen, maar eigenlijk 3 of 5.

[Reactie gewijzigd door David Mulder op 22 juli 2024 23:55]

[mae-t.net]

Een api bevat meer dan basale eigenschappen zoals je hier opnoemt. Analogieen zijn niet ideaal, maar deze vergelijking zit er te ver vanaf.

[i-chat]

het hele probleem is - het IS GEEN 1:1 kopie, - ja misschien wel van de taal en de gekozen naamgeving en argumenten, maar juist DIE zijn in beginsel niet patenteerbaar,
en zouden ook niet onder copyright mogen / moeten / kunnen vallen.

bovendien zou ik me als google nog beroepen op gewoonterecht, Als SUN in de begindagen niets tegen android heeft ondernomen, dan heeft ze haar recht op bescherming verspeeld, en mag Oracle die zeker niet meer inroepen. Dat die dat nu toch doet, en kan doen, ligt alleen maar aan het slechte amerikaanse stelsel. in de EU zou zoiets veel minder kans van slagen hebben.

[Anoniem: 167912]

bovendien zou ik me als google nog beroepen op gewoonterecht, Als SUN in de begindagen niets tegen android heeft ondernomen, dan heeft ze haar recht op bescherming verspeeld, en mag Oracle die zeker niet meer inroepen.

Dat kan gelukkig niet zomaar. Als jij een copyright schendt doe je dat ongetwijfeld zonder de eigenaar daarvan op de hoogte te brengen. Er is geen copyright politie, het is de eigenaar die dat zelf moet zien te achterhalen en dan actie kan ondernemen.
En Oracle is volgens het artikel al sinds 2010 aan het procederen, ik weet niet wanneer android op grote schaal op de markt is gekomen maar het was in ieder geval na de introductie van de iPhone in 2007.

[TWyk]

De API definities zijn misschien niet patenteerbaar maar wel auteursrechtelijk beschermd.
Het is prima mogelijk om nieuwe API's definities te schrijven. Ja, dan kun je geen bestaande software meer gebruiken zonder deze te poorten maar dan heb je wel zelf het product bedacht en alle rechten daarop in eigen hand. Google heeft gekozen voor een oplossing om de onderliggende code te kopieren zodat niemand anders daar rechten op zouden hebben maar ze hebben wel het API definitie deel gekopieerd waar ze geen rechten op hadden zodat er veel software hergebruikt kon worden onder het mom van fair use. Dat is een keuze die Google veel heeft opgeleverd. En nu misschien weer geld gaat kosten

[Reactie gewijzigd door TWyk op 22 juli 2024 23:55]

[bkor]

(1 op 1 kopie tussen haakjes, er zit nuance in maar voor de uitleg is dit het makkelijkst).

Zo'n versimpeling kan je niet maken. Het is helemaal geen 1 op 1 kopie. Indien dat het geval zou zijn zou copyrightschending veel makkelijker bewezen zijn.

Het gaat om het namaken van de API. Compleet wat anders.

[Jeoh]

Tuurlijk is het fijn dat het op zo veel mogelijk platformen draait, zolang Oracle maar geld in het laatje krijgt.

[invic]

Je denkt dat Google geen geld aan Android verdient? Via Android weten ze meer dan de nsa... Een verdienen ze miljarden aan advertenties waar wij ermee gespam worden !

[Reactie gewijzigd door invic op 22 juli 2024 23:55]

[Hydranet]

http://nl.tinypic.com/r/w0qh5y/9

[TheekAzzaBreek]

Hij is leuk, maar off-topic. Die gaat over Oracle licensing op VMWare.

[lezzmeister]

Niet alleen fijn, het is exact wat Oracle graag ziet. Zang je er flink voor betaald natuurlijk.

[Vizzie]

Gewoon een bedrijf dus net als oh ik weet niet...Google bijvoorbeeld?

[84hannes]

Oracle is wel even een tikje erger dan de meeste bedrijven hoor. Ze maken niets voor consumenten, dan hoef je net als bijvoorbeeld SAP niet een product te maken waar klanten blij van worden: je moet een product maken waar bedrijven niet vanaf kunnen komen. Naar mijn mening niet te vergelijken met, om maar wat te noemen, Volkswagen (als het je niet bevalt is je volgende auto een Citroën), Google (Gmail werkt lekkerder dan Yahoo! Mail, maar ik zou best kunnen overstappen) of Jetbrains (die IDE' werken gewoon fijn): als je eenmaal in het Java-ecosysteem zit, of je applicaties op een Oracle database draaien, dan wil je niet meer switchen. Ook niet als de volgende versie duurder, trager en lastiger te configureren is.

[Vizzie]

Wat een onzin (niet dat je moeilijk van Java af kan kan maar de rest). Alsof bedrijven die aan andere bedrijven niet hoeven te zorgen dat klanten blij worden van hun product. Bedrijven zijn ook gewoon klanten hoor.

Er zijn een heleboel bedrijven die alleen aan andere bedrijven leveren en die willen allemaal dat het lastig is om een andere leverancier te kiezen. Oracle is daar niets erger in dan andere bedrijven.

Als je je als bedrijf in een positie brengt dat je zo afhankelijk bent van een van je leveranciers dan moet je niet piepen als die leverancier iets doet wat je niet aanstaat (mits binnen de wet).

Google verdient letterlijk miljarden aan de software van Oracle en betaalt daar niet voor terwijl dat wel moet.

Dat is wat mij betreft een veel beter voorbeeld van een naar bedrijf.

[Reactie gewijzigd door Vizzie op 22 juli 2024 23:55]

[84hannes]

Bedrijven zijn ook gewoon klanten hoor.

Bedrijven hoeven niet 'blij' te worden van een product, ze moeten er mee kunnen werken. Dat zie je aan producten als Lotus Notes, SAP, Sharepoint en heel, heel veel andere baggerproducten die je van je baas moet gebruiken maar die je thuis nooit zou gebruiken, zie bijvoorbeeld Stack Overflow om te zien hoeveel mensen Sharepoint in het weekend gebruiken.
Dat gezegd hebbende is er inderdaad veel meer nodig om 'evil' te zijn: IBM en Red Hat leveren ook vooral aan bedrijven, maar hebben toch niet het slechte imago dat Oracle heeft. Er zijn een heleboel indirecte argumenten die erop wijzen dat Oracle geen prettig bedrijf is, maar ik heb geen directe bewijzen. Wel vind ik dat de snelheid waarmee Open Source ontwikkelaars wegrenden toen Oracle Sun overnam, en daarmee ook Open Office (geforked naar LibreOffice) en MySQL (geforked naar MariaDB) een duidelijk signaal was.

Google verdient letterlijk miljarden aan de software van Oracle en betaalt daar niet voor terwijl dat wel moet.

Dat is natuurlijk verschrikkelijk overdreven. Google verdient miljarden aan Andoid. Android bestaat uit heel veel onderdelen van Google heel veel werk in gestoken heeft. Ze hebben voor de programmeertaal/API inspiratie opgedaan bij Java van Oracle. Daarvan heeft de rechter nu gezegd dat dat niet netjes was. Maar dat is net zoiets als beweren dat Mercedes miljarden verdient aan het werk van Ford, omdat Ford het proces een eeuw geleden al heeft geoptimaliseerd: dan onderschat je ernstig hoeveel werk r komt kijken bij het ontwikkelen van een auto. Jij bent niet productief door Notepad, ook al gebruik je het elke dag.

[Reactie gewijzigd door 84hannes op 22 juli 2024 23:55]

[mikesmit]

Lees de andere reacties hier. Java is niet gratis mits voor commercieel gebruik en/of op embedded devices

[jj71]

Java is niet gratis mits voor commercieel gebruik en/of op embedded devices

Dat is wat te simpel gezegd. Vele duizenden bedrijven gebruiken Java voor allerlei commerciële business software en ze kunnen de Oracle Java VM daarvoor gewoon gratis gebruiken. Daarnaast heeft Oracle commerciële support beschikbaar, waarvoor je moet betalen.

Je moet een licentie hebben van Oracle als je je eigen implementatie wilt maken van de Java VM specificatie en je wilt het officieel "Java" noemen. Er zijn een paar bedrijven die hun eigen JVM implementatie hebben, bijvoorbeeld IBM en HP voor hun eigen Unix servers.

[smitae]

Ik snap het niet helemaal.

Java is sinds 2007 Open Source (GNU GPL) maar ergens kwam iemand op het idee dat je op de API's wel een copyright kon krijgen, later weer niet, dan fair-use, dan weer niet. En daardoor is het toch niet zo OpenSource GNU GPL als je zou denken.

Vreemd zaakje. Dat Oracle doorzet snap ik wel, heel veel geld uit het verleden en mogelijk nog heel veel in de toekomst?

Blijft toch echt een ding, dat copyright. Kost meer dan je lief is :-) Uiteindelijk betalen de consumenten alle kosten, niet handig.

[Tangled Tales]

De GPL licentie geeft je de toestemming om code te kopieren, aanpassen en herdistribueren zolang je dit opnieuw doet onder de GPL licentie. Google heeft de onder de GPL gepubliceerde API (en bepaalde implementaties) overgenomen, en vervolgens alles wat ze ermee gedaan hebben van de GPL licentie gestript omdat ze niet wilden dat andere delen van Android en afgeleid werk ook onder GPL vrijgegeven zouden moeten worden. Dit is dus een schending van GPL.

Google's verdediging is dat een API niet licenseerbaar is en dat daarom de hele GPL licentie uberhaupt niet van toepassing is. In mijn ogen heeft Google echter oneigenlijk gebruik gemaakt van GPL software en bewust de licentie geschonden omwille van geldelijk gewin en het beschermen van hun eigen werk.

[Reactie gewijzigd door Tangled Tales op 22 juli 2024 23:55]

[David Mulder]

Naja, dat wat belangrijk is dat de consument de kosten betaald op een manier die de persoon die het werk verricht geld bezorgd, zodat die persoon weer meer werk kan verrichten. Dus dat is het super handige aan copyright. Hetgeen hier zo vaag is, is dat de copyright op een interface is... wat natuurlijk ook wel iets van werk is, maar niks vergeleken met de implementatie ervan. Dus ja, apart verhaal dat ze in beroep verloren hebben.

[Anoniem: 890159]

De persoon die het werk verricht ziet daar gewoonlijk niks van. Men zou copyright al aanzienlijk verbeteren als het tot een niet overdraagbaar recht van een natuurlijke persoon zou beperken. En niet langer dan 5 jaar na publicatie laat gelden.

[David Mulder]

Dus hoe zou je dan een film maken? Stel je wilt als Netflix een film aanbieden, zou je dan licentie overeenkomsten moeten maken met iedere houder van een klein stukje copyright in de gehele film? Dat is compleet niet te doen. Of als ik als programmeur iets voor een klant doe (naja, dat is auteursrecht), en ik dan met iedere klant van die klant een overeenkomst moet aangaan. Copyright en auteursrecht moet overdraagbaar zijn en door een rechtspersoon gehouden kunnen worden, want anders is het niet mogelijk om grotere projecten te organiseren.

En stel dat je enkel 5 jaar de tijd hebt vanaf publicatie om je geld terug te verdienen, dat zou betekenen dat een gigantisch deel van de populatie simpelweg 5 jaar zou 'wachten'... en de rest die niet kan wachten zou plots een veelvoud moeten betalen van wat ze nu betalen. En ergens is het ook compleet oneerlijk; als ik als individu iets met m'n handen maak is het voor altijd van mij (en daarna van m'n kinderen en hun kinderen, etc.). Als ik echter iets met m'n 'brein' maak, dan zou het plotseling door de overheid na 5 jaar van me worden 'afgepakt'. Ik bedoel, ik ben een groot voorstander ervan dat na een bepaalde tijd een werk in het publieke domein komt, gezien het niet te doen is als we copyright voor altijd laten gelden, maar "tot het einde van het leven van de auteur" lijkt met het minimum (en om te voorkomen dat bekende auteurs worden vermoord een toevoeging van "en minimaal tot 75 jaar na publicatie").

[Anoniem: 890159]

Nou doe je net alsof kennis iets is dat je kunt bezitten en als iemand anders het heeft jij het niet meer hebt. Maar dat is nou net het mooie: als ik iets uitdenk en het jou leer dan ben ik het niet kwijt maar hebben we beide die kennis. Als ik iets met m'n handen maak en jij maakt het na hebben we het ook beide.

Dat het bepaalde verdienmodellen onderuit haalt zie ik niet als een probleem. Het feit dat het door de industrie steeds verder oprekken van imaginar eigendom en de steeds fanatiekere handhaving van die gekochte wetgeving fundamentele vrijheden aantast vind ik veel erger.

[TWyk]

En daardoor is het toch niet zo OpenSource GNU GPL als je zou denken.
...
Blijft toch echt een ding, dat copyright. Kost meer dan je lief is :-)

Je begrijpt toch wel dat GPL puur een copyright gedreven licentie is. Zonder copyright waren alle voorwaarden in de GPL helemaal niet af te dwingen.

[smitae]

Wel grappig. Je snapt heel goed wat ik bedoel maar je wilt blijkbaar een punt maken.

Je weet ook dat GNU GPL onder copyleft valt? Strikt gesproken ook een soort van copyright.
Maar juist "bedacht" om aan te geven dat men het tegenovergestelde van copyright wil.

Dus ja, copyright blijft een irritant ding.

[Anoniem: 636203]

Oracle denkt dat zij kunnen bepalen hoe iemand een stuk software mag gebruiken wat zij zelf ge-open sourced hebben. Dat is natuurlijk compleet belachelijk. Rechtspraak wordt zo een lot uit de loterij. Je kan net zo lang door procederen totdat iemand je je zin geeft.

Google zal wel verder procederen en zo zal je zien dat uiteindelijk alleen de advocaten hier wijzer van worden.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 23:55]

[OdieHerpaderp]

Het mag dan wel open source zijn, maar er is alsnog een licentie die er aan hangt die je niet zomaar kunt schenden in een commerciele setting zonder problemen.

[multimho]

Het ligt véél genuanceerder. GPL is vrij voor elk gebruik. Echter "Java" is niet GPL! De Java taal en de compiler definitie is GPL. De implementatie van Sun van de compiler is altijd al in een andere licentie geweest. Bepaalde delen van de Sun source code implementatie van de runtime zijn wel weer GPL. De implementatie (runtime en JIT compiler) van Sun is niet vrij van royalties voor commercieel gebruik in embedded devices. Daarnaast mag je de naam Java pas noemen wanneer die voldoet aan een certificerings test set die ook weer te koop is.

Dus ja de taal en compiler definitie is GPL, net als groot gedeelte van de runtime implementatie en compiler (in source code vorm), maar niet voor commerciël gebruik in embedded systemen.

Had Google meteen hun eigen compiler (Dalvik) gebouwd en vervolgens niet gesproken over Java, dan hadden ze nu niet hoeven te betalen.

Overigens is er nog een bedrijf dat enorm verdient aan Android door allerlei juridisch gegochel en dat is Microsoft. Die zeggen wij hebben heel veel patenten meneer de telefoon bouwer en door Android te verkopen op jullie telefoons zijn jullie in overtreding. Dus betalen. Vaak wordt de 'protection' dan maar gewoon betaald, zonder überhaupt te weten of Microsoft een valide patent claim heeft.

Dus vrije software is hardstikke mooi en handig alleen moet je goed oppassen wat er precies uitgebracht is onder de GPL en wat er allemaal nog meer is afgesproken rondom de techniek in andere overeenkomsten dan alleen de GPL....

[Anoniem: 636203]

Uiteindelijk heeft Google een gigantische strategische misser begaan door Android niet op C# of een andere puur open source taal te baseren. Het zal mij niet verbazen als ze in de toekomst Android ombouwen naar Go of Dart, een taal die zij zelf onder controle hebben.

Ik heb mij vaak afgevraagd waarom Google destijds Sun niet heeft overgenomen. Ze wisten toen al dat Android gebaseerd was op Java van Sun. Het is zo'n centraal onderdeel van hun strategie dat je toen al kon zien dat je dat niet in de handen van een concurrent wil laten vallen.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 23:55]

[Cyb]

De misser was dat ze de propriëtaire Oracle JDK hebben gebruikt i.p.v. OpenJDK.

[xrf]

Dat is onjuist, ze hebben niet gebruik gemaakt van Oracle's proprietary code, maar van een andere open source implementatie van Java genaamd Apache Harmony, aangevuld met zelf geschreven code. (Dit hebben ze gedaan omdat de Apache-licentie waaronder Harmony beschikbaar was minder eisen stelt dan de GPL.)

De vraag waar het in de rechtszaak om ging was of het gebruik van Java-API's inbreuk maakte op copyright. Tot nog toe is er in de softwarewereld altijd vanuit gegaan dat het gebruik van API's niet onder copyright viel, bijvoorbeeld bij het maken van een 'clean room' herimplementatie van de IBM BIOS of het herimplementeren van diverse UNIX-onderdelen in GNU/Linux.

Met Java-API's wordt bedoeld de namen van functies, classen, interfaces en dergelijke in Java, bijvoorbeeld java.lang.Integer of java.io.FileReader. De onderliggende code waarin deze functies, klassen etc. geïmplementeerd zijn is niet gekopieerd door Google. (Hoewel er wel een onbetekenend stukje van 18 regels dat waarschijnlijk uit OpenJDK gekopieerd is, in Harmony is terechtgekomen (door een niet voor Google werkende ontwikkelaar), wat Oracle vervolgens enorm heeft proberen op te blazen.)

Omdat bestaande software anders niet compatibel zou zijn met een "clean room" herinplementatie van een programmeertaal ontkom je er niet aan deze namen over te nemen; een bestaand stukje code dat java.io.FileReader verwacht zal immers niet langer werken als je het hernoemt naar google.inputOutput.ThingThatReadsFiles.

Bron: diverse Ars Technica artikelen over deze zaak (bijvoorbeeld deze uit 2016) en de nodige jaren ervaring als programmeur.

[Reactie gewijzigd door xrf op 22 juli 2024 23:55]

[Anoniem: 636203]

Waarom hebben ze dit gedaan dan? Wat is het verschil tussen die twee?

[Cyb]

Belangrijkste verschil is dat OpenJDK open source is en die van Oracle is propriëtair, en dat OpenJDK sinds Java 7 de reference implementatie is. Verder bestaat OpenJDK minder lang, waardoor Google mogelijk met die van Oracle of Sun is gestart.

Overigens zijn er ook nog andere JDK's:
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

nieuws: Google ruilt voor volgende Android-versie Java-api's in voor OpenJDK

[Anoniem: 890159]

Daar hebben ze Kotlin al voor bedacht. Met enige pech kan ik nu dat gedrocht van een taal gaan leren waar regelafsluitingen niet eens fatsoenlijk en duidelijk gedefinieerd zijn.

[Cyb]

Semicolon inference is iets wat moderne talen (Kotlin in dit geval) hebben. Je kan ook expliciete semicolons gebruiken in Kotlin als je dat prettiger vindt.

[Anoniem: 890159]

Het is een modeverschijnsel dat talen niet bruikbaarder maakt.

[WhiteDog]

Ik geef je gelijk. Ofwel een terminator ofwel een newline, maar niet beide door elkaar.

[mae-t.net]

Moderne talen, als in talen die regelnummers gebruikten?

Okay, ik ga wat kort door de bocht, maar ik ken het ontbreken van ; toch vooral van GWBASIC en dat is geen moderne taal.

[Ventieldopje]

Javascript en coffeescript hebben het ook allebei, zo zijn er vast nog wel meer talen. Maar dat zijn ook geen moderne talen zeker

[Upquark]

Wat bedoel je precies?

[Anoniem: 890159]

uit https://en.wikipedia.org/...28programming_language%29

"Semicolons are optional as a statement terminator; in most cases a newline is sufficient for the compiler to deduce that the statement has ended"

Dat maakt een taal niet leesbaarder IMO. Dan moet je oppassen met het afbreken van lange regels bijvoorbeeld, omdat de betekenis opeens kan veranderen.

[veltnet]

Ja...als je een nieuwe taal wilt leren dat heb je soms even tijd nodig om dingen af te leren en nieuwe zaken aan te leren. Dat het anders is maakt het niet per definitie slechter.

[RobinJ1995]

Uiteindelijk heeft Google een gigantische strategische misser begaan door Android niet op C# te baseren

Wat, met het .NET framework? Dan moest het (vooral in die tijd) dus ook op Windows draaien, want .NET is/was niet open source. Had dus een complete flop geweest.

Het gaat hier om de APIs, niet om de taal zelf. Het equivalent bij C# is het .NET framework...

[BikkelZ]

Op zich mooi om te zien dat Java nu waarschijnlijk versneld uitgefaseerd gaat worden door ieder bedrijf wat ook maar eventjes denkt last te kunnen gaan krijgen van Oracle. En fijn voor Android devs dat Kotlin nog harder doorgedrukt gaat worden.

Het was een leuk idee in de jaren '90 maar het is inmiddels gewoon op alle fronten ingehaald door betere alternatieven. Maar voor mensen die het niet erg vinden om software maintenance te doen is er baangarantie voor het leven, waarschijnlijk draait op sommige plekken over 40 jaar de zelfde Java code nog.

[Reactie gewijzigd door BikkelZ op 22 juli 2024 23:55]

[Cyb]

In de C# wereld is Microsoft een grote speler in C#. In de Java wereld (welke overigens een stuk groter is in open source community dan de C# wereld), is Oracle een kleine speler in de Java wereld. Dit resulteert in dat er in de Java wereld veel stakeholders zijn die meedenken en deelnemen in Java standaard en wereld, Oracle is daar slechts één van. De fout die Google heeft gemaakt is om gebruik te maken van de propriëtaire Oracle JDK, terwijl ze eigenlijk gebruik hadden moeten maken van OpenJDK, wat ze nu uiteindelijk ook hebben gedaan.

Het was een leuk idee in de jaren '90 maar het is inmiddels gewoon op alle fronten ingehaald door betere alternatieven.

Java blinkt uit op vele vlakken, met name op goede open source community, specificaties, virtual machine, compatibility. De taal is sinds Java 8 weer lekker in ontwikkeling, en er zijn veel toekomst plannen. Veel bedrijven maken dan ook graag gebruik van Java. Om een willekeurig paar bedrijven te noemen die Java gebruiken: Bol.com, Netflix, Tweakers, Twitter, LinkedIn.

Verder is Kotlin geen concurrent van Java, maar juist een aanvulling/aanwinst voor de Java community, even als bijv. Scala, Clojure en Groovy. Leden van het Kotlin team maken dan ook niet voor niets deel uit van het Java JCP Executive Committee.
Als je dergelijke talen goed wilt beheersen, begin je bij Java.

Opmerkingen als "op zich mooi om te zien dat Java nu waarschijnlijk versneld uitgefaseerd gaat worden door ieder bedrijf" komen om eerlijk te zijn erg trollerig over. Ik begrijp dat veel programmeurs om wat voor redenen dan ook graag language wars voeren met hun eigen favoriete taal in het achterhoofd, maar dergelijke opmerkingen zeggen meer over de schrijver dan over Java.

[BikkelZ]

Opmerkingen als "op zich mooi om te zien dat Java nu waarschijnlijk versneld uitgefaseerd gaat worden door ieder bedrijf" komen om eerlijk te zijn erg trollerig over. Ik begrijp dat veel programmeurs om wat voor redenen dan ook graag language wars voeren met hun eigen favoriete taal in het achterhoofd, maar dergelijke opmerkingen zeggen meer over de schrijver dan over Java.

Er ís helemaal geen language war: Kotlin is gewoon op alle vlakken een betere en modernere taal. Nieuwe projecten beginnen in Java - tenzij je verplicht wordt door legacy redenen - is gewoon een nutteloze exercitie in zelfkastijding. Een taal waarin bijvoorbeeld referenties naar classes niet standaard nullable zijn is gewoon een taal waarmee je makkelijker betere programma's schrijft. En dat is nog maar één argument (maar eigenlijk al degene die álle andere argumenten bijna overbodig maakt).

Wat eigenlijk een weggever is dat je wel weet dat Java als taal weinig meer toevoegt is dat van álle argumenten die je aandraagt er geen één inhoudelijk over programmeren in Java gaat en dat zegt eigenlijk alles. Ik kan hier tot morgenochtend doorgaan en punt voor punt aangeven waar Java een zwakkere taal is ten opzichte van andere talen. Onweerlegbare punten.

De taal is sinds Java 8 weer lekker in ontwikkeling, en er zijn veel toekomst plannen.

Too little, too late en vooral veel vage beloften tot nu toe. Nog los van de fundamentele fout nullable pointers standaard te maken zijn generics er ook maar een beetje los opgeplakt destijds in plaats van echt te integreren in de taal en JVM. Daarom zijn allerlei dingen die al een decennium te gebruiken zijn in C# gewoon onmogelijk met Java of slechts half bakken.

Het is een pompeus verhaal om Java qua belangrijkheid op te blazen maar ik lees helemaal nergens waarom nou precies Android programmeurs het dan jammer zouden moeten vinden om met Kotlin te moeten gaan werken in plaats van Java.


Ik vraag me echt af of fanatieke Java verdedigers niet een beetje lijden aan Stockholm syndrome of gewoon na 10-20 jaar Enterprise Java nieuwe ontwikkelingen een beetje vastgeroest zitten aan de tools en taal die ze kennen. Een taal die al jaren bestaat door een van de grootste spelers ter wereld een beetje wegzetten als de new and shiny toy language die wel weer weg gaat lijkt er wel een beetje op te duiden.

[Reactie gewijzigd door BikkelZ op 22 juli 2024 23:55]

[latka]

Kotlin is het nieuwe Scala: een JVM taal die iets toegankelijker is dan Scale voor de meute met een beter typesysteem, maar volledig op Jetbrains leunt. Google doet mee (leuk, maar die hebben een history van dit soort projecten achterlaten. GWT anyone?). Scala leeft, maar heeft Java niet vervangen (bij lange na niet) en ik heb het eerste conversie traject van Scala naar Java al mogen doen.
Java heeft een heel leger aan organisatie erachter zitten. Ik zie Kotlin als een leuke toevoeging op de JVM (net zoals Groovy en JRuby) en op Android als een alternatief (zoals Swift dat is voor iOS).
Kotlin lijkt me leuk, maar ik kijk over 5 jaar nog wel een keer hoe het erbij hangt ;-)

[BikkelZ]

Zoals ik al eerder aangaf baangarantie heb je met Java. Maar wat mag je dan doen? Enterprise applicaties onderhouden? Of interessante nieuwe applicaties bouwen? Mensen gebruikten geen Objective-C of Java voor mobiele applicaties omdat het gewoon het allerfijnste was wat ze konden gebruiken. Het was het énige wat ze lange tijd konden gebruiken. Natuurlijk is Google geen Apple maar Apple is wel in een paar jaar naar het grootste deel van de nieuwe projecten naar Swift code gegaan. En dat terwijl er echt hele interessante use cases zijn te bedenken waarbij Objective-C beter is dan Swift die niet eens bestaan voor Java.

[Joppiez]

"Maar wat mag je dan doen? Enterprise applicaties onderhouden? Of interessante nieuwe applicaties bouwen?"

Er wordt meer dan genoeg nieuw spul in Java gemaakt en dat zal wel voorlopig ook zo blijven. Voor een organisatie is het belangrijk dat er genoeg kennis/consultancy voor handen ligt, en dat is met Java (met haar trackrecord van decennia lang inmiddels) het geval (net als C# e.d.).

Dus ongeacht of Java nou de beste taal is of niet, dat doet er niet perse toe. Het is een taal waar ongelooflijk veel mensen mee werken of gewerkt mee hebben, waar ontzettend veel ondersteuning voor beschikbaar is. En dat is vooral belangrijk.

[MeZZiN]

Java is voorlopig nog heer en meester van bijna elk groot project. Plus het heeft een track record dat het over 5 - 10 jaar nog steeds draait. Daar kunnen de meeste talen niet zeggen.

Het grappig is gewoon elk jaar is er weer een language of the year ik hou het zelfs niet meer bij (Ruby, Golang, Kotlin, Scala, etc) er zijn er zat te noemen maar geen van alleen maakt een deuk in de adaptatie van java. Elke project waar ik kom wordt gewoon java geschreven voor oude (hele oude) projecten maar elke nieuw project ook. Zie wel wat meer beweging naar javascript (een van de 10 varianten) maar verder is Java java en oh java en een klein beetje C# maar goed daar moet ik weer niets van hebben. En C# is ook op grote afstand van java.

Java is here to stay en ja het is baan garantie (altijd handig) plus dat het gewoon een prima taal is voor bijna elke use case. En voor de vreemde usecase kunnen we altijd nog een speciale taal uit de kast trekken die beter werkt. Java werkt op alles van oude meuk tot de snelste machine die AWS je leveren kan. Op elk platform het is gewoon een zwitsers zakmes goed in veel specialist is niets.

[BikkelZ]

Kijk ik lees in jouw verhaal - sorry dat ik het zeg - eigenlijk alle vooroordelen over veel Java-programmeurs (en C# devs even goed) wel een beetje bevestigd. Geen echte passie voor de programmeertaal, gewoon een degelijke carrièrekeuze en weinig interesse in nieuwe technische ontwikkelingen buiten wat er echt noodzakelijk is om dagelijks het werk te kunnen doen. Nieuwe programmeertaal leren? Over tien jaar en alleen als het echt moet.

Elke project waar ik kom wordt gewoon java geschreven voor oude (hele oude) projecten maar elke nieuw project ook

En hoe denk je zelf dat het komt dat je alleen voor Java projecten uitgenodigd wordt? Ik zou waarschijnlijk ook tot aan mijn dood alleen nog maar uitgenodigd worden voor C# projecten als ik verder gewoon door was gekabbeld met mijn carrière. Maar ik had ergens nog iets te veel vuur in mijn ziel om de rest van mijn dagen in grijze kantoren Enterprise applicaties te schrijven.

Als je in meerdere programmeertalen bekend bent en je moet dan ineens terug naar talen als VBA of Java zonder dat daar echt een logisch voordeel aan hangt dan zit je echt te vloeken. Ik kan me ook niet voorstellen dat de huidige generatie jonge programmeurs die leren werken met modern JavaScript of Swift nog echt terug kan naar Java dus ik denk ook echt dat je steeds meer grijzende mensen om je heen gaat zien.

[MeZZiN]

Laten even duidelijk stellen ik ben geen standaard javaan (doe meer met javascript dan java). Ik geef alleen aan dat je punten wat kort door de bocht zijn zoals zoveel vooroordelen zijn over java.

Voor mij is een taal een tool om een doel te bereiken (means to an end) Java voldoet voor mijn opdrachtgevers meestal daaraan. Wat ik zelf veel doe is python javascript en ja ook java maar goed.

Voor mij is java gewoon een prima taal waar weinig mee mis is. Gezond eco systeem alleen de sommige developers (lees de meeste) maken er een potje van. En dat geeft java een slechte naam.

Verder bouw ik graag de mooiste dingen met de nieuwste technieken en java is daar een van maar het is altijd een combinatie van verschillende oplossingen. En ja soms die saaie gedrochten van applicaties moeten omgezet worden in de nieuwste technieken en tja dat is wel leuk. En dat kan ik de komende tijd blijven doen.

De realiteit is dat java nog het meest gebruikt is dus ook huidige generatie moet daar aan geloven dus die gaan ook gewoon nog een java doen. Je kan natuurlijk altijd nog je hippe talen willen maar goed wie gebruikt er nog ruby on rails... (en echt even realistisch) dat is het voorland van de meeste talen zoals Golang kotlin scale. Het zijn gewoon niche talen die het niet gaan halen. De enige echte reden dat C# nog een beetje kans maakt is omdat M$ het pushed en via de raamovereenkomsten naar binnen schuift. Maar het gros wordt gewoon in java gemaakt.

[BikkelZ]

De enige echte reden dat C# nog een beetje kans maakt is omdat M$ het pushed en via de raamovereenkomsten naar binnen schuift.

In de Enterprise wereld misschien. Maar C# gaat wel de breedte in, Unity en Xamarin hebben voldoende tractie en .Net is al lang geen Windows-only verhaal meer. Vroeger was Java de standaard cross-platform taal maar dat is gewoon niet meer zo. Ondanks dat Java wel een "native" taal is voor 80% van alle mobiele telefoons.

Je hoeft echt niet iedere nieuwe hippe taal te leren maar talen als Kotlin en Swift hebben wel de backup van grote partijen die het verschil kunnen maken en de complete stack beheersen tussen OS en IDE. Als Kotlin Java voor een groot deel gaat vervangen op Android waar dat niet door C# en JavaScript gedaan wordt dan wordt Java steeds meer een Enterprise eiland.

[latka]

Ik weet niet wat jij denkt waar Java voor gebruikt wordt, maar ik doe vrij veel met Hadoop en Kafka (big data en high speed messaging). EJBs en JSF zijn niet helemaal meer van deze tijd. Frontend doe ik HTML/JS met Rest services op het backend. Alles via JMX laten monitoren. Ik mis Kotlin precies nooit bij al deze activiteiten ;-) Apps voor mobiel? HTML5/JS + Corodova does the trick en is veel goedkoper/sneller dan een iOS en een Android versie bakken. Nope, Java bied voldoende en is een bekend gereedschap om mijn doel te bereiken. Kotlin zorgt er niet voor dat ik mijn doel sneller ga bereiken maar is wel leuk voor CV vulling. Om die reden staat het erbij.

[seapip]

Ugh html/js apps met Cordova, ja dat voelt native aan en ziet er niet brak uit

React Native zie ik dan nog wel hoop in net als Xamarin nog steeds groter aan het worden is.

Er is een reden waarom de grote bedrijven massaal hun brakke html/js apps aan het omschrijven zijn naar native apps. Enige reden om een html/js app te maken voor een klant is omdat het budget te laag is maar dan zou ik een andere baan gaan zoeken waar wel projecten met budget zijn.

[Gopher]

Welke bedrijven? Met name bedrijven zoals ING kijken steeds meer naar Polymer e.d. voo rmobile.

Zo graag wat bronnen zien

[seapip]

Rabobank is juist weer van plan over te stappen naar Native.

[anargeek]

React Native zie ik dan nog wel hoop in net als Xamarin nog steeds groter aan het worden is.

Er is een reden waarom de grote bedrijven massaal hun brakke html/js apps aan het omschrijven zijn naar native apps.

React Native apps schrijven is html & js schrijven...

[Reactie gewijzigd door anargeek op 22 juli 2024 23:55]

[seapip]

Nee, React Native is jsx en js, dit houdt in dat er geen web view met html wordt gebruikt maar er daadwerkelijk native UI Android/iOS views worden gerenderd doormiddel van js. Daardoor voelen React Native apps aan als Native apps immers wordt er gewoon een Native UI gerenderd.

[latka]

lolwut? Native apps zijn leuk voor banken en games die iets nauwer met de hardware willen werken. De meeste applicaties hebben dit niet nodig en dan moet je 3 versies onderhouden (online, iOS en Android). Bedrijven die dat strategisch verstandig vinden ga ik met een boog omheen: dat is werkverschaffing. Kun je beter tijd en geld steken in de Chrome/Firefox verbeteren om het verschil weg te nemen (als je dat al merkt). Brakke HTML apps zijn er ook ja: facebook, linked-in.

[seapip]

Facebook is geen HTML app maar een React Native app, oftewel een Native app die js gebruikt voor shared code tussen platformen en om een Native UI te renderen.

[Anoniem: 401398]

Net even de syntax van Kotlin bekeken en ik moet toch even zeggen dat ziet er vreselijk gedateerd uit wtf met al die { }. Er is een betere en ook nog Nederlandse oplossing voor deze onzin.

[jj71]

Je hebt nog nooit met Kotlin gewerkt, alleen maar nu "even naar de syntax gekeken" en omdat er, zoals in bijna alle programmeertalen van de laatste 50 jaar accolades worden gebruikt "ziet het er vreselijk gedateerd uit"? Je hebt wel erg snel een oordeel klaar over iets waar je duidelijk weinig vanaf weet...

Kotlin is een goede programmeertaal met een features die zijn geleend uit een hele reeks andere talen (o.a. Java, Scala, C# en JavaScript) en een groot voordeel wat mij betreft boven Python, Groovy enz. is dat het statically typed is.

[BikkelZ]

Kotlin is bedoeld als drop-in replacement voor Java, een betere expressievere versie van Java waarin je makkelijker veiligere code kunt schrijven. De accolades zijn er eigenlijk om mensen niet meteen weg te jagen bij het zien van de syntax, een beetje een vertrouwd gezicht voor overstappers. Maar het gekke is dat ik sowieso altijd een Pythonesque indenting flow heb ook in talen met accolades en dat ik me ook irriteer aan mensen die geen fatsoenlijke indenting doen. Veel IDE's fixen ook de indenting voor je en die doen dat ook altijd zo goed als altijd zoals Python er ook uit ziet.

Ik vind hem wel te kort door de bocht reageren maar als vandaag alle accolades zouden verdwijnen uit de talen die ik gebruik zou ik er geen traan om laten.

[quintenV]

Nederlandse oplossing? Vertel meer! Linkje is voldoende ik ben geïnteresseerd! Misschien mooie lectuur voor zodadelijk tijdens de les C# Databases

[BikkelZ]

Ik geef ook de voorkeur aan de manier waarop Python blokken structureert maar Python draait niet op een JVM. Kijk anders naar Elixir of F# als Kotlin te braaf is.

[KontI]

Groovy?

[ChillinR]

Niet direct, maar er is wel Jython.

[Anoniem: 890159]

Een taal waarin bijvoorbeeld referenties naar classes niet standaard nullable zijn is gewoon een taal waarmee je makkelijker betere programma's schrijfEr ís helemaal geen language war: Kotlin is gewoon op alle vlakken een betere en modernere taal.

Dat vind jij, maar daar is dus lang niet iedereen het over eens.

Een taal waarin bijvoorbeeld referenties naar classes niet standaard nullable zijn is gewoon een taal waarmee je makkelijker betere programma's schrijf

Krijgen we dat gezeur weer, een taal die probeert de programmeur te beperken omdat mensen proberen voor je te denken. Als je een klasse wilt die niet standaard nullable is gebruik je de annotation library in Java.

[BikkelZ]

Dat vind jij, maar daar is dus lang niet iedereen het over eens.

Jij en de onzichtbare zwijgende groep achter je die ook geen argumenten heeft?

Krijgen we dat gezeur weer

echt?

een taal die probeert de programmeur te beperken omdat mensen proberen voor je te denken

Leuk argument als je me wil uitleggen waarom C gewoon betere prestaties oplevert dan JVM of .Net achtige talen bij het schrijven van performante code. Maar het gaat in dit geval om Java, een taal die gewoon crasht op een null-pointer terwijl het 0 voordeel oplevert voor de programmeur noch voor het eindresultaat terwijl het alternatief dat niet doet.

Ja je moet wel eens een check rondom nullable objecten heen schrijven waarbij je bij Java dacht "ah joh ik doe geen check hoeft niet". Maar ook dat is vooral te wijten aan externe libraries in Java (zonder annotaties) en/of programmeurs die Java in Kotlin schrijven.

Als je een klasse wilt die niet standaard nullable is gebruik je de annotation library in Java.

Dat is slechts een pleister op de wonde zoals vele verbeteringen in de taal. Een taal die gegarandeerd geen NPE genereert compile time afgedwongen tenzij je het expliciet zelf zo schrijft is vele malen sterker dan dat.

[Reactie gewijzigd door BikkelZ op 22 juli 2024 23:55]

[EraYaN]

Leuk argument als je me wil uitleggen waarom C gewoon betere prestaties oplevert dan JVM of .Net achtige talen bij het schrijven van performante code. Maar het gaat in dit geval om Java, een taal die gewoon crasht op een null-pointer terwijl het 0 voordeel oplevert voor de programmeur noch voor het eindresultaat terwijl het alternatief dat niet doet.

Nee, want in C hoef je nooit op null te checken op pointers, C regelt gewoon automatisch al het memory management voor je...

Ik bedoel als we op die fiets gaan dan is heel het memory management ook alleen maar lastig voor de programmeur, dat stomme gezeur met malloc en free toch de hele tijd.

Daarbij is C en Java (en hun compilers) eigenlijk een slechte vergelijking. De ene komt platform afhankelijke machine code uit en is een zeer low level niet OO taal; en de andere bytecode voor een VM en een high level taal waar bijna alles en object is.

[BikkelZ]

Ik weet niet of we elkaar helemaal begrijpen maar....ik ben het in ieder geval met alles eens wat je schrijft. Maar ik kan geen enkele nuttige use case bedenken voor NPE's ten opzichte van het systeem van optionals / non-optionals in Kotlin terwijl handmatig geheugenbeheer onder C de programmeur echt meer vrijheid geeft om snellere code te schrijven.

De originele post zegt:

een taal die probeert de programmeur te beperken omdat mensen proberen voor je te denken

Dat is toch precies wat Java op een vrij klunzige manier ook doet vergeleken met C++? Je handje vasthouden en voor de programmeur proberen te denken qua memory management en pointers? @Anoniem: 890159 doet het een beetje overkomen alsof Java een taal is voor echte stoere programmeurs met woeste baarden en sandalen vergeleken met andere talen.

[Anoniem: 890159]

Nou nee, Java heeft ook z'n quirks natuurlijk maar is minder erg dan Kotlin. En er zijn nu eenmaal geen omgevingen om met C(++) Android programma's te maken die zo makkelijk werken als Android Studio. Technisch moet het natuurlijk best kunnen, en je kunt veel functionaliteit via JNI aanroepen in C++.

[BikkelZ]

Java heeft ook z'n quirks natuurlijk maar is minder erg dan Kotlin.

Onderbouw het nou eens? "In Java kan X en dat kan in Kotlin niet", "In Java werkt Y wel betrouwbaar terwijl in Kotlin je daar crashes mee krijgt". Syntax. Error handling. Alles mag. Maar kom nou eens met wat anders dan wat vage klachten over functionele code op Stack Overflow die je niet begrijpt.

[Anoniem: 85014]

Een taal waarin bijvoorbeeld referenties naar classes niet standaard nullable zijn is gewoon een taal waarmee je makkelijker betere programma's schrijft.

Ik merk hierover dat er nogal wat 'programmeurs' zijn die hierover allerlei dingen 'weten'. Als C++ programmeurs gebruiken wij vaak MijnClass& referentie in plaats van MijnClass* referentie omdat een &referentie gegarandeerd niet nullptr zal zijn. Het is namelijk een referentie naar een instantie, en niet een adres naar een instantie. Merk op dat dit specifiek is voor C++, en niet voor C.

Wanneer is dat handig? Wel, bijvoorbeeld (want het is handig in veel andere gevallen ook): Wanneer je in dat UML class diagramma die ruitjes tekende toen je dat nog moest doen op de school van de leerkracht, toen had je twee soorten ruitjes: De open ruit stond voor een aggregatie en de volle ruit stond voor een compositie.

Een aggregatie is zoals de fietser die op een fiets zit. Zonder de fietser is de fiets nog steeds een functionele fiets. Een compositie is zoals de wielen die aan een fiets hangen. Zonder de wielen is de fiets geen functionele fiets meer. Zonder de wielen blijft slechts een fietsframe over. Dat is, stel, in je programmeermodel geen Fiets meer (dat kan in je model dus niet). Dus men maakt in UML dan een lijn van de class Fiets naar de class Wiel en tekent tegen Fiets een volle ruit en zet een 2 bij Wiel. Iedere fiets heeft dus gegarandeerd twee wielen. Indien dat niet zo is, dan is het geen fiets.

Die Wiel instanties kan je in fiets nu als een referentie plaatsen (C++rs noemen dat ook wel RAII of stack variablen in de class of etc etc). Wanneer je ze doorgeeft kan je die als referentie doorgeven als parameter van een methode. Want je weet dat als Fiets verdwijnt, de twee Wiel instanties ook verdwijnen. M.a.w. kunnen die Wielen niet, nooit, nullptr zijn in de Fiets instantie die er op dat moment nog is.

Daar kan je C++ compiler dus op nakijken. M.a.w. gebruik je de type-safety van de compiler om jezelf te helpen minder bugs te gaan schrijven.

[NicoJuicy]

Noot: Kotlin is/wordt wel een concurrent van Java, aangezien het zelf gaat compileren. https://kotlinlang.org/docs/reference/faq.html

[xrf]

De fout die Google heeft gemaakt is om gebruik te maken van de propriëtaire Oracle JDK, terwijl ze eigenlijk gebruik hadden moeten maken van OpenJDK

Dat is onjuist, ze hebben niet gebruik gemaakt van Oracle's proprietary code, maar van een andere open source implementatie van Java genaamd Apache Harmony, aangevuld met zelf geschreven code. (Dit hebben ze gedaan omdat de Apache-licentie waaronder Harmony beschikbaar was minder eisen stelt dan de GPL.)

De vraag waar het in de rechtszaak om ging was of het gebruik van Java-API's inbreuk maakte op copyright. Tot nog toe is er in de softwarewereld altijd vanuit gegaan dat het gebruik van API's niet onder copyright viel, bijvoorbeeld bij het maken van een 'clean room' herimplementatie van de IBM BIOS of het herimplementeren van diverse UNIX-onderdelen in GNU/Linux.

Met Java-API's wordt bedoeld de namen van functies, classen, interfaces en dergelijke in Java, bijvoorbeeld java.lang.Integer of java.io.FileReader. De onderliggende code waarin deze functies, klassen etc. geïmplementeerd zijn is niet gekopieerd door Google. (Hoewel er wel een onbetekenend stukje van 18 regels dat waarschijnlijk uit OpenJDK gekopieerd is, in Harmony is terechtgekomen (door een niet voor Google werkende ontwikkelaar), wat Oracle vervolgens enorm heeft proberen op te blazen.)

Omdat bestaande software anders niet compatibel zou zijn met een "clean room" herinplementatie van een programmeertaal ontkom je er niet aan deze namen over te nemen; een bestaand stukje code dat java.io.FileReader verwacht zal immers niet langer werken als je het hernoemt naar google.inputOutput.ThingThatReadsFiles.

Bron: diverse Ars Technica artikelen over deze zaak (bijvoorbeeld deze uit 2016) en de nodige jaren ervaring als programmeur.

Wat wel klopt is dat Google uiteindelijk toch is overgestapt op OpenJDK.

[Reactie gewijzigd door xrf op 22 juli 2024 23:55]

[jabwd]

Ik weet niet of het meer zegt over de schrijver dan over java. Java heeft nou gewoon problemen. Naast het feit dat het te vaak gebruikt wordt door beginners, die door java een enorme achterstand oplopen door het enorme opgekloot van de "lets try to make it simple by making it more complicated" dat java overal probeert toe te passen. De eeuw oude vraag waarom een "Person, Dog both can reside in an Animal type" is daar een goed voorbeeld van: mensen snappen niet wat de taal allemaal achter de schermen doet.

Laten we eens kijken naar de simpele Socket implementatie van java. Je hebt toegang tot een OutputStream en een InputStream, beide van welk niet in alle gevallen voldoende zijn om fatsoenlijk met de socket cte kunnen werken. Waarom moet alles over wat er achter zit, namelijk gewoon een simpele POSIX socket weg gehaald worden omdat het 'toe moeilijk' zou zijn. Waarom bepaalt de InputStream wanneer de socket weer bytes kan ontvangen. Waarom is `available()` volledig nutteloos. Of ik heb issues gezien waar iemand ByteBuffer.allocateDirect gebruitke , en dit voor een corrupted data stream zorgde ( once again: omdat alles lekker abstracted wordt zodat je geen idee hebt wat er fout gaat ). Enige reden dat er achter was gekomen dat het een probleem was om allocatedirect te gebruiken is dat de documentatie opnoemde dat allocateDirect voor langdurig gebruik is, niet voor een kort-bestaande instance. Nou, dat is inderdaad een goede reden dat deze buffer denkt dat er gewoon 24 bytes aan null in het begin moet zitten ( ookal probeer je die te vervangen ).

Ik snap best dat er hele mooie toepassingen zijn voor java, maar totdat de API's een beetje beter gaan werken en niet allemaal van die hidden issues heeft, of ABSTRACT ALL THE THINGS, zie ik het als een drolletje.

[Reactie gewijzigd door jabwd op 22 juli 2024 23:55]

[Fab1Man]

Ik herken dit wel. Bij mijn studie Software Engineering begonnen we in jaar 2 met Java. Het ging specifiek om het ontwikkelen van een "AEX banner", dus letterlijk zo'n lopende banner zoals je die ziet in RTL Z. Dat was op zichzelf nog niet genoeg, het moest ook nog eens multithreaded, platformonafankelijk op meerdere pc's/Macs draaien. Deze "grap", de onwil van de docent om dit fatsoenlijk uit te leggen en het neerpleuren van de opdracht onder het mom van "zoek het maar uit" heeft mij uiteindelijk doen besluiten om met de studie te stoppen. Grote factor was de onbegrijpbaarheid voor Java van mijn kant.
Uiteindelijk ben ik Bedrijfskundige informatica gaan doen, afgestudeerd en bouw ik nu al enkele jaren apps op basis van JavaScript. Java heeft voor mij gewoon een nare nasmaak.

[280562]

ingehaald door betere alternatieven.

En wat zijn die alternatieven ?
En voor welke toepassings-gebieden zijn die alternatieven van toepassing ?
(Java werd niet alleen voor Android gebruikt. Misschien is iets anders dat goed is voor Android weer niet goed genoeg ergens anders, waar voorheen Java werd gebruikt ?)

[BikkelZ]

Het hangt er inderdaad van af voor welke toepassing je een taal nodig hebt maar zelfs binnen de JVM talen is Kotlin eigenlijk alleen maar beter zonder echte nadelen maar er zijn meer opties als je liever functioneel programmeert bijvoorbeeld. C# is qua taal een betere Java dan Java. Maar zonder op specifieke scenario's in te gaan zou ik eigenlijk altijd sowieso voor Kotlin gaan.

[latka]

Wat is er beter aan C# of Kotlin? Het zijn gewoon imperatieve programmeertalen met object orientatie en static typing (of eventueel static typing als je wilt en vars leuk vind). Net zoals Java. Eigenlijk zijn er maar 3 soorten programeertalen: imperatief, logisch (prolog) en functional (lisp). Alle andere programmeertalen zijn een mix van elementen van deze talen. Al deze talen zijn Turing compleet dus uiteindelijk kun je er hetzelfde mee doen. Beter is dus eigenlijk vreselijk subjectief. Objectief gezien zijn ze gelijk. Wellicht is een programmeur met 1 taal handiger dan met de anders, maar dat zegt meer over de persoon dan over de techniek (en techneuten hebben lange tenen in dit opzicht weet ik uit ervaring).

[BikkelZ]

Al deze talen zijn Turing compleet dus uiteindelijk kun je er hetzelfde mee doen.

Dat zou eigenlijk inhouden dat we allemaal net zo productief zijn in assembler als in reguliere programmeertalen en dat is duidelijk niet het geval. Zowel qua leesbaarheid, onderhoudbaarheid als veiligheid kies ik niet voor assembler tenzij er echt een hele duidelijke reden voor is. Wellicht overgechargeerd dit voorbeeld maar het maakt wel duidelijk dat Turing compleet eigenlijk niks zegt. VB6 is een ander voorbeeld van een taal die netjes turing compleet is maar niet echt lekker werkt voor complexe projecten.

Je programmeert eigenlijk met name voor de ménsen die na je komen, inclusief jezelf. Een prettig leesbare logica en duidelijke scheiding van functionaliteit helpt daarbij. Als het makkelijk is om correcte code te schrijven en moeite kost om fragiele code te schrijven of makkelijker leesbare code oplevert doordat de programmeertaal je helpt daarbij dan is dat pure winst.

Java is......redelijk......leesbaar maar heeft wel enorm veel regels code nodig voor basale zaken. Daarbij kost het constant extra werk om bijvoorbeeld een NP check te doen terwijl negeren niet direct een gevolg heeft zoals niet meer compileren van je applicatie. Je vraagt meer discipline aan de programmeur zonder dat je er iets voor terug geeft.

Maar andere talen leiden ook tot correctere code. In een taal als F# krijg je als je kilometers door uren deelt een waarde met het type kilometer/uur. Stel je voor dat je een compiler error zou krijgen als ontwikkelteam aan de ene kant van het land miles zou gebruiken en het team aan de andere kant kilometers. In plaats van float vs float.

True story bro.

Natuurlijk hadden de programmeurs destijds nóg betere discipline kunnen hebben om het voorkomen maar ik heb zelf het gevoel dat dat al om te beginnen geen mensen waren die over een nacht ijs gingen. Ik ga niet zeggen dat ik beter ben dan hen.

Beter is dus eigenlijk vreselijk subjectief. Objectief gezien zijn ze gelijk.

Meetbare en significante verschillen zijn er wel degelijk. Je kunt misschien meer waarde aan andere parameters hechten waardoor taal X beter uit de verf komt dan Y maar het argument dat het met name gaat om de kwaliteit van de programmeur is tegelijkertijd heel erg waar maar ook meteen een enorm zwaktebod.

Bij gelijke kwaliteit van de programmeur zitten er in een C programma meer fouten dan in een Java programma. En zo zijn er weer programmeertalen of stacks die bij gelijke kwaliteit van een programmeur betere kwaliteit van het eindresultaat opleveren dan Java.

[latka]

Ik snap je punt helemaal en deel het deels. Natuurlijk is een taal als Kotlin expressiever dan Java, maar je schrijft zelf al dat je programmeert voor het nageslacht. Juist dan is het handig niet voor Kotlin te kiezen als je ziet wat er met Scala gebeurt is: geen hond die het nog doet over 5 jaar. Helaas voor de techneuten: Cobol, Java, Fortran en VBA zijn samen goed voor de bulk van de IT.

[Anoniem: 890159]

En fijn voor Android devs dat Kotlin nog harder doorgedrukt gaat worden.

Nou fijn hoor.

Gedrocht van een syntax, geen duidelijke end of line en als je pech hebt moet je code onderhouden vaniemand die een of ander stuk onleesbare functionele sytnax van Stackoverflow copy and pasted heeft.

[BikkelZ]

Gedrocht van een syntax

Geef anders eens een voorbeeld waar een stuk Java code eleganter is dan vergelijkbare Kotlin code.

als je pech hebt moet je code onderhouden vaniemand die een of ander stuk onleesbare functionele sytnax van Stackoverflow copy and pasted heeft.

Ja dat gevaar loop je natuurlijk altijd met copy paste prutsers. Ik gebruik zelf wel redelijk wat functionele trucs maar ik zie mensen toch wel eens alles net te kort willen doen qua naamgeving en dergelijke. Het idee is dat je minder regels code schrijft maar dat ze wel duidelijker moeten zijn.

[andreetje]

Waarom zou dat anders zijn dan bij Cobol...

[mutley69]

Het is ongelooflijk dat men maar blijft in beroep gaan tot men wint in de VS - en de prijs hiervan zal hoog zijn. Oracle verdient in een wip Java terug - en Java wordt tegelijkertijd obsolete.
Verliezer: zij die op java gegaan zijn met hun platformen! Oracle gaat de prijzen nog verder op blijven trekken - zeker weten! Larry E. bouwt nu een groot feestje.

[Liberteque]

Lijkt mij in deze zaak dat Google hier de plank behoorlijk heeft misgeslagen.. Code gebruiken zonder licenties af te dragen en daar vervolgens vele miljarden mee verdienen? En Oracle is nu niet bepaald een patent trol of zo..

In dit specifieke geval is het meer dan prima dat Oracle heeft volgehouden net zolang er een rechtvaardige uitspraak kwam..

[smartsys]

Hoe heeft google dan verdiend met Android? Android zelf is gratis!
De extra apps die er bij geleverd worden en de diensten daaromheen, daar moet een fee voor afgedragen worden en daar verdiend Google dus aan.
Android heeft het mogelijk gemaakt om meer afzet voor Google te creëren, maar dat was op het moment van creatie helemaal niet zeker. Toen was het een nieuw mobiel OS, naast IOS, Symbian en Windows Phone.

Waarom is Oracle op het moment van introductie of kort daarna niet naar de rechter gestapt? Het gebruik van die API was toen toch ook al bekend?
Wederom is men gaan wachten tot iets mega succesvol blijkt te zijn, dan wordt als een malle gezocht naar mogelijke overtredingen of andere manieren om een concurrent te naaien en er zelf beter van te worden.
Oracle had natuurlijk heel andere plannen. Die hadden een wereld vol apparaten waar een volledige Java client op draaide en waar per apparaat een fee voor afgedragen moest worden voor ogen. Oftewel een constante immer groeiende stroom van inkomsten.
Jammerlijk bleek Java daar uit veiligheidsoogpunt verre van ideaal voor en zijn slimme geesten alternatieven gaan bedenken. Er zijn steeds minder inkomsten uit Java en men wilde gewoon even lekker cashen.

[Xifar]

In de VS? Je bedoelt overal waar miljarden op het spel staan.

[90710]

Heel mooi dit! Als je Java technologieën gebruikt zonder Java opzich te gebruiken moet je daar gewoon voor betalen. Dat Google dit niet wil geeft al heel duidelijk aan wat voor bedrijf Google is...

[Cyb]

Gewoon Java OpenJDK gebruiken i.p.v. de propriëtaire Oracle JDK, en het probleem is opgelost.

[Arokh]

Vooral die laatste zin is heel treffend. $42.000.000.000. Veel geld aan omzet op advertenties in Android.

[Franckey]

Ik heb geen ervaring met Android, maar het is toch hopelijk niet zo dat je in Android zelf advertenties ziet? Waar komt die omzet dan vandaan?

[Arokh]

Ik heb geen idee, gebruik nog steeds Windows Phone :-). Maar ik verwacht dat die advertenties in de apps verstopt zitten

[TheGhostInc]

Oeps?

Overigens kan dit vergaande gevolgen hebben voor Java. Als Google stopt met Java ondersteuning is dat een flinke aderlating voor de taal.

[pk128934]

Dat valt best mee. Het wordt nog mega veel gebruikt in allerlei sectoren. Hele backends en middlewares van bedrijven zijn er van afhankelijk. Het duurt nog tientallen jaren eer dat daar echt verandering in komt. Misschien wel een beetje zoals het met bv Cobol gegaan is.

Het grootste gevaar voor Java is de ontwikkeling van de taal. Of juist het gebrek daaraan.

[Robtimus]

Dat laatste is juist nu weer in een stroomversnelling gekomen. Java 8 voegde streams en lambda's toe, Java 9 het module system en Java 10 (deze maand alweer uit) voegde o.a. het var keyword toe. We zullen nu ook elke 6 maanden een nieuwe release krijgen dus ook vaker nieuwe features.

Java EE zal zich overigens ook sneller gaan ontwikkelen zodra Eclipse er echt mee op gang komt.

[Frituurbaas]

Java 10 zal zeer snel door 11 worden opgevolgd. 10 is slechts een opvullertje, beetje zoals Windows 8.1. LTS voor Java 10 is er niet. http://www.oracle.com/technetwork/java/eol-135779.html

[Ossebol]

Vergeet ook niet dat de Java-ondersteuning met betrekking tot Docker aanzienlijk is verbeterd https://www.infoworld.com...ect-in-the-next-java.html

[Anoniem: 890159]

Android werkt nog steeds met versie 7, en 8 wordt min of meer ondersteund maar sommige features geven meteen deprecated warnings. Ik heb voor Android Studio nog steeds JDK 1.8 geinstalleerd staan, dus die ontwikkeling is voor mij niet zo relevant.

[Anoniem: 890159]

Het grootste gevaar voor Java is de ontwikkeling van de taal. Of juist het gebrek daaraan.

Talen zijn het meest gebaat bij stabiliteit. Ik doe wel eens embedded opdrachten en de C syntax is sinds Kernighan and Ritchie in 1988 hun standaardwerk publiceerden niet meer veranderd. Dat zorgt er voor dat je niet steeds bestaande programma's moet aanpassen aan de laatste mode.

[Upquark]

Als Google stopt met Java ondersteuning is dat een flinke aderlating voor de taal.

Welnee. Java is huuuge op serverside-gebied, en dat zal nog wel even zo blijven.

[LOTG]

De opvolger van Android is primair ook niet Java als ik het goed begrepen heb dus ik denk dat Google dat misschien flink in een stroomversnelling zet als ze dik mogen gaan betalen aan Oracle.

Maar goed, Java wordt op Enterprise niveau nog veel gebruikt dus dat valt opzich wel mee.

[Bastiaan V]

Wanneer je java vanuit beheer oogpunt niet kan handelen moet je op zoek naar nieuwe beheerders..
Wanneer je java vanuit performance oogpunt niet kan handelen moet je op zoek naar nieuwe programmeurs..

Natuurlijk zijn er gebieden waarin andere platformen het beter gaan doen. Maar gemiddeld genomen is java een prima (en nog steeds actueel) platform om server-side mee te werken.

[Wim-Bart]

Wanneer je java vanuit beheer oogpunt niet kan handelen moet je op zoek naar nieuwe beheerders..
Wanneer je java vanuit performance oogpunt niet kan handelen moet je op zoek naar nieuwe programmeurs..

Natuurlijk zijn er gebieden waarin andere platformen het beter gaan doen. Maar gemiddeld genomen is java een prima (en nog steeds actueel) platform om server-side mee te werken.

Beheertechnisch is Java een Drama. Je moet zo voorzichtig zijn met bijvoorbeeld een update, zelfs een .121 naar .125 release kan een applicatie kapot maken waardoor je zo veel extra werk hebt met beheer en patchen.

Een Visual C library kan je gewoon vervangen, een .NET release kan je meestal ook gewoon patchen, maar Java..... Er zijn applicaties heden ten dage die zelfs nog op Java 6 moeten draaien omdat het anders stuk loopt.

Nee, Java moeten we gewoon snel vanaf.

[TeunSegers]

Jammer genoeg weinig informatie over de motivering van de rechters. Het lijkt waarschijnlijk dat dit naar de Supreme Court gaat.

Bron: https://www.bloomberg.com...ollar-case-against-google

[Anoniem: 343906]

Kunt van de bedrijfsvoering van Oracle van alles vinden maar kan niet ontkennen dat Oracle wat dit betreft naar mijn idee wel degelijk een punt heeft.