Et sidste spørgsmål - Skal nok sætte pointene op ;)
Swing er en grafisk brugerflade til Java Applikationer, men den bruger temmelig meget hukommelse.. findes der andre grafiske brugerflade, man bør bygge sin applikation på?
Native executable i JB7 er ikke konvertering af java byte kode til native. Det er en EXE fil som indeholder jar-filer etc. og som starter JVM og lader den eksekvere Java byte kode fra jar-filer etc..
Der er ingen performance fordele eller andet ved den process. Det er en nem måde at distribuere sit program på til folk der ikke ved hvad classpath er for noget.
I og med at JBuilder kan pakke JVM'en med ned i den eksekverbare betyder det at JBuilder kan generere native eksekverbare der kan distribueres til systemer hvorpå der ikke er installeret en jvm.
Desuden er en eksekverbar ikke nødvendigvis en EXE fil.
Hvad du får er fordelen af kun at skulle distribuere dit program (optimalt; én fil) hvilket er en kæmpe fordel. Det er ikke nødvendigt at basere sig på en evt. allerede installeret JVM som så naturligvis er i den forkerte version, for slet ikke at nævne det evindelige problem med klassepadder.
CLASSPATH + JAR er DLL+PATH (DLL_HELL) bare i en anden indpakning).
Det er en praktisk feature til visse environments.
Classpath har en god ting sammenlignet med DLL (før .NET), man smider dem ikke et "system" directory men sammen med applikationen og man kan sagtens have forskellige applikationer bruge forskellige versioner af den samme.
Visse applikationer (Tomcat for at nævne en enkelt) kræver at JAR filer der skal loades ved opstart ligger i en bestemt folder, i så fald kan du ikke bruge forskellige versioner af det samme arkiv, præcis som DLL er og system32. Teoretisk er det nemmere at håndtere JAR filer, i praksis er det min erfaring at problemerne er de samme - ikke uventet da begge teknologier forsøger at løse det samme problem.
.Net løser jo heller ikke DLL problematikken, nu skal du som udgangspunkt bare lægge dine 'private' DLL'er lokalt istedet for globalt.
At en applikation evt. forventer at JAR filer ligger i et bestemt directory forhindre da ikke på nogen måde at forskellige applikationer bruger forskellige versioner af en JAR filer.
Så jeg kan slet ikke følge dit argument !
Nu er jeg ikke .NET ekspert, men så vidt jeg ved indeholder .NET to nye ting: - det er ikke længere comme il faut at opdatere globale DLL'ere (de kommer som lokale for applikationen) - der kan være 2 versioner af samme DLL i hukommelsen samtidigt Tilsammen gør det at applikationer kan installeres og køres uafhængigt af hinanden.
DLL hell er ikke at sætte path. DLL hell er konfliktende versioner af de samme DLL'er.
Det er en misforståelse at DLL_HELL udelukkende drejer sig om DLL'er i system32 kataloget - Pathen er i høj grad en del af problemet.
Når en app. beder win32 om at loade en dll så kigger systemet først efter filen i applikationens work dir, derefter i system32 og sidst i pathen, system32 er derfor i denne sammenhæng at betragte som roden af pathen.
konfliktende DLL'er kan derfor findes alle steder i pathen, ikke kun i system32.
Det er korrekt at parksis for installation af DLL'er er ændret i .Net. At Microsoft nu som udgangspunkt installerer DLL'er lokalt betyder bare at du på din maskine skal have en håndfuld msvcrt.dll'er installeret hist og pist på din maskine.
Problemet med flere versioner af jar filer og flere classpathen er præcis det samme - for igen at nævne tomcat så prøv at få denne java applikation igang med to forskellige versioner af myslqs jdbc driver.
At .NET bruger lokale DLL'ere betyder at applikationer bliver totalt uafhængige af hinanden og at DLL problemet er løst. Ja det koster lidt disk-space. But so what.
Og problemet med 2 versioner af samme JAR fil er løst i Java. Det hedder classloaders. Og hvis man kan stole på Tomcat dokumentationen, så er det også løst i Tomcat. Er det nemt med de classloaders ? Nej, men hvis folk vil bruge 2 forskellige versioner af samme software i deres applikation, så må de sætte sig ned og læse lidt !
classes12.jar og classes111.jar er to forskellige versioner af oracles thin jdbc driver.
Java applikation a benytter sig af classes12.jar Java applikation b benytter sig af classes111.jar Begge applikationer benytter sig af system CLASSPATH.
Applikation a duer ikke længere fordi classes111.jar kommer før classes12.jar i CP. Præcis samme opførsel som DLL_HELL.
Nu vil du argumentere at app a og app b ikke skal benytte systemets CLASS_PATH, men det er et faktum at det gør en stor del af dagens java applikationer.
Og nej, det er ikke løst i Tomcat hvis det er nødvendigt at jar filerne loades af Tomcat ved opstart - d.v.s før web-applikationerne.
Det lyder rigtigt: hvis man vil validere brugere i 2 forskellige web-applikationer mod 2 forskellige database som kræver samme JDBC driver i forskellig version, så har man nok et problem.
Men at sammenligne det problem med DLL'er i system32 directories finder jeg ret malplaceret. Det ene er en meget specielt tilfælde (hvor det altså virker perfekt i de normale tilfælde). Det andet er normal tilfældet.
Jeg har aldrig mødt en applikation som definerede en classloader der kun kiggede i system classpath.
Hvilket på almindeligt dansk betyder, at det står folk frit for at rette startup scriptet til at bruge en eksplicit classpath i java kommandoen.
Iøvrigt synes jeg at de fleste apps idag kommer med det i startup scripts.
System CLASSPATH var langt hen af vejen et 90'er problem.
Hvis jeg havde behovet for at løse den problem-stilling:
#Det lyder rigtigt: hvis man vil validere brugere i 2 forskellige #web-applikationer mod 2 forskellige database som kræver samme JDBC #driver i forskellig version, så har man nok et problem.
Så ville jeg nok vælge at køre 2 instanser af Tomcat på port 8009 og 8010, og så lade Apache connecte til to forskellige porte for de to forskellige apps.
Det vil kræve lidt arbejde med konfigurationen, men det må man leve med, når man vil lave noget så specielt.
Tomcat var bare et (åbenbart uheldigt valgt ?!) eksempel på at forskellige versioner af jar filer giver problemer.
Og nej system CLASSPATH er stadig et nærværende problem, det forsvandt ikke fordi vi rundede 2000.
At bede almindelige brugere om at ændre i startup scriptet er uholdbart, det er de slet ikke klædt på til.
"når man vil lave noget så specielt" ? De fleste webapplikationer har et brugerbegreb, hvis du vil bruge realms så er det et almindeligt forekommende problem.
Spørgsmålet gik egentlig på om JB kan lave exe filer ud af min code, til det er svaret ja. Godt nok i form af en indpakning af dine jar fil(er), men det finder jeg underordnet.
Det er ganske rigtigt almindeligt at validere brugere. Men det er jo totalt irrelevant for diskusionen.
Du påstår jo at det er almindeligt at have 2+ web-applikationer som validerer mod 2+ databaser med samme JDBC driver med forskellig version i samme instans af Tomcat !
Jeg tror du misforstår mig med vilje for at kunne fortsætte din argumentation. Det er livet altså for kort til.
Forskellige versioner af jar filer giver samme problem som forskellige versioner af dll'er i min verden, hvis det ikke gør det i din verden så tilykke med det.
Altså: * for at have et problem med 2 forskellige versioner af samme jar, så må man nødvendigvis have 2 forskellige versioner af samme jar (det kan jeg ikke have misforstået) * Tomcat er nævnt 10+ gange (det tror jeg heller ikke jeg har misforstået) * hvis ikke de skal bruges til validering så putter man dem bare i app'ernes lib og så har man ikke noget problem - altså må det være fordi de skal bruges til validering (det synes jeg heller ikke at jeg kan have misfortsået)
Jeg mener så at det setup er både usædvaneligt og uhensigtsmæssigt.
Det står enhver frit for selv at vurdere om de er enige.
Du er meget velkommen til at tro, at 1 Tomcat instans med 2 forskellige versioner af samme JDBC driver som begge bruges til validering er almindeligt.
Det er det ikke.
Jeg har fuldt ud accepteret, at hvis man tænker sig en lille smule om, når man laver Java, så har man aldrig problemer med forskellige versioner af samme jar fil.
Du er meget velkommen til at fortsætte med den Tomcat konfiguration, anbringe dine utility libraries i system CLASSPATH etc. og leve med problemerne.
Java har løsninger. Men det er op til folk selv om man vil bruge dem.
Jeg husker ikke jeg har postet et spørgsmål, endnu mindre du har postet et svar jeg ville/kunne bruge til noget som helst.
Hvis jeg havde problemer med Tomcat jeg ikke selv kunne løse ville jeg da naturligvis poste et spørgsmål.
Du ser kun problemet fra udviklerens/superbrugerens synspunkt, der kan man sagtens forvente problemerne vil/kan blive løst. Det er en anden snak når applikationerne rykker ud på slutbruger maskinerne.
Så jeg kan konkludere at: - du mener ikke at Tomcat har et problem med forskellige versioner af samme JAR fil som du ikke kan løse men at du alligevel mener at det er et stort problem ?
Tomcat var et,som tidligere nævnt, (åbenbart uheldigt valgt !?) eksempel.
Du springer rundt i argumentationen, man kunne godt mistænke dig for at besidde en konsulent stilling.
Problemet var jar filer + CP er analogt med Path+DLL. Hvad i alverden har det med tynde klienter, tomcat og koden på server at gøre, det er jo helt hen i vejret.
#Problemet var jar filer + CP er analogt med Path+DLL.
Og det er lige præcist det det ikke er.
Fordi: * forskellige JVM kører uafhængigt af hinanden * JVM har classloader hieraki hvilket gør at foskellige komponenter indenfor JVM kan køre uafhængigt af hinanden (hvis man følger god praksis for design)
Og det eneste eksempel du kunne komme op med for at argumentere mod det var meget meget specielt.
classes12.jar og classes111.jar er to forskellige versioner af oracles thin jdbc driver.
Java applikation a benytter sig af classes12.jar Java applikation b benytter sig af classes111.jar Begge applikationer benytter sig af system CLASSPATH.
Applikation a duer ikke længere fordi classes111.jar kommer før classes12.jar i CP
#Hvad i alverden har det med tynde klienter, tomcat og koden på server at gøre, det er jo helt hen i vejret.
Du bragte selv emnet på bane !
Du skrev: #Du ser kun problemet fra udviklerens/superbrugerens synspunkt, der kan man #sagtens forvente problemerne vil/kan blive løst. Det er en anden snak når #applikationerne rykker ud på slutbruger maskinerne.
Jeg svarede: #Og den nemmeste måde at løse slutbruger problemet på er: Tomcat ! #Eller lidt mere generelt: tynde klienter og koden på server.
Du kan være uenig med mig i at tynde klienter og kode på serveren er løsningen på dette problem.
Men hvis ikke du vil give mig ret i at det er en almndelig anbefalet løsning på problemet, så har du misset lidt de sidste 10 år.
Enig, men sådan bliver applikationerne desværre ikke installeret. Det er jo deri hele problemet ligger.
Der er heller ikke krav om at du absolut pladrer dine dll'er ned i system32, det er ligeså fint at lægge dem lokalt ved applikationen (ja det kunne man også før .Net), faktum er bare at en helt masse applikationer lægger deres DLL'er globalt.
Det samme gør sig gældende for DLL problematikken, leverandøren kan lægge sind DLL'er lokalt, eller man kan "bare" kopiere de korrekte DLL'er hen i applikationens home katalog. Problemerne er sammenlignlige
Der er både arkitektoniske forskelle: * før .NET kan du kun loade 1 DLL med et bestemt navn * DLL navne angives i EXE filen - og det er noget nemmere at rette i en BAT-fil end patche en EXE så man kan ikke "bare" rette til.
Og praktiske forskelle: * ingen Java installationer jeg har set erstatter filer i en eksisternde JDK/JRE på maskinen - modsætning til Windows * de fleste Java programmører har lært at putte jar filer i et app specifikt lib og ikke putte noget i system CLASSPATH
Løsningerne er forskellige, problemerne er de samme .......
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
