[java] Jdk 1.4 beta3 is uit..

[Alarmnummer]

topic naam zegt genoeg denk ik
http://java.sun.com/j2se/1.4/

[Jelmer]

en hier het changelog sinds beta2.

[mbravenboer]

Goh, je was sneller dan ik . Thanks voor de tip.

[tomato]

Dankje, * tomato gaat hem binnenkort neerhalen

[mbravenboer]

Alarmnummer: weet je al iets over de stabiliteits problemen die jij in MS Windows 2000 had met beta 2? Opgelost in beta 3?

[Alarmnummer]

Op dinsdag 30 oktober 2001 23:26 schreef mbravenboer het volgende:
Alarmnummer: weet je al iets over de stabiliteits problemen die jij in MS Windows 2000 had met beta 2? Opgelost in beta 3?

De hele dag gaat mijn IDE erop draaien, daarna krijgen jullie wel bericht. Ik heb de indruk dat het wel sneller is.

[mbravenboer]

Alarmnummer: De hele dag gaat mijn IDE erop draaien, daarna krijgen jullie wel bericht. Ik heb de indruk dat het wel sneller is.

Die eerste indruk had ik ook bij Jext. Hij vliegt nu werkelijk. Het was ook aangekondigd dat de performance release zou zijn, dus kennelijk is dat gelukt...

[mbravenboer]

Ik lees trouwens net op javalobby dat de laatste stil gereleasde ( ) 1.3 de Applet tag in IE ondersteunt. Merkwaardig dat dat niet algemere bekend is gemaakt.

Ondersteunt de beta3 van 1.4 dit ook?

[mbravenboer]

Ik lees net dat beta 3 zichzelf inderdaad installeert als default VM voor applet tags in IE4.x, 4.x, 6.x.

Extreem cool dus . 1.4.0 wordt een geweldige stap . Hopelijk kiezen enkele OEMs voor het meeleveren van 1.4.0.

[Alarmnummer]

Ik zou niet weten wanneer ik voor het laatst een applet hebt gemaakt

[mbravenboer]

Alarmnummer: Ik zou niet weten wanneer ik voor het laatst een applet hebt gemaakt

Hum zit wat in, maar toch . Stel dat alle AOL/Dell/Compaq gebruikers een 1.4.0 VM zouden hebben. Veel meer sites zullen er dan vanuit gaan dat er een Java Plugin aanwezig zal zijn. Applets zouden in deze gevallen weleens een flink heropstanding kunnen doormaken.

Er is nu in ieder geval een goede, recente VM die werkt voor alle applets! Die was er tot nu toe gewoon niet . Uiteraard is de aanwezigheid van Java Web Start in 1.4.0 helemaal interessant .

[Alarmnummer]

Ik ben nog geen problemen tegengekomen. Alles draait erugh soepel en snel en stabiel. Alleen mijn toolbar buttons zijn iets groter dan gewoon Maar afgezien hiervan is dit denk ik een uitstekende versie.

fix voor te grote button in toolbar.

code:

button.setMargin(new Insets(0,0,0,0))

[mbravenboer]

Mooi .

Maximalisatie onder KDE werkt nog steeds niet goed (both maximaliseerd alleen verticaal), maar dat schijnt ook iets met KDE te maken te hebben las in ik een bug-report.

[mbravenboer]

Ik zag trouwens dat Java Web Start nu ook in Mac OS X 10.1 zit (chem: al zien draaien?).

In de 1.4.0 beta-3 Linux distributie wordt Java Web Start trouwens niet geinstalleerd (maar is wel inbegrepen). Ik hoop dit onder MS Windows wel gebeurd?

[chem]

Op woensdag 31 oktober 2001 12:23 schreef mbravenboer het volgende:
Ik zag trouwens dat Java Web Start nu ook in Mac OS X 10.1 zit (chem: al zien draaien?).

Er zit een hoop Java in OS X

oa. de mogelijkheid om een .jar file te dubbelklikken waarna alles afgehandeld wordt etc.

Eerlijk gezegd heb ik op de X bak nog weinig ge Java'd...

[mbravenboer]

chem: Er zit een hoop Java in OS X

Het is dat die krengen zo duur zijn . Hopelijk weet Apple de releases ook goed bij te houden. De samenwerking met Sun schijnt aardig te zijn, dus wellicht komt dat wel goed.

