Waarom JRE niet standaard in Windows

[Verwijderd]

Iemand enig idee?

[Verwijderd]

/me zucht

Misschien omdat de makers van Java (Sun) en Windows (Microsoft) niet de dikste vriendjes zijn? En wat heeft Microsoft te winnen ermee? Bedenk dat MS en Sun concurrenten zijn, en al hun werk doen om geld te verdienen en niet om de wereld te verbeteren.

[mbravenboer]

Hehe . Dat zou wel heel merkwaardig zijn. Microsoft en Sun zijn de grootst mogelijke vijanden. Microsoft zal nooit de recentste Java technologie van Sun leveren in hun operating system.

In feite is alles wat ze ooit gedaan hebben met Java slechts bedoelt voor gebruik op MS Windows, op een vrij verplichtende manier: Sun heeft dit altijd als een gevaar voor hun platform-onafhankelijke oplossing gezien. Zodra Java gebonden wordt aan het MS Windows platform zou in hun ogen een groot deel van de kracht verloren gaan.

Overigens gaan enkele grotere OEMs wellicht wel over op het meeleveren van de Sun JRE. Er was al sprake van bij het uitbrengen van MS Windows XP, maar Sun was te laat met een goede JRE voor MS IE. Nu die er is, is er geen enkele reden meer om de zwaar veroudere Microsoft Java VM alsnog mee te leveren (wat enkele OEMs nu dus doen).

[LightYears]

maar helaas geeft deze jre (1.3_1) wel het nadeel van alle sun jvm's mee, het opstarten is zo traag als dikke stront T zal wel niet aan me systeem liggen maar het valt me gewoon op dat de microsoft jvm sneller was / is. (dit zal wel komen omdat het weer es in het geheugen geladen wordt, maar waarom zou sun dat dan niet doen?)

[mbravenboer]

Er wordt bij Sun hard gewerkt aan het draaien van alle applicaties in 1 JVM. Deze kan dan gestart worden als het OS start... Dit zou een hele verbetering zijn voor de opstarttijd, maar uiteraard komen daar een hoop problemen bij kijken...

Op dit moment zijn er al JVMs (die op Mac OS X) die geladen libraries kunnen delen. Dit zal waarschijnlijk iets sneller ook in de 'gewone' JVMs' zitten.

[Onno]

Op vrijdag 28 december 2001 12:47 schreef mbravenboer het volgende:
Op dit moment zijn er al JVMs (die op Mac OS X) die geladen libraries kunnen delen.

Novells JVM voor NetWare doet dat ook al jaren.

Ik weet niet precies hoe het werkt, maar Java wordt maar 1x geladen, voor alle applicaties. Daardoor kan dat ene Java proces ook gewoon alle Java applicaties laten zien die draaien enzo. Is best leuk.

[stylee]

MrX: Bedenk dat MS en Sun concurrenten zijn, en al hun werk doen om geld te verdienen en niet om de wereld te verbeteren.

Mooi gezegd

[mbravenboer]

Onno :Novells JVM voor NetWare doet dat ook al jaren.

Cool, dat wist ik niet .

Wat gebeurt er dan precies? Uit je verhaal begrijp ik dat alle Java applicaties in 1 JVM draaien?

Hoe hebben ze hierbij dan
1. versie-conflicten bij klassen
2. static gegevens (die normaal gesproken dus voor de hele VM gelijk zijn) en
3. security aspecten
opgelost?

Delen van libs is nog vrij eenvoudig, maar alles in 1 JVM vind ik wel spannend .Ben benieuwd hoe dat ik elkaar zit...

[Onno]

Op vrijdag 28 december 2001 13:56 schreef mbravenboer het volgende:
Wat gebeurt er dan precies? Uit je verhaal begrijp ik dat alle Java applicaties in 1 JVM draaien?

Dat weet ik niet precies.

Alles draait in 1 proces, maar of er binnen dat proces meerdere JVMs gemaakt worden, of dat het *echt* een is.. ik kan het je niet vertellen. Ik ben zelf ook wel benieuwd hoe het precies in elkaar zit, maar ik zou niet weten hoe ik daar achter kan komen.

[mbravenboer]

