Java im Web

[slothsoft]

Huhu!

Ich brauch einen Moment mein Dilema zu erklären, also seid geduldig mit mir. Ich möchte eine Android-App schreiben und habe deswegen angefangen ein Framework in Java zu schreiben (eigentlich eine ganze Palette derer, aber das spielt keine Rolle), was wundervoll in JUnit getestet und mit Maven gebaut wird (also das, was in Android nicht geht). Die GUI ist dabei gänzlich entkoppelt und kann von außen injected werden, so dass im Moment nur ein oder zwei Klassen neu implementiert werden, um Graphiken in Swing oder Android zu malen. Soweit, so gut.

Nun würde ich gern aber parallel auch eine Browser-Version entwickeln. Die Letzte habe ich der Einfachheithalber als Applet gemacht, aber danke dem Werbe-Problem konnte ich die nie veröffentlichen. Das möchte ich nun nach Möglichkeit anders händeln.

Ich habe dabei folgende Anforderungen zusammengetragen: 1.a) Ich möchte mein gut getesteten Kern-Komponenten verwenden. 1.b) Ich brauche einen Canvas zum Zeichnen. 1.c) Ich weiß was die Applications-Server kosten, also fällt WAR raus. 2. Threads wären schön, aber die meisten Frameworks haben dafür einen Workaround. 3. Möglichst große Verbreitung in Browsern (wobei mir mobile Geräte egal sind) 4. Werbung wäre sehr großartig.

Folgendes hab ich mir dabei angeguckt, mit folgenden Makeln:

Google Web Toolkit - [1c] Bin nicht sicher, ob reiner Client-Code ohne WAR ausführbar ist, [4] keine Werbung
Eclipse RAP - [1b] Canvas ist sehr eingeschränkt, [1c] Server nötig, [4] keine Werbung
Java2Script - [2] kein natives Threading, [4] keine Werbung, [x] sehr dürftige Umsetzung von RCP und länger nicht gewartet
Qooxdoo Web Toolkit [1c] Server nötig, [4] keine Werbung, [x] Version 0.2 macht mir Sorge

Und an der Stelle wurde es dann abenteuerlich:

Flash / ActionScript3 - eigentlich alles super, nur ist ein Compiler zwischen den Sprachen nötig, und die entsprechenden Maven-Projekte von FlexMojo machen Probleme z.B. kompilieren sie die Konstruktoren nicht mit (und wer weiß was noch nicht), und ich hab eigentlich keine Lust, nochmal über das ganze Framework drüber zu gehen und Anpassungen zu machen

So und jetzt kommt meine Frage: Übersehe ich hier eine offensichtliche Lösung? Gibt es vielleicht andre lustige Cross-Compiler (JAVA zu CSS oder was weiß ich ) die ich mir mal ansehen könnte? Hat jemand sonst Erfahrungen mit dem Thema Multi-Plattform-Entwicklung und einen guten Tipp?

Ich bedanke mich im Vorraus!

 

[Tobse]

Java zu CSS wäre mal tatsächlich eine interessante Sache, wirst du aber sicherlich nicht antreffen. Aber du könntest CSS zu Java klassen einbauen, die CSS Dateien lesen und daraus die GUI bilden. Man schreibt also die Anwendung fürs web und dein Framework verarbeitet es weiter bis es nativ zu sehen ist.

 

[slothsoft]

Erm ja nein, CSS war ein Witz. ^_^ Würde in dem Fall auch keinen Sinn machen, weil ich mit dem Framework auf verschiede Canvase maken will.

 

[Tobse]

Du kannst deinen Quellcode in JavaScript übersetzen und einfach eine

<canvas style="width:100%;height:100%;" />