oa. de mogelijkheid om een .jar file te dubbelklikken waarna alles afgehandeld wordt etc.

Executable jars. Perfect .

[Alarmnummer]

Op woensdag 31 oktober 2001 12:23 schreef mbravenboer het volgende:
Ik zag trouwens dat Java Web Start nu ook in Mac OS X 10.1 zit (chem: al zien draaien?).

In de 1.4.0 beta-3 Linux distributie wordt Java Web Start trouwens niet geinstalleerd (maar is wel inbegrepen). Ik hoop dit onder MS Windows wel gebeurd?

Bij windows wordt webstart inderdaad wel automatisch geinstalleerd.

[Alarmnummer]

Op woensdag 31 oktober 2001 12:28 schreef mbravenboer het volgende:

[..]

Het is dat die krengen zo duur zijn . Hopelijk weet Apple de releases ook goed bij te houden. De samenwerking met Sun schijnt aardig te zijn, dus wellicht komt dat wel goed.
[..]

Executable jars. Perfect .

Dit bestaat toch al lang mbv die manifest file? (werk er zelf niet mee). Dubbelklikken.. en voila..

[mbravenboer]

Alarmnummer: Dit bestaat toch al lang mbv die manifest file? (werk er zelf niet mee). Dubbelklikken.. en voila..

Idd, je moet simpel de Main-Class opgeven in de manifest.mf file. Ik gebruik het zelf wel voor alle applicaties. Het is supermakkelijk (ook voor gebruikers). In de manifest file kan je ook de classpath opgeven. Dat is helemaal een perfect oplossing.

[Alarmnummer]

Op woensdag 31 oktober 2001 12:43 schreef mbravenboer het volgende:

[..]

Idd, je moet simpel de Main-Class opgeven in de manifest.mf file. Ik gebruik het zelf wel voor alle applicaties. Het is supermakkelijk (ook voor gebruikers). In de manifest file kan je ook de classpath opgeven. Dat is helemaal een perfect oplossing.

Maar wat is het verschil?

[wasigh]

dat het nu ook werkt op een mac

[Alarmnummer]

Maar daar hoeft toch niet speciaal een nieuwe versie van jdk voor uit te komen? Je kunt toch reageren op de extensie en de bij behoordende app opstarten. Of kon de mac niet met een manifest file omgaan?

[Gerco]

Hij komt binnengestormd...

edit:
Hij IS binnen

Alleen wil die webstart niet werken. Hij blaat over dat er geen goede JRE is en wil steeds JRE 1.3+ 1.2+ downloaden, terwijl ik dus net 1.4 geinstalled heb

An error occurred while launching/running the application.

Title: SwingSet2
Vendor: Sun Microsystems, Inc.
Category: Launch File Error

No JRE version found in launch file for this system

En dat dus voor alle 4 die webstart dingen die er standaard instaan.

[Alarmnummer]

Op woensdag 31 oktober 2001 13:12 schreef Gerco het volgende:
Hij komt binnengestormd...

edit:
Hij IS binnen

Alleen wil die webstart niet werken. Hij blaat over dat er geen goede JRE is en wil steeds JRE 1.3+ 1.2+ downloaden, terwijl ik dus net 1.4 geinstalled heb
[..]

En dat dus voor alle 4 die webstart dingen die er standaard instaan.

Ik heb het probleem ook gehad met jdk1.4 beta1 en beta2. Dit komt omdat met jdk1.3+ geen beta versies van jdk1.4 geaccepteerd worden.

[mbravenboer]

Dit is geen bug maar een feature .

Betas zijn geen production releases. Als de launch-file niet expliciet de beta opgeeft als mogelijke JRE wordt de laaste production release gebruikt.

Je kunt het natuurlijk oneens zijn met deze gemaakte afweging .

[Alarmnummer]

Op woensdag 31 oktober 2001 13:40 schreef mbravenboer het volgende:
Dit is geen bug maar een feature .

Betas zijn geen production releases. Als de launch-file niet expliciet de beta opgeeft als mogelijke JRE wordt de laaste production release gebruikt.

Je kunt het natuurlijk oneens zijn met deze gemaakte afweging .

Ben ik met je eens. Maar als je in je jnlp (webstart opstart script) ook goedkeuring geeft voor jdk1.4beta dan werkt het ook niet (systeem herkent de 1.4beta niet). Zelfs hun eigen 1.4beta voorbeeld werkt niet.

