Kenai.com en java.net sluiten 28 april 2017

Gebruikers van de communitywebsites kenai.com en java.net hebben een bericht ontvangen dat beide sites op 28 april 2017 zullen stoppen. Java.net verwees al enige tijd door naar Oracle's eigen Java-community-site.

De sluiting betekent voor gebruikers dat ze bestaande projecten die op de sites staan er voor de sluitingsdatum af moeten halen om deze te behouden. De inhoud van een project kan slechts één keer door een administrator opgevraagd worden. Oracle waarschuwt daarom in de instructies voor het verkrijgen van een tarball van een project om afspraken te maken met andere project-admins over wie de aanvraag doet. Oracle behandelt aanvragen op een 'wie het eerst komt, het eerst maalt'-principe. Voor het opvragen van een tarball of voor het doorsturen van verkeer naar het project naar een nieuwe locatie, heeft Oracle een formulier opgesteld.

Project Kenai werd in september 2008 in het leven geroepen door Sun Microsystems. In februari 2010 kondigde Oracle aan dat in verband met de samenvoeging van Sun en Oracle Kenai overgeheveld zou worden naar java.net waarbij de achterliggende infrastructuur van kenai.com naar java.net over zou gaan. De migratie zou toentertijd 'snel achter de rug' moeten zijn.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (60)

Misschien domme vraag, maar betekend dat het einde van Java zelf ook in zicht komt?

Domme vragen bestaan niet, maar het einde van Java zit er nog lang niet aan te komen hoor. Integendeel, Java is nog steeds een veelgebruikt platform, vooral voor serverside-applicaties.

Talen komen, en talen gaan....

Ik heb natuurlijk geen glazen bol, maar persoonlijk denk ik dat Java vrij snel gaat verdwijnen en "vervangen" gaat worden door javascript, of beter gezegd EcmaScript 6 (ES6). Het grote voordeek van ES6 is dat je als web programmeur dezelfde taal aan beide kanten kan gebruiken. Dus op de server side host je je web applicatie via Node.Js en op de client side gebruik je de javascript engine van de browser.

Een volgende stap zou zijn om typescript te gaan gebruiken, zodat je tijdens compile time de meeste fouten er al uit kan halen, en niet moet wachten totdat je in een bepaald stuk code komt waar er bv. een type mismatch plaats vind.

Zolang JavaScript een zeer vreemde manier heeft om met Objecten en types om te gaan zal het nooit - NOOIT - de enterprise taal worden. Een taal die met dynamische types werkt is vreselijk om te onderhouden en te testen. Uiteindelijk wil je simpelweg zo min mogelijk mogelijkheden hebben om iets correct uit te voeren; JavaScript werkt hier niet aan mee.

Misschien dat het een vlucht neemt voor web based applicaties. Zolang ik dan maar niet verantwoordelijk ben voor de werking ervan.

Ik denk precies het tegenovergestelde. Ik denk dat Java een van de weinige huidige talen is die over twintig jaar nog steeds gebruikt wordt. Een beetje zoals je vandaag nog COBOL tegen kan komen in enterprise systemen.

Ik zie de gemiddelde bank nog niet zo snel van Java overstappen op iets anders bijvoorbeeld.

Dat Java vrij snel gaat verdwijnen is echt bullshit. Java bezit echt wel heel wat meer kracht dan Node.JS...

Nee, denk van niet.

In tegenstelling tot Flash blijft Java nog een tijd rondzwerven denk ik.

Het is alleen maar de nr 1. meest gebruikte programmeertaal ter wereld ofzo:

Bron: http://www.tiobe.com/tiobe_index

Oracle had gewoon nooit die browserplugin moeten releasen. Java is nooit bedoeld om untrusted content veilig te draaien op een client PC. Het is jammer want nu heeft de taal een slechte reputatie er aan overgehouden.

[Reactie gewijzigd door Oerdond3r op 28 april 2016 12:50]

Het is alleen maar de nr 1. meest gebruikte programmeertaal ter wereld ofzo:

Bron: http://www.tiobe.com/tiobe_index

Taal met de meeste zoekresultaten. Dat zegt niet veel over het gebruik (behalve dat als er niets over te vinden is, de kans niet zo groot is dat er veel gebruikers zijn).

Dat Java de meest gebruikte programmeertaal is staat volgens mij niet echt ter discussie, voor bedrijven is het vaak de enige realistische keuze. De hele consultancy industrie is rond Java programmeurs opgebouwd bijvoorbeeld, als je 20 Java programmeurs nodig hebt dan is dat zo geregeld, maar probeer maar eens 20 C++ programmeurs te vinden... Wat dat betreft is het gewoon een soort van lowest common denominator voor cross-platform en server development, het doet wat het moet, is relatief snel, toegankelijk (vrij makkelijk om van helemaal geen kennis naar 'Java prutser' te gaan bedoel ik dan, om echt een goede Java programmeur te worden is net zo moeilijk als voor de meeste andere talen, maar helaas wordt dat kwaliteitsverschil maar zeer zelden gevraagd, herkend of gewaardeerd).