Onno: Ik ben zelf ook wel benieuwd hoe het precies in elkaar zit, maar ik zou niet weten hoe ik daar achter kan komen.

Hum, ik zal eens kijken of ik ergens docs kan vinden .

[mbravenboer]

Ik kan zo snel helemaal niets vinden... Ik vermoed dat hier toch wel iets anders aan de hand zal zijn, want Novell speelt ook helemaal geen rol in de JSR...

Hier is de pagina van de Isolation JSR, misschien wel leuk om te lezen:
http://www.jcp.org/jsr/detail/121.jsp

[mbravenboer]

Dit is de enige site waar JSR 121 en Novell samen worden genoemd: Het JANOS project. Ziet er wel interessant uit.

http://www.cs.utah.edu/flux/janos/

[Verwijderd]

Wat intens stom dat een goede taal als Java maar beperkt gebruikt kan worden doordat MS het niet in Windows wil stoppen. Is dit niet een serieuze bedrijging voor de waarde van Java? Ik bedoel, wie gaat er nou software schrijven waarvoor eerst de JRE geïnstalleerd moet worden? Dat is alleen rendabel als het pakket zo groot is dat 20Mb JRE er ook nog wel bij kan en dan weet ik nog niet eens of je de JRE zomaar mag meeleveren van SUN. Of sla ik nu onzin uit?
Ik ben eens een thread gestart met de vraag of het mogelijk is een Java exe te maken die platformonafhankelijk is door er de minimale JRE benodogdheden in te verpakken.
[topic=313034]
Blijkt een moeilijk verhaal te zijn. Je hebt sowieso die hele 20Mb JRE nodig, toch?

*zucht*

[mbravenboer]

rubenski: Wat intens stom dat een goede taal als Java maar beperkt gebruikt kan worden doordat MS het niet in Windows wil stoppen. Is dit niet een serieuze bedrijging voor de waarde van Java?

Voor de client-side is dat op dit moment inderdaad wel het grootste probleem. Maar ja, er zijn meer dan genoeg blunders gemaakt die ook aan het falen van Java op de desktop bijdragen. Ik zou hiervan echter niet direct de schuld aan Microsoft willen geven.

Ik bedoel, wie gaat er nou software schrijven waarvoor eerst de JRE geïnstalleerd moet worden?

Gelukkig is er ook nog een server-side, waar Java een stuk (zo niet immens) populairder is. Voor de server-side is de installatie van een JRE geen enkel punt. Ook op intranets van bedrijven kan je uitstekend Java applicaties gebruiken omdat je zelf de controle hebt over de geinstalleerde software. Ook voor wat minder general-purpose software voldoet het uitstekend.

Maar een feit is, dat de wereld een stuk aantrekkelijker zou zijn als overal een recente JVM zou zijn. De JVM is de grote kracht van het Java Platform (het veroorzaakt immers alle voordelen), maar gelijk ook een enorm blok aan z'n been.

Blijkt een moeilijk verhaal te zijn. Je hebt sowieso die hele 20Mb JRE nodig, toch?

Nee geen 20 mb. de nieuwste is maar 11 Mb. Oudere versies zijn nog kleiner.

Er wordt overigens ook gewerkt aan het on-demand downloaden van libs zodat de JRE minder log wordt... In de labs van Sun zijn ze er al in geslaagd om de JRE enorm te verkleinen.

[Skinkie]

Op zaterdag 29 december 2001 12:57 schreef rubenski het volgende:
Wat intens stom dat een goede taal als Java maar beperkt gebruikt kan worden doordat MS het niet in Windows wil stoppen. Is dit niet een serieuze bedrijging voor de waarde van Java? Ik bedoel, wie gaat er nou software schrijven waarvoor eerst de JRE geïnstalleerd moet worden? Dat is alleen rendabel als het pakket zo groot is dat 20Mb JRE er ook nog wel bij kan en dan weet ik nog niet eens of je de JRE zomaar mag meeleveren van SUN. Of sla ik nu onzin uit?
Ik ben eens een thread gestart met de vraag of het mogelijk is een Java exe te maken die platformonafhankelijk is door er de minimale JRE benodogdheden in te verpakken.
[topic=313034]
Blijkt een moeilijk verhaal te zijn. Je hebt sowieso die hele 20Mb JRE nodig, toch?

