Java-grondlegger James Gosling verlaat Oracle

Software-ontwikkelaar James Gosling, vooral bekend als een van de grondleggers van de programmeertaal Java, heeft op zijn weblog laten weten dat hij Oracle heeft verlaten. De precieze reden voor zijn vertrek per 2 april wil Gosling niet noemen.

Gosling schrijft op zijn weblog dat hij sinds 2 april niet meer in dienst is bij Oracle en dat hij na een periode van rust op zoek gaat naar een nieuwe uitdaging. Hij wil niet precies kwijt waarom hij zijn baan heeft opgegeven: "Waarom ik ben vertrokken is moeilijk te zeggen. Alles wat ik gemeend en oprecht zou kunnen zeggen, zou meer kwaad dan goed doen", zo schrijft hij. Vorige maand uitte hij echter kritiek op het Java Community Process, een programma waarbinnen partijen verbeteringen of uitbreidingen van het Java-platform kunnen aandragen. Volgens Gosling zou het samenwerkingsverband last hebben van toenemende politisering.

De 53-jarige James Gosling was jarenlang in dienst bij Sun Microsystems, het bedrijf dat vorig jaar werd overgenomen door Oracle. Begin jaren negentig stond hij aan het hoofd van een ontwikkelteam dat begon te werken aan een nieuwe, op objecten georiënteerde en platformonafhankelijke programmeertaal. Tijdens de ontwikkeling werd de taal tot Oak gedoopt, maar uiteindelijk werd gekozen voor Java. Gosling richtte zich onder andere op de syntaxis van de taal en ontwikkelde de compiler en virtual machine waarbinnen Java-code draait. Door de opkomst van internet en de Java-compatibiliteit van Netscape Navigator groeide het gebruik van Java. Inmiddels wordt het Java-platform op talloze apparaten toegepast, van servertoepassingen tot mobiele telefoons.

Het ontslag van Gosling bij Oracle volgt kort op het vertrek van voormalig Sun-ceo Jonathan Schwartz. Daarnaast hebben ook 'xml-guru' Tim Bray en Zack Urlocker, nauw betrokken bij MySQL, Oracle vaarwel gezegd. Verder gaan er al maandenlang geruchten dat nog meer hooggeplaatste ex-Sun-medewerkers ontevreden zouden zijn over de koers die Oracle heeft gekozen.

Reacties (65)

[Enfer]

Spijtig voor Oracle. Het lijkt me niet dat je iemand met zoveel kennis en dergelijke zomaar kwijt wilt. Hij heeft namelijk teveel kennis van Java waardoor hij zelf ook iets zou kunnen opzetten, mits z'n contract dat toelaat . Aan z'n reden te zien zal er wel mot geweest zijn, anders lijkt het me niet dat je zo opeens vertrekt..

[Reactie gewijzigd door Enfer op 26 juli 2024 17:17]

[beany]

Ik denk dat Java iets te groot is momenteel om even zelf iets nieuws op poten te zetten. Microsoft heeft gedaan, met .Net. Maar mist de platformonafhankelijkheid zoals dat bij Java is.

[OpenMinded]

Microsoft heet .NET nooit opgezet om platform onafhankelijk te zijn, maar om Java kapot proberen te maken.
Dat is ze niet gelukt.

[BlackHawkDesign]

Waarom wordt .net code dan omgezet in een soort bytcode en vervolgens net zoals bij java door soort van jre geinterpreteerd te worden? Voor andere besturingssystemen is die 'jre' nooit gekomen

[84hannes]

Het is maar een visie, maar:

Waarom wordt .net code dan omgezet in een soort bytcode en vervolgens net zoals bij java door soort van jre geinterpreteerd te worden?

Om platform onafhankelijk te kunnen zijn. Alle programma's die in C/C++ e.d. geschreven zijn, zijn platform- en processorafhankelijk.

Het gaat nog jaren duren. Maar stel dat op een goede dag programma's als Office en Internet Explorer volledig in .Net draaien. Dan kan Microsoft Intels x86 vaarwel zeggen, vanaf de grond een nieuw (object georienteerd, managed) besturingssysteem opbouwen en daar een .Net implementatie voor uit brengen. Vervolgens kunnen alle programma's die op het .net framework draaien ook op dit nieuwe besturingssysteem draaien.

De afgelopen jaren heeft Apple een paar keer een stap genomen die Microsoft nooit heeft aangedurft. Backwards compatibility emuleren en vervolgens laten vallen. Morola->Ibm->Intel, Macintosh->Mac OS X. Deze keuzes zijn, in mijn ogen, verstandig geweest, en ik denk dat Microsoft deze mogelijkheid ook wil hebben. Een smartbook op ARM, een netbook met Intel en een server met een PowerCore die allemaal dezelfde programma's kunnen draaien met een kleine overhead? Lijkt mij fantastische toekomstmuziek.