Dit alles zegt dan weer helemaal niks over hoe 'goed' de taal Java is, en hoe snel het uit de gratie zou kunnen raken. Nu C# en Xamarin officieel door Microsoft worden gepushed als cross-platform oplossing zie ik Java daar nog wel vervangen zien worden, C# is gewoon op elke objectieve metric een veel betere taal. Op de langere termijn ben ik wel benieuwd wat Swift gaat doen, nu het al zo vroeg in zijn bestaan volledig open-source is en dus ook een echte cross-platform taal kan worden waar bijvoorbeeld IBM ook veel in investeert voor op de server.

"C# is gewoon op elke objectieve metric een veel betere taal."

Kun je dit misschien toelichten? Ik lees het zo af en toe, andersom ook.

Ik ben zelf nooit een taal tegengekomen waarvan je zo "mooi"/subtiel in OO kunt programmeren als in Java. Daarnaast biedt Java gewoon alles wat je nodig hebt.

Helaas zie ik veel mensen Java onterecht downplayen. Over het algemeen is het gewoon onwetendheid.

Denk dat het een beetje een erg lange lijst zou worden als ik alle voordelen van C# (de taal, niet het platform) zou gaan vergelijken met Java.

Een simpele manier om hetzelfde punt te maken is dat C# zo ongeveer elke taal feature van Java implementeert, maar dan beter, plus een heleboel dingen die Java standaard niet heeft denk aan: async/await, properties, veel betere generics, een veel betere standard library, veel makkelijker te koppelen met andere talen (bijvoorbeeld F# als je delen van je programma functioneel wilt implementeren).

C# is gewoon een modernere taal die veel beter mee geevolueerd is met de tijd, minder 'design by comittee', minder star/dogmatisch object-georienteerd, enzovoorts.

Ik ben zelf nooit een taal tegengekomen waarvan je zo "mooi"/subtiel in OO kunt programmeren als in Java. Daarnaast biedt Java gewoon alles wat je nodig hebt.

Helaas zie ik veel mensen Java onterecht downplayen. Over het algemeen is het gewoon onwetendheid.

Niet bedoeld om jouw ervaring belachelijk te maken, maar ik kan niet anders zeggen dat je opmerking 'onwetendheid' enigzins ironisch is als je eerst zegt dat je nog nooit een taal bent tegengekomen waarin je zo 'mooi' OO kunt programmeren. Niks aan Java is namelijk mooi, het is OO tot in het extreme doorgevoerd, compromisloos, en daar is alles wel mee gezegd. Ik heb er al aardig wat regeltjes van mogen schrijven en inderdaad, het biedt het meeste wat je nodig hebt wel, maar het is echt een drama om te schrijven. Veel boilerplate, vreselijke standard library (ouderwets, onhandig, vol deprecated en/of inefficiente troep), geen enkele manier om je code anders te structureren dan met classes. De tijd waarin iedereen dacht dat elk programmeerprobleem het best met OO opgelost kon worden is alweer even voorbij, maar Java is gewoon niet met de tijd meegegaan.

Wat dat betreft denk ik dat de onwetenheid vooral bij Java programmeurs ligt, van alle talen waarin ik mezelf wel expert zou durven noemen (C, C++, Objective-C, Java, Python, Lua) is Java toch echt het minst elegant, subtiel of mooi.

Edit:
Zie dat er ook een mooie Wikipedia pagina is die de twee talen vergelijkt. Veel tabelletjes met language features, ik zou zeggen kijk waar de meeste groene vakjes staan en trek je conclusies ;-)

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

[Reactie gewijzigd door johnbetonschaar op 28 april 2016 16:31]

Dankjewel voor je reactie!

Een punt wat ik wilde maken, maar niet echt duidelijk naar voren komt, is dat onwetendheid eigenlijk altijd wel parten speelt in de discussie of taal/technologie x beter is dan taal/technologie y, uitzonderingen daargelaten.

Een simpele manier om hetzelfde punt te maken is dat C# zo ongeveer elke taal feature van Java implementeert, maar dan beter, plus een heleboel dingen die Java standaard niet heeft denk aan: async/await, properties, veel betere generics, een veel betere standard library, veel makkelijker te koppelen met andere talen (bijvoorbeeld F# als je delen van je programma functioneel wilt implementeren).

Ik kan mij bijvoorbeeld niet echt een goed beeld vormen waar Java haar wijze van generics-features in tekortschiet. Mede de async/await features en de veel betere standard library die C# zou bieden. Simpelweg omdat ik vind dat Java haar generics-feature de volle lading "gewoon" dekt.