machen und dadrauf alles malen; würde in den aktuellen HTML5-Browsern sogar garnicht schlecht funktionieren. Maus- und Tastatur-events kannst du ja über JavaScript auch abfangen. Aber wenn du ein Canvas willst kommst du anders fast nicht zum Ziel.
Wenn du auf das Canvas verzichten willst bleibt dir nur HTML. Die interne Struktur von Swing ließe sich gut in ein valides HTML-Dokument rendern dass dann vom Browser angezeigt wird. Wie du dann allerdings die JavaScrip-Events vom Browser in deinen Java-Code bekommst (der ja nicht im Applet läuft, wo sonst?) kann ich dir nicht sagen...

 

[slothsoft]

Ausgezeichnete Idee, nur wie kriege ich mein Java nach JavaScipt? (Nebenbei bemerkt hab ich weder Applet noch Swing in Benutzung, nur Kernklassen wie Object, String, Map...)

 

[Tobse]

nur wie kriege ich mein Java nach JavaScipt?

Du kannst deinen Quellcode in JavaScript übersetzen

Allerdings wäre ein neuer JavaScript code der mit einem bestehnden Framework (jQuery, node.js etc...) zusammenarbeitet und das gleiche macht einfach deutlich effizienter und eleganter. Das Web ist das Web und native Desktopanwendungen sind native Desktopanwendungen. Die Verbindung zwischen beidem zu schaffen haen schon viele (oft vergebens) versucht, z.B. M$ mit den Gadgets in Win7.

 

[slothsoft]

Okay...? Ich verstehe immer noch nicht den Vorteil deines Vorschlags. Mal angenommen ich hätte die Willenskraft und die Manpower, hunderte Klassen, Unit- und Integrations-Tests in zwei Sprachen zu pflegen... dann was? Von meinen obigen 6 Anforderungen sind doch nur die Hälfte erfüllt. Warum sollte ich es dann so machen?

Und wie kommst du von dem Satz "Ich möchte eine Android-App schreiben" immer auf Applets und Desktop-Anwendungen? Ich habe nichts dergleichen. Ich hab nur Logik-Code bislang (nebenbei es gibt sehr gute Frameworks für RIA-Anwendungen im Web (z.B. RAP)). Die GUI kann ich problemlos für jedes Endgerät neu schreiben, das wichtige ist, dass der Logik-Teil wiederverwendet werden kann.

 

[Tobse]

Und wie kommst du von dem Satz "Ich möchte eine Android-App schreiben" immer auf Applets und Desktop-Anwendungen?

Nun würde ich gern aber parallel auch eine Browser-Version entwickeln.

Eine App ist (aus meiner Sichtweise) rein von der Planung bzgl. Frameworks / Technik / Sprache gleichzsuetzen mit Desktop-Anwendungen.

Um also nochmal auf den Kern deiner Frage zurückzukommen: Deinen Java-Code kannst du as-is in die Android-App packen da Android Java voll unterstützt.
Im Web kannst du Java code ausschließlich im Applet benutzen. Wenn du zwei Versionen deiner Bibliothek - eine für die App und eine fürs Web - willst, wirst du um zwei verschiedene Code-Bases nicht herumkommen.

 

[slothsoft]

Im Web kannst du Java code ausschließlich im Applet benutzen. Wenn du zwei Versionen deiner Bibliothek - eine für die App und eine fürs Web - willst, wirst du um zwei verschiedene Code-Bases nicht herumkommen.

Entschuldige die Direktheit, aber diese Aussage ist gelogen. Und wenn du den ersten Post in diesem Thread gelesen hast, dann weißt du das auch. Denn dort habe ich 4 (in Worten: VIER) Frameworks aufgelistet, die dafür konzipiert sind, mit JAVA Webanwendungen zu schreiben. Es gibt noch tausende weitere (siehe zum Beispiel diese Auflistung ). Nein, die muss man nicht kennen. Aber wenn man sie nicht kennt, muss man da echt auf einen Thread antworten der "Java im Web" heißt?

Mal abgesehen davon: Selbst wenn man mit JAVA keine GUI für den Browser schreiben könnte, gäbe es immer noch Möglichkeiten, um zwei Code-Basen herum zu kommen, z.B. eben das Cross-Compilieren.

 

[Tobse]

