Wann ist Client plattformunabhängig?

[isabellaferrerowaldner]

Hey Leute,
was soll es denn heißen das man darauf achten soll das der Client plattformunabhängig ist? Soviel ich weiß ist Java ja plattformuanbhängig (und läuft auch unter Windows und Linux)

sry wenn die Frage zu doof ist.....

 

[JStein52]

Trotzdem könntest du ja da drin plattformabhängige Konstrukte verwenden, z.B. Pfadangaben der Form "D:\MeineProjekte\*" oder du könntest externe Programme aufrufen die es nur auf Windows oder Linux gibt (z.B. cmd.exe)

 

[Mülchmann]

Hey Isabella,

Also gemeint ist damit, dass du einen Clienten hast, der wie der Name schon sagt plattformunabhängig ist.
Heißt also, dass du dieses dann halt auf verschiedenen Betriebssystemen laufen lassen kannst und es somit deine freie Entscheidung ist, welchen System du nutzen möchtest.
du kannst diesen Clienten also z.B. auf 2 Rechnern installieren, wobei der eine mit Windows und der andere mit Linux läuft. Die Funktionalität ist dabei bei beiden gewährleistet.

wäre es nicht so müsste man immer darauf achten, dass man dann auch das richtige Betriebssystem verwendet.


Gruß
Felix

 

[isabellaferrerowaldner]

