[java] java en exe`s

[Alarmnummer]

Eindelijk maar toch is er weer een:

http://jsmooth.sourceforge.net/

Ik heb hem zelf nog niet getest, maar dit is gewoon superhandig. Het is alleen wel jammer dat ik nog geen anttask ervoor heb ontdekt.

[ari3]

Nah, Dit soort dingen zuigen... Het is beter om een installer te hebben die de JRE download, installeerd en configureerd als er nog geen JVM aanwezig is op het systeem.

[idee]Wat we eigenlijk nodig hebben is dat er altijd een (pooled) JVM draait in het OS. Dan starten Java applicaties tenminste ook snel op. Een beetje zoals m$ altijd de DLL in het geheugen heeft zodat IE snel kan opstarten... [/idee]

[Alarmnummer]

ari3 schreef op 05 September 2003 @ 11:10:
Nah, Dit soort dingen zuigen... Het is beter om een installer te hebben die de JRE download, installeerd en configureerd als er nog geen JVM aanwezig is op het systeem.

Ik ben het met je eens dat het idd vervelend is als de gebruiker nog helemaal geen vm heeft geinstalleerd op zijn machine. Maar de exe`s die gegenereerd worden geven tenminste wel aan dat een vm niet geinstalleerd is, en waar die gedownload kan worden:

When no VM is available, it provides feed-back to the users, and can launch the default web browser to an URL that explains how to download a Java VM.

Ik vind dit toch een goed begin. En verder is dat ook niet de taak van de exe, maar van de installer. De installer moet ervoor zorgen dat java geinstalleerd gaat worden, en de installer moet zelf ook zonder java draaien

Wat we eigenlijk nodig hebben is dat er altijd een (pooled) JVM draait in het OS. Dan starten Java applicaties tenminste ook snel op. Een beetje zoals m$ altijd de DLL in het geheugen heeft zodat IE snel kan opstarten... [/idee]

Weet je al hoe lang deze request open staat? Ze zouden bij jdk1.5 eindelijk een shared vm toevoegen, maar uiteindelijk is dit niet door gegaan. Dit is idd een enorm minpunt aan java en ze zouden eigelijk een voorbeeld moeten nemen aan de mac (waar ze het dus al lang hebben).

[curry684]

ari3 schreef op 05 September 2003 @ 11:10:
m$

Het bedrijf waar Steve Ballmer CEO is heet Microsoft en kort je af met MS. Termen als M$ en Mickeysoft zijn enkel kinderachtige verbasteringen en voegen niets toe. Dus ajb niet doen. Ditzelfde geldt ook voor Linsux etc. Een gefundeerde discussie over pro en cons mag natuurlijk, maar dit is enkel flamen.

.addendum door .oisyn: en die discussie hoort dan natuurlijk in een andere draad

[ Voor 9% gewijzigd door .oisyn op 05-09-2003 13:24 ]

[Verwijderd]

Ik gebruik de native code builder van JBuilder (9 geloof ik) werkt prima en als student kan ik gratis gebruik maken van JBuilder

[.oisyn]

Maar hoe gaat die om met niet aanwezige VM's enzo?

[Soultaker]

Leuk is dat; heb je een platformonafhankelijke applicatie en dan wordt 'ie in een platformafhankelijke wrapper gestopt! Als je toch platformspecifieke releases maakt, had je dan niet gelijk een native applicatie (desnoods in een portable taal) kunnen schrijven?

Verder vraag ik me af hoe zo'n applicatie alternatieve VM's herkent; op de JSmooth website zie ik alleen ondersteuning voor de Sun en Microsoft VM's.

Al met al vind ik het dus alleen maar een beetje hackwerk om in een aantal situaties een aantal luxeproblemen op te lossen. Een mooie toevoeging vind ik het dus absoluut niet.

[alienfruit]

Ik gebruik de native code builder van JBuilder (9 geloof ik) werkt prima en als student kan ik gratis gebruik maken van JBuilder

Hmm. Dan ben ik een andere student dan jij denk ik

Overigens die native-code functie in JBuilder 9 werkt perfect, het is in het beginsel gemaakt voor JBuilder IDE zelf en uiteindelijk in versie 9 ook als functie verschenen in JBuilder er zijn nog wel wat problemen mee.

