Java-Version (ME, SE) erkennen und darauf reagieren?

[Kukulkan]

Hallo,

ich bin neu im Forum und und auch noch JAVA Neuling (Umsteiger von PHP). Hier gleich meine erste Frage:

Ich programmiere gerade ein paar Klassen, welche ich anderen Entwicklern später evtl. zur Verfügung stellen möchte. Das ganze soll unter JavaME als auch JavaSE (1.6) funktionieren. Ich achte darauf, dass ich alle Funktionen, welche unter JavaME nicht zur Verfügung stehen, in separate Klassen auslagere.

Ich frage mich nun, ob ich den Code so gestalten kann, dass ich unter JavaME andere Funktionen verwende als unter zB JavaSE 1.6. Das Ziel wäre es, die selben Dateien für die Entwicklung unter JavaME und JavaSE zu verwenden. Geht das überhaupt? Wenn ja, wie kann ich das im Code feststellen und dann entsprechend verzweigen (zB Swing-Messagebox nur unter JavaSE, unter JavaME dann eben eine Ausgabe über System.out...).

Grüße,

Kukulkan

 

[The_S]

Nein, geht nicht. Auch deine Java SE Klassen würden sich ja zur Ausführungszeit im Classpath befinden, würden also mit geladen werden bevor du überhaupt prüfen kannst, ob es sich um eine ME oder eine SE Umgebung handelt. Du könntest zwar ein bisschen tricksen, aber das funktioniert nur bei den wenigsten ME Geräten. Außerdem müsste das Ganze ja auch irgendwie einheitlich kompiliert werden.

Einzige Möglichkeit wäre ein Build-Tool wie bspw. Ant, mit welchem du aus deinem Code unterschiedliche Versionen für ME und SE generieren lassen kannst.

 

[mvitz]

Oder aber man baut insgesamt 3 Libraries:

1. Alle Klassen, die unter SE und ME laufen
2. Nur die Klassen, welche SE spezielle Dinge an JavaSE deligieren
3. Nur die Klassen, welche diese Dinge für ME implementieren.

Dann muss man halt je nachdem für welche Plattform man deployt sich zwischen 2 oder 3 entscheiden.

 

[Noctarius]

Es geht schon. Man nutzt ein Interface und verschiedene Implementierungen. Diese muss man dann je nach Plattform passend per Reflection nachladen. Dann (und nur dann) werden die Klassen nicht automatisch geladen und man könnte es so machen.

PlatformSupportUtils.java - lycia - Project Hosting on Google Code
PlatformFactoryProvider.java - lycia - Project Hosting on Google Code

Z.B. mit 2 solchen Klassen.

 

[The_S]

Es geht schon. Man nutzt ein Interface und verschiedene Implementierungen. Diese muss man dann je nach Plattform passend per Reflection nachladen. Dann (und nur dann) werden die Klassen nicht automatisch geladen und man könnte es so machen.

PlatformSupportUtils.java - lycia - Project Hosting on Google Code
PlatformFactoryProvider.java - lycia - Project Hosting on Google Code

Z.B. mit 2 solchen Klassen.

Und wie machste das bei Java ME (darum gehts hier ja, nicht um Android)?

 

[Kukulkan]

Hallo,

danke für die Antworten und Vorschläge. In manchen anderen Programmiersprachen gibt es Compiler-Direktiven. Da kann man im Source sowas machen (Beispiel, Schematisch):

String VersionsKonstante = "JavaSE"
CompilerIf (VersionsKonstante = "JavaME") {
  // some JavaME code
  private int testCode() {
  }
}

CompilerIf (VersionsKonstante = "JavaSE") {
  // some JavaSE code
  private int testCode() {
  }
}

Dann setzt man vor der Erstellung/Compilierung einfach die Konstante auf den richtigen Wert und das Compilat ist dann entsprechend. VersionsKonstante kann auch was aus den Projekt-Properties sein oder so... Einen ähnlichen Ansatz habe ich mir erhofft

Es wurde ANT erwähnt. Wie kann ich da am besten reinfinden? Gibt es einen guten, einführenden Link?

Grüße,

Kukulkan

 

[Noctarius]

Nein direkt gibt es sowas in Java nicht, da die JRE beim Laden einer Klasse alle benötigten (aber noch nicht geladenen) Klassen mitläd. Findet er dabei eine Klasse nicht gibt es eben eine ClassNotFoundException.

Einen Preprozessor gibt es in Java zum Glück nicht aber du kannst halt mit der oben erwähnten Variante trotzdem passende Implementierungen eines Interfaces laden.

 

[Kukulkan]

Hallo,

Hm. Was wäre denn jetzt der ideale Weg? Soll ich mich in ANT einarbeiten oder mich mit Reflection befassen (nicht vergessen, bin noch recht neu in Java)?