Entschuldige die Direktheit, aber diese Aussage ist gelogen. Und wenn du den ersten Post in diesem Thread gelesen hast, dann weißt du das auch. Denn dort habe ich 4 (in Worten: VIER) Frameworks aufgelistet, die dafür konzipiert sind, mit JAVA Webanwendungen zu schreiben. Es gibt noch tausende weitere (siehe zum Beispiel diese Auflistung ). Nein, die muss man nicht kennen. Aber wenn man sie nicht kennt, muss man da echt auf einen Thread antworten der "Java im Web" heißt?

Mal abgesehen davon: Selbst wenn man mit JAVA keine GUI für den Browser schreiben könnte, gäbe es immer noch Möglichkeiten, um zwei Code-Basen herum zu kommen, z.B. eben das Cross-Compilieren.

Dass es möglichkeiten gibt ist mir schon bewusst. Aber das resultat von einer "Cross-Compilation" nennst du dann qualitativen Code? Und den muss man dann auch 0 debuggen damit er läuft?

 

[slothsoft]

Dass es möglichkeiten gibt ist mir schon bewusst. Aber das resultat von einer "Cross-Compilation" nennst du dann qualitativen Code? Und den muss man dann auch 0 debuggen damit er läuft?

Der Code ist definitiv besser, wenn ich gut getesten Code automatisiert kompiliere, als wenn ich in zwei Sprachen parallel entwickle. Und natürlich muss der Code debuggt werden. Aber dass muss er ja auch für Android, weil das eine andre JVM ist. Und auch da störe ich mich nicht dran. Ich muss ganz ehrlich sagen, ich wüsste nicht, wie ich eine GUI für meine Logikkomponenten schreiben könnte, OHNE sie zu benutzen und damit natürlich auch zu validieren.

 

[KSG9|sebastian]

Ich versteh noch immer nicht was du willst?

Du hast ein/mehrere Frameworks geschrieben? In meinem Sprachgebrauch haben Frameworks keine Oberfläche oder ähnliches.

Jenachdem was du verwendest kannst du mit GWT locker ein Frontend dafür schreiben - sofern diverse Vorgaben seitens GWT erfüllt sind.

Wenn du eine Webanwendung bereitstellen willst brauchst du nunmal einen Server. Für reinen Clientcode reicht mit GWT ein Webserver. Willst du serverseitige Funktionen haben brauchst du entsprechend zumindest einen Servletcontainer.

Cross-Compilation kannst praktisch vergessen. Genauso wie ein UIFramework für Mobile, Desktop, Web und sonstwas. Viele habens versucht, viele sind gescheitert. Hauptsächlich weil du immer den kleinsten gemeinsamen Nenner brauchst - und das ist meist ziemlich wenig. Ganz abgesehen davon das sich die Modelle gnadenlos unterscheiden...

Beschreib mal genauer was rauskommen soll...

 

[slothsoft]

Du hast ein/mehrere Frameworks geschrieben? In meinem Sprachgebrauch haben Frameworks keine Oberfläche oder ähnliches.

Genau so ist es auch.

Jenachdem was du verwendest kannst du mit GWT locker ein Frontend dafür schreiben - sofern diverse Vorgaben seitens GWT erfüllt sind.

Ich hab mir seit dem GWT noch mal angesehen, und es sieht echt gut aus. Allerdings bin ich direkt über einen frameworkspezifischen Bug geflogen, dass Object#clone() nicht unterstützt wird. Und das ist ein wirkliches Problem, weil ich diese Methode aus Performance-Gründen überall eingesetzt habe. Ich werde die Tage nochmal schauen, ob ich das patchen kann.

Wenn du eine Webanwendung bereitstellen willst brauchst du nunmal einen Server.

Jain... ich habe einen einfachen REST-Server geplant, den ich mit PHP schreiben möchte (demzufolge reicht mir ein Webserver und ich brauch keinen Applikationsserver). Da er für verschiedene Clients gedacht ist, denke ich es ist sinnvoller, ihn auch wirklich losgelöst von einer bestimmten GUI zu schreiben.