[mbravenboer]

Werkt dit ook niet dan?

How do I run my application under a beta J2RE?

Java Web Start does not consider a non-FCS JRE to match a request for a particular platform version. For example, a request of the form <j2se version="1.4+"> does not consider an installed "1.4.0-beta" JRE as a match for the request. A JRE from Sun Microsystems, Inc. is by convention (starting from 1.3.0) a non-FCS if there is a dash (-) in the product version string. An application wishing to run under any beta J2RE must explicitly specify a product version, i.e., also using the href attribute in the j2se element. For example, a proper request for a beta JRE:

<j2se version="1.4-beta" href="http://java.sun.com/products/autodl/j2se"/>

[raptorix]

Java aan de kant van de server lijkt me prima, maar applets , imo is flash stukken efficienter zeker als in flash 6 nog wat kleine dingetjes worden toegevoegt.

[mbravenboer]

Bij de nieuwe Swing Sightings zit trouwens een extreem bruut 3D spel zo te zien.

Zie:
http://java.sun.com/products/jfc/tsc/sightings/S5.html

[mbravenboer]

raptorix: maar applets , imo is flash stukken efficienter zeker als in flash 6 nog wat kleine dingetjes worden toegevoegt.

Mwah, niet echt een goede vergelijking denk ik. Veel applets hadden wellicht beter in flash geschreven kunnen worden, maar Java biedt toch wel iets meer/anders dan flash.

[Alarmnummer]

Op woensdag 31 oktober 2001 13:52 schreef mbravenboer het volgende:
Werkt dit ook niet dan?
[..]

Met jdk1.4 beta1 en beta2 voor windows werkt dit niet. Beta3 heb ik nog niet geprobeerd.

[tomato]

mbravenboer:

Sun: Arkane is a very very (very) good looking game...

...this game is every bit as good as the commercial competition.

Echt bescheiden zijn ze nooit geweest daar bij Sun he?

_{(dat soort dingen zijn nou typisch Amerikaans... )}

[mbravenboer]

tomato: Echt bescheiden zijn ze nooit geweest daar bij Sun he?

Ach, ze hebben hem niet zelf gemaakt hoor . Zelfs de engine niet. Op zich is dat absoluut geen compliment voor Java 3D.

Het ziet er toch ook erg, erg, heel erg goed uit?

dat soort dingen zijn nou typisch Amerikaans...

Ach, bescheidenheid is weer typisch Nederlands .

[tomato]

Op woensdag 31 oktober 2001 14:19 schreef mbravenboer het volgende:
Ach, ze hebben hem niet zelf gemaakt hoor .

Ja, daar heb je gelijk in...

Ach, bescheidenheid is weer typisch Nederlands .

Met bescheidenheid is idd niets mis naar mijn mening * tomato is Nederlands)

[raptorix]

Op woensdag 31 oktober 2001 14:04 schreef mbravenboer het volgende:

[..]

Mwah, niet echt een goede vergelijking denk ik. Veel applets hadden wellicht beter in flash geschreven kunnen worden, maar Java biedt toch wel iets meer/anders dan flash.

Klopt maar dat komt omdat flash volledig afhankelijk is van de ingebakken functionaliteit, het is bijvoorbeeld in flash niet mogelijk om gewoon een lijn te trekken van punt a naar punt b. Om maar eens een voorbeeld te noemen

[mbravenboer]

Nog een nieuwtje:

De MS Windows XP Java Plug-in is nu eindelijk ook via niet slinkse wegen beschikbaar. Er is een hele site opgezet die de Java Plug-in nieuw leven moet inblazen en als de portal moeten dienen voor het downloaden van Java:

http://java.sun.com/getjava/

Op de front-page staat nog een mooi knoppie. Als iedereen die nu eens op z'n site zet .

[mbravenboer]

Om even het goede voorbeeld te geven :


Klik!

Hehe .

[Stephan Oudmaijer]

om ff een kick te geven:

wanneer komt de final nou eens uit?

[mbravenboer]

Eerst komen er waarschijnlijk nog 2 release candidates. Ik verwacht de final dus de tweede helft van het eerst kwartaal: februari/maart. Ik verwacht de eerste release candidate vrij spoedig... (misschien nog 1 laatste, korte beta daarvoor).

[The - DDD]

Als dat Webstart er echt door komt. Stel je dan is voor hoe je in een organisatie het software beheer zou kunnen verbeteren.