Async/await features zijn beschikbaar binnen Java haar concurrency api's (iig vanaf Java 7+), Properties alsmede (bijv. voor het fatsoenlijk implementeren van (geo) locatie-onafhankelijke features), Java/JVM genoeg standaarden/protocollen (out of the box) implementeert om programmatuur te koppelen etc. Over functioneel programmeren wilde ik het eigenlijk niet hebben, maar ook daar heb je oplossingen zoals Clojure waarbij je gewoon JVM protocollen kunt gebruiken om over en weer te communiceren om een dergelijke doel te bewerkstelligen.

Ik kan nog wel heel lang doorgaan met discussieren, en ik vind wel dat je goede punten hebt, zoals deprecated troep in Java (ookal is dit een beetje een onfortuinlijke concessie welke nodig is ter behoud van backward-compatibility). Maar dan kom ik weer terug op mijn punt van onwetendheid wat deze zaken wel overkomelijk maakt om vervolgens op jouw punt te komen dat Java een hoge leercurve kent (had je niet zo geformuleerd maar ik interpreteer dat zo).

Anyways, ik geloof ook C# een uitstekende taal is maar Java hoeft er niet persee aan onder te doen, en dat wordt wel vaak beweerd en dat vind ik onterecht.

[Reactie gewijzigd door D.D.W. op 28 april 2016 16:55]

Hier kunnen we inderdaad lang over doorzagen, daar was ik eigenlijk al een beetje bang voor . Een dingetje over Java generics wil ik nog wel kwijt

Ik kan mij bijvoorbeeld niet echt een goed beeld vormen waar Java haar wijze van generics-features in tekortschiet

Het probleem met Java generics is dat ze later bovenop de taal geschroefd zijn, en per se volledig backwards compatible moesten zijn. Dit betekent dat ze leiden aan 'type erasure', wat simpel gezegd zoveel zegt als dat achter de schermen al jouw mooie List<T> instanties gewoon als List<Object> zijn opgeslagen, en al je type checking pleite is op runtime. Bij het compileren probeert de compiler nog wel zo goed en zo kwaad als het kan warnings/errors te geven als je de verkeerde types uit een collectie probeert te halen, maar vaak kan dit niet, en dan ga je op runtime gewoon kapot. Vooral als je met third-party libraries werkt die zelf geen generics gebruiken kun je de raarste bugs schrijven, omdat sommige objecten 'per ongeluk' dezelfde method implementeert als het type dat jij denkt dat er in de collectie zit (dingen als 'toString' of 'isEqual' bijvoorbeeld, die van Object meegekomen zijn). Been there, done that

Dat is al vervelend, maar net zo vervelend is dat de manier waarop Java generics implementeert geen enkele performance voordelen biedt zoals templates bij C++. Het is gewoon syntactic sugar die je code wat explicieter maakt, en hopelijk iets meer type safe omdat je minder van/naar Object hoeft te casten, maar daarbij een hele nieuwe klasse bugs introduceert die minstens even erg zijn.

Hier staat iets meer discuss, maar als je wat googled kun je genoeg informatie over de minpunten van Java generics vinden:

http://programmers.stacke...wrong-with-javas-generics

[Reactie gewijzigd door johnbetonschaar op 28 april 2016 18:43]

Hoewel ik het met je eens ben dat C# een enigszins betere enterprise language is dan Java* ben ik het niet eens met je redenering dat dat vooral voortkomt uit het afchecken van meer checkboxes. Dat is namelijk ook de aanpak die C++ en Scala nemen, en ik ben er allerminst door gecharmeerd omdat het getuigt van weinig visie aan het begin.
Indien aan het begin namelijk een set goed bij elkaar passende primitives wordt ontwikkeld kan je namelijk heel veel zonder er extra syntactic sugar voor nodig te hebben.
Voorbeeld: als je full lexical closures** tot je beschikking hebt neemt de behoefte aan o.a. classes flink af.

* Het concept van "de beste language" en dus ook "lang X is beter dan lang Y" is nogal achterhaald: Een lang als Go is geoptimaliseerd voor server side programming en is daar relatief goed in, misschien beter dan bijvoorbeeld Python. Maar zelfs als dit waar is, is Python een veel betere lang dan Go om GUIs mee te maken. Het is dus handiger om te zeggen "X is een betere lang dan Y voor taak T".
** Hiermee bedoel ik een fn die de lexical scope dusdanig tot z'n beschikking heeft dat read en write beide mogelijk zijn. Dit diskwalificeert Java bijvoorbeeld, omdat de closed over vars allemaal final moeten zijn. Het feit dat je daar omheen kan met de internal mutability van final vars doet daar niets aan af.

Hoewel ik het met je eens ben dat C# een enigszins betere enterprise language is dan Java* ben ik het niet eens met je redenering dat dat vooral voortkomt uit het afchecken van meer checkboxes.

