Ich enthalte mich jetzt mal meiner sehr ausführlichen Meinung über NICHT-M$-Systeme da das zu OT werden würde. Lass dir nur soviel zu meiner Meinung sagen : wer meint sich ein nicht-Mainstream-System zulegen zu müssen der muss auch damit leben können das Dinge die für den Mainstream konzipiert sind unter seinem System nunmal nur schlecht oder im meisten Fall überhaupt nicht laufen.

Wie gesagt : mit SUN-JRE *im Übrigen v7-ea* läuft das alles ohne Probleme ... sowohl unter MS Win als auch unter OpenSuSE.

SUSE war mein erstes Linux, dass aber schon Jahre her

Zitat von SPiKEe

Lass dir nur soviel zu meiner Meinung sagen : wer meint sich ein nicht-Mainstream-System zulegen zu müssen der muss auch damit leben können das Dinge die für den Mainstream konzipiert sind unter seinem System nunmal nur schlecht oder im meisten Fall überhaupt nicht laufen.

Ich stimme dir zu das die Wirtschaft hauptsächlich Produkte für diejenigen Betriebsysteme entwickelt bei denen die maximale Kaufkraft zu finden ist und das ist bei M$ Windows richtig. Auf der anderen Seite muss derjenige der so ein Betriebsystem einsetzt auch mit seiner zumüllung leben (sei nur Registry und DLLs von Drittsoftware im Systemverzeichnis genannt). Da bin ich mit der strikten trennung von System und Userland wie es bei FreeBSD der Fall ist trotz mangelndem Angebot von Drittsoftware sehr zufrieden. Auch die integrierte root Plattenverschlüsselung mittels dem hauseigenen GELI die mir wichtig ist schätze ich sehr. Sowie das Kernel und Userland von der gleichen Community entwickelt wird und die Ports Collection eine flexible und transparente Installationslösung darstellt. Und zu erwähnen ist auch noch die sehr gute Dokumentation auch in Deutsch.

Es muss am ende jeder selbst entscheiden was er genau haben will, die Pro und Kontras abwägen. Die eierlegende Wollmilchsau wird man jedenfalls nicht finden, weder mit FreeBSD noch mit Windows oder Linux. Aber du hast recht, wir werden langsam etwas Off-Topic

Ich konnte jetzt doch noch linux-sun-jdk16 installieren, der Fehler lag wohl nicht am Makefile bzw. beim Port-Maintainer sondern bei mir. Hab die gleichnamige aber ältere *.bin Datei heruntergeladen und weil die Dateiprüfung auch noch via Hashwert von statten geht war das fehlen der Datei die Folge (leider mit mangelnder Fehlerausgabe, weshalb ich es auf anhieb nicht merkte).

Aber dennoch, auch mit dem linux-sun-jdk16 (das offizielle Java für Linux) bleibt das Problem bestehen. Hab dann noch OpenJDK7 ausprobiert mit gleichem Resultat. Alle JDKs verhalten sich demnach zu 100% exakt gleich, man könnte schon fast sagen sie sind sauber synchron implementiert (ja, JAVA_HOME war richtig gesetzt )

Spass bei Seite, weil du nun sagst du verwendest die SUN JDK 7 glaubst du wirklich das es so ein gravierender Unterschied zu den anderen drei JDKs gibt? Das diablo-jdk-16 ist die native SUN JDK für FreeBSD (1.6 Update 7), die linux-sun-jdk16 ist die auf der ABI (Fedora Linux) laufende offizielle SUN JDK (1.6 Update 24) und die openjdk7 ist das Open Source JDK 1.7. Generell funktionieren alles LAFs, nur bei ein paar externen passiert beim Umschalten von den externen LAFs zurück zum Metal LAF diese unerwüschnten Effekte.

Aber gut, wenigstens hab ich nun mit openjdk7 endlich den Nimbus drauf, ist ja mal schon was

Zitat von xoom4

Auf der anderen Seite muss derjenige der so ein Betriebsystem einsetzt auch mit seiner zumüllung leben (sei nur Registry und DLLs von Drittsoftware im Systemverzeichnis genannt).

Da muss ich dir allerdings mal voll und ganz zustimmen. Ich meine gut .. Registry is jetzt auch kein so riesen File und man muss schon ne ganze Menge reinpumpen um auslastungs-Erscheinungen zu bemerken ... aber eigentlich gehört sowas schon strikt getrennt.

Alles andere was ich jetzt hier schreiben würde wäre dann aber wirklich ZU OT ...

//EDIT
Wie gesagt ... es könnte auch daran liegen das ich das 3D-Rendering von Java deaktivieren muss damit keine Fehler durch das CCC2 von AMD erstehen *such mal bei Google nach "java ati radeon schwarze fenster"* ... vieliecht liegt es auch daran ... *da ich leider keinen 2ten Rechner mit NICHT ATI-Karte habe kann ichs leider nicht mit 3D-Rendering testen.

Hab das mit dem "-Dsun.java2d.d3d=false" auf allen JDKs ausprobiert, die Effekte waren die gleichen. Nunja, ich werd halt für die Problem LAFs halt das mit den MessageBoxen implementieren. Ist ja jetzt nicht lebensnotwendig das alle on the fly umgeschaltet werden müssen. Sollte ich demnächst auch wieder mal Zugriff auf einen zweit Rechner haben werde ich dort meine Applikation mal ausprobieren und schauen ob der Effekt noch besteht.

Also ich persönlich würde sowieso sowas immer non-on-the-fly machen ... aber das ist eher Geschmackssache.

Zitat von SPiKEe

Also ich persönlich würde sowieso sowas immer non-on-the-fly machen ... aber das ist eher Geschmackssache.

Darf ich erfahren warum du non-on-the-fly Lösungen bevorzugst? Schreibfaul?

Nein nein ... so war das nicht gemeint ...
Natürlich baue ich sehr viel on-the-fly ... aber etwas ... nun ich nenne es jetzt mal "elementares" wie das "Design" *im Sinne von Java : Look&Feel* sollte grundsätzlich einen App-Neustart erfordern, denn L&F's sind in dem Sinne nichts fest statisch gelinktes sondern dynamisch geladenes. Das Problem bei Java ist aber etwas dynamisch geladenes auch irgendwie wieder freigeben zu können so lange noch etwas darauf zugreift. Das ist nämlich unmöglich ! Darum gibt es auch extrem viele Programme wo man sich denkt : diese Änderung ist doch dynamisch ... und dann bei genauerer Analyse feststellt : im Anbetracht des Programmflusses ist "ES" an dieser Stelle statisch / wird blockiert und kann gar nicht geändert werden.

DAS ... und nichts anderes war damit gemeint.

btw : das Java die Möglichkeiten hat L&F , Design und Layout dynamisch zu ändern *mit entsprechendem Code* erleichtert es uns gegenüber einigen Sprachen soetwas auch wirklich als dynamisch änderbares Feature einzubauen.