Cross-Compilation kannst praktisch vergessen. Genauso wie ein UIFramework für Mobile, Desktop, Web und sonstwas. Viele habens versucht, viele sind gescheitert. Hauptsächlich weil du immer den kleinsten gemeinsamen Nenner brauchst - und das ist meist ziemlich wenig. Ganz abgesehen davon das sich die Modelle gnadenlos unterscheiden...

Die GUI möchte ich gar nicht cross-kompilieren. Ich würde gern die App ähnlich einer Desktop-Anwendung gestalten, mit einer kleinen lokalen Datenbank und optional der Möglichkeit, sich mit dem Internet zu verbinden. Die Browser-Version dagen muss natürlich immer mit dem Netz verbunden sein, dort kann ich aber auch von einer größeren Übertragungsgeschwindigkeit ausgehen. Generell unterscheiden sich die Feature auch etwas. Alles in allem mag es Überschneidungen geben, aber ich kann sehr gut damit leben, wenn ich diese dann zwei Mal ausimplementiere.

Der "wichtige" Teil sind die Frameworks. Ohne zu sehr ins Detail zu gehen sind das biologisch-genetische Algorithmen. Außerdem Komponenten zur Visualisierung, die nur gegen ein Canvas-Interface arbeiten, was ganz allgemeine Methoden hat (drawLine(Point from, Point to), drawRectangle(Rectangle rect), usw.). Dieses Interface wird dann mit der entsprechenden GUI-Technologie implementiert (wie gesagt, Swing habe ich zum schnellen Testen, und Android als Proof-of-concept), so dass ich auch den Code zur Erstellung von Grafiken wiederverwenden kann.

Da ich aber insgesamt eigentlich nur die Packages "java.lang" und "java.util" benutze, wäre theoretisch ein Kompilieren in eine andre Sprache möglich (wenn auch nicht schön). Es geht halt einfach darum, komplizierten Logik-Code wiederzuverwenden und menschliche Fehler auszuschließen.

 

[Tobse]

Da ich aber insgesamt eigentlich nur die Packages "java.lang" und "java.util" benutze, wäre theoretisch ein Kompilieren in eine andre Sprache möglich (wenn auch nicht schön). Es geht halt einfach darum, komplizierten Logik-Code wiederzuverwenden und menschliche Fehler auszuschließen.

Dann mach doch folgendes: Pack den logik-code in einen Application-Server und frage aus der App, dem Web (AJAX) und welche GUIs/Platformen du sonst noch machen willst von dort die Berechnungen ab. Da hast du sie super zentral und wenns ein Update gibt muss sich das der End-User nichtmal zwingend runterladen.

 

[slothsoft]

Ne, das geht nicht. Applikationsserver steht außer Frage wegen des Geldes, und außerdem hab ich dann ja keine Möglichkeit mehr, eine Offline-Version anzubieten. Nötig ist es auch nicht, sowohl bei App als auch im Browser habe ich die Möglichkeit, zeitnahe Updates zu fahren.

 

[Tobse]

Ne, das geht nicht. Applikationsserver steht außer Frage wegen des Geldes, und außerdem hab ich dann ja keine Möglichkeit mehr, eine Offline-Version anzubieten. Nötig ist es auch nicht, sowohl bei App als auch im Browser habe ich die Möglichkeit, zeitnahe Updates zu fahren.

Aber dein Java-Code wird im Browser ausser per Applet nicht einfach so laufen, versteh das doch Wenn du irgendein Framework nimmst, dass dir den Code "übersetzt" musst du ihn aufs neue auf herz und Nieren testen. Da kannst du's gleich neu machen.

Was die App und das Internet angeht: wer hat heutzutage kein Internet auf dem Handy? Mit einem gut durchdachten Protokoll ließe dich das Datenvolumen auch auf ein paar KB beschränken.
Zum Application-Server: Man bekommt brauchbare und zuverlässige Cloud-Server für 15-20€/Monat, das muss doch drin sein o.0

 

[slothsoft]