Enige wat je nodig hebt is voldoende bandbreedte op je netwerk en een stevige server (met voornamelijk schijfruimte voor je apps).

[Apache]

net ook java geinstalleer, nog wel een stable 1.3.1

maar ik zal em eens upgraden, k'ben bezig om me al wat voor te bereiden voor we er op school mee beginnen, heb enkele testjes gedaan enz, nog niet echt iets nuttig in gedaan (ook niet echt inspiratie op het moment )

k'ga hier niet om een opgave vragen, volgens mij houdt mbravenboer alleen al mij dan wel bezig tot het einde van mijn vakantie

[mbravenboer]

Apache: net ook java geinstalleer, nog wel een stable 1.3.1

maar ik zal em eens upgraden, k'ben bezig om me al wat voor te bereiden voor we er op school mee beginnen

1.4.0 biedt een hoop leuke nieuwe features zoals een verbeterde Java Look and Feel in Swing en vooral een sterk verbeterde MS Windows Look and Feel. Ook zijn er een hele hoop zeer nuttige compleet nieuwe API's: XML parsers en XSL transformaties, reguliere expressies, logging, nieuwe IO API's enzovoorts . Best wel stoer dus .

k'ga hier niet om een opgave vragen, volgens mij houdt mbravenboer alleen al mij dan wel bezig tot het einde van mijn vakantie

+1, inzichtvol .

[mbravenboer]

The - DDD: Als dat Webstart er echt door komt. Stel je dan is voor hoe je in een organisatie het software beheer zou kunnen verbeteren.

Idd: het benut de capaciteiten van Java op de ultieme manier .

Vervelend is alleen dat Java Web Start zich vooral kan bewijzen als het al geinstalleerd is... Je moet dus de voordelen van Java Web Start in de toekomst inzien.

[Apache]

jammer

ff de gewone features testen.

[mbravenboer]

Apache: jammer

<uitleg voor niet-plaatje-bekijkers of wel-plaatje-bekijkers die het plaatje niet snappen>

Elke Webstart applicatie draait in een eigen JVM

</uitleg voor niet-plaatje-bekijkers of wel-plaatje-bekijkers die het plaatje niet snappen>
(goh wat is XML toch verbose )

Op zich zou het handig lijken om dat dus niet te doen en alles in 1 VM te draaien, maar ik denk dat het kortzichtig zou zijn geweest als ze dat hadden gedaan: Het draaien van meerdere applicaties in 1 JVM is een apart probleem wat ze aan het oplossen zijn. Hierbij spelen veel aspecten een rol: security, loaden en unloaden van klassen, verschillende versies van klassen... Zodra dit goed is uitgewerkt zal Java Web Start dit vast ook gaan toepassen.

[Apache]

nee hoor, k'had het gewoon over het probleem dat hij daar 'hing'

zo is het de hele nacht blijven staan

[mbravenboer]

Apache: nee hoor, k'had het gewoon over het probleem dat hij daar 'hing'

Owh . Dan viel ik dus ook in de categorie die het plaatje niet begreep .

zo is het de hele nacht blijven staan

Java Web Start wacht op u! Perfect toch? .

[Apache]

Op donderdag 27 december 2001 12:41 schreef mbravenboer het volgende:

[..]

Owh . Dan viel ik dus ook in de categorie die het plaatje niet begreep .
[..]

Java Web Start wacht op u! Perfect toch? .

Ja, en uncompressen ging ook razendsnel

[mbravenboer]

Apache: Ja, en uncompressen ging ook razendsnel

Wist je dat de gzip libraries van Java in native code zijn geimplementeerd? . Naar mijn ervaring zijn ze ook wel behoorlijk snel...

[Apache]

Op donderdag 27 december 2001 13:14 schreef mbravenboer het volgende:

[..]

Wist je dat de gzip libraries van Java in native code zijn geimplementeerd? . Naar mijn ervaring zijn ze ook wel behoorlijk snel...

Wat zou het verlies in snelheid zijn als ze ze in de VM hadden geinplementeerd en niet native?

en het gewone snelheids verlies bij applicaties tov native code.

[Onno]

Op donderdag 27 december 2001 13:38 schreef Apache het volgende:

[..]

Wat zou het verlies in snelheid zijn als ze ze in de VM hadden geinplementeerd en niet native?

