Hallo zusammen, ich programmiere intern in der Abteilung in meiner Firma eigentlich ausschließlich C und C++. Vor ein paar Jahren gab es dann einen Hype mit Java, sodass sehr viele auf Java umgestiegen sind, da plattformunabhängig etc. Allerdings sehe ich ein sehr großes Problem in der Bedienung des Endprodukts beim Kunden: - Java bietet nicht wie z.B. Visual Studio (C++ und C#) an, dass man sich einen Installer der Java-Anwendung bauen kann. Klar, in der Entwicklungsphase ist so ein JAR-File wunderbar. Aber wer will schon einem Kunden ein einziges JAR-File geben? Vielleicht bin ich noch nicht so richtig in der Materie drin, da ich eben "alteingesessener" C++-Programmierer in VS bin. Könnt ihr mir sagen, was ihr darüber denkt? :)
Andi schrieb: > Allerdings sehe ich ein sehr großes Problem in der Bedienung des > Endprodukts beim Kunden: > - Java bietet nicht wie z.B. Visual Studio (C++ und C#) an, dass man > sich einen Installer der Java-Anwendung bauen kann. C++ und C# bieten ebensowenig Installer an. Hingegen kann man selbsverständlich auch für Java-Anwendungen Installer erstellen und verteilen.
Andi schrieb: > Klar, in der Entwicklungsphase ist so ein JAR-File wunderbar. Aber wer > will schon einem Kunden ein einziges JAR-File geben? für Java gibt es ja webstart, damit ist auch das updaten und installieren kein Problem mehr. > Vielleicht bin ich noch nicht so richtig in der Materie drin, da ich > eben "alteingesessener" C++-Programmierer in VS bin. > Könnt ihr mir sagen, was ihr darüber denkt? :) für Client Anwendungen finde ich c++ nicht mehr zeitgemäß. Auch wenn ich es gerne als Server Anwendung einsetzte. Wenn man nur Windows Kunden hat, nutzte ich gerne C#. Da sind viele dinge schon drin, wofür man bei C++ erst irgendwelche Libs braucht. Auch das Thema 32/64 bit oder sogar ARM kann man mit einer Anwendung erschlagen.
Es gibt auch elegante Arten, aus einem JAR ein Ausführbares Programm *.exe (mit Icon) zu machen. Allerdings muss dann trotzdem JAVA installiert sein. Genau wie bei C# eben das .NET Framework. Das kann man dann mit dem Installer machen.
Rainer1975 schrieb: > OpenOffice sind ja auch Java-"Programme" ich glaube nicht. https://www.openoffice.org/de/downloads/zusatz.html OpenOffice.org funktioniert auch ohne Java
Als Wrapper kannst du z.B. Launch4J nehmen. (nur ein Beispiel, gibt viele, je nach Anforderung, aber für Desktopanwendungen eignet sich Launch4J gut) http://launch4j.sourceforge.net/ Für Setup gibt es z.B. http://nsis.sourceforge.net/Main_Page Gibts auch alles als Maven Plugin. mfg Andreas
Wenn das Setup dein einziges Problem mit Java ist, scheint es doch eine sehr gute Plattform zu sein. Mit C++ gibts regelmäßig alle möglichen schwierig zu lösenden Probleme, aber das Installer-Problem ist - wie an den vorherigen Posts zu sehen - trivial zu lösen. Daher scheint Java sehr gut geeignet zu sein.
Wiegesagt, ich habe keine Abneigung Java künftig anstelle von C++ einzusetzen. Aber wenn ich mir dann die Bedienungshinweise von sämtlichen "jar to exe"-Convertern anschaue, dann wird mir etwas schlecht. Keiner der genannten Installer ist a) kommerziell einsetzbar und b) so zu verwenden, dass er auch funktioniert. Launch4J: nach einer halben Stunde Rumprobiererei noch kein EXE-File aus einer JAR entstehen lassen können. Ich verstehe trotzdem die Denke nicht von Java. Da wird eine unglaublich mächtige Programmiersprache auf die Beine gestellt und dann wird kein Gramm an Hirnschmalz dafür aufgewendet, dass man das Endprodukt ja auch mal an Dritte weitergeben könnte, die eine handelsübliche Installation "voraussetzen".
Andi schrieb: > Ich verstehe trotzdem die Denke nicht von Java. Da wird eine unglaublich > mächtige Programmiersprache auf die Beine gestellt und dann wird kein > Gramm an Hirnschmalz dafür aufgewendet, dass man das Endprodukt ja auch > mal an Dritte weitergeben könnte, die eine handelsübliche Installation > "voraussetzen". Du sprichst in Rätseln. Was hat das mit der Programmiersprache zu tun? Es gibt 1001 verschiedene Wege einen Installer für $wasauchimmer welches in $beliebiger Programmiersprache geschrieben wurde zu bauen, sich Dir doch einfach einen aus. Am besten Du nimmst den selben den Du auch für C++ genommen hättest. Ich fand früher zum Beispiel Inno-Setup immer ganz nett, unkompliziert, flexibel und hybsch anzuschaun, nur mal so als Beispiel.
Rainer1975 schrieb: > Es gibt auch elegante Arten, aus einem JAR ein Ausführbares Programm > *.exe (mit Icon) zu machen. > Allerdings muss dann trotzdem JAVA installiert sein. Genau wie bei C# > eben das .NET Framework. > > Das kann man dann mit dem Installer machen. Und inwieweit ist das dann noch ... Andi schrieb: > plattformunabhängig ?
>Du sprichst in Rätseln.
Wiegesagt...Visual Studio bringt eine (wenn auch nicht wirklich schöne)
Installer-Umgebung mit, damit man nicht nur die Software
stunden/wochen/jahrelang programmiert, sondern auch mal an einen
ausgeben kann, der nicht die Umgebung und das nötige Zeugs auf der Kiste
installiert hat.
Und genau das meine ich: Es wird von der IDE (ob Eclipse oder Netbeans)
kein bisschen an einer Möglichkeit gearbeitet, dass man die geschrieben
Software dann auch ausliefern kann.
Alles nur Expertisen, die auf dem System, auf dem man die Software
gerade schreibt hier und gleich funktioniert.
Andi schrieb: > Es wird von der IDE (ob Eclipse oder Netbeans) > kein bisschen an einer Möglichkeit gearbeitet, dass man die geschrieben > Software dann auch ausliefern kann. Das ist auch nicht Aufgabe einer IDE. Aufgabe der IDE ist es Dich in Deinen Code eintauchen und damit eins werden zu lassen und außerdem noch die externen build-Tools auf Knopfdruck aufzurufen. Und welche Tools das konkret sein sollen bestimmst Du. Installer zum Beispiel gibts separat, Du hast die freie Wahl, entweder was selbstgeschriebenes (weniger empfehlenswert) oder was fertiges (wie z.B. Inno oder dergleichen). Du kannst das Bauen des Installers ja in Dein Build script mit reinnehmen, dann fällt auf Knopfdruck auch gleich der Installer raus.
:
Bearbeitet durch User
Wobei es bei Eclipse RCP sogar so ist, dass man auf "als Produkt exportieren" klickt und dann 2 mal auf Weiter und dann werden Dir bis um die 14 verschiedenen Ordner mit ausführbaren Programmen erzeugt. Jeweils für ein anderes Betriebssystem oder Prozessor. Also unter Windows mit einer .exe. Im OSX Ordner dann eine App. Das soll die Microsoft IDE erst mal vormachen.
Rainer1975 schrieb: > Jeweils > für ein anderes Betriebssystem oder Prozessor. warum sollte Java Prozessor abhängig sein? > Das soll die Microsoft IDE erst mal vormachen. einfach den Build Prozess passend konfigurieren.
Rainer1975 schrieb: > Wobei es bei Eclipse RCP sogar so ist, dass man auf "als Produkt > exportieren" klickt und dann 2 mal auf Weiter und dann werden Dir bis um > die 14 verschiedenen Ordner mit ausführbaren Programmen erzeugt. Jeweils > für ein anderes Betriebssystem oder Prozessor. > > Also unter Windows mit einer .exe. Im OSX Ordner dann eine App. > > Das soll die Microsoft IDE erst mal vormachen. Und läuft die Exe dann, wenn ich als unbedarfter Windows Anwender einfach so draufklicke? Oder bekomme ich dann eine nette Meldung, dass ich mir erst mal eine JRE irgendwo beschaffen und installieren soll?
Peter II schrieb: > Rainer1975 schrieb: >> Jeweils >> für ein anderes Betriebssystem oder Prozessor. > > warum sollte Java Prozessor abhängig sein? Weil ein Installer immer Betriebssystemabhängig sein wird. Oder hast Du schon jemals was anderes gesehen? Es sei denn man verteilt das nackte .jar, das bekommt man (ganz ohne Installer) unverändert überall direkt zum Laufen. Also entweder er verteilt ein .jar und jeder kanns einfach so nutzen wie es ist oder er kümmert sich um jedes einzelne System gesondert, also eine setup.exe für Windows die vorher nachschaut ob die JRE installiert ist und sie bei Bedarf installiert, eine .deb Datei für Debian/Ubuntu, eine .rpm für Redhat, ein [keine Ahnung wie das dort heißt] für OSX, etc. etc. etc.
Angehängte Dateien:
-
rcp.png
65 KB
>Und läuft die Exe dann, wenn ich als unbedarfter Windows Anwender >einfach so draufklicke? Ja. Es sind sogar 20 Varianten.
Andi schrieb: > Es wird von der IDE (ob Eclipse oder Netbeans) kein bisschen an einer > Möglichkeit gearbeitet, dass man die geschrieben Software dann auch > ausliefern kann. Da stimmt nicht. In Plain Java villeicht nicht (da gibt es ja auch zig möglichkeiten wie etwas verteilt werden kann: Lib, WAR, Executable-JAR ....). Für das OSGi-Framework (auf dem auch Eclipse selbst basiert) kann Eclips über sogenannte "Produkte" sehr wohl (für verschiedenste Plattformen!) Launcher exportieren, diese können sogar die benötigte JRE enthalten. Gut "Installieren" kann man da nix, sondern einfach nur entpacke und starten... Und wenn es mir nicht mehr gefällt lösche ich den Ordner einfach wieder. Beschäftigen muss man sich damit aber auch. Es ist immer die Frage was man vorhat: - Kleine Anwendung, Tool o.ä. -> Executable-JAR -> Startbar über doppelklick wenn Java installiert ODER Exe-Wrapper (z.B. JSmooth) - Größere Anwendung mit vielen Modulen -> Abhängig von unterliegendem Framework passende Distributionsmethode wählen.
Java Hype? Inzwischen gibt es Java doch nur mehr bei IT-Dienstleistern. Wird für einen Kunden programmiert und läuft auf den eigenen Servern. Die Programmierer installieren es selbst. Und mal ehrlich - die unzähligen Möglichkeiten ein Java Programm zu installieren, existieren doch nur deshalb, weil keine davon wirklich brauchbar ist.
Noch einer schrieb: > Und mal ehrlich - die unzähligen Möglichkeiten ein Java Programm zu > installieren, existieren doch nur deshalb, weil keine davon wirklich > brauchbar ist. Es existieren genausoviele Möglichkeiten wie für in anderen Sprachen geschrieben Programme auch. Zum Beispiel hier ist eine Liste: https://en.wikipedia.org/wiki/List_of_installation_software Die wurden alle entwickelt weil jeweils alle anderen unbrauchbar waren. Aber was hat das mit Java zu tun?
Der springende Punkt: Suns Marketingabteilung hat behauptet, durch Java würde dieser Wildwuchs an komplizieren Cross-Platform-Installern obsolet. Statt dessen haben wir jetzt zusätzlich ein Sammelsurium von Workarounds für unpassende Java-Runtime Installationen.
Noch einer schrieb: > würde dieser Wildwuchs an komplizieren Cross-Platform-Installern > obsolet. Du kannst ja auch in ein standalone .jar exportieren, das funktioniert dann auf allen Plattformen meist einfach per Doppelklick (passende JRE vorausgesetzt, ja ich weiß, jetzt wirds rekursiv, aber das wäre kein Problem gwesen wenn Java die Weltherrschaft erlangt hätte so wie es heute die Jünger von .NET für sich beanspruchen, das musste man früher auch erst umständlich installieren und es gab etliche verschiedene Versionen). Ich persönlich nehme für kleine GUI-Tools übrigens lieber Lazarus+FPC, das macht auch statisch gelinkte standalone .exe Dateien ohne Abhängigkeiten, aber Java verwende ich ebenfalls wenn es der Einsatzzweck gebietet (z.B. umfangreiche aber sehr spezielle lib verwenden müssen die es nur für Java gibt, dann wird halt eben Java genommen, so abwegig ist es ja nun auch wieder nicht). Für jeden Zweck gibts meist ein passendes Werkzeug.
Angehängte Dateien:
-
blubb1.png
29 KB -
blubb2.png
16 KB
Du kannst auch dem Kunden ein jar geben, dass einen Webserver auf localhost aufmacht (mit GUI-Fenster) und den Browser startet, so dass der Kunde das Programm dann über ein Java-Applet, in dem die grafische Oberfläche eines normalen GUI-Programms (Menüleisten, Fensterrand etc) schlecht nachgebildet ist, bedienen kann. Das ist wahrhaft professionell.
> Ich persönlich nehme für kleine GUI-Tools übrigens lieber Lazarus+FPC Damit sind wir beim anderen Problem. AWT taugt nichts, Swing war lange Zeit zu träge und als SWT kam, gab es schon genug andere plattform-unabhängige GUIs. Erstaunlich, dass bei solchen Pannen die Sprache überhaupt so verbreitet ist. > Du kannst auch dem Kunden ein jar geben, dass einen Webserver auf > localhost aufmacht Die Firma, für die ich arbeite, hat eine bessere Idee. Die lassen das Jar auf ihrem eigenen Webserver laufen und berechnen für jeden Kleinkram ein paar Euro. Das summiert sich! Mich wundert auch, dass die Anwender so etwas akzeptieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.