Ehrlich gesagt bin ich grad nicht sicher, ob du ein Troll bist oder einfach nur nicht mitliest. Von daher reagier ich mal nur auf die Sache, die mich am Allermeisten stört:

Man bekommt brauchbare und zuverlässige Cloud-Server für 15-20€/Monat, das muss doch drin sein o.0

Erstens Mal ist das einfach nur falsch. Für das Geld kriegt man absoluten Mist, mit dem man nur Scherereien hat, wenn überhaupt. Zweitens Mal: Jetzt sind wir schon in der Cloud? Hast du dir Mal Gedanken gemacht, dass das eine komplett andre Architektur vorraussetzt als Desktop-Anwendungen? Bist du dir überhaupt sicher, dass AJAX in der von dir erzählten Form cloudfähig ist? Und drittens, die Krönung, "das muss doch drin sein": Worauf basierst du das? Auf deinem monatlichen Taschengeld? Soweit ich weiß haben wir nicht drüber gesprochen, ob und wie ich meine Anwendung am Ende vermarkten will. Und ob ich für etwas, durch das ich kein Geld verdienen werde, trotzdem jeden Monat Geld ausgeben möchte, hast du gar nicht zu entscheiden.

 

[Tobse]

Ehrlich gesagt bin ich grad nicht sicher, ob du ein Troll bist

Ich bin mir nicht sicher, ob so etwas überhaupt zielführend ist.

Erstens Mal ist das einfach nur falsch.

Sachliche Belege für solche Amasungen?

Für das Geld kriegt man absoluten Mist, mit dem man nur Scherereien hat, wenn überhaupt.

Achja? Ich entwickle seit monaten auf einem Cloud vServer und der war kein eiziges mal down. Zudem legt das Teil ne größere Performance an den Tag als mein Entwicklungscomputer (mit i5 und 8GB RAM).

Hast du dir Mal Gedanken gemacht, dass das eine komplett andre Architektur vorraussetzt als Desktop-Anwendungen?

Hast du dir mal Gedanken gemacht, dass ein Web-Server/Applikation-Server der auf einem Cloud-Server läuft genauso für HTTP-Requests/Socket-Verbindungen zugänglich ist??

Bist du dir überhaupt sicher, dass AJAX in der von dir erzählten Form cloudfähig ist?

Sicher doch. JavaScript sendet den Request, über PHP wird (siehe befehle system() oder exec()) dein Java-Programm aufgerufen und die ausgabe wird von PHP JSON formatiert (oder Java macht das gleich). Dann kannst du das im Web wunderbar angzeigen.

Auf deinem monatlichen Taschengeld?

Worauf basiert die Annahme, dass ich Taschengeld bekomme? Ich verdiene Geld wie jeder andere auch und auch keine unsummen. Wie gesagt, 16€ für den Server waren nie ein Problem. Und wenn du genug Zeit hast um "so viele komplexe Klassen" zu Entwickeln aber kein geregeltes Einkommen solltest du vielleicht nochmal überdenken, womit du deine Zeit am sinnvollsten verbringst.

Und ob ich für etwas, durch das ich kein Geld verdienen werde, trotzdem jeden Monat Geld ausgeben möchte, hast du gar nicht zu entscheiden.

Nichts ist umsonst. Überleg nurmal wieviel Geld du in der Zeit (beim aktuellen Mindestlohn) verdient hättest wärend du deine Bibliothek entwickelt hast.

 

[slothsoft]

Sachliche Belege für solche Amasungen?

Jetzt außer Ausprobieren und entäuscht werden?

Achja? Ich entwickle seit monaten auf einem Cloud vServer und der war kein eiziges mal down.

Da hast du ganz schön Schwein gehabt mit deinem Anbieter. Meiner Erfahrung nach ist es dann doch billiger, sich einen eigenen Server aufzusetzen, aber dann nicht ständig zu schauen, warum nun schon wieder Ausfälle vorliegen. Und "billig" in dem Sinn ist das auch nicht.