Ik denk dat je uit het feit dat ze 't native gedaan hebben haast wel kunt concluderen dat het snelheidsverschil best groot is.

[mbravenboer]

Apache: Wat zou het verlies in snelheid zijn als ze ze in de VM hadden geinplementeerd en niet native?

Geen idee, daar kan je slechts naar gissen. Ik vermoed echter dat het niet gedaan is vanwege de performance: volgens mij is er ergens een standaard library vandaan getrokken. Als je de source van de JVM download kan je het nagaan ( ik heb hem hier ff niet bij de hand) . In de source in de SDK kan je niet alles vinden. Dit is het laaste:

code:

new sun.security.action.LoadLibraryAction("zip"));

[Apache]

Onno schreef het volgende:

[..]

Ik denk dat je uit het feit dat ze 't native gedaan hebben haast wel kunt concluderen dat het snelheidsverschil best groot is.

<=>

mbravenboer schreef het volgende:

[..]

Geen idee, daar kan je slechts naar gissen. Ik vermoed echter dat het niet gedaan is vanwege de performance ...

Jullie spreken elkaar dus tegen, dit word nog intressant

Ik had ook nog net m'n vraag geedit over het algemene verlies in snelheid dat je krijgt door een VM

Ik geef toe dat zo'n VM voordelen biedt zoals perfecte cross-platform development, maar ik kan nog niet echt schatten wat voor impact dit heeft, k'neem aan dat voor applicatie's waar snelheid de prioriteit is C(++) nog steeds geschikter is, en Java voor applicatie's waar er eisen worden gesteld die de VM kan leveren zoals Cross-platform.

[mbravenboer]

Apache: Jullie spreken elkaar dus tegen, dit word nog intressant

Beetje ons tegen elkaar uitspelen he? . Ik zal ff uitzoeken wat er precies gebruikt wordt.

Ik geef toe dat zo'n VM voordelen biedt zoals perfecte cross-platform development, maar ik kan nog niet echt schatten wat voor impact dit heeft, k'neem aan dat voor applicatie's waar snelheid de prioriteit is C(++) nog steeds geschikter is, en Java voor applicatie's waar er eisen worden gesteld die de VM kan leveren zoals Cross-platform.

Ach tja, uiteraard heeft een VM een overhead op bepaalde punten, maar het is niet per definitie zo dat een applicatie in een VM trager is dan vergelijkbare code die naar native code is omgezet. Vooral de opstart-tijd is echter wel een probleem. De JVM moet bij het opstarten veel klassen-laden. Deze code wordt allereerst puur geinterpreteerd. Dat is dus zeker langzamer dan het uitvoeren van native code. Zodra er echter 'hotspots' worden ontdekt, gaat de just-in-time compiler (Hotspot genoemd ) delen van de code omzetten naar native code. Hierbij kan hij eventueel run-time optimalisaties toepassen die at compile-time nog niet mogelijk zijn. Dit laatste voordeel is echter nogal toekomst-muziek.

Het is natuurlijk een feit dat een oplossing met Java in een JVM niet voor alle doeleinden de beste is. Het punt is juist dat er heel veel doeleinden zijn waarvoor Java en een JVM wel geschikt zijn. De voordelen van niet-native code en een duidelijke taal worden dan belangrijker.

Overigesn: De Microsoft .NET CLR kent ook een soort bytecode: Intermediate Language. Deze is een beetje te vergelijken met de Java bytecode. Het grote verschil met het Java Platform is dat de gecompileerde 'bytecode' wordt opgeslagen voor later gebruik en dat er in feite nooit wordt geinterpreteerd (voor zover ik weet). Het is dus in feite voor een deel de combinatie van een positief aspect van Java en een oplossing voor het negatieve aspect van Java (maar dan naar mijn mening weer uitgewerkt met nieuwe negatieve aspecten).

[Apache]

Op donderdag 27 december 2001 14:06 schreef mbravenboer het volgende:

[..]

Beetje ons tegen elkaar uitspelen he? . Ik zal ff uitzoeken wat er precies gebruikt wordt.

Ok, s'goed, persoonlijk gok ik op native code omwille van prestatie's omdat zippen toch iets waarbij performance verschil gemeten kan worden.

[..]

