Nieuwe Java-VM draait zonder OS

BEA Systems zal volgende week waarschijnlijk zijn nieuwe Java-VM voorstellen. Met behulp van de nieuwe software voor servers kunnen Java-programma's rechtstreeks op de hardware gedraaid worden zonder tussenkomst van een besturingssysteem. Hierdoor zou volgens BEA de vertraging die ontstaat doordat Java-code niet rechtstreeks uitgevoerd wordt, maar door de Virtual Machine geïnterpreteerd wordt, teniet gedaan worden. Volgens de geruchten zou BEA de nieuwe versie van JRockit, zoals de virtual machine heet, op de JavaOne-beurs voorstellen. Ondersteunde processors zullen volgens een anonieme bron zowel Intels Xeon-chip zijn als de Power-processor en de Sparc-chip, respectievelijk van IBM en Sun. Eerder al had Sun een specifieke Java-processor geannuleerd en kondigde Azul aan dat het Java-servers zou gaan verkopen met aangepaste processors om Java-software sneller te kunnen draaien.

Reacties (50)

[voodooless]

Wat een onzin...

Geen OS, tuurlijk wel: de software zelf is gewoon een klein OS waarin alleen java apps zullen draaien

Java code draait ook nog steeds niet rechtstreeks op de hardware. Er is nog steeds een VM. Enige wat je nu hebt is dat de VM het OS is en je mist dus een abstractielaag, waardoor je een beetje snelheid wint. Erg veel zal dat niet zijn gok ik.

Toch, best leuk idee. Kan erg handig zijn, maar moet zich eerst nog bewijzen

[KnoppenSpook]

Prcs, de laag van het OS wordt weggehaald c.q. zelf geimplementeerd.

Iig verdwijnt er een laag in de hele toren van software lagen. Dus: Snelheids winst.

Klinkt idd niet verkeerd. Ben wel benieuwd hoe de java apps dan samen werken met het OS...

[voodooless]

Ben wel benieuwd hoe de java apps dan samen werken met het OS...

Maakt niet uit. Je hebt gewoon je java api, en daar werk je mee. Aangezien de api platformonafhankelijk is, zal deze ook zonder OS gewoon werken.

[mxcreep]

Wel ernstig handig als je app externe libs gebruikt die specifiek op bijvoorbeeld *nix aanwezig zijn...
De applicatie omgeving runnen is leuk, maar er is meer nodig om een applicatie te bouwen...

[Anoniem: 399]

mxcreep wrote:

Wel ernstig handig als je app externe libs gebruikt die specifiek op bijvoorbeeld *nix aanwezig zijn...

Als je app linux libs gebruikt is ie sowieso niet platform onafhankelijk natuurlijk. Het hele porteringsverhaal gaat alleen op als je het hele stuk in Java doet.
Wat je wél kan doen hiermee, is, afhankelijk van de prijzen van deze software, java-only terminals bouwen die je *nix of Windows of voor mijn part Netware doos aanspreken voor bepaalde stukken van je applicatie. Verder lijkt dit inderdaad primair zinvol als oplossing voor embedded spul: de lift besturen op een klein, simpel computertje maar wel gewoon in Java programmeren kan heel fijn zijn als je de aansturing van vijftien liften in een pand aan het bouwen moet. Er komen rap Java ontwikkelaars bij en de echte PLC artiesten worden steeds zeldzamer.

[wasigh]

Als je bedoeld: er is nog steeds een Hardware Abstraction Layer dan heb je gelijk. Maar deze VM zal direct de Hardware aanspreken in plaats van de functies van het host OS. Dat betekend dus dat een VM voor een bepaald stuk hardware geoptimaliseerd kan worden.
Wat volgens mij een flinke tijdswinst op kan leveren.

Het klinkt alsog het gaat werken als een stukje embedded software.

[voodooless]

De meeste dingen die echt tijd kosten zijn niet een zo van het OS afhankelijk, dus echt veel winst valt er niet te behalen.

[captain007]

Je kunt het niet een echt OS meer noemen. De basisfuncties om iets een OS te mogen noemen zijn er eigenlijk uitgehaald. (Denk aan memory management e.d.)

Het is niets anders dan een runtime compiler die machine instructies geeft aan de processor. T verschil is alleen dat er geen extra lagen meer nodig zijn, maar dat deze software rechtstreeks op de processor werkt.
Qua security denk ik dat dit minimaal is. Anders gaat dit weer ten koste van de performance.

[Janoz]

Memorymanagment zit (ook) gewoon in de VM. Hetzelfde geldt voor (Disk & netwerk)IO. Alles is gewoon een laagje opgeschoven. Ik zie dus nog steeds geen reden waarom dit niet een OS genoemd zou kunnen worden.