Helemaal mee eens, eigenlijk had ik dat er zelf ook bij moeten zeggen. Los daarvan zijn er toch ook wel een heleboel van die checkboxes bij C# die toch wel rete handig zijn om te hebben ;-)

... ik ben er allerminst door gecharmeerd omdat het getuigt van weinig visie aan het begin

In principe ook mee eens, echter vind ik zelf dat dit wat Java betreft ook een deel van het probleem is. Java had namelijk wel een hele duidelijke visie: toegankelijker dan C++, puur-OO, write-once run-anywhere. Het probleem is echter dat OO eigenlijk voor heel veel programmeer problemen helemaal niet zo geschikt is, en je door de taal toegankelijker/laagdrempeler te maken een stijl van programmeren oplegt die onnodig verbose en omslachtig is, en lastig aan te passen voor de toekomst. Dat zie je nu terug in de latere Java versies: er worden wel wat zaken bovenop geplakt, maar het werkt gewoon nooit echt lekker vanwege keuzes die in het verleden gemaakt zijn. Denk aan type erasure bij generics, lambdas die deels mutable zijn omdat ze uit noodzaak als Object geimplementeerd moeten zijn etc..

Laat ik nog maar eens duidelijk zeggen dat dit alles echt niet betekent dat je met Java niet netjes kunt programmeren of wat dan ook, alleen dat het vergeleken met andere talen erg weinig echte pluspunten heeft behalve dat het zo populair is.

Hoe goed de taal is is maar 1 aspect. Het feit dat je je voor C# aan Microsoft overleverd is voor veel bedrijven een veel groter probleem. Mono is echt niet een alternatief. Dat betekend ook dat je alle rommel zoals Visual Studio en TFS er bij moet rekeken.

Java is vooral sterk in de infrastructuur en tooling rond de taal. Verder heeft het een sterk gedocumenteerde API. Dat maakt onderhoud met Java een stuk makkelijker dan met veel andere talen. De taal is dan ook altijd redelijk conservatief geweest, mede omdat de IDE's en tooling niet te complex mogen worden.

---

Dat laatste kan je van C# niet echt zeggen; er zijn heel veel dingen nogal plotsklaps toegevoegd. Sommige dingen kan het ook te veel. Ik ziet niet echt te wachten op een taal met ingebouwde SQL.

Verder kan je in C# gewoon te veel met inheritance, het feit dat je kan kiezen of je een method "virtual" wilt maken of niet zegt al genoeg. Een van de sterkere kanten van Java is juist dat je je als programmeur hier geen rekening met al die extra keuzes hoeft te houden. Dat is wat het makkelijk maakt om programma's te onderhouden.

C# is een mooie taal, duidelijk afgeleid van Java, wat nieuwer en minder conservatief. Maar wat mij betreft kan vooral de onderhoudbaarheid en infrastructuur rond de taal niet tippen aan Java.

het was sun die de browserplugin bouwde, en oracle die hem juist definitief de nek om draaide, dus als je wilt zeggen dat java een slechte naam heeft dan is dat voonamelijk omdat sun in veel opzichten geen visie had voor java...

bovendien zegt de sluiting van java.net helemaal niets, zelfs als oracle er morgen de stekker helemaal uittrekt dan heb je nog zaken als OpenJDK waaraan gewoon doorontwikkeld zal worden, java is immers een van de meest gebruikte programmeer talen op dit moment, zelfs als je android (wat feitelijk geen echte java is), buiten beschouwing laat is java HUGE!.

het was sun die de browserplugin bouwde, en oracle die hem juist definitief de nek om draaide, dus als je wilt zeggen dat java een slechte naam heeft dan is dat voonamelijk omdat sun in veel opzichten geen visie had voor java...

Volgens mij was het idee van Sun om een taal te introduceren die alle andere talen overbodig zou maken. Cross platform zodat het ook geschikt was voor mobile devices, browser integratie met sandbox model zodat je applets veilig kon draaien over internet en als server side/back end programmeertaal.

Uiteindelijk waren de resultaten nog al wisselend. Met name de browser plugin is uiteindelijk een grote flop geworden. Op mobile devices wordt zo ongeveer alles behalve Java gebruikt (als je Android niet meerekent) en cross platform applicaties blijven een niche markt en er zijn ook tal van alternatieven voor. Voor server side en backoffice development is het wel een succes, maar met name .Net heeft ook een aanzienlijk aandeel op dat gebied.

Als ik het samen moet vatten zou ik zeggen dat het zeker een succes genoemd mag worden, maar dat het lang niet alle beloften waar heeft weten maken.

Vanuit hun bedrijfsoptiek was het echter slim. Je biedt een alternatief aan en aan het eind van de dag moeten je concurrenten tegen 2 verschillende opties opboksen terwijl jij je een grotere hap van de taart toe-eigent. In principe dan.