Ach tja, uiteraard heeft een VM een overhead op bepaalde punten, maar het is niet per definitie zo dat een applicatie in een VM trager is dan vergelijkbare code die naar native code is omgezet. Vooral de opstart-tijd is echter wel een probleem. De JVM moet bij het opstarten veel klassen-laden. Deze code wordt allereerst puur geinterpreteerd. Dat is dus zeker langzamer dan het uitvoeren van native code. Zodra er echter 'hotspots' worden ontdekt, gaat de just-in-time compiler (Hotspot genoemd ) delen van de code omzetten naar native code. Hierbij kan hij eventueel run-time optimalisaties toepassen die at compile-time nog niet mogelijk zijn. Dit laatste voordeel is echter nogal toekomst-muziek.

dus eigenlijk zal hij bottlenecks of code waar hij kan aan optimaliseren on-the-fly optimaliseren.
Een beetje zoals slecht C programmeren en het oplossen door inline assembler te gebruiken

Het is natuurlijk een feit dat een oplossing met Java in een JVM niet voor alle doeleinden de beste is. Het punt is juist dat er heel veel doeleinden zijn waarvoor Java en een JVM wel geschikt zijn. De voordelen van niet-native code en een duidelijke taal worden dan belangrijker.

Grootste voordeel dat ik zie is natuurlijk platform onafhankelijkheid van java, normale (grafische) applicatie's zullen snel genoeg draaien op de pc's van vandaag.

Applicatie's zoals games, hoewel die screenshots er erg mooi en snel uitzien, zie ik op dit moment nog niet op grote schaal in java geprogged worden

Overigesn: De Microsoft .NET CLR kent ook een soort bytecode: Intermediate Language. Deze is een beetje te vergelijken met de Java bytecode. Het grote verschil met het Java Platform is dat de gecompileerde 'bytecode' wordt opgeslagen voor later gebruik en dat er in feite nooit wordt geinterpreteerd (voor zover ik weet). Het is dus in feite voor een deel de combinatie van een positief aspect van Java en een oplossing voor het negatieve aspect van Java (maar dan naar mijn mening weer uitgewerkt met nieuwe negatieve aspecten).

Wat zijn dan de voordelen bij de VM van microsoft, ik neem aan dat die niet cross-platform word, en het hele .NET principe er ook niet sneller door zal worden.

[mbravenboer]

In 1.3.0 werd zlib-1.1.3 gebruikt. Deze is platformonafhankelijk geimplementeerd in C en dus niet geschreven door Sun.

Waarschijnlijk hebben ze gedacht: er is een goede, snelle cross-platform native implementatie, waarom moeilijk doen...

zlib 1.1.3 is a general purpose data compression library.

The zlib home page is http://www.cdrom.com/pub/infozip/zlib/

[Apache]

Op donderdag 27 december 2001 14:24 schreef mbravenboer het volgende:
In 1.3.0 werd zlib-1.1.3 gebruikt. Deze is platformonafhankelijk geimplementeerd in C en dus niet geschreven door Sun.

Waarschijnlijk hebben ze gedacht: er is een goede, snelle cross-platform native implementatie, waarom moeilijk doen...
[..]

zlib word ook onder linux gebruikt als een 'bijna' standaard library, word dus ook gebruikt voor bvb de http compressie hiet op got

Maar die beslissing werd dus niet genomen vanuit het performance standpunt denk je?

[mbravenboer]

Apache: Ok, s'goed, persoonlijk gok ik op native code omwille van prestatie's omdat zippen toch iets waarbij performance verschil gemeten kan worden.

Ik vermoed dus dat je gok fout is . Ze konden een goede en snelle native implementatie gebruiken, dat hebben ze gedaan .

Wat zijn dan de voordelen bij de VM van microsoft, ik neem aan dat die niet cross-platform word, en het hele .NET principe er ook niet sneller door zal worden.

De .NET IL is wat algemener dan die van Java bytecode, waardoor er meer talen naar toe gecompileerd kunnen worden. De Java bytecode biedt nogal beperkte functionaliteit (maar is wel veiliger). C++ of Haskell zouden bijvoorbeeld nooit op een acceptabele manier naar (de huidige) Java bytecode kunnen worden gecompileerd. In de IL van .NET is dat wel mogelijk. Ook zullen applicaties in de .NET CLR later sneller starten omdat de native code wordt bewaard.

Op zich is de .NET IL dus op bepaalde punten veel interessanter dan Java bytecode. De zuivere CLR zonder libs kan ook uitstekend naar andere platforms worden geport. Het probleem is de libs: die zijn veel te veel verbonden aan het MS Windows Platform. Praktisch zal .NET voorlopig dus niet echt platform-onafhankelijk te gebruiken zijn naar mijn mening.