Ich will keinesfalls einen Source-Split für JavaME oder JavaSE. Das würde bedeuten, dass ich jede Änderung immer in mehreren Sourcen durchführen müsste... Ich implementiere eine Art SDK für ein spezielles Protokoll. Das sollen Entwickler unter JavaME und JavaSE anwenden und einbinden können. Auch will ich am besten nur einen Source rausgeben (egal, ob der Anwender dann etwas für JavaME oder JavaSE erstellen möchte).

Das Problem ist, das manche Funktionen in den Klassen ja schon in Eclipse Probleme machen, nur weil Sie da sind (auch wenn Sie nicht aufgerufen würden).

Kukulkan

 

[The_S]

aber du kannst halt mit der oben erwähnten Variante trotzdem passende Implementierungen eines Interfaces laden.

Evtl. hast du ja meine Antwort übersehen, aber die Frage steht nach wie vor im Raum:

Und wie machste das bei Java ME (darum gehts hier ja, nicht um Android)?

 

[The_S]

Hm. Was wäre denn jetzt der ideale Weg? Soll ich mich in ANT einarbeiten oder mich mit Reflection befassen (nicht vergessen, bin noch recht neu in Java)?

Ich würde wie gesagt Ant nehmen. Je nach Anforderung kannst du auch überlegen, ob du die Logik auf einen Server auslagerst und dann via HTTP-Requests, WebServices, ... nur noch die GUI auf den jeweiligen Endgeräten befüllst. Das ist eigentlich ein recht gebräuchlicher weg, wenn man für unterschiedliche Plattformen entwickeln will. Wenn ich mir den Rest deines Beitrages ansehe, ist diese Variante aber vermutlich nichts für dich.

Ich will keinesfalls einen Source-Split für JavaME oder JavaSE. Das würde bedeuten, dass ich jede Änderung immer in mehreren Sourcen durchführen müsste...

ANT oder sowas in die Richtung . Im ME bzw. SE spezifischen Teil wirst du aber um einen "Source-Split" nicht herum kommen.

Das sollen Entwickler unter JavaME und JavaSE anwenden und einbinden können. Auch will ich am besten nur einen Source rausgeben (egal, ob der Anwender dann etwas für JavaME oder JavaSE erstellen möchte).

Dann aber auch mit Skript zum Builden. Ein Source - OK. Aber um unterschiedliche Bin-Files für die unterschiedlichen Plattformen wirst du nicht kommen.

 

[Noctarius]

Evtl. hast du ja meine Antwort übersehen, aber die Frage steht nach wie vor im Raum:

Kann J2ME kein Reflection? Oo - Hab mich mit dem Ding nie beschäftigt. Wenn dem so ist nehme ich alles zurück Aber dann gehört das Teil endgültig von Handys verbannt.

 

[The_S]

Kann J2ME kein Reflection? Oo - Hab mich mit dem Ding nie beschäftigt. Wenn dem so ist nehme ich alles zurück Aber dann gehört das Teil endgültig von Handys verbannt.

Nö, hats nicht.

 

[Noctarius]

Nö, hats nicht.

Jo gerade gesehen, erst ab CDC (Connected Device Configuration). Hoffentlich fliegt das Teil endlich mal in den Müll um eine saubere, einheitliche Plattform zu schaffen.

 

[The_S]

Jo gerade gesehen, erst ab CDC (Connected Device Configuration). Hoffentlich fliegt das Teil endlich mal in den Müll um eine saubere, einheitliche Plattform zu schaffen.

Und CDC unterstützen die wenigsten Geräte. Meistens MIDP und CLDC.

 

[Noctarius]

Jo das CLDC kannte ich auch. Dachte da wäre es auch schon drin gewesen. Wie gesagt noch nie wirklich mit J2ME gearbeitet, ergo ziehe ich den Vorschlag über Reflection zu arbeiten zurück, S hat gewonnen

 

[Kukulkan]

Danke für die Tipps und die Info. Ich werde dann wohl nur mit einem Build-Script voran kommen (zB ANT). Ich mach mich mal dran

Grüße,

Kukulkan

 

[Landei]

Um in "normale" Umgebungen je nach Konfiguration unterschiedliche Implementierungen eines Interfaces zu laden würde sich das Service Provider Interface anbieten, aber das hat J2ME wahrscheinlich auch wieder nicht.

 

[Noctarius]

... würde sich das Service Provider Interface anbieten, aber das hat J2ME wahrscheinlich auch wieder nicht.

Hehe vermutlich nicht =)

 

[Bierhumpen]