[Anoniem: 61096]

Deze claim komt de laatste tijd wel vaker op. Een OS moet schijnbaar tegenwoordig iets heel gecompliceerds zijn. Dat is natuurlijk onzin. Als ik een Commodore 64 pak heeft dat ding een duidelijk OS. Maar zaken als multithreading, memorymanagment? Nee, dat zit er echt niet in. Zelfde geldt voor DOS.

Misschien dat je kunt claimen dat een modern OS dat soort functionaliteit moet bieden. Het is in ieder geval niet een basiseis voor elk OS. Of dit "java OS" die functionaliteit biedt waarschijnlijk wel. Maar met of zonder die functionaliteit. Het blijft gewoon een OS.

[Anoniem: 112954]

Java code draait ook nog steeds niet rechtstreeks op de hardware. Er is nog steeds een VM.

Ooit gehoord van Just In Time compilatie? Gebeurt in een Java VM al een tijdje hoor.

[epoortvliet]

JRockit wordt door BEA voornamelijk gebruikt om hun applicatieservers (WebLogic) op te laten draaien. Wanneer zij dit onafhankelijk van het OS kunnen doen scheelt dat aanzienlijk in de performance en kunnen ze de concurrentie beter aan met, bijvoorbeeld, IBM WebSphere. Uit het verleden bleek al dat BEA WebLogic beter presteerde met JRockit dan met Suns JVM.

[Anoniem: 93305]

Hier gaat waarschijnlijk de processor virtualisatie een belangrijke rol spelen!
Java NAAST een standaard os op dezelfde CPU!

[martijnvanegdom]

Standaard boek op de Tu-delft:

Operating System Concepts 6th Editon

What is an Operating System?

An operating system is a program that manages the computer hardware. It also provide a basis for application programs and acts an an intermediary between a user of a computer and the computer hardware.

Lijkt me duidelijk dit sysem is een os.. weliswaar niet zo uitgebreid als veel mensen denken dat een os is.. Wat windows dat is een OS plus een enorme hoop aan tools..
Linux is een veel meer een OS.. GNU/Linux is het OS. plus tools. Denk dat je het daarmee wel kunt vergelijken

[boner]

dus voor alle hardware weer een aparte VM omgeving? lekker de klok terug dan.....

[catfish]

nu hebben we toch ook een VM nodig per OS, of denk je dat de Windows-VM ook op Linux draait?

ze hebben deze gewoon nu gemaakt dat hij rechtstreeks de hardware aanspreekt en dus net minder afhankelijk is van het OS, lijkt mij net beter eigenlijk

[boner]

wat d8 je van een andere video kaart? Een andere printer? USB1 usb2 firewire? PCI, PCI-X SATA,SCSI, ATA?

moet ik verder gaan?

[Anoniem: 61096]

Het is uiteindelijk een "gewoon" OS. Dus met drivers voor de videokaart enz enz enz. Maar de beperkingen daarvan vallen wel mee. JRocket wordt voornamelijk op servers gebruikt Videokaarten, scanners, geluidskaarten enz enz. zijn daar meestal niet echt relevant. Het is niet zo dat dit OS met Windows of OS-X moet gaan concurreren. Het is een OS voor een beperkte doelgroep en waarschijnlijk ook met een beperkte hardware ondersteuning. Maar als het duidelijke performancevoordelen heeft kan het voor een hoop servers wel een zinvolle oplossing zijn.

[Janoz]

Het gaat hier niet over client systemen. Het gaat hier over applicatie servers. Ten eerste zijn dat niet de computers waar zo even een paar pci kaarten bijgedrukt worden, een printer aangehangen wordt of waar iemand zo een usb stick in hangt.

Daarnaast worden dit soort computers in een geheel afgenomen. De hardware kan in dat geval exact worden afgestemd op de te gebruiken software.

[Anoniem: 14829]

Dat heb je nu toch ook al? Of is 't jou al 's gelukt om een VM voor een Sparc op een x86 of PowerPC aan de praat te krijgen?
Het gaat hier om een laagje tussen de VM en de hardware die Java bytecode rechtstreeks (of zo rechtstreeks mogelijk) omzet naar code die de processor snapt. Lijkt me een goede ontwikkeling voor bv. embedded systemen, NAS/SAN oplossingen en servers met een specifieke taak.

[Anoniem: 18254]

Dit is weer het zoveelste lapmiddel waarmee men probeert een fundamenteel slechte taal minder slecht te maken. Net als al die andere pogingen is uiteraard ook deze tot mislukken gedoemd - Java blijft een langzaam gedrocht. De vertraging wordt namelijk niet door het OS veroorzaakt, maar door de Virtual Machine zelf (zoals iedereen weet staat de afkorting VM voor Virtual Memory, en dus niet voor Virtual Machine). Door middel van iets als gcj zou je eventueel voor sommige applicaties nog normale performance kunnen behalen, maar dan nog wordt de meeste software langzamer door de fundamentele fouten die er bij het bedenken van de taal Java gemaakt zijn en het ontbreken van essentiële features.