mmh, danke aber ich glaube das verstehe ich noch nicht ganz :-(
Wenn mir jetzt jemand sagt, dass ich "aufgaben bearbeiten soll, bei denen der Client plattformunabhängig ist" was ändert das denn beim programmieren?

 

[Mülchmann]

beim Programmieren wird das in der Hinsicht "geändert", dass du ( wie JStein52 schon sagte) auf andere Pfadangaben und Programme eingehen musst, jenachdem was du für Aufgaben bearbeiten sollst.

wichtiges Thema bei der plattformunabhängigkeit sind "Sockets"
hast dich da schon einmal eingelesen?

und wie sehen denn deine Aufgaben aus?

 

[JStein52]

was ändert das denn beim programmieren?

Das ändert erst mal gar nichts. Ausser dass du deinen Code öfter mal kritisch anschauen solltest und dir klarmachen solltest habe ich da was verwendet was es evtl. auf Linux nicht gibt/nicht geht ?

Edit: und natürlich solltest du deinen Code am Ende auch auf mindestens zwei verschiedenen Plattformen testen ...

 

[isabellaferrerowaldner]

Okay, danke dann hat sich das geklärt!

 

[mrBrown]

wichtiges Thema bei der plattformunabhängigkeit sind "Sockets"
hast dich da schon einmal eingelesen?

Inwiefern spielt das bei Java eine Rolle?

 

[Manuel.R]

Eine Plattform besteht mehr als nur das Betriebsystem darunter/dahinter. Hardware, Sprache, Zeichensatz und was nicht sonst noch alles.
"Write once run everywhere" zählt nicht immer

 

[mrBrown]

Eine Plattform besteht mehr als nur das Betriebsystem darunter/dahinter. Hardware, Sprache, Zeichensatz und was nicht sonst noch alles.
"Write once run everywhere" zählt nicht immer

Ernstgemeinte Frage, wann spielt bei nem Java-Program "Hardware, Sprache, Zeichensatz" des Hosts eine Rolle?

 

[Manuel.R]

Haha, ehrlich?

Auch wenn die Hardware von uns durch die JRE verborgen bleibt, muss man mit den Informationen, die uns das OS von der Hardware liefern kann, leben.

Stichwort: Zeitmessung

Computer-Systeme verfügen neben der physikalischen Uhr, die nur im Sekundentakt (1Hz) synchronisiert, eine logische Uhr. Betriebssysteme aktualisieren diese Uhr im Time Slice durch interrupts (musst du nachlesen). Die Aktualisierung der logischen Uhr variiert zwischen 10ms und 50ms, abhängig vom BETRIEBSSYSTEM!

Auch wenn du eine Anwendung in Java schreibst, heißt es nicht, dass überall die gleichen Ergebnisse passieren oder gezeigt werden.

Java-Byte-Code, der auf einer I586-Maschine läuft, muss auf einem ARM-System nicht funktionieren, auch wenn auf beiden ein JRE läuft.

Ganz unabhängig sind wir nicht von OS und Hardware.

 

[Flown]

Java-Byte-Code, der auf einer I586-Maschine läuft, muss auf einem ARM-System nicht funktionieren, auch wenn auf beiden ein JRE läuft.

Wenn beide eine vollwertige JVM haben, dann ist das garantiert, sonst wäre die JVM witzlos (außer natürlich man verwendet OS spezifischen Code - Pfade z.B.)

 

[mrBrown]

Haha, ehrlich?

Ja.

Computer-Systeme verfügen neben der physikalischen Uhr, die nur im Sekundentakt (1Hz) synchronisiert, eine logische Uhr. Betriebssysteme aktualisieren diese Uhr im Time Slice durch interrupts (musst du nachlesen). Die Aktualisierung der logischen Uhr variiert zwischen 10ms und 50ms, abhängig vom BETRIEBSSYSTEM!

In wie vielen Java-Programmen spielt die Aktualisierungsfrequenz der Uhr eine Rolle?
Die Ungenauigkeit steht übrigens in der Doku.

Java-Byte-Code, der auf einer I586-Maschine läuft, muss auf einem ARM-System nicht funktionieren, auch wenn auf beiden ein JRE läuft.

Wenn ich, schlicht wie ich bin, strikt nach Doku programmiere, wann hab ich damit Probleme? Hast du irgendein Beispiel?

 

[Manuel.R]

Glaub mir, es gibt viele Gründe....
https://dzone.com/articles/does-write-once-run-anwhere

Einer kann zum Beispiel der JIT-Compiler sein. Der Übersetzt den Byte-Code in native Maschinen-Sprache. Das kann gewollt sein oder auch nicht. Aber es führt dazu, dass man sich gedanken machen muss, um evaluieren, geht das überall durch oder nicht.
Und eine andere Frage an der Stelle kann sein: Was mache ich, wenn es ein JIT-Compiler gibt, wie vehält sich der Code dann.

Es gibt viele Artikel, die zeigen, dass das Konzept/Ziel eigentlich gescheitert ist.

Aber dennoch bin ich ein riesen Fan davon, zu sagen, dass es eigentlich überall (einer JRE) laufen "könnte". Die Anpassungen wären zum Teil nur marginal.

Ach Mensch.....

Von JavaEE-Entwicklung wollen wir erst gar nicht anfangen.....

Zum größten Teil kannst du es vergessen, dass eine Enterprise Anwendung, die vielleicht für den JBoss/wildfly entwickelt wurde auf einem IBM Websphere unfallfrei läuft.

 

[mrBrown]

Glaub mir, es gibt viele Gründe....
https://dzone.com/articles/does-write-once-run-anwhere

Na in diesem Artikel werden zumindest keine wirklichen genannt...

Einer kann zum Beispiel der JIT-Compiler sein. Der Übersetzt den Byte-Code in native Maschinen-Sprache. Das kann gewollt sein oder auch nicht. Aber es führt dazu, dass man sich gedanken machen muss, um evaluieren, geht das überall durch oder nicht.
Und eine andere Frage an der Stelle kann sein: Was mache ich, wenn es ein JIT-Compiler gibt, wie vehält sich der Code dann.

Keine Ahnung was du da herbei fabulieren willst, aber der JIT-Compiler ist nun wirklich absolut nichts, über das man sich bezüglich Plattformunabhängigkeit Gedanken bei der Entwicklung machen müsste...
Falls ich da falsch liege: Wann hast du dir zum letzten Mal Gedanken gemacht, ob das mit dem JIT läuft, und wolltest es lieber ohne laufen lassen, und was war der Grund dafür?

Von JavaEE-Entwicklung wollen wir erst gar nicht anfangen.....

Zum größten Teil kannst du es vergessen, dass eine Enterprise Anwendung, die vielleicht für den JBoss/wildfly entwickelt wurde auf einem IBM Websphere unfallfrei läuft.

Das ist eher ein schönes Beispiel dafür, dass Plattformunabhängigkeit am Entwickler hängt.
Oder erwartest du wirklich, dass ein für eine bestimmte Plattform entwickeltes Programm immer noch Plattformunabhängig ist?

 

[Manuel.R]

Hast du jemals Java Benchmarks im Vorfeld vom JMH entwickelt?

 

[Manuel.R]

Alleine die unterschiedlichen JVM-Implementierungen sagen schon alles zur Plattform-Unabhängigkeit. Es gibt die JRocket-JVM, Sun-JVM, IBM-JVM.
Fast überall läuft der Garbage-Collector anders. Nicht für jede Plattform ist die jeweilige JVM erhältlich.

 

[Flown]

In diesem Thread geht es um Plattformunabhängigkeit, die ein Entwickler beachten sollte. Wenn er Java verwendet, dann gibt es ein paar Dinge die eben vermieden werden sollten, wie z.B. absolute Pfadangaben.
Wenn man das beachtet hat, dann kann man den Spaß kompilieren und auf jeder x-beliebigen JVM laufen lassen. Das nennt sich dann Plattformunabhängigkeit, denn es ist egal worauf die JVM läuft.

Was du da herschwadronierst, macht überhaupt keinen Sinn. Denn es ist klar, dass die JVM nicht plattformunabhängig ist, aber das hat mit der Entwicklung überhaupt nichts zu tun.

JavaEE ist auch plattformunabhängig: Denn es ist egal, auf welchem JEE Application Server meine App laufen lasse, wenn ich mich an den Standard gehalten habe.

 

[Flown]

Alleine die unterschiedlichen JVM-Implementierungen sagen schon alles zur Plattform-Unabhängigkeit. Es gibt die JRocket-JVM, Sun-JVM, IBM-JVM.
Fast überall läuft der Garbage-Collector anders. Nicht für jede Plattform ist die jeweilige JVM erhältlich.

Interessiert den 0815 Entwickler überhaupt nicht! Wichtig ist nur wenn ich java MeineApp eingebe, läuft das Ding.

 

[mrBrown]

Hast du jemals Java Benchmarks im Vorfeld vom JMH entwickelt?

Jetzt hast du einen speziellen Anwendungsfall gefunden, in dem Kenntnisse des JITs eine Rolle spielen. Wo ist jetzt der Zusammenhang zur Plattformunabhängigkeit?

Alleine die unterschiedlichen JVM-Implementierungen sagen schon alles zur Plattform-Unabhängigkeit. Es gibt die JRocket-JVM, Sun-JVM, IBM-JVM.
Fast überall läuft der Garbage-Collector anders. Nicht für jede Plattform ist die jeweilige JVM erhältlich.

Aber das Java-Programm läuft auf jeder JVM, wenn man sich an Standards hält. Völlig unabhängig von JVM, GC und Plattform.

 

[Manuel.R]

Okay, eins noch: Es kommt auf das Programm an! So hört sich das besser an. Wenn ich ein Programm entwickle für ein Datei-, Verwaltungs- und Berechtigungsystem, dann sollte ich mir schon Gedanken über die Plattform (Betriebssystem) machen. Ich weiß nicht wie das heute ist aber damals lagen einige Betriebsysteme weit auseinander, Stichwort Access Control Matrix.

Ich weiß, Anfänger-Themen.... aber WORA bzw. Plattformunabhängigkeit ist ein Mythos, der in der privaten Entwicklungswelt vielleicht stimmt aber zusammenfassend muss gesagt werden, dass es das nicht zu 100% gibt.

Da kann ich mich an einen s... Standard halten wie ich will. Und an dieser Stelle bildet die Plattform das Auschluss-Kriterium, nicht die JVM.

Will ich 1+1=2 rechnen dann läuft das überall, okay. Mit Zunahme der spezifischen Funktion der Anwendung fällt auch die Plattformunabhängigkeit.

Macht was ihr wollt mit der Aussage, das ist meine Meinung und kein "schwadronieren".

 

[mrBrown]

Macht was ihr wollt mit der Aussage, das ist meine Meinung und kein "schwadronieren".

Wollen wir nicht statt über Meinung lieber über Fakten reden?

Und willst du nicht statt ständig neue Dinge in den Raum zu werfen, irgendwann mal auf eine der ganzen Antworten eingehen?
Ich hab extra zu so jedem deiner Punkte nach einem Beispiel gefragt...

Da kann ich mich an einen s... Standard halten wie ich will. Und an dieser Stelle bildet die Plattform das Auschluss-Kriterium, nicht die JVM.

Welche Teile der Plattform werden denn durch die JVM nicht so abstrahiert, dass sie Plattformspezifisch sind?

Will ich 1+1=2 rechnen dann läuft das überall, okay. Mit Zunahme der spezifischen Funktion der Anwendung fällt auch die Plattformunabhängigkeit.

Welche spezifischen Funktionen kann ich mit Java ohne(!) zusätzliche native Libs nutzen, die Plattformabhängig sind?

 

[Flown]

Schade, keine Rückmeldung mehr