@Kukulkan: Mein Tipp: lass es. Das ist unnötige Arbeit. JavaME hat praktisch Null bedeutung mehr auf dem Mobilmarkt und wird in den nächsten Monaten noch weiter sinken. Das Unterfangen kannst du dir also guten Gewissens sparen ;-)

 

[Noctarius]

Joar so kann man es auch sehen. Aber J2ME wird ja nicht nur im Bereich Mobilfunk genutzt, sondern auch bei Auto-Onboard-Computern, BD+, ...

Und auch bei anderen Plattformen wie Android muss man gewisse Dinge beachten / anders machen

 

[The_S]

@Kukulkan: Mein Tipp: lass es. Das ist unnötige Arbeit. JavaME hat praktisch Null bedeutung mehr auf dem Mobilmarkt und wird in den nächsten Monaten noch weiter sinken. Das Unterfangen kannst du dir also guten Gewissens sparen ;-)

Auch wenn es dir merkwürdig vorkommen mag: Die wenigsten Leute, die ich kenne (vor allem aus dem Nicht-IT/Technik-Bereich), haben ein Android/Bada-Handy oder iPhone und diese planen auch nicht, sich in nächster Zeit eines anzuschaffen. Da bleibt nur Java ME.

 

[Runtime]

Oder C.

 

[The_S]

Oder C.

Wenn du nicht mal minimale Plattformunabhängigkeit möchtest: Ja .

 

[Runtime]

Java ME ist ja auch nicht wirklich Plattformunabhängig.

 

[Noctarius]

Deswegen hat er ja geschrieben "minimal plattformunabhängig"

 

[Runtime]

Der Endteil vom Thread passt gar nicht mehr zum Titel, jemand* sollte den mal verschieben.
*Wer ist da wohl mit "jemand" gemeint?

 

[The_S]

Der Endteil vom Thread passt gar nicht mehr zum Titel, jemand* sollte den mal verschieben.
*Wer ist da wohl mit "jemand" gemeint?

Klar passt der zum Titel. Einfach deinen und diesen Beitrag hier löschen und gut ist wieder .

 

[Kukulkan]

Hallo,

es ist so, dass ich eine Art SDK für unser Protokoll bereitstellen möchte. Das soll dann auf dem BlackBerry, auf Android und auf Desktops/Servern eingesetzt werden. Während ich auf Desktops/Servern problemlos auf JavaSE setzen kann, muss ich auf den mobilen Geräten (also Android und BB) auf JavaME setzen. Da habe ich die grösste Chance, dass es machbar ist. Auf JAVA zu verzichten scheint mir da kein guter Vorsatz zu sein. Wie sonst soll ich denn eine gemeinsame Codebasis für mehrere mobile Devices schaffen? Ich hoffe ja, dass Oracle es schafft MS davon zu überzeugen unter Windows Mobile 7 auch JAVA zu unterstützen. feif:

Ich habe vor, zumindest für die JAVA fähigen Geräte, auf eine gemeinsame Code-Basis zuzugreifen. Und deshalb die Idee, evtl. durch geschickte Programmierung, Includes, Direktiven. Reflection etc. weitere Sourcecodes und Aufwände zu reduzieren.

Grüße,

Kukulkan

 

[Noctarius]

Android ist kein J2ME sondern ein Superset von Java SE

 

[The_S]

Android ist kein J2ME sondern ein Superset von Java SE

Genau. Und Java ME muss meistens separiert für BlackBerry compiliert werden.

 

[Noctarius]

Genau. Und Java ME muss meistens separiert für BlackBerry compiliert werden.

Echt? Ist ja Moppelkotze

 

[The_S]

Echt? Ist ja Moppelkotze

Richtig . BlackBerry ist da ne Ausnahme mit eigenen Binaries (soweit ich weiß, habe noch nie separiert für BlackBerry compiliert, weiß aber, dass meine nicht separiert compilierten Apps auf fast keinem BlackBerry laufen (warum auch immer sie auf manchen Geräten trotzdem laufen )

 

[homer65]

Bin mir nicht 100 prozentig sicher, aber hilft System.getProperties() nicht weiter?

Edit:
Habe noch mal genauer geguckt.

System.getProperty("os.name");

gibt den Namen des Betriebssystems. Das müßte doch als Entscheidungskriterium ausreichen.

 

[The_S]

Du hast schon den Rest vom Thread gelesen ?

 

[homer65]

Na ja, überflogen. Habe ich wieder das Wesentliche übersehen?
Ups, ich schäme mich. :-(

 

[The_S]

Es geht um grundsätzlich unterschiedliche Plattformen - SE, ME und Android. Da werden ganz unterschiedliche Code-Grundlagen benötigt die man nicht erst zur Runtime unterscheiden darf/kann (zumindest bei ME).