habe wegen swing etwas nachlesen muessen. theoretisch stimmt das schon, abu. mit einsatz der swing klassen wird es portabler.
da sage ich aber bewusst theoretisch und portabler - nicht portabel.
Folgende Gruende:
Um die UI-Steuerung portabel zu machen, muessen sich die klassen auf den common denominator beschraenken. wer mit puren java anwendungen schon gearbeitet hat, weiss, wie das ist. recht mager und funktionell auf dem stand von windows 2.0
andere technologien wie model view controller schaffen portabilitaet nativ.
ich benutzte bewusst das wort ui paradigma ( - denkmuster - ). ein beispiel: portiere ich eine anwendung von sagen wir xp auf ein smartphone, dann habe ich eine voellig andere analogie. und dann noch von phone zu phone anders.
selbst innerhalb eines aehnlichen paradigmas: apple benutzt einen mausknopf, windows (meist) 2. simples beispiel mit grosser wirkung: wie setze ich die ganzen (guten) kontext sachen des rechten mausknopfes auf apple um?
dies sind gruende, weshalb sich java fuer server-anwendungen recht schnell durchsetzte, beim frontend jedoch nicht.
beim frontend kam die allgegenwaertige praesenz der browser ganz schnell. das damit implementierte paradigma (dokument) ist intuitiv und hat sich durchgesetzt. daher kommt der grosse bedarf an web-orientierten anwendungen. und die frage nach portabilitaet stellt sich gar nicht mehr, ausser wieweit ein gegebener browser standarts befolgt oder nicht.