In tegenstelling tot Flash wordt Java ook voor zo veel meer gebruikt dan alleen widgets en games op het web. Applicaties op servers, Android, embedded systemen (en dat zijn er nogal wat), noem maar op. Daar zie ik geen verandering in komen.

[Reactie gewijzigd door ThePendulum op 28 april 2016 12:48]

In tegenstelling tot Flash blijft Java nog een tijd rondzwerven denk ik.

Je doet net alsof Java vooral bestaat uit de browser plug-in waar veel mensen een hekel aan hebben.

Java is één van de meest gebruikte programmeertalen ter wereld en wordt vooral gebruikt op de server, waar jij als gewone Internetgebruiker niets van merkt. Het grote succes van Java is aan de serverkant, en niet in de webbrowser.

Oracle heeft een tijdje geleden al aangekondigd dat ze gaan stoppen met de browser plug-in. Maar dat betekent helemaal niet dat Java als programmeertaal en platform voor server-side applicaties zal verdwijnen. En dat is helemaal niet erg, want het is nog altijd een zeer levend en populair platform voor server-side applicaties.

En Android applicaties! (onder andere!)

Wellicht dat Android in de toekomst over zal gaan op een taal waarvoor ze geen miljarden hoeven te betalen (Swift?). Maar ook dat duurt nog even.

Ik dacht dat Google ging switching naar OpenJDK (voor Android)?

Naast Oracle Java heb je ook de open source variant (OpenJDK) dat onafhankelijk van Oracle door kan gaan. Maar Oracle zelf is zwaar afhankelijk van Java dus die zullen dat voorlopig nog niet opgeven. Dat ze die oude Sun domeinen opdoeken heeft meer te maken dat ze alles via Oracle zelf willen laten lopen dan via een aparte website.

Geloof mij maar, Flash zwerft ook nog wel een paar jaar door, zo niet langer.

Op het moment dat Google over gaat naar een andere programmeertaal voor Android gaat het wel een beetje de Cobol-fase in. Als je het niet erg vindt om 20 jaar aan de zelfde enterprise applicatie te werken heb je job security maar er worden nog maar bar weinig nieuwe dingen in geschreven.

Vraag me af waar je die indruk krijg. Ik werk bij een organisatie waar nu nog grote projecten worden gestart in Java, en bij veel van mijn oud studiegenoten die ook werkzaam zijn als software engineer is dit eigenlijk niet anders.

Het hele "write once, run everywhere" is gewoon in de praktijk niet echt uit gekomen. Applets zijn al dood. Op de desktop zijn het maar een paar applicaties die echt veel gebruikt worden die een Java core hebben. Het kan vaak in principe wel maar met de opkomst van de smartphones is dat verhaal in de praktijk eerder bij .Net terecht gekomen. Het is geen geheim dat Google langzaam aan het overstappen is naar een alternatieve taal aangezien Oracle het gebruik van Java gewoon te moeilijk maakt.

Dat houdt in dat én desktop Java nooit echt aangeslagen is én het straks op telefoons verdwenen is.

Wat blijft er dan over? Enterprise. Grote projecten inderdaad, die nog decennia onderhouden moeten worden. Maar zoals Oracle met Java om springt terwijl de concurrentie niet stil zit is er eigenlijk alleen nog maar een weg naar beneden mogelijk. Het is ook niet echt een moderne taal meer, het loopt al achter bij C# en C# is al een beetje opgerekt tot de grens van wat nog mogelijk is.

Kotlin, Swift en dat soort talen bieden veel meer compile-time safety en performance juist voor Enterprise applicaties. Je verdient gewoon geld door een modernere taal te gebruiken net zoals het maken van applicaties in Cobol ook niet meer interessant was na de introductie van Java.

Het hele "write once, run everywhere" is gewoon in de praktijk niet echt uit gekomen.

Excuseer? Ik kan nog steeds dezelfde applicatie maken voor MacOS, Windows en Linux? Hoewel de MIDlets en applets niet echt zijn doorgebroken draait heel Android op Java technologie. Het lijkt er sterk op dat Android nu over gaat op de OpenJDK (niet dat er veel keus was voor Google, maar goed). Smart watches, blue ray, smart cards...

Kotlin lost inderdaad veel problemen op die Java kent. Ik hoop dat Kotlin in de praktijk daadwerkelijk zo goed onderhoudbaar is als Java. Maar Kotlin draait op de Java infrastructuur. Verder trekt Java zelf ook richting Kotlin. Er wordt al gesproken over het introduceren van var voor locale variabelen.

Een veel groter probleem met Java is het gebruik van licenties. Oracle lijkt op dat gebied de teugels steeds iets strakker aan te trekken. Het wordt steeds meer een enkele speler zoals Microsoft.