[voodooless]

Dit is het zoveelste onzin verhaal dat met domme nutteloze argumenten probeert een prima taal, die op enorm veel plekken wordt ingezet, de grond in te boren. Bekijk de financieele wereld, heel veel backend stuff is java. Om de snelheid is het dan ook nooit gemaakt.

Het verschil tussen gcj en de jvm implementatie is tegenwoordig ook zo klein dat het amper wat uit maakt. Daarnaast is het tegenwoordig ook amper tager dan een impementatie in een andere taal. Natuurlijk moet je java ook niet overal voor gebruiken. Maar zeggen dat het een fundamenteel slechte taal is, is gewoon lulkoek.!

[Anoniem: 42145]

idd. Java kan langzamer zijn, maar ook sneller. In situaties waar je met runtime optimalisaties winst kunt behalen zal java gecompileerde talen als C++ evenaren of inhalen.

Het licht niet (altijd) aan de VM dat java kwa rekenkracht langzaam zou zijn.

Wat mischien wel een klein probleem is in sommige specialistische situaties, is dat java geen stack allocaties van objecten kent. In andere talen heb je dikwijls de keuze tussen heap en stack allocatie. In Java is het *altijd* de heap. Voor vele kleine tijdelijke objecten is de stack efficienter.

Hieraan gerelateerd is het probleem dat een Java class met aggregated objecten altijd fragmented is. M.a.w. een Java class kan alleen pointers naar andere objecten bevatten. Andere talen (zoals C++) staan ook toe dat een class is opgebouwd (composition) uit verschillende objecten die sequentieel achter elkaar (in vaste volgorde) in het geheugen staan.

Voor specificieke problemen -kan- dit een performance probleem zijn, maar je moet een verdraaid goede programmeur zijn die precies weet wat ie doet om deze edge van bijvoorbeeld C++ goed in te kunnen zetten.

[Anoniem: 18254]

Dat Java wordt gebruikt wil niet zeggen dat het niet slecht is. En als Java nooit voor de snelheid gemaakt is, waarom worden er dan toch pogingen gedaan de snelheid te verhogen?

Ook zonder Virtual Machine heeft Java genoeg dingen die de performance verslechteren - exceptions, late bindings en het niet bestaan van C-stijl arrays zijn slechts enkele voorbeelden.

Er is geen enkele toepassing te bedenken waarvoor er niet minstens 1 taal beter geschikt is dan Java, en dus is het een slechte taal.

[qless]

Ik heb zo het idee dat jij java alleen kent van applets. En die willen nog wel eens wat traag zijn ja...

Met een recente JVM (Java Virtual Machine) haal je een keurige performance, Java is tegenwoordig met een aantal operaties zelfs sneller dan C++.

Of zit jij nog bij 1.2 JRE?

[Anoniem: 18254]

Een uitspraak als "sneller dan C++" is vaag en slecht toetsbaar. Ik durf te wedden dat jij voor geen enkele bewerking met een stuk Java code kunt komen waar ik geen sneller alternatief voor in C zou kunnen schrijven, uitgaande van hetzelfde hardware platform en OS en een te kiezen compiler.

[sirdupre]

Oh ja, elke extreme C guru kan vast wel iets schrijven dat sneller is dan een random java programma. C is dan ook niet veel meer dan een high-level assembly taal. Als jij wil kan je die JIT-optimalisaties die java soms als voordeel biedt t.o.v. gewone C++, ook wel in C schrijven. Je programmeerwerk wordt er echter niet makkelijker op. En ontwikkelsnelheden zijn tegenwoordig een stuk interessanter dan runtime-snelheden. Manuren zijn namelijk een heel stuk duurder dan brute computerkracht.

Verder is het ook een gigantische bullshit dat je zegt dat het onzin is dat men java sneller probeert te maken terwijl het nooit voor hoge snelheid bedoeld is. Snelheid is namelijk iets wat bij élke computerapplicatie interessant is. Dat bij java de nadruk ligt op portabiliteit wil natuurlijk niet zeggen dat men java expres sloom gaat zitten houden.

[Anoniem: 18254]

De ontwikkeltijd is bij Java absoluut niet lager dan bij C (of C++ voor objectofielen), eerder hoger vanwege de absurde syntax en pseudo-low-level aspecten van de taal (waarom moet ik bijvoorbeeld een BufferedReader om een FileReader heenzetten? Bufferen is een taak van het OS!).