*zucht*

Kijk dat is juist het punt waarom je java gebruikt, om er geen .exe van te maken. Ik weet het... ben er ook geen fan van en programmeer ook liever in behoorlijke talen. Echter na java 1x gecompileerd te hebben met de standaard javac kun je um op ieder platvorm waar jre voor geport is draaien. Dat maakt het universeel. Ben met je eens dat een exe mooier is. Maar JIT (Just In Time) JRE heeft ook wel wat. Persoonlijk zou ik java nooit gebruiken voor een heel groot project, op de pc wel te verstaan. Want waar het ooit voor gemaakt is: Embedded software, is het helemaal perfect voor. Het idiote daaraan is dat ze daarvoor juist weer VB gebruiken, maar gelukkig is Nokia een offencief gestart

[Janoz]

Op vrijdag 28 december 2001 14:28 schreef mbravenboer het volgende:
Dit is de enige site waar JSR 121 en Novell samen worden genoemd: Het JANOS project. Ziet er wel interessant uit.

http://www.cs.utah.edu/flux/janos/

.. Nou.. * Janoz weet iig niks van dat project

[Janoz]

Op zaterdag 29 december 2001 13:28 schreef Skinkie het volgende:

[..]

Kijk dat is juist het punt waarom je java gebruikt, om er geen .exe van te maken. Ik weet het... ben er ook geen fan van en programmeer ook liever in behoorlijke talen. Echter na java 1x gecompileerd te hebben met de standaard javac kun je um op ieder platvorm waar jre voor geport is draaien. Dat maakt het universeel. Ben met je eens dat een exe mooier is. Maar JIT (Just In Time) JRE heeft ook wel wat. Persoonlijk zou ik java nooit gebruiken voor een heel groot project, op de pc wel te verstaan. Want waar het ooit voor gemaakt is: Embedded software, is het helemaal perfect voor. Het idiote daaraan is dat ze daarvoor juist weer VB gebruiken, maar gelukkig is Nokia een offencief gestart

Mwah... voor echt grote projecten zou ik juist eerder voor java kiezen. Doordat Java het memory managment voor je doet (en dan bedoel ik niet alleen de gc) worden alvast een heleboel mogelijke bugs geelimineerd. Daarnaast is OO natuurlijk ideaal waneer je met meerdere mensen aan een groot project werkt.

Trouwens... Een JRE mag je gewoon meeleveren. Ik zie er het probleem ook niet echt van in.. Vergelijk het met DirectX bij spellen.. Bij elk spel wordt er wel een versie hiervan meegeleverd op de CD, en mensen zijn niet te beroerd om ff de nieuwste versie te downloaden..

[Verwijderd]

Even als vergelijking: als je een Visual Basic applicatie uitlevert, lever je daarbij oook nog steeds een stel algemene VB libs mee uit, die alle VB applicaties nodig hebben. Deze zitten meestal in de setup ingepakt, en ik zie niet in waarom je dat niet met de JRE zou doen.

Ja, 20 danwel 11 MB is wel veel, maar als je in de setup een check maakt die de aanwezigheid van JRE controleert en alleen een nieuwe download en installeert als dat nodig is, kan dat prima werken.

[The - DDD]

Jullie hebben toch ook algehoord over de geweldige en eenvoudige compatibiliteit van J.NET (voorheen J++). Je kan heel eenvoudig Sun-Java converteren naar MS-Java. Bla bla bla bla. Bla bla bla bla. Meer PR gelul. Bla bla bla bla. Bla bla bla bla. Bla bla bla bla. Maar dan moet je wel converteren vanaf Sun 1.1 Java. Bla bla bla bla. Bla bla bla bla. Bla bla bla bla.

[grhmpf]

J.Net is niets anders dan programmeren voor .net met een java syntax. Met wat tools kan je bepaalde referenties naar java classes naar de .net classes -of hoe ze ook heten in .net- vertalen. J.Net heeft behalve de syntax eigenlijk niets met java te maken. Om geen problemen met sun te krijgen noemt microsoft het ook "java syntax" (kleine letters) en geen Java of JAVA.