Het word wel degelijk tijd voor een nieuwe open source taal met een up-todate API, ondersteund door een paar grote spelers. Eentje die zich richt op modulair programmeren, onderhoudbaarheid en veiligheid. Zolang zo'n taal er niet is zullen enterprises gewoon bij Java (of de .NET infrastructuur) blijven.

Je hebt keuze tussen de hele rambam van Oracle als je bij Java blijft of totaal iets anders en partijen die geen zin hebben om van Oracle afhankelijk te zijn stappen naar iets anders over, eventueel met behoud van de JVM.

Google gaat meer naar native code voor Android, Java is al jaren een probleem. iOS heeft dankzij native code en talen die geen Garbage Collection hebben al jaren de bovenhand in belangrijke statistieken als batterijverbruik en FPS bij het scrollen van een tabel met gegevens.

Java voor Android is gewoon een vergissing geweest op meerdere vlakken, zowel technisch als juridisch. Als Google vol inzet op een alternatief dan valt ineens een enorm deel van de Java-markt weg.

Nee, maar Oracle is zichzelf gigantisch in de voet aan het schieten. Android gebruikt Java? Aanklagen. Microsoft is ook heel aggressief tegen Java aan het verzetten, zo hebben ze een project dat Java op iOS mogelijk maakte overgekocht en gesloten. Dus Java op mobile is straks wel dood.

Zo lang Google geen alternatieve programmeertaal officieel gaat ondersteunen is er niet eens zicht op het uitfaseren van Java de taal, compiler, of de Java std lib APIs.
De rest van de Java stack is idd niet-bestaand op mobile, en dat zal waarschijnlijk niet veranderen.

Er was laatst nog in het nieuws dat ze Swift als vervanger overwegen. Dit zal allemaal wel even duren, maar Java zal niet altijd de standaardtaal van Android blijven.

Ik hoop oprecht van niet. Het zou namelijk betekenen dat Google erkent dat zowel Dart als Go ongeschikt zijn voor GUI-rich apps (en in elk geval voor Go klopt dat ook wel gegeven de focus op server-based programming). Daarnaast weet ik niet of ik Swift wel zo'n competente taal vind. Dat is natuurlijk subjectief, maar ik heb er wel objectieve argumenten voor:

Ik heb eerlijk gezegd liever dat Google eens behoorlijk naar Mozilla Rust gaat kijken, daar zit veel meer formele Programming Language Theory achter, bijvoorbeeld hoe Rusts borrow checker werkt.

Op de langere termijn verwacht ik eerlijk gezegd ook veel meer van Rust dan van Swift, wat mij eigenlijk een beetje aanvoelt als een niet-zo-heel coherent allegaartje van language features, om geen enkele andere reden in de taal gezet dan dat ze convenient leken op dat moment.

Het gevolg? Een zogeheten "stable" language die van 1 stable versie op de volgende plots een enorme hoeveelheid al-geschreven code kan deprecaten*. Wat dat betreft voelt het aan als Rust voordat dat stabiliseerde met 1.0.

Daarnaast schijnt de compiler nogal buggy te zijn**, en een goed 3e argument is dat je geen reference counting of garbage collection wil om je memory te managen wanneer je ook zonder kan***.

* Dit is ook meerdere keren al gebeurd, en real-world app developers die al vroeg hadden ingezet op Swift voor productiecode hebben ook vaker aangegeven simpelweg op een oude Swift versie te blijven voor een tijd omdat de changes niet zijn bij te benen wanneer je ook nog features wil developen. Het probleem hier is dat Swift te vroeg stable is verklaard, en niet zozeer dat de taal verandert. Het gaat om het signaal naar developers toe.
** zelf geen last van gehad overigens
*** Rust kan dit wel dmv het ownership model, hetgeen een groot pluspunt is voor Rust op zo'n beetje elke andere programmeertaal. C++ komt nog het dichtste bij in de zin dat je daarmee ook aan ownership-based memory management kan doen, maar Rust heeft als voordeel tov C++ dat de compiler dat afdwingt: Weg is de memory unsafety, zonder runtime kludges zoals Garbage Collection of Reference Counting. Toegegeven, er zijn use cases voor RefCounting, ook in een language als Rust, bijvoorbeeld voor een graph waar meerdere edges naar dezelfde node wijzen. Maar die use cases zijn redelijk beperkt en je komt het RC<T> type (Rust's manier om RefCounting aan te bieden) ook niet zo vaak voor in real-world code.

[Reactie gewijzigd door Jeanpaul145 op 28 april 2016 14:50]

Ik denk dat het ze eerder gaat om compatibiliteit met iOS. Bugs kunnen natuurlijk gefixt worden maar ik ben het wel met je eens over garbage collection / arc. Rust moet ik toch echt weer eens naar kijken.