[mbravenboer]

Apache: Maar die beslissing werd dus niet genomen vanuit het performance standpunt denk je?

Kan ik niet echt over oordelen . Met de nieuwe IO API's in 1.4.0 denk ik niet dat performance de hoofdreden hoeft te zijn om liever een native implementatie te gebruiken. De nieuwe IO API's zijn razendsnel en samen met unsafe code zou compressie heel erg snel kunnen zijn denk ik.

Maar ja, waarom iets opnieuw ontwikkelen als je een bestaande implementatie goed kunt gebruiken? De JVM moet immers aanwezig zijn, dus native code hierin is in principe geen nadeel en voor veel onderdelen zelfs een vereiste (hier uiteraard niet).

[Apache]

Op donderdag 27 december 2001 14:34 schreef mbravenboer het volgende:

[..]

Ik vermoed dus dat je gok fout is . Ze konden een goede en snelle native implementatie gebruiken, dat hebben ze gedaan .

Ik wil een second opion (van Onno )

Nee, maar zlib is een goede keuze voor zo'n dingen, die is er ook al een tijdje en dus doorontwikkeld.

Zijn er nog zo'n dingen die bij java native gebruikt worden?

Blijkbaar wel dus, denk je dat ze met de nieuwe IO api's dan zlib overboord zullen gooien en een eigen implemaentatie zullen schrijven?

[..]

De .NET IL is wat algemener dan die van Java bytecode, waardoor er meer talen naar toe gecompileerd kunnen worden. De Java bytecode biedt nogal beperkte functionaliteit (maar is wel veiliger). C++ of Haskell zouden bijvoorbeeld nooit op een acceptabele manier naar (de huidige) Java bytecode kunnen worden gecompileerd. In de IL van .NET is dat wel mogelijk. Ook zullen applicaties in de .NET CLR later sneller starten omdat de native code wordt bewaard.

Op zich is de .NET IL dus op bepaalde punten veel interessanter dan Java bytecode. De zuivere CLR zonder libs kan ook uitstekend naar andere platforms worden geport. Het probleem is de libs: die zijn veel te veel verbonden aan het MS Windows Platform. Praktisch zal .NET voorlopig dus niet echt platform-onafhankelijk te gebruiken zijn naar mijn mening.

Dus uiteindelijk zal het niet meer uitmaken of je C# of VB.NET schrijft, het word allemaal dezelfde bytecode ...

Aangezien ik besloten heb om mijn windows niet meer te upgraden zie ik kijk wel vanop een afstand wat er gebeurt met het hele .NET gebeuren

[mbravenboer]

Apache: Zijn er nog zo'n dingen die bij java native gebruikt worden?

Wat media stuff geloof ik, verder niet echt complete libraries die ook in Java geimplementeerd hadden kunnen zijn. AWT, IO en dergelijke libs vereisen natuurlijk native code om een brug te slaan tussen Java en het OS.

Blijkbaar wel dus, denk je dat ze met de nieuwe IO api's dan zlib overboord zullen gooien en een eigen implemaentatie zullen schrijven?

Die kans is er wel, er is nogal wat kritiek op de mogelijkheden van de huidige zip lib.

Dus uiteindelijk zal het niet meer uitmaken of je C# of VB.NET schrijft, het word allemaal dezelfde bytecode ...

Yep, maar dat kan bij het Java Platform dus ook: niet alleen Java compileert naar bytecode. .NET IL is alleen algemener, daardoor kan je er wat meer talen naartoe compileren.

Aangezien ik besloten heb om mijn windows niet meer te upgraden zie ik kijk wel vanop een afstand wat er gebeurt met het hele .NET gebeuren

Ik heb op m'n windoos de .NET Framework SDK draaien en het is af en toe toch wel leuk om daar eens in te duiken en te onderzoeken wat de verschillen zijn .

[Apache]

bedankt voor deze verhelderende antwoorden en kijk op de toekomst

Ik denk dat ik maar eens aan de slag ga met enkele java tutorials

[mbravenboer]

Apache: bedankt voor deze verhelderende antwoorden en kijk op de toekomst

Graag gedaan .

Ik denk dat ik maar eens aan de slag ga met enkele java tutorials

Altijd verstandig .