Omdat programma's voor .net wel exe's zijn leveren programmas gemaakt in J.net ook exe's op. Maar je hebt dan feitelijk geen Java programma maar een .net programma.

[Tuinhark]

grhmpf: [knip] Omdat programma's voor .net wel exe's zijn leveren programmas gemaakt in J.net ook exe's op. Maar je hebt dan feitelijk geen Java programma maar een .net programma.

Misschien een beetje OT hoor, maar het is met .NET ook mogelijk om een platform voor Linux te ontwikkelen, right? Wordt je dan als Linux gebruiker ook geacht om die .exe appies te draaien? (In Linux heb je immers het executable file attribuut om aan te geven of een file een 'appie' is.) Ik bedoel dus.. gaan al die .NET appies dan gewoon de .exe file extensie blijven behouden? Ook als ze niet onder Windoos worden gedraaid?

[mbravenboer]

J.Net is niets anders dan programmeren voor .net met een java syntax.

Mwah, die Java syntax valt ook wel weer iets mee . Zoals bij elke taal die in .NET draait hebben ze het zaakje aardig verdraaid om het goed in .NET te laten draaien. Denk aan delegates, properties, attributen. Die kent Java allemaal niet.

J.Net heeft behalve de syntax eigenlijk niets met java te maken.

Zeker wel: de 1.1.4 libraries zijn beschikbaar in .NET.

[The - DDD]

De aanstaande 1.4 JRE/SDK past toch de <applet> tag aan in de web browsers? Je hoeft met 1.4 niet meer zo'n vage object aanroep te doen.

In Tomcat gaat een applet plaatsen trouwens ook cool. Die genereerd de applet tag op basis van de browser van de client. Maar dat gaat dus minder nodig worden.

[mbravenboer]

The - DDD: De aanstaande 1.4 JRE/SDK past toch de <applet> tag aan in de web browsers? Je hoeft met 1.4 niet meer zo'n vage object aanroep te doen.

Mwah ongeveer: de laatste 1.3.1 en 1.4.0 beta 3 pikt nu ook eindelijk de applet tag op in MS Internet Explorer. Eerder maakten deze applets dus geen gebruik van de Java Plugin.

Dit is opeens gedaan na het verwijderen van de MS JVM uit MS Windows XP, maar had natuurlijk veel eerder moeten gebeuren.

De Applet tag is overigens deprecated door het W3C, wat eigenlijk ook wel erg logisch is. Het is dus sowieso beter om hem niet te gebruiken... De HTMLConverter lost dit toch wel netjes voor je op .

[grhmpf]

Mwah, die Java syntax valt ook wel weer iets mee . Zoals bij elke taal die in .NET draait hebben ze het zaakje aardig verdraaid om het goed in .NET te laten draaien. Denk aan delegates, properties, attributen. Die kent Java allemaal niet.

Daarom noemen ze het ook java syntax Het lijkt nog enigzins op Java

Zeker wel: de 1.1.4 libraries zijn beschikbaar in .NET.

Als een layer om de .net libs neem ik aan ?
Zelf ben ik niet echt kapot van .net. Ook bij de platform onafhankelijkheid zet ik nog vraagtekens. Hoe ze exe's gaan runnen op een ander platform zal me een raadsel wezen, maar het meest logische lijkt me een "dotnet -exe programma.exe"

[mbravenboer]

grhmpf: Daarom noemen ze het ook java syntax Het lijkt nog enigzins op Java

Het is zinloos naast C# ... het is een combinatie van een wanhopige poging om oude J++ gebruikers niet al te zeer frustreren en .NET aantrekkelijker te maken voor Java kenners.

Als Java kenners echter niet inzien dat C# eenvoudig is, zou ik ze geeneens op m'n platform willen hebben .

Waarschijnlijk speelt het onderwijs op Universiteiten echter nog een grotere rol: die lui lopen toch altijd achter . (ik bedoelde die laatste opmerking serieuzer dan hij overkomt ).

Als een layer om de .net libs neem ik aan ?

Ik heb de source niet gezien, dus dat weet ik niet. Ik vermoed echter dat dit nog wel aardig tegenvalt (of meevalt, het ligt er maar net aan wat je zou willen ).