Compatibiliteit met iOS is zo moeilijk nog niet:
Als je zorgt dat je eigen native libraries een C API hebben (in Rust, ObjC en C++ is dat sowieso mogelijk dus waarom zou t niet in Swift kunnen) en gewoon dezelfde ABI target als t platform zelf, dan kan je over het algemeen die API callen vanuit elke andere native taal

Ja, maar dat heeft Android niet. Die hebben alle standaard libraries in Java geschreven...

... die (deels) accessible zijn in native code d.m.v. de Android NDK.
En sowieso kan je native code callen vanuit Java code in Android, dus er is niet echt een probleem

Dus eigenlijk isver geen probleem?

Moh, Xamarin is gratis, PhoneGap en Cordova geloof ik ook? Het uitfaseren van die technologie erachter is misschien niet in zicht, maar ik leer liever Xamarin dan Android-Java vanwege de cross-platform functies.

Over Xamarin kan ik geen harde uitspraken doen, maar elke web-based library die zichzelf adverteert als een cross-platform oplossing voor app development slaat echt serieus de plank mis:

• De look & feel zal nooit 100% hetzelfde zijn als native, en afhankelijk van de app merkt de user dit direct en persistent
• Als je JS code gaat uitvoeren zit je gelijk weer vast aan zo'n nare kluge van een garbage collector, en over het algemeen geldt voor GC talen dat je 4-6x de hoeveelheid RAM moet hebben voor een app als dezelfde app in een language met manual memory management. Dit is de hoofdreden dat Facebook destijds de HTML versie van hun Android en iOS apps heeft vervangen door native code
• Cross-platform solutions in t algemeen* hebben nooit 100% coverage mbt features van het native platform. Dit komt omdat het extreem lastig is de corner cases weg te krijgen, en leidt naar dingen als leaky abstractions in de cross-platform code

* Dit geldt dus ook voor Xamarin

RoboVM?

"Gelukkig" is er nog Intel's MOSE. Dit is wel closed source dus als ze de stekker er uit trekken zit je alsnog met een probleem. RoboVM was welliswaar OSS maar 3 maanden geleden heel snel closed source gemaakt en vervolgens heeft MS via Xamarin de stekker eruit getrokken.

How corporate politics destroy useful software

Jammergenoeg niet nee. Dit is slechts een dienst waar sourcecode gehost kon worden, denk aan sourceforge en github.

"Jammer genoeg niet" en dan +2 gemod worden?
Java is en blijft nog wel even bestaan; er wordt ontzettend veel mee ontwikkeld.
Ik denk dat je, net als velen, in de war bent met de 'Java browser addon' vs 'Java als platform onafhankelijke ontwikkeltaal'.

Ontopic:
jammer dat de community sites moeten sluiten.
Gemiste kans wel voor Oracle om er een MSDN-achtige community van te maken met voorbeelden en vraagbaak.

[Reactie gewijzigd door CyBeRSPiN op 28 april 2016 12:48]

Daar kennen de meeste het van, en dat is inderdaad niet zo'n heel prettige ervaring. Recent ben ik ook bezig gegaan met server-side ontwikkeling in java (en, vooruit, javascript) en daar draait het prima. Zolang je gebruikmaakt van de taal en libraries zonder daarbij direct de UI componenten te (willen) gebruiken, is het prima

om van java.net een MSDN clone te maken, pfew dan ben je nog wel even bezig, ik denk dat het aanbieden van sourcecode hosting ook geen meerwaarde bied voor ontwikkelaars-communities, het is natuurlijk leuk, maar vanuit commecieel oogpunt nauwelijks interessant met github en dergelijken als 'concurent'

toch is het wel vervelend om te zien dat er weer een projecthosting platform onderuit gaat; na sourceforge (ok deze is dan wel niet dood, maar dat komt nog wel, na al die schandalen, en nulled development aan het platform), en het stoppen van google code (of hoe googles codehosting platform ook mocht heten), nu dus ook java.net, dan bleven er zo langzamerhand nog maar erg weinig over.

ik ben er zelf niet zo rouwig om, de sites zijn simpelweg ingehaald door bijvoorbeeld een Github. De belangrijkste projecten die op java.net / kenai stonden zijn nu al daar terug te vinden.

Ik snap de link met MSDN verder niet echt, dat staat compleet los van het doel van deze sites. Ik zie Oracle ook niet snel zoiets van de grond krijgen, het Java platform wordt teveel gedreven door third parties waar ze geen controle over hebben.

Wat is er mis met Java? Welke taal gebruik jij?

Java heeft bij toch nog steeds de stempel erg traag, maar ik heb de indruk dat de meeste (java)developers daar helemaal niet wakker van liggen.
In dat opzicht was het vroeger veel en veel beter (assembler, C), snel compact en beter betaald

Java 1.0 was inderdaad erg traag maar het is nu veel sneller geworden.
Zie ook https://en.wikipedia.org/wiki/Java_performance