[Alarmnummer]

Soultaker schreef op 05 September 2003 @ 17:51:
Leuk is dat; heb je een platformonafhankelijke applicatie en dan wordt 'ie in een platformafhankelijke wrapper gestopt! Als je toch platformspecifieke releases maakt, had je dan niet gelijk een native applicatie (desnoods in een portable taal) kunnen schrijven?

Ik had eerlijk gezegd zo`n antwoord niet van je verwacht Soultaker. De jar die je wrapt voor windows die kan natuurlijk ook voor andere platformen gebruikt worden. Het is alleen de opstarter die platform specifiek is, niet de rest van het systeem.

Misschien maak je er voor linux even een mooi scriptje bij, zodat het daar ook eenvoudig te draaien is. Met een goed ANT-script zou het geen enkel problem mogen zijn en zou je eenvoudig een build windows/build rest kunnen doen.

Verder is het grootste deel van de desktop ossen windows en ik heb persoonlijk het volgende met grafische applicaties -> fuck platform onafhankelijkheid. Maak gebruik van de compontenten die je systeem je aanbied en gaat niet eewig liggen worstelen met halfgebakken oplossingen.

Al met al vind ik het dus alleen maar een beetje hackwerk om in een aantal situaties een aantal luxeproblemen op te lossen. Een mooie toevoeging vind ik het dus absoluut niet.

Het probleem aan de oplossing die sun aanbied is dat niemand een jar herkend als opstartbaar bestand (althans niet de gemiddelde gebruiker). Daarom zie ik ook enorm veel java applicaties met een .sh en .bat opstart script. Je kan nog een stapje verder gaan en gewoon een exe genereren voor het opstarten. En wat maakt het uit als de jar gewrapped is, of in het andere geval: als de exe niets anders is dan een opstart 'script'. Voor de gemiddelde windows gebruiker (en niet voor de computer goden zoals wij *ahum*) is dit herkenbaar en java valt dan veel minder snel door de mand.

Ik moet zelfs toegeven dat ik weiger java applicaties te draaien onder windows, omdat het er altijd anders uitziet, altijd anders werk en vaak vervelende krengen zijn om op te starten.

Als java succes wil hebben aan de desktop kant, moeten ze juist meer van dit soort componenten gaan maken.

[ Voor 22% gewijzigd door Alarmnummer op 08-09-2003 09:15 ]

[Verwijderd]

Alarmnummer schreef op 08 September 2003 @ 09:09:
[...]

Ik moet zelfs toegeven dat ik weiger java applicaties te draaien onder windows, omdat het er altijd anders uitziet, altijd anders werk en vaak vervelende krengen zijn om op te starten.

Als java succes wil hebben aan de desktop kant, moeten ze juist meer van dit soort componenten gaan maken.

Hier ben ik helemaal mee eens!!

Aangezien ik java ontwikkelaar ben heb ik nog wel een url voor iedereen die wat meer wil weten over (native) compilers van java:
http://www.geocities.com/marcoschmidt.geo/jcomp.html

Ik zelf heb Excelsior JET downgeload om een .exe te krijgen voor mijn apps, maar helaas is het mij nog niet helemaal gelukt om dit draaiend te krijgen

[Soultaker]

Alarmnummer schreef op 08 september 2003 @ 09:09:
Ik had eerlijk gezegd zo`n antwoord niet van je verwacht Soultaker. De jar die je wrapt voor windows die kan natuurlijk ook voor andere platformen gebruikt worden. Het is alleen de opstarter die platform specifiek is, niet de rest van het systeem.

Accoord; dat bezwaar is misschien niet terecht.

Het probleem aan de oplossing die sun aanbied is dat niemand een jar herkend als opstartbaar bestand (althans niet de gemiddelde gebruiker). Daarom zie ik ook enorm veel java applicaties met een .sh en .bat opstart script. Je kan nog een stapje verder gaan en gewoon een exe genereren voor het opstarten. En wat maakt het uit als de jar gewrapped is, of in het andere geval: als de exe niets anders is dan een opstart 'script'. Voor de gemiddelde windows gebruiker (en niet voor de computer goden zoals wij *ahum*) is dit herkenbaar en java valt dan veel minder snel door de mand.