Hast du dir mal Gedanken gemacht, dass ein Web-Server/Applikation-Server der auf einem Cloud-Server läuft genauso für HTTP-Requests/Socket-Verbindungen zugänglich ist??

Es geht mir um Architektur der Software. Desktop-Anwendungen gehen davon aus, dass ein Anwender ist eine JVM. In der Cloud ist es nicht mehr so, da kommen mehrere Anwender auf eine JVM und unter Umständen läuft die Anwendung dann noch verteilt. Da kann man tierischst mit hinfallen, weil "static" dann halt nicht mehr das macht, was man gerne mal annimmt.

Sicher doch. JavaScript sendet den Request, über PHP wird (siehe befehle system() oder exec()) dein Java-Programm aufgerufen und die ausgabe wird von PHP JSON formatiert (oder Java macht das gleich). Dann kannst du das im Web wunderbar angzeigen.

Wo da der Vorteil gegenüber dem reinen REST-Service ist musst du aber noch mal erklären, außer dass man mehr Stellen hat, wo man durchdebuggen muss.

Worauf basiert die Annahme, dass ich Taschengeld bekomme?

Darauf, dass in deinem Profil "18" als Alter steht und du offensichtlich nicht weißt, wie viel 20 Euro im Monat für die Familienkasse sein können.

Überleg nurmal wieviel Geld du in der Zeit (beim aktuellen Mindestlohn) verdient hättest wärend du deine Bibliothek entwickelt hast.

Ich kriege glücklicherweise doch etwas mehr als Mindestlohn, aber leider ist meine Arbeitszeit festgeschrieben. Und ganz ehrlich: Meine Freizeit ist mir mehr wert als mein Stundenlohn, deswegen wird die Umrechnung immer hinken.

 

[Tobse]

Jetzt außer Ausprobieren und entäuscht werden?
[...]
Da hast du ganz schön Schwein gehabt mit deinem Anbieter.

Ausprobiert hab ichs schon, mit Erfolg wie gesagt. Um das geheimnis zu lüften: es handelt sich um eine JiffyBox bei domainfactory.eu.

Es geht mir um Architektur der Software. Desktop-Anwendungen gehen davon aus, dass ein Anwender ist eine JVM. In der Cloud ist es nicht mehr so, da kommen mehrere Anwender auf eine JVM und unter Umständen läuft die Anwendung dann noch verteilt. Da kann man tierischst mit hinfallen, weil "static" dann halt nicht mehr das macht, was man gerne mal annimmt.

Kommt auch wieder drauf an, welche Cloud man nutzt. Bei den vServern/Root-Servern die ich kenne hat man ein ein ganzes OS für sich; der einzige Cloud-Aspekt ist dass man sich seine 3-8 Rechenkerne mit anderen Nutzern Threadweise teilt.

Darauf, dass in deinem Profil "18" als Alter steht und du offensichtlich nicht weißt, wie viel 20 Euro im Monat für die Familienkasse sein können.

Das ist korrekt aber ich war mir mit der Annahme, dass 20€ für eine Studentenkasse nicht schwerwiegender sein können wie für eine Familienkasse recht sicher. Entschuldige bitte, wenn ich falsch lag.

De facto habe ich alles gesagt, was ich dazu sagen kann - die Möglichkeiten die sich dir stellen sind glaub alle im Thread. Viel Erfolg

 

[slothsoft]

Ausprobiert hab ichs schon, mit Erfolg wie gesagt. Um das geheimnis zu lüften: es handelt sich um eine JiffyBox bei domainfactory.eu.

Ich denk mal drüber nach, danke.

De facto habe ich alles gesagt, was ich dazu sagen kann - die Möglichkeiten die sich dir stellen sind glaub alle im Thread. Viel Erfolg

Danke, aber bitte lass mal offen, ob das hier echt alle Möglichkeiten sind. Ich hoffe ja immer noch darauf, dass jemand kommt und sagt: "Hast du mal an diese oder jene Lösung gedacht: ..." Und dann werden alle meine Probleme gelöst und meine Küche aufgeräumt. Oder so...