Het idee dat Java traag is, is al minstens tien jaar achterhaald. Maar mensen die er niet echt verstand van hebben blijven toch maar hardnekkig denken dat het traag is.

De Java Virtual Machine bevat heel veel geavanceerde optimalisaties. Java bytecode wordt on-the-fly naar geoptimaliseerde machinecode vertaald door de JIT (just-in-time) compiler. De code kan dan, in tegenstelling tot wat een ahead-of-time compiler zoals een traditionele C / C++ compiler, geoptimaliseerd worden voor precies de CPU die in de machine zit waar de code op draait. Als jij een bepaalde Core i7 hebt met een bepaalde instructieset, dan krijg je dus optimale code - in tegenstelling tot wanneer jij van tevoren gecompileerde code hebt, die voor een grootste gemene deler (bijv. de Intel Pentium) is gecompileerd.

Er zitten nog veel meer speciale optimalisaties in de JVM, bijvoorbeeld profile-based optimalisaties: de JVM houdt in de gaten wat de performance van het draaiende programma is en kan dingen aan de hand van die profile-data nog verder optimaliseren.

Het is allang niet meer de JVM van 2005...

Google dacht er in 2011 toch net zo over als ik.

Volgens die studie is C++ heer en meester als het op snelheid aankomt. Zelfs een factor 10 en meer, dat is nogal wat.

C++ kan je net zo goed optimaliseren, en een beetje inhouse developer kent zijn omgeving en optimaliseert bijgevolg voor het juiste platform.

http://m.theregister.co.u..._cplusplus_java_scala_go/

Eigenlijk maak je precies mijn punt door te stellen dat de java virtual machine wel de juiste optimalisaties zal doorvoeren in functie van de hardware.
Die kennis hoort te zitten bij de developer niet in de virtual machine.

[Reactie gewijzigd door klakkie.57th op 28 april 2016 23:24]

Jammergenoeg? Server-side draait er heel veel in Java en dat werkt daar vaak gewoon prima.

Java heeft vooral een slechte naam gekregen vanwege de Desktop applicaties zoals LimeWire en content in browsers.

Maar server-side is Java een prima taal die veel tooling kent waarmee je er stabiele en ook snelle code mee kan ontwikkelen.

Wat is dan het verschil tussen java.com en java.net?

Op java.com kan je Java downloaden (en wat informatie vinden over Java). Java.net is voor de Java community.

was te verwachten, oracle wil met java een andere kant op dan sun. en met hun eigen community.

trouwens behalve voor server-side (en een deel client side) toepassingen is java nog voor een andere medium de belangrijkste programmeertaal: Blu-Ray schijfjes. Of te wel films en tv series op Blu-Ray. deze hebben allemaal een java-virtual machine aan boord die een deel van de drm mogelijk maakt, een goede blu-ray speler moet dus, om aan de officiële standaard te voldoen deze vm kunnen uit voeren om een deel van de decryptie keys te verkrijgen. daarnaast wordt java tevens gebruikt om alle interactieve menu's, special features e.d. mogelijk te maken, waaronder dus BD-Live en BonusView extra's.

Dus tsja, ik zie ook voor java nog een lange toekomst, idem voor flash/silverlight, zolang bepaalde content aanbieders weigeren om op html5 over te stappen (npo, rtl, sbs, kijk, nlziet etc)

klopt, maar er zijn nog heel veel bedrijven die hun toepassingen/systemen in silverlight hebben draaien, en dan bedoel ik niet alleen aanbieders van (streaming) video content, zoals voorheen Netflix die gelukkig als een van de eerste grote spelers op html5 is over gegaan. maar neem SAAS en PAAS (software as a service/platform as a service) aanbieders, veel van die systemen draaien in de browser mits de silverlight plugin geïnstalleerd is en dan voornamelijk alleen op Microsoft Windows. Ik zelf heb recent wat server-side programmeer werk gedaan voor een financiële dienstverlener op het gebied van budget beheer en bewindvoering, en hun systeem werkt met (of is althans gekoppeld aan) de software en systemen van Conclusion een ICT dienstverlener, en de specifieke software die deze bewindvoerder afneemt van het bedrijf Conclusion heet EOS welke op de servers van de Conclusion, danwel de bewindvoering draait, én alleen op windows, in Internet Explorer mét Silverlight.

Tja, ik heb ook ooit eens een Java development omgeving gezien die draaide op Internet Explorer. Op zich wel mooi natuurlijk dat je gewoon alle instellingen op een centrale server kan doen. Maar je vasthouden aan - toendertijd - OLE koppelingen die alleen onder Internet Explorer draai(d)en, dat was toen ook al een gok. Nooit meer wat van gehoord natuurlijk. Het was sowieso al een vreemde combinatie.

En dan komen we automatisch op J# - leuk overstappen van Java naar .NET - zolang het duurt.