Zelf ben ik niet echt kapot van .net. Ook bij de platform onafhankelijkheid zet ik nog vraagtekens. Hoe ze exe's gaan runnen op een ander platform zal me een raadsel wezen, maar het meest logische lijkt me een "dotnet -exe programma.exe"

.NET levert ook helemaal geen exe's, maar Microsoft Intermediate Language assemblies, een variant van Java bytecode. Deze IL is in theorie uitstekend platform-onafhankelijk, dus dat is het probleem niet.

Het grote probleem zijn de libraries n de .NET CLR die veel te veel op het MS Windows platform zijn gericht en enorm lastig te porten zullen zijn naar andere platforms (WinForms, ADO .NET etc).

[The - DDD]

Op zondag 30 december 2001 13:28 schreef mbravenboer het volgende:
De Applet tag is overigens deprecated door het W3C, wat eigenlijk ook wel erg logisch is. Het is dus sowieso beter om hem niet te gebruiken... De HTMLConverter lost dit toch wel netjes voor je op .

Dus het is gewoon het beste om die plug-in te gebruiken. Of mis ik nu iets? (Ben zelf geen Applet guru ) Kan ik me wel voorstellen, want als je plug-in versie te laag of totaal afwezig is, kun je automatisch een download pagina laten popup-en.

[mbravenboer]

The - DDD: Dus het is gewoon het beste om die plug-in te gebruiken. Of mis ik nu iets?

Nee hoor, dat klopt precies . W3C adviseerd de applet tag niet meer te gebruiken. Dit is overigens al zo in HTML 4.0, dus geen nieuwigheid in XHTML.

Zie hier:
http://www.w3.org/TR/REC-html40-971218/struct/objects.html#edef-APPLET

APPLET is deprecated (with all its attributes) in favor of OBJECT.

Ik heb ff de voorbeelden overgenomen:

code:

<APPLET code="Bubbles.class" width="500" height="500">
Java applet that draws animated bubbles.
</APPLET>

Moet volgens het W3C worden:

code:

<OBJECT codetype="application/java"
      classid="java:Bubbles.class"
      width="500" height="500">
Java applet that draws animated bubbles.
</OBJECT>

Je kan hier:
http://java.sun.com/products/plugin/1.3/docs/tags.html
de docs van Sun vinden waarin alle (ja: alle ) mogelijke varianten worden uitgelegd. Ook staat hier beschreven hoe je naar een specifieke versie van Java moet verwijzen.

Ik zou in de praktijk denk ik maar de HTMLConverter gebruiken als je zeker wilt zijn dat het overal werkt. Als je netjes wilt zijn, kan je het het beste netjes op de XHTML manier doen.

[grhmpf]

Op zondag 30 december 2001 13:50 schreef mbravenboer het volgende:

[..]

.NET levert ook helemaal geen exe's, maar Microsoft Intermediate Language assemblies, een variant van Java bytecode. Deze IL is in theorie uitstekend platform-onafhankelijk, dus dat is het probleem niet.

Dat er in die exe's eigenlijk die IL zit dat snap ik Kennelijk hebben ze op windows wel iets gebakken zodat .exe native worden uitvoerd als het geen .net code is en anders door de .net runtime. Het lijkt me sterk dat ze platform afhankelijke code in die .exe's proppen als ze platform onafhankelijkheid propaganderen. Als ik het allemaal goed heb begrepen zijn die exe's gewoon het equivalent van .jars alleen heet het dan een assembly. Vandaar (om de parallel nog maar even door te trekken) kwam ik op m'n "./dotnet -net prog.exe". Tenzij andere OS-sen ook native .exe's door hun .net runtime gaan draaien.

Het grote probleem zijn de libraries n de .NET CLR die veel te veel op het MS Windows platform zijn gericht en enorm lastig te porten zullen zijn naar andere platforms (WinForms, ADO .NET etc).

Inderdaad, daarom ben ik nog sceptisch over die platform onafhankelijkheid van .net. In theorie zal het allemaal wel, maar probeer al die op windows gerichte zooi maar eens te porten. DotNet is niet echt begonnen als een platform onafhankelijke taal, maar als een taal die windows programmeren een stuk makkelijker zal maken. Omdat ze common libs gebruiken en IL is het in theorie inderdaad prima te porten