Het maakt mij wel uit, want ik kan me al levendig voorstellen dat zo'n gewrapte applicatie niet op te starten is als je een alternatieve VM gebruikt. Die wordt dan niet herkend en dan moet ik per se de Sun VM (of een andere ondersteunde VM) gaan installeren omdat die applicatie vindt dat 'ie niet werkt met mijn eigen VM (wat zou kunnen, maar niet bij voorbaat waar is). Met een .bat filetje kun je dat soort restricties er nog wel uit hacken (al is het ook dan irritant) maar met een .exe file is dat allemaal veel lastiger.

Overigens start ik al tijden mijn .jar files door er gewoon op te klikken in explorer of vanuit het run/start menu, net zoals ik .exe files, .com files, .py files en .bat files kan starten. Dat de gemiddelde gebruiker dat niet kan lijkt me sterk; bij een default installtie krijg de gebruiker niet eens bestandsextenties te zien, dus kan 'ie een .jar file net zo goed aan klikken als een .exe file (zeker als de omschrijving iets van "Java Applicatie" is).

Ik vraag me dan ook af waarom een "domme" (of laten we "gemiddelde") gebruiker die .jar file zou moeten kunnen uitvoeren, als een installer al gewoon snelkoppelingen in het start menu kan plaatsen.

Verder is het grootste deel van de desktop ossen windows en ik heb persoonlijk het volgende met grafische applicaties -> fuck platform onafhankelijkheid. Maak gebruik van de compontenten die je systeem je aanbied en gaat niet eewig liggen worstelen met halfgebakken oplossingen. [...]
Ik moet zelfs toegeven dat ik weiger java applicaties te draaien onder windows, omdat het er altijd anders uitziet, altijd anders werk en vaak vervelende krengen zijn om op te starten.

Als java succes wil hebben aan de desktop kant, moeten ze juist meer van dit soort componenten gaan maken.

Nu doe je net alsof het noodzakelijk is dat Java voor alle soorten gebruikersapplicaties wordt gebruikt. Ik betwijfel of dat de juiste instelling is: voor platformafhankelijke systemen bestaan immers allang veel betere tools. Dat blijkt wel uit het feit dat je zelf ook constateert: aan het gebruik van Java voor platformspecifieke toepassingen kleven veel nadelen. Ten dele zijn die veroorzaakt door grove fouten in het beleid van Sun, maar voor een groot deel worden die ook veroorzaakt door het feit dat Java specifiek ontworpen is om een onafhankelijk, vaststaand ontwikkelplatform te bieden.

Ik vind dan ook dat je onderscheid moet maken tussen beperkingen die een logisch gevolg zijn van de ontwerpdoelstelling en beperkingen die het gevolg zijn van slechte ontwerpbeslissingen. De laatste wil je waarschijnlijk corrigeren; de eerste waarschijnlijk niet. In de tweede categorie valt wat mij betreft het ontwerp van de GUI API's, in de eerste categorie de eis dat binaries platformafhankelijk zijn.

[Alarmnummer]

Soultaker schreef op 09 September 2003 @ 11:14:
Het maakt mij wel uit, want ik kan me al levendig voorstellen dat zo'n gewrapte applicatie niet op te starten is als je een alternatieve VM gebruikt. Die wordt dan niet herkend en dan moet ik per se de Sun VM (of een andere ondersteunde VM) gaan installeren omdat die applicatie vindt dat 'ie niet werkt met mijn eigen VM (wat zou kunnen, maar niet bij voorbaat waar is). Met een .bat filetje kun je dat soort restricties er nog wel uit hacken (al is het ook dan irritant) maar met een .exe file is dat allemaal veel lastiger.

Het is idd een minput (en behoorlijk grote zelfs) dat je alleen een vm van een bepaalde fabrikant zou kunnen gebruiken. Daar heb je gelijk in.

Overigens start ik al tijden mijn .jar files door er gewoon op te klikken in explorer of vanuit het run/start menu, net zoals ik .exe files, .com files, .py files en .bat files kan starten. Dat de gemiddelde gebruiker dat niet kan lijkt me sterk; bij een default installtie krijg de gebruiker niet eens bestandsextenties te zien, dus kan 'ie een .jar file net zo goed aan klikken als een .exe file (zeker als de omschrijving iets van "Java Applicatie" is).