Iets wat door mij gezegd wordt is per definitie geen bullshit, en jullie Java-lovers moeten gewoon eens een keer een keuze maken: of je vindt performance niet belangrijk en projecten zoals dit zijn dus zinloos, of performance is wel belangrijk en kritiek op het gebrek daaraan bij Java is dus terecht.

Ook wat betreft portabiliteit legt Java het trouwens af tegen C. Er is geen enkel platform waarvoor wel een Java Virtual Machine beschikbaar is maar geen C compiler, terwijl andersom wel het geval is. En hoe vaak hoor je niet "voor deze applicatie is Sun JVM versie 42.Haïti vereist" (eventueel nog in combinatie met een bepaald OS)? In Java geprogrammeerde software is dus niet per definitie portable, en aan de andere kant is het ook in C prima mogelijk om portable software te schrijven...

[Anoniem: 127204]

Dit brengt wel een groot security probleem met zich mee. Het OS is er niet voor niets en beschermd een hoop dingen. Als deze laag wegvalt, moet dit wel door de VM zelf geregeld en bekeken worden. Dit kost ook weer tijd.
Al met al zal het wel schelen, maar men moet uitkijken dat er niet te veel direct met de hardware gerommeld kan worden.

[Anoniem: 14829]

Ik denk dat BEA (met hun ervaring met J2EE en EJB's) hier ook wel aan gedacht zal hebben. Een hoop van hun grote klanten zitten immers in de financiele hoek (banken, verzekeraars, etc.) en die hechten nogal wat waarde aan security...

[Janoz]

De VM heeft die beveiligingen nu ook al ingebouwd. Er komt dus op dat gebied nauwelijks extra functionaliteit. Daarnaast bied java niet de mogelijkheid om veel 'met de hardware te rommelen'. Het is dus niet ineens zo dat je op die computer nu ineens een 'app of death' kunt draaien.

[Gody]

Ik neem aan dat er dan software op het ontwikkelpltform komt waarmee je de doel-machine kunt simuleren. Debuggen zonder development-tools ertussen lijkt me namelijk niet makkelijk.

[Janoz]

1: Als het goed is werkt de JRockit VM hetzelfde op een linux/windows/apple systeem als zonder OS. De JRockit VM hoort zelfs hetzelfde te werken als de JVM van Sun. Je locale testomgeving is dus (in theorie) gelijk als je productie omgeving (,maar ik geef toe dat dit punt vooral theoretisch is).
2: De JVM is op te starten met een debug poort. Ik neem aan dat dit ook geldt voor deze versie. Je kunt dan gewoon de javadebugger of je IDE met deze server verbinden.

[AxiMaxi]

Ik snap het niet helemaal... ga je met dit idee niet voorbij aan de voordelen van een OS?
Je wilt toch juist dat het OS de verbindingen met de hardware legt, zodat je straks naast de Windows/Linux drivers niet ook nog Javadrivers moet installeren voor je videokaart

[epoortvliet]

Deze reactie was voor B Muerte
Nee, snap 't dan.

Het is niet bedoeld voor werkstations maar voor applicatieservers. Hoe denk jij dat je alle content op via je browser binnenkrijgt? Niet via statische HTML maar door applicatieservers Java, .Net noem 't maar op.

[Anoniem: 62763]

Wat was de definitie van een besturingssysteem nog maar? 'Een systeem wat interactie tussen de gebruiker en de apparatuur vereenvoudigd'? Je hebt een java VM omgeving, een bytecode interpreter en en je hebt de hardware. Tenzij er een of andere magische bewerking aan te pas komt, zal het nog steeds zo zijn dat de die VM de resources van het host systeem representeert in resources geschikt voor je java app. Volgens mij voldoet dit dan aan de definitie van een besturingssysteem. Okee. Het werkt dan zonder een los OS, want de VM IS dan het OS.

Verder lijkt een JAVA only platform mij niet ideaal.
Tenzij je daar weer een X86 (of sparc enz.) emulator op krijgt, beetje omgekeerde wereld.
Er zal maar een heel klein percentage consumenten zijn die hier baat bij hebben, nauwelijks de ontwikkelkosten waard.

-R-

[Left]

Er zal maar een heel klein percentage consumenten zijn die hier baat bij hebben, nauwelijks de ontwikkelkosten waard.

BEA maakt geen software voor consumenten, ze maken software voor web-en applicatieservers.
De klanten waar BEA op mikt zijn bedrijven die alleen maar 1 serverapplicatie hebben draaien die geimplementeerd is in Java.

Ze hadden met JRockit al een retesnelle JVM, maar nu gaat alles kennelijk nog een stap sneller. Goeie zaak!