[mbravenboer]

Dit is dus trouwens de XHTML code:

code:

<object  classid="java:com.package.ClassName.class"
       width="400"
       height="500" 
       codetype="application/java">

   <param name="label" value="Waarde van label"/>
   <param name="blaat" value="Waarde van blaat"/>

Sukkel! Je hebt geen Java Virtual Machine!

</object>

Optioneel kan je nog een codebase opnemen

Dit is het mime-type voor 1.3:

code:

application/x-java-applet;version=1.3

hier kan je een lange lijst van types vinden:

http://home.netscape.com/plugins/get_java.html

Hier staat het een en ander ook nog wat beter:

http://java.sun.com/j2se/1.3/docs/tooldocs/appletviewertags.html

[mbravenboer]

De documentatie over het opnemen van applets zuigt trouwens wel enorm. Op de sun-site staan op verschillende plekken allemaal verschillende oplossingen. Het is gewoon een ongelofelijke zooi .

[roelio]

agree, is er niet 1 oplossing waarmee het allemaal te fixen is? gewoon aan de w3c specs houden?

[mbravenboer]

limoentje: agree, is er niet 1 oplossing waarmee het allemaal te fixen is? gewoon aan de w3c specs houden?

Tja, de HTMLConverter in de Java 2 SDK levert een oplossing in de vorm van 'we houden gewoon rekening met alle browsers en willen percee Java 2'.

Als je gewoon de default JVM wilt gebruiken is de w3c aanbeveling denk ik het beste.

Sowieso zou ik geen applet tag gebruiken, maar helaas moet je dan kiezen voor de object tag, die oude Netscapes niet ondersteunen. HTMLConverter houdt daar rekening mee.

Als je Applet Java 2 vereist zou en je XHTML wilt gebruiken is de bovenstaande XHTML oplossingen met het specifiekere type denk ik de beste oplossing.

[roelio]

maar oude netscapes dan praten we neem ik aan over versie 3.x en eerder, persoonlijk zou ik daar geen rekening mee houden omdat die teveel andere "standaarden" ook niet ondersteunen... of snapt NS 4.x er ook nix van?

[mbravenboer]

limoentje: of snapt NS 4.x er ook nix van?

Als ik het goed heb eet die inderdaad geen object tag, maar wel embed. Dat weet ik alleen niet zeker, mijn laatste applet is ook al weer een tijd geleden .

[chem]

heeft er iemand een voorbeeld van een vrij zware applet/servlet?

ben toch benieuwd hoe dat onder OS X presteert

[roelio]

applet of servlet, maakt nogwel wat verschil

[chem]

Op zondag 30 december 2001 17:42 schreef limoentje het volgende:
applet of servlet, maakt nogwel wat verschil

niet voor de installatie

tomcat is zo geinstalleerd...

[mbravenboer]

chem: ben toch benieuwd hoe dat onder OS X presteert

Ik ook wel . Ik heb nog wel een wat pittigere Swing applicatie liggen die cross-platform is (althans, getest op Linux en MS Windows). Die zou je dus zo moeten kunnen draaien. Bovendien kan je de Look and Feel instellen en daar ben ik in het bijzonder benieuwd naar . Mac OS X zou dacht ik native componenten moeten kunnen gebruiken en dat lijkt me erg yummie .

[mbravenboer]

Trouwens, je kunt ook wel de SwingSet in de SDK draaien. Dat is de zwaarst denkbare Swing applicatie . Als die enigszins soepel draait, werke alle andere Swing apps als een speer .

[chem]

Op zondag 30 december 2001 18:44 schreef mbravenboer het volgende:

[..]

Ik ook wel . Ik heb nog wel een wat pittigere Swing applicatie liggen die cross-platform is (althans, getest op Linux en MS Windows). Die zou je dus zo moeten kunnen draaien. Bovendien kan je de Look and Feel instellen en daar ben ik in het bijzonder benieuwd naar . Mac OS X zou dacht ik native componenten moeten kunnen gebruiken en dat lijkt me erg yummie .

geef maar...

[chem]

Ik heb net moneydance ff geprobeerd (www.moneydance.com) en dat draai als de wiedeweerga... geen verschil tussen deze 'swing' app en een andere app... yeah