Tja.. het is wel de klacht die ik binnenkrijg. En ik heb er zelf ook vaak gedonder mee, en ben daarom ook blij als ik een batfile zie staan om een applicatie op te starten.

Ik vind dan ook dat je onderscheid moet maken tussen beperkingen die een logisch gevolg zijn van de ontwerpdoelstelling en beperkingen die het gevolg zijn van slechte ontwerpbeslissingen. De laatste wil je waarschijnlijk corrigeren; de eerste waarschijnlijk niet. In de tweede categorie valt wat mij betreft het ontwerp van de GUI API's, in de eerste categorie de eis dat binaries platformafhankelijk zijn.

(ik neem aan dat je het andersom bedoelt)

Waar ik als developer mee zit zijn toch voornamelijk windows gebruikers. En wat maakt het uit als je een platform specifieke exe wrapper genereerd, als je meteen ook een distributie genereerd voor een ander platform? Ok... misschien dat de vm het niet leuk vind dat de jar gewrapped is (daarom ben ik dus ook voor opstart exe`s vergelijkbaar met een opstart script).

[kortom]
Ik zie dus het liefste een exe opstart script. Het zelfde als een batfile, maar dan een exe. Exe`s staat voor normale gebruikers nu eenmaal serieuzer dan batfiles.

[ Voor 5% gewijzigd door Alarmnummer op 09-09-2003 12:18 ]

[Soultaker]

Alarmnummer schreef op 09 September 2003 @ 12:16:
(ik neem aan dat je het andersom bedoelt)

Eigenlijk bedoel ik het precies zoals het er staat, maar ik kan me voorstellen dat de tekst door het afwisselende gebruik van "laatste, eerste" en "eerste, tweede categorie" op een verkeerde manier uitgelegd zou kunnen worden.

Waar ik als developer mee zit zijn toch voornamelijk windows gebruikers. En wat maakt het uit als je een platform specifieke exe wrapper genereerd, als je meteen ook een distributie genereerd voor een ander platform? Ok... misschien dat de vm het niet leuk vind dat de jar gewrapped is (daarom ben ik dus ook voor opstart exe`s vergelijkbaar met een opstart script).

Ik vind het niet per defintie nuttig dat je een principiele eigenschap van een Java applicatie, namelijk de platformonafhankelijkheid van de binaries, wegneemt. Waar heb je dan nog je just-in-time compilatie voor? Nergens eigenlijk; je .exe is toch al Wintel-only, dus dan kun je je Java code ook wel alvast precompilen, of beter nog: native compilen, zodat je helemaal geen VM meer nodig hebt! Feitelijk hou je nu namelijk de nadelen van het Java platform in stand (traag laden van klassen, bijvoorbeeld) terwijl je een voordeel (platformonafhankelijkheid) inlevert.

Ik zie dus het liefste een exe opstart script. Het zelfde als een batfile, maar dan een exe. Exe`s staat voor normale gebruikers nu eenmaal serieuzer dan batfiles.

Je kunt je afvragen of je je vanuit technisch oogpunt veel moet aantrekken van wat een gebruiker die geen idee heeft wat Java is, allemaal wel of niet "serieus neemt". Ik kan me voorstellen dat hier wel commerciele aspecten aan zitten, maar daar heb ik als informaticus niets mee te maken.

Als het argument is dat de gebruiker het nu eenmaal zus of zo wil (wat in de praktijk erg vaak voorkomt) dan kan ik me voorstellen dat het prettig is om een middel als JSmooth ter beschikking te hebben, maar vanuit een technisch oogpunt levert het dan nog geen voordeel. Dat laatste is ook eigenlijk mijn punt, terwijl ik het met je eens ben dat het in een praktische situatie JSmooth een nuttige tool kan zijn.

Vanuit een technisch oogpunt is een .bat file handiger dan een .exe, omdat deze om te beginnen onafhankelijk is van CPU-architectuur (in tegenstelling tot .exe's) en bovendien (belangrijker) naast de losse .jar file bestaat, waardoor een gebruiker altijd nog die .jar file kan aanklikken.