@ncoesel

Met WP7 laat Microsoft misschien een tipje van de door mij geschetste sluier oplichten, maar de geruchten gingen dat de opvolger van Windows Vista ook radicaal met het verleden zou breken.. Helaas liep Vista zo slecht dat Microsoft eerst even een opgepoetste Vista moest uitbrengen.

@roy-t
C en C++ zelf zijn inderdaad niet platformafhaneklijk. Echter de hele omgeving waarbinnen je met C en C++ werkt zijn dat wel. Denk aan API calls, GUI's, heet gebruik van assembly binnen C/C++ code etc. Niet de taal C# (Java) maar de omgeving .net (Java) zorgen voor platform onafhankelijkheid.

[Reactie gewijzigd door 84hannes op 26 juli 2024 17:17]

[roy-t]

C en C++ zijn juist niet platform onafhankelijk, je kunt niet zomaar iets van Linux naar Windows porten als het geschreven is in C++, je kunt het wel hercompilen en alle code die omgaat met het besturingssysteem herschrijven.

.Net is trouwens wel multi-platform. Het draait op Power-PC (xbox360) ARM (Mobieltjes en embedded systemen) en X86(+64) Intel/ADM.

Dat is het voordeel van een soort van zelfde aanpak als java.


Java is trouwens niet de eerste taal die dit doet. Objective-C van Apple deed dit al voordat Java het deed, en er zijn vast nog wel andere talen te vinden die dit doen. (Obj-C's implementatie is wel erg anders waardoor het meer in de buurt komt van C/C++, maar er is wel een soort van bytecode en een soort van runtime).

[.oisyn]

C en C++ zijn juist niet platform onafhankelijk, je kunt niet zomaar iets van Linux naar Windows porten als het geschreven is in C++, je kunt het wel hercompilen en alle code die omgaat met het besturingssysteem herschrijven.

En dús zijn de talen C en C++ platform onafhankelijk. Als je praat tegen een cross platform API dan is je code volledig portable, en de broncode dus niet platform afhankelijk. Het enige verschil tussen C++ en iets als C# is dat die laatste eerst naar een intermediate representation wordt omgezet. Zou je een JITer maken die gewoon C++ snapt dan kun je een (ongecompileerde) C++ applicatie ook op elk platform runnen. Verder kun je in Java en in C# net zoveel platformafhankelijks doen als met C++.

[Helmore]

C# hoeft niet naar een 'intermediate representation' omgezet te worden, C# zou in principe ook direct naar machine code kunnen worden gecompileerd. Er staat niks in de specificaties van C# over dat het naar de .NET bytecode gecompileerd moet worden. De reden dat zoiets niet gedaan wordt is omdat niemand daar nog een compiler voor heeft geschreven. Wat jij dus zegt voor C++ geldt dus ook voor C#, maar dan andersom.

[Verwijderd]

C en C++ zijn talen en dat heeft niets met een platform te maken.

C en C++ gebruiken wel API's die platform afhankelijk zijn, denk maar aan het openenen en sluiten van files, of sockets, of video en muziek achtigs. Gelukkig hebben we zo ongeveer 2 'mainstream' systemen, POSIX en Windows (Windows NT4 zou vroeger posix compliant zijn, nu niet meer).

Dat wil zeggen als je een C of C++ programma maakt op je Linux bak, dan draait dat nog niet zomaar op je windows machine. Als je alleen API's gebruikt die op bijde platformen bestaan, dan zou het mischien wel kunnen werken, maar grote kans van niet.

Daarom zie je dat veel open source programma het bekenede 'make' en 'configure' hebben zodat deze voor jouw kan uitzoeken watvoor platform het is en bepaalde macro's voor je kan activeren zodat je een hoop zaken niet in je eigen code hoeft uit te zoeken... Soms moet je dat nog steeds doen....

Omdat c en c++ vrijwel direct met het OS praat kunnen we deze dus niet platform onfahankelijk noemen en we kunnen omdiezelfde reden ook niet gemakkelijk een c of ++ interpeter schrijven, deze zou hopeloos traag worden.

Praten tegen een cross-platform API heeft geen zin om diezelfde reden. omdat diezelfde API ook weer macros bevat voor veschillende platformen en dus wordt de boel erg traag tijdens compileren.

[silentsnake]

Lijkt mij ook niet zo raar dat Microsoft hun backwards compatibility niet wil laten vallen. Ze hebben 90-95% van de markt in handen, in tegenstelling tot die paar procent die Apple heeft. Ze hebben nu al problemen om bedrijven over te laten stappen naar Vista of Windows 7, laat staan als het OS geen bestaande apps kan draaien. Dat is zo ongeveer de grofste fout die je kan maken. Als MS in de loop der jaren de desktop in het bedrijfsleven verliest (wat niet ontdenkbaar is met een OS zoals deze) dan zullen ze hun monopolie verliezen. Leuk voor de aandelen ...

Maar on-topic, ik denk dat dit het begin van het einde is voor Sun zoals we het kennen. Het is ook dan maar de grote vraag wat er met dingen als OpenSolaris, OpenOffice, VirtualBox, MySQL en dat soort dingen gaat gebeuren. De tijd zal het leren.

[Ford Prefect]

Maar on-topic, ik denk dat dit het begin van het einde is voor Sun zoals we het kennen. Het is ook dan maar de grote vraag wat er met dingen als OpenSolaris, OpenOffice, VirtualBox, MySQL en dat soort dingen gaat gebeuren. De tijd zal het leren.

Wat bedoel je met dat je je afvraagt wat er met dingen zoals OpenSolaris, OpenOffice, VirtualBox, MySQL gaat gebeuren? Oracle heeft een aardig bedrag betaald voor Sun, ze zullen zeker iets gaan doen met deze producten. Java was natuurlijk 1 van de grote redenen voor Oracle om Sun in te lijfen maar het dunkt me dat ze toch wel meer laten leven dan alleen Java. Kijk alleen maar naar hoe zwaar Oracle nu inzet op Exadata V2.

[Verwijderd]

Je bedoelt Windows Mobile 7?

[johnbetonschaar]

Om platform onafhankelijk te kunnen zijn. Alle programma's die in C/C++ e.d. geschreven zijn, zijn platform- en processorafhankelijk.

Dat is slechts 1 voordeel en waarschijnlijk zeker niet de belangrijkste reden, ik zie Microsoft namelijk niet snel van x86 afstappen, en bovendien is daar niet per se een geinterpreteerde bytecode taal voor nodig. Dat Microsoft heel Windows, Office en alle andere spullen die ze maken langzaam maar zeker allemaal naar managed code gaat omschrijven zie ik ook niet gebeuren, gecompileerde talen hebben nog steeds veel voordelen voor bepaalde toepassingen en dat zal zo blijven. Toen Java er net was, volgens mij al zo'n 15 jaar geleden, dacht ook iedereen dat het gedaan was met native code, en dat is eigenlijk ook nooit echt van de grond gekomen.

Het grote voordeel van zoiets als C# of andere bytecode talen is dat je managed code schrijft, het is dus veel makkelijker om processen te sandboxen, om automatisch geheugenbeheer te implementeren, en om de functionaliteit van bestaande code te verbeteren of uit te breiden zonder te hoeven recompilen. Met andere woorden: flexibeler, veiliger en makkelijker te schrijven. Nadelen zijn er natuurlijk ook, en die zijn vooral van toepassing voor code die close to the metal moet draaien voor optimale performance.

De afgelopen jaren heeft Apple een paar keer een stap genomen die Microsoft nooit heeft aangedurft. Backwards compatibility emuleren en vervolgens laten vallen. Morola->Ibm->Intel, Macintosh->Mac OS X. Deze keuzes zijn, in mijn ogen, verstandig geweest, en ik denk dat Microsoft deze mogelijkheid ook wil hebben.

Apple heeft dat inderdaad heel knap voor elkaar gekregen en ik denk dat Microsoft daar best een beetje jaloers op is. Maar Apple heeft het ook wel iets makkelijker omdat ze zelf de hardware maken en alle installaties dus veel meer op elkaar lijken, wat het makkelijker maakt om de backwards compatibility laag goed te laten werken voor iedereen. Maar nog steeds een hele knappe prestatie. Alleen weerspreekt dit een beetje je verhaal over bytecode talen, omdat OS 9 en OS X programma's nog altijd vrijwel exclusief in gecompileerde talen worden geschreven (C, C++, Objective C). Java wordt echt amper gebruikt en .Net talen al helemaal niet.

[rob12424]

Uhm Apple heeft nog iets anders gedaan namelijk mac osx in Perl geprogrameerd waardoor het cross platform is en aan de unix standaard voldoet en ook Linux daardoor ondersteunt.

Perl werkt overigens op Linux en Unix en deels op Windows

[the_shadow]

Dat omdat talen die met een intermediate language werken andere voordelen hebben dan platform onafhankelijkheid. Denk aan eenvoudige garbage collection. Het is ook zo dat met het .NET framework, Microsoft de keuze aan de developer laat in welke taal ze schrijven. C#, VB .NET etc., het wordt allemaal naar de .NET bytecode gecompileerd, en het draait allemaal op de zelfde VM. Als er aanpassingen worden gedaan in die VM, dan betekent dat een optimalisatieslag voor meerdere talen, ipv slechts 1.

[Parlor_Inventor]

Microsoft wil niet dat alle applicaties afhankelijk zijn van alle quirks in het onderliggende Windows-systeem, omdat het OS dan na verloop van tijd steeds moeilijker aan te passen is.

Door applicaties dmv bytecode en vaste interfaces van het onderliggende OS te scheiden zijn ze veel vrijer om delen van het onderliggende OS te herschrijven en te herstructureren zonder dat een hele rits programma's het ineens niet meer doet.

Daarnaast maakt het een migratie naar een ander hardware-platform ook veel eenvoudiger, wat eigenlijk al het geval is met Windows Mobile. Write once, run MS-Anywhere.

[Alex]

Grappig dat je dat zegt. Microsoft had namelijk de strategie gekozen om Java en C++ volledig te adopteren. Toen heeft Microsoft een prachtige IDE uitgebracht welke vervolgens door Sun vakkundig de nek om is gedraaid. Dit door o.a. de licentie van Java op het scherpst van de schrede te gaan voeren.
Microsoft heeft toen besloten nooit meer van iemand afhankelijk te willen zijn voor ontwikkeling van eigen tools, maar tevens ook hun klanten een toekomst veilig platform te geven. Daarom is .NET ontwikkeld.

Daarnaast is het zo dat Java heel lang enkel een taal is geweest op een gesloten platform, maar dit is verandert sinds the general purpose introductie van Scala. Gelukkig hebben ze bij Sun in gezien dat Developer Productivity boven Language Addiction gaat .
.NET is vanaf dag een echt gepositioneerd als een platform met daarin allerlei talen. Het .NET platform is vrij vroeg al gepubliceerd en zo zijn talen als C# en VB ook gestandardizeerd.
Hierin zie je overigens dat Microsoft misschien wel beter in zag wat voor goud Sun in handen had met het Java platform.

Ieder kiest hierin haar eigen weg. Sun heeft in der tijd een hoop Java Library code voor lange tijd achter gehouden. Microsoft kiest voor haar eigen MS-PL-licentie bij het publiceren van source code. Goed of fout... Tsja... In elk geval door elkaar geinspireerd.

In mijn ogen(als Software Architect) zijn het beide volwassen platformen, waarbij .NET zeer sterk is in Line of Business Applications(Processen, Tooling, RIA's, Smart Clients, etc) en Java nog steeds haar sterke plaats heeft op het gebied van Enterprise Security & Transactions(vaak refererend aan Bank en Verzekering applicaties).

Ontopic: Jammer, weer een belangrijke jongen weg daar. Het zou mij niets verbazen als hij terecht komt in het Microsoft Research(MSR) programma. Daar wordt per jaar 1 Miljard geinvesteerd in Researchers die volledig vrij met hun taak bezig mogen zijn maar wel onder de naam van MS. Een hoop voormalig collega's van James Gosling zijn hem voor gegaan. Laten we hopen(zelf ik als MS-groepie ) dat hij een keuze maakt voor een andere partij, dan kan er misschien weer eens wat pionierswerk gebeuren .

[Janoz]

Goed verhaal, alleen dit stukje is nogal een 1-sided view van het geheel:

Grappig dat je dat zegt. Microsoft had namelijk de strategie gekozen om Java en C++ volledig te adopteren. Toen heeft Microsoft een prachtige IDE uitgebracht welke vervolgens door Sun vakkundig de nek om is gedraaid.

MS had aan hun eigen Java implementaties enkele toevoegingen gedaan waardoor Java applicaties die in Visual Studio gemaakt werden eigenlijk alleen maar werkten met de specifieke microsoft virtual machine. Aangezien dat het hele concept van Java onderuit haalde is het natuurlijk niet vreemd dat Sun daar hard tegen optreed.

IMHO is het een beetje naïef om te denken dat MS Java wilde adopteren. Assimileren is misschien het betere woord.

[garagaholic]

Als het zo mooi was als geschetst, dan had sun ook verstandig kunnen zijn en de wijzingen kunnen adopteren in plaats van aborteren..

[OddesE]

Die waren niet te adopteren, want afhankelijk van Windows features.

MS had gewoon gedaan wat ze altijd doen: Je neemt iets platform afhankelijks, zoals Java of het Web, en daar voeg je dan de 'mogelijkheid' aan toe om Windows-only calls te maken. Daar was Sun niet zo blij mee, want als ze dat hadden laten gaan dan was Java nu gesplitst in allerlei subsystemen die niet langer met elkaar compatible waren.

[OMX2000]

Nee niet naief. Ik denk dat het de strategie was om te zorgen dat hun platform (Windows) het beste platform is waar Java op draait. Zoals ze dat nu nog steeds doen met php. Dat is wat MS doet, zoveel mogelijk Windows en Office verkopen.

Maar zoals Alex al zei, ze zijn van de strategie afgestapt, aangezien ze niet afhankelijk willen zijn van een andere partij qua applicatie platform.

[Mr_Light]

het beste platform is waar Java op draait.

Je snapt dat, in het licht van dat de microsoft implementatie RETE TRAAG was, ik niet met je mee kan gaan in je verhaal. En nee sun had wel een snelle jvm implementatie echter werd die niet meegeleverd bij windows. Het hele idee dat java mischien toch niet zo traag is bij de mainstream developer is gekomen toen OEM's de sun implementatie meegaven met windows.

@OMX2000
- Die benchmark focused zich op netwerk stack ik weet niet of die nu helemaal een waarheids getrouw beeld geeft.

Ook ging de boel pas verkeert in 2002 java versie 1.3 - 1.4 die benchmarks gaan over 1.2 en 1.3 beta
http://news.bbc.co.uk/2/hi/business/1862986.stm

[Reactie gewijzigd door Mr_Light op 26 juli 2024 17:17]

[OMX2000]

Het is alweer een tijdje terug. Maar de Microsoft JVM was echt niet zo heeel traag.

Zie: http://www.javaworld.com/...10-1999/jw-10-volano.html

Ik heb geen beef met Java. Ben gewoon een liefhebber van .NET. En nu Java in handen is van Oracle, denk ik niet dat het het java platform goed zal doen. Wat Java m.i. nog meer op een achterstand qua nieuwe ontwikkelingen zal zetten.

[sumac]

Ik denk niet dat Java kapotmaken de intentie is, hooguit een bijkomende bonus. Doel is de markt te veroveren en zoveel mogelijk geld te verdienen.

[Dykam]

Als aanvulling op sumac.
Ondertussen is .NET nu toch deels platformonafhankelijk en ondersteund het .NET team zelfs de mensen die aan Mono werken. Mijn bron zijn de mensen die aan Mono werken.

Java kapot maken, je nickname suggereert dat je open minded bent, dit klinkt heel anders.

[Verwijderd]

Dat zou ik niet te hard zeggen. Voor Java heb je altijd een virtual machine nodig. .Net code kun je compileren naar meerdere binaries voor verschillende platforms. Dat is een zeer krachtige feature waardoor je eenvoudig cross platform kunt programmeren.

Bovendien werken .Net applicaties doorgaans beter dan Java. In veel Java applicaties zitten toch altijd weer rare bugs die waarschijnlijk met de implementatie van de virtual machine / threading te maken hebben.

[kozue]

Java kun je ook naar bytecode native binary code compileren, bv met GCJ (java compiler van GCC). Echter raak je dan de platform-onafhankelijkheid van je programma helemaal kwijt, en moet je weer voor ieder systeem een aparte binary maken. Net als vroegah.
Imho is dit helemaal geen goede feature, en om het als voordeel aan te dragen voor .net getuigt van weinig inzicht in het hoe en waarom van interpreters (vs compilers), afgezien van het feit dat dat geen .net-specifieke feature is.

[edit:] Ja, je hebt gelijk, stomme typo

[Reactie gewijzigd door kozue op 26 juli 2024 17:17]

[Xenan]

Java kun je ook naar bytecode compileren, bv met GCJ (java compiler van GCC).

Je bedoelt zeker:
"Java kun je ook naar native code compileren, bv met GCJ (java compiler van GCC)."

Want Java wordt altijd al naar bytecode gecompileerd. Het is juist de native code die voor elke platform, en elk OS, anders is.

[Reactie gewijzigd door Xenan op 26 juli 2024 17:17]

[Verwijderd]

Een binary is altijd compacter en veel sneller dan bytecode die wordt uitgevoerd door een VM. Voor ieder platform een aparte binary zie ik niet als probleem. Kijk naar Debian Linux. Die hebben voor +/-10 platforms aparte binaries.

[Mr_Light]

Jammer dat het onzin is, zelfs bij gentoo(?) waar men (bijna) alles specifiek voor hun box compileerd kan men nog altijd niet rekening houden met runtime parameters(beschikbaarheid van memory cpu-cycles et al) dit komt omdat zowel mensen als computers niet de toekomst kunnen voorspellen. Het kan dus prima zo zijn dat spul dat in een vm draaid sneller is, links of rechts om je claim dat binaries altijd veel sneller zouden zijn is onzin. Wat betreft compactheid als je runtime optimalisaties zou meecompileren(guards trampolines and alternative subroutines zal de binary bijna altijd (behoorlijk) groter uitvallen, dit omdat je de code die in de (j)vm zit dan bij elke binary aan het bij plakken bent.

Daarnaast heeft het hele bytecodes verhaal juist andere voordelen bv dat je ze kan verifieren(en dus uitspraken kan doen over de veiligheid van het programma) En verder geeft VM je nog een helehoop andere voordelen.

[Verwijderd]

Byte-code is geinterpreteerd. Dat is per definitie langzamer dan machinecode die door de processor wordt uitgevoerd. Waarom denk je dat het JIT compilers zijn die de bytecode eerst naar machinecode compileren?

Beveiliging binnen een VM is niet beter of slechter. In een goed OS draait ieder process in zijn eigen omgeving. De kernel zorgt voor de scheiding tussen de processen net als een VM dat doet.

[Mr_Light]

Byte-code is geinterpreteerd. Dat is per definitie langzamer dan machinecode die door de processor wordt uitgevoerd. Waarom denk je dat het JIT compilers zijn die de bytecode eerst naar machinecode compileren?

Bij interperteren gaat het ook uiteindelijk altijd naar machine code wat uit eindelijk altijd naar micro code gaat wat uiteindelijk altijd naar (elektrische) signalen gaat. DE cpu vreet maar een instructie set en dat is z'n eigen. Waar het om gaat is wanneer de stappen worden genomen. Afhankelijk van hoe veel afstand(tijd) er tussen zit moet men conservatiever zijn in de keuze van algoritmes en dus is daar mogelijk efficiëntie verlies. Dit verlies kan groter zijn dan de overhead van het interperten/JIT-en/etc. Bytecode hoeft dus niet langzamer te zijn dan ahead-of-time compilation.

Beveiliging binnen een VM is niet beter of slechter. In een goed OS draait ieder process in zijn eigen omgeving. De kernel zorgt voor de scheiding tussen de processen net als een VM dat doet.

Ik geloof niet dat ik je volg - VM's zijn troep behalve als het in de kernel zit?

Zelf als je proces gesandboxed is wil je alsnog controle hebben over code dat van een onbetrouwbare bron komt, die code kan dan wel geen schade uitrichten buiten het proces maar je programma crashed nog steeds.

Ook hoor ik graag over het OS die dat wel allemaal voor elkaar heeft... want ik ken er geen.

[Verwijderd]

Ik typte: een VM is net zo veilig als een process rechtstreeks onder het OS zelf uitvoeren. Er geen enkele mainstream VM of OS dat 100% gegarandeerd geen gaten heeft. Daarom: een VM is niet beter of slechter dan een programma rechtstreeks op het OS draaien.

[Mr_Light]

Als alles even veilig is waarvan we niet 100% kunnen garanderen veilig is kunnen we wel op houden met security... want dan is alles even veilig.

Bij geverifieerde bytecode is de security afhankelijk van bugs bij andere gevallen is er de mogelijkheid dat er onveilige instructies worden uitgevoerd. Hierover zijn talloze papers te vinden. Nu kan je daarvoor checks toevoegen maar juist de overhead daarvan is alleen maar te elemineren door middel van JIT/interperer overandere vorm van late time compilation.

[McCloud]

Bovendien werken .Net applicaties doorgaans beter dan Java. In veel Java applicaties zitten toch altijd weer rare bugs die waarschijnlijk met de implementatie van de virtual machine / threading te maken hebben.

Heb je hier ook voorbeelden van? Ik werk al zo'n 13 jaar met Java, en afgezien van een bug die ik ooit in IBM JDK ben tegengekomen worden de meeste bugs in applicaties mijns inziens veroorzaakt door (slechte) programmeurs, niet door de implementatie van de JVM. Zeker als het gaat om threading en synchronisatie (wat gewoon een complex onderwerp is) worden veel fouten veroorzaakt door programmeurs die het concept niet snappen.

[Verwijderd]

Ik noem Eclipse als grootste voorbeeld maar ik ben in de afgelopen jaren ook andere Java applicaties van bijvoorbeeld gerenommeerde bedrijven als SAP en Mathworks (Matlab) tegengekomen die gewoon niet lekker lopen.

Als programmeurs het concept niet snappen, dan zou dat ook aan de compexiteit/valkuilen van de taal kunnen liggen. Ik zie dezelfde problemen ook met Delphi/Pascal applicaties. Rare bugs en niet afgevangen fouten doordat mensen teveel met de taal worstelen in plaats van met programmeren (vooral Pascal dwingt programmeurs in een strak stramien).

[HerrPino]

.NET is in zijn basis zeer zeker wel platform onafhankelijk... ECHTER, de Microsoft .NET framework is dat niet volledig (voorbeeld: Windows Forms gedeelte). Maar het is ook heel goed mogelijk om Linux of Mac specifieke libraries te bouwen... daarmee kun je niet zeggen dat Java niet platform onafhankelijk is.

[OddesE]

Theoretisch: Ja. In de praktijk kun je inderdaad op allerlei *windows* platforms draaien en *misschien* dat je app het ook doet op Mono...

Is toch wel heel wat anders als Java waar je app vrijwel gegarandeerd kan draaien op alle architecturen waar een JVM voor is (allemaal dus).

Je kunt met Java wel een app bouwen die *alleen* op Windows werkt, maar dat is wel moeilijk.

Je kunt met .NET wel een app bouwen die NIET alleen op Windows werkt, maar dat is zo mogelijk nog veel moeilijker. Standaard zit je gewoon vast op Windows.

[Verwijderd]

Spijtig voor Oracle. Het lijkt me niet dat je iemand met zoveel kennis en dergelijke zomaar kwijt wilt. Hij heeft namelijk teveel kennis van Java waardoor hij zelf ook iets zou kunnen opzetten, mits z'n contract dat toelaat . Aan z'n reden te zien zal er wel mot geweest zijn, anders lijkt het me niet dat je zo opeens vertrekt..

Ik kan je vertellen dat Oracle (internationaal, Nederland denkt er vaak anders over) toch iets anders denkt over medewerkers dan jij hier impliceert. Zoals ook anderen hier op Tweakers hebben ervaren, speelt het concept arbeidsrelatie een stuk minder bij Oracle dan wat wij hier in Europa gewend zijn.
Sterker nog, Larry heeft intern vaak genoeg aangegeven dat alle medewerkers in principe eenvoudig te vervangen zijn.

In Nederland zouden we zo iemand als James Gosling graag voor het bedrijf behouden. Indien dat zijn voorkeur heeft, wellicht in een andere positie. Maar dat is niet bepaald het beleid van Oracle. Zeker als het gaat om mensen die bij een overgenomen bedrijf vandaan komen, is Oracle over het algemeen erg blij als ze weg gaan. Ook als je de laatste alinea leest, is wel duidelijk dat Oracle ook bij Sun hetzelfde beleid voert als na de overname van diverse andere grote spelers, zoals bijvoorbeeld Hyperion en PeopleSoft.

[the_shadow]

Ik zit er bijna op te wachten dat veel van deze ex-medewerkers een eigen bedrijf starten (Moon, Alpha Centauri, whatever) dat een fork maakt van de huidige open source codebase van Java en MySQL en de ontwikkeling hiervan op een door de communitie wel geaccepteerde manier doorzet. Zeker met mensen als Schwartz, Gosling, Bray en Urlocker zie ik een dergelijke onderneming nog een redelijk eind komen. Communitie support zullen ze gegarandeerd krijgen en de ontwikkeling van nieuwe technologieën gaat op zo'n manier waarschijnlijk ook een stukje sneller, dan wanneer het onder de koepel van een logge organisatie als Oracle valt.

[latka]

Interresant maar Java is tegenwoordig vooral groot in bedrijven en zeker de groten zullen bij Sun/Oracle/IBM blijven voor hun Java zaken. Dus ik denk niet dat dit zal gebeuren.

[arjankoole]

Interresant maar Java is tegenwoordig vooral groot in bedrijven en zeker de groten zullen bij Sun/Oracle/IBM blijven voor hun Java zaken. Dus ik denk niet dat dit zal gebeuren.

Niet perse, het is als nieuwkomer heus wel mogelijk iets neer te zetten wat klanten trekt. Maar dan moet je wel heel heel goed zijn.

[OddesE]

Maar met welk nut?

Is niet het hele idee van Java, "Write once, run anywhere", afhankelijk van één goed gedefinieerde Java omgeving waar alle apps in kunnen draaien? Door te forken zou je dat in gevaar brengen, tenzij je precies compatible blijft met Oracle/Sun, maar dan kun je dus ook niets veranderen en vervalt het hele nut.

[the_shadow]

Er zijn zat andere JVMs dan de huidige Sun HotSpot JVM. Denk hierbij aan Kafee en IBM J9. Daarnaast is er ook nog een legio aan onderzoeks JVMs of server specifieke JVMs. Allemaal kunnen ze overweg met gangbare Java code, maar hebben allemaal iets wat ze specifiek voor een bepaald doel geschikt maakt.

[mashell]

deze ex-medewerkers een eigen bedrijf starten ... dat een fork maakt van de huidige open source codebase

En hoe gaat dat bedrijf geld verdienen? Open Source is heel erg hip maar geld ermee verdienen is nog knap lastig.

[jj71]

Maar niet onmogelijk, kijk maar eens naar bedrijven zoals Red Hat.

[Verwijderd]

Die politicalisering merk je overal, software development lijkt tegenwoordig 99% politiek en 1% daadwerkelijk techniek... Al geloof ik best dat Oracle wat dat betreft vooruit loopt.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 17:17]

[FloRadix]

Is ook mede doordat je firma wordt overgenomen en dat nadien alle processen veranderen, als het gehele management structuur. Voor veel mensen is dat een aanpassing maar niet altijd een verwelkomde verandering

[latka]

Zal best, maar Oracle heeft een naam hoog te houden waar het gaat om spreadsheet management waarbij Sun een cultuur van technische kwaliteiten had. Dit versneld de uittocht wel een beetje in dit geval.

[OddesE]

Spreadsheet management? Waar heb je het over?

Ik ken Oracle toch voornamelijk van hun database...

[Ford Prefect]

Latka doelt met Spreadsheat management niet op een product grapjas

Hij bedoelt dat Oracle vooral stuurt op of ze onder de streep en het rood of in het zwart staan en niet zo zeer op technische gedrevenheid.

[Left]

Tot nu toe heeft de overname van MySql en Sun door Oracle de developerscommunity weinig goeds gebracht.
Jdk7 wordt telkens verder uitgesteld, als je java.sun.com opent dan krijg je tegenwoordig hier en daar Oracle praatjes voorgeschoteld, en nu is er dus een uittocht begonnen van MySql en Java kopstukken.

Ik als Java programmeur had meer verwacht van een overname van Sun door IBM.

[Verwijderd]

Ik (ook als Java devver) had minder verwacht van IBM. Als ik kijk naar de Java die IBM meestuurt lopen ze redelijk achter en willen het wiel vaak opnieuw uitvinden ipv aan de standaarden voldoen van de Java Community

[freshy98]

Dit blijf ik altijd humor vinden "platformonafhankelijke programmeertaal" voor een taal waar specifieke machine architectuur code in zit.

[Alex]

Je hebt wel gelijk hoor. Er zit in veel Java code gewoon environment specifieke 'troep'. Dit ook omdat er gewoon platform specifieke routines, bugs en workarounds zijn.
Toch is het streven van Java goed want het maakt code beter onderhoudbaar en overdraagbaar. Je ziet dat het in een host zoals Browser nog steeds zeer goed werkt.

[Reactie gewijzigd door Alex op 26 juli 2024 17:17]

[OddesE]

Eén voorbeeld?

(Java is Open Source tegenwoordig, dus als je je mening écht wil onderbouwen post je hier een link naar de betreffende file(s))

[Alex]

Ahh fout beschreven, in veel in Java geschreven code zit Environment specifieke 'troep'. Dit blijkt er al uit dat er boeken als de volgende zijn:

Klik naar Amazon

Hoewel het kan, is het nog steeds ongelooflijk moeilijk om bijvoorbeeld generieke file manipulatie te doen die op elk platform werkt. Alleen al omdat de conventions over shares, paths, etc, zoveel verschillen, dat je er niet aan ontkomt om af en toe een path gewoon lekker te hardcoden.

Update: Btw dit is niet ranzig oid, de tijd om een applicatie vervolgens te porten naar een ander platform is inschatbaar en ook maintenance over verschillende platformen is zeker goed mogelijk. Al met al heb je dan de benefits van het Java platform.

[Reactie gewijzigd door Alex op 26 juli 2024 17:17]

[Left]

Het boek waarnaar je linkt is nogal gedateerd:

Morgan Kaufmann (September 28, 1998)

Verder behandelt het o.a. Microsoft's eigen Java SDK die uiteindelijk verboden werd juist omdat er zoveel 'environment specifieke troep' in zat.

Wat betreft het voorbeeld wat je geeft dat je doet besluiten een path te hardcoden:
Hardcoded paths in je code zijn een erg slechte programeergewoonte.
Maar als je het toch wil dan is er in de komende Java 7 SDK een API voor: java.nio.file.Path

[Herko_ter_Horst]

Leg uit?

De taal en gecompileerde code zijn onafhankelijk van een specifiek hardware+OS-platform, dit in tegenstelling tot andere talen, zeker in de tijd dat Java ontstond. Dit omdat het platform voorziet in een virtuele machine (de JVM). Inmiddels hebben meer talen/platforms het concept van een virtuele machine omarmd.

[the_shadow]

Het enige deel van Java waar architectuur specifieke code in zit, is de JVM, en daar hoef je als ontwikkelaar niet zelf tegen te praten. De Java code die geschreven wordt, kan volledig platform onafhankelijk, simpel door een System.getProperties(). Dit geeft gewoon een lijstje met wat het OS is, wat de geldende file, path en line seperators zijn, etc.

[Haijo]

Een applicatie hoeft niet platformafhankelijk te zijn als de taal waarin hij geschreven is dat wel is natuurlijk. Een "\" hardcoded in een diretory in plaats van een line.separator en hij draait alleen maar op Windows.

[HoeZoWie]

James Gosling verlaat Oracle

Eigenlijk moet daar staan:

James Gosling verlaat (voorheen) Sun, laatst overgenomen door Oracle

Dat zou beter bij hem passen. Hij zegt niet voorniets:

"Waarom ik ben vertrokken is moeilijk te zeggen. Alles wat ik gemeend en oprecht zou kunnen zeggen, zou meer kwaad dan goed doen", zo schrijft hij.

Hieruit blijkt toch duidelijk dat ze niet als 'goede vrienden' uit elkaar gaan....

[Reactie gewijzigd door HoeZoWie op 26 juli 2024 17:17]

[Verwijderd]

Freshy98,

Kun je daar wat meer over uitleggen?

[Verwijderd]

Ow "the father of Java" verlaat het schip!

[The Inquisitor]

Spijtig he.