Will mir jemand erklaeren wofuer man Module wirklich braucht?

[Robert Zenz]

Also ich bin hier ein alter Mann und verstehe noch nicht wo mir diese Neuerung helfen soll (und bleibt gefaelligst von meinem Rasen unten!). Etwas ernster, ich sehe gerade keinen Anwendungsfall bei dem Module eine Verbesserung bringen, kann aber gut sein dass ich nicht die Zielgruppe bin oder einfach nicht in der richtigen Ecke dafuer. Ich weisz das Module eigentlich den Klassenpfad abloesen sollten, aber dann doch irgendwie was aehnliches geworden sind (Stichwort Versionen von Abhaengigkeiten). Als die beiden Argumente fuer Module hoere ich immer "explizite und klare Abhaengigkeiten" und "Kapselung". Ich fange vielleicht mal damit an wo ich bei meinem Anwendungsfaellen keine Verbesserung sehe.

Beim ausliefern Desktop-Applikationen sehe ich keine Aenderungen ob nun ein Modul oder nicht. Das endgueltige Paket wird von mir gebaut, damit spielt sind Abhaengigkeiten mein Problem, nicht das des Nutzer. Die Laufzeit-Umgebung kontrolliere ich nicht, die Kontrolle ueber das Paket welches ausgefuehrt wird gebe ich genauso ab. Also ob nun eine starke Kapselung erzwungen wird oder nicht kann ich nicht bestimmen. Fuer Desktop Applikationen gibt es dann noch das Argument von Native Images, welchem ich ebenfalls relativ kritisch gegenueber stehe da ich Java verwende weil "Build once, run anywhere", und wenn ich eine Applikation als Native Image ausliefere, ich fuer jedes Zielsystem ein eigenes Paket bauen muss (ich muss dann auch alle testen, theoretisch, und es sind keine Pakete fuer "exotische" oder neue Plattformen verfuegbar, weil die muss man erst bauen). Ist aber ein anderes Thema. (Ja, ich weisz, "Java am Desktop ist tot lolroflmao das macht niemand mehr auf der ganzen Welt rofl!1")

Wenn ich eine Server-Applikation habe, sind die Abhaengigkeiten ebenfalls mein Problem, nicht dass des Admins, spielen also keine Rolle. Die Laufzeit-Umgebung hingegen kontrolliere ich (oder halt der Admin), also was dort passiert liegt bereits unter meiner Kontrolle. Selbiges gilt fuer Servlets und aehnliche. Auch hier sehe ich keine unmittelbare Verbesserung.

Wenn ich eine Bibliothek bereitstelle, wird es hingegen interessanter. Die expliziten Abhaengigkeiten klingen hier nach einer guten Hilfe, da aber weder Versionen noch Repositories inkludiert sind, muss ich erst wieder auf Ivy/Maven/Gradle zurueck fallen um diese zu verwalten. Ebenfalls interessant klingt im ersten Moment die Kapselung, ich kann also einem Benutzer meiner Bibliothek verbieten in das Paket "x.y.z" zu greifen...nur dass mir das nichts nuetzt und ist genauso erzwingbar wie wenn ich das Paket "x.y.impl.z" nennen wuerde. Ich habe eine zeitlang mit ein paar GUI-Bibliotheken zu tun gehabt welche final und package-private sehr, sehr freizuegig verwendet haben um ihre Vorstellungen von Kapselung durchzusetzen. Das Ergebnis am Ende war dass ich die entsprechenden Dateien in mein Projekt kopiert, gepatcht und einfach im Klassenpfad zuerst gesetzt habe um die Funktionalitaet zu erzielen welche ich haben musste. Ja, der "korrekte" Weg waere ein Ticket zu oeffnen am besten mit MR...ich brauche die Funktionalitaet aber *jetzt* nicht in sechs Monaten nach wochenlanger Diskussion wieso ich das will. Also ist es ein interessanter Mechanismus, aber nicht erzwingbar und damit in etwa der gleiche Wert wie wenn ich es im Javadoc vermerke (die Javadoc Notiz haette fuer den Benutzer sogar den Vorteil dass dieser nicht erst durch Reifen springen muss wenn er es doch machen will).

Wenn ich eine Bibliothek verwende, ist es natuerlich interressant zu sehen dass diese wirklich nur diese Klassen aus dem Paket dort verwendet, ich kann mich aber nicht erinnern dass mich das jemals interessiert hat. Wenn die Bibliothek "A" API "B" implementiert aber in Wahrheit von "C" Implementierungsdetails zieht, habe ich so oder so verloren als Benutzer von "A", egal ob Module oder nicht. Klar, "C" koennte das mit einem Modul verhindern, aber zum einen "A" einen Grund dafuer haben, und zum anderen kann "A" ja einfach d'rum herum arbeiten und es wieder umgehen.

So wie ich die Beschreibungen des Modul-Systems bis jetzt verstanden habe, klingt der Anwendungsfall nach Embedded. So etwas wie Android, nur noch zugesperrter, wo man mehrere unbekannte Module in die selbe Laufzeitumgebung laedt und diese so gut von einander trennen will wie man kann.

Kann mich hier jemand aufklaeren was genau ich uebersehe?

 

[Flown]

Meine 10cent zu diesem Thema: man braucht Module nur, wenn man eine eigene Runtime zu einer Applikation ausliefern möchte, damit nicht jeder eine ~700MB JRE zu installieren hat. Applikation ist dann ~20MB groß und liefert nur was es braucht.

Hingegen bei Server-Applikationen da gibts Lösungen wie Quarkus mit Native build. Da brauchst du wiederum keine Module.

 

[httpdigest]

Japp. Das Java Platform Module System hat hauptsächlich für die Modularisierung und Wartung des JREs selbst geholfen und dem Ziel, wie @Flown schon sagte, kleine Runtimes assemblen und ausliefern zu können durch klare Dependency-Deklarationen der JRE-Module (und nicht third-party Libraries).
Von den Zielen/Goals von Project Jigsaw: https://openjdk.java.net/projects/jigsaw/ können wir eigentlich zwei hervorheben:

• Make it easier for developers to construct and maintain libraries and large applications;
• Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular;
• Enable improved application performance; and
• Enable the Java SE Platform, and the JDK, to scale down for use in small computing devices and dense cloud deployments.

Das erste und dritte Ziel sehe ich persönlich nicht erfüllt oder zumindest nicht _besser_ erfüllt, als mit den Mechanismen, die es schon seit Jahrzehnten gibt.

 

[White_Fox]

Auch wenn mein Einblick darin nur ein kleiner ist (ein einziges lokales Desktopprogramm): Mir hat sich das Modulsystem auch nicht erschlossen. Abgesehen davon daß ich es nicht nutze fiel mir auch kein theoretischer Fall ein, wo es sinnvoll sein könnte.

Nicht daß das Kapselungssystem nicht noch verbesserungsbedürftig wäre – ich persönlich könnte einen vierten Sichtbarkeitsmodifizierer gut gebrauchen – aber das ist eine andere Baustelle.

 

[mihe7]

persönlich könnte einen vierten Sichtbarkeitsmodifizierer gut gebrauchen

Welchen?

 

[httpdigest]

Ich persönlich fände es fantastisch, wenn Java auch "friend" kann.
Ich habe eine Library, in der ein public/exposed/exported Package ist und ein private/internal Package. Klassen im public Package sind von außen sichtbar und durch Clients nutzbar. Klassen im internal Package sind package-private. ABER, ich will, dass Klassen im internal Package auf private/protected Members von Klassen im public Package zugreifen können sollen.

 

[Oneixee5]

damit nicht jeder eine ~700MB JRE zu installieren hat

Das JRE8 ist bei mir 206 MB groß, das 17er-JDK noch nicht mal 300MB - also so groß wie eine Word-Datei
Die Größe ist mir einfach egal, wer es klein haben will soll eben Assembler programmieren.

 

[Robert Zenz]

Meine 10cent zu diesem Thema: man braucht Module nur, wenn man eine eigene Runtime zu einer Applikation ausliefern möchte, damit nicht jeder eine ~700MB JRE zu installieren hat. Applikation ist dann ~20MB groß und liefert nur was es braucht.

Ist natuerlich etwas das ich sehen kann, aber wenn mann eine Applikation mit ein paar Kilobyte hat welche denn ~20MB grosz wird, blutet einem auch so ein biszchen das Herz. Es ist halt schade dass das einzige Betriebssystem auf welchem das bereitstellen einer JVM ein "Problem" ist, auch das am weitesten verwendete Desktop System ist. Ist halt doof gelaufen. Auch nicht toll war das sich Java==Applet==Boese durchgesetzt hat in vielen Koepfen (und Google hat da meiner Meinung nach auch nicht geholfen...Oracle sowieso nicht, Oracle haben Java nur um Google zu verklagen).

Hingegen bei Server-Applikationen da gibts Lösungen wie Quarkus mit Native build. Da brauchst du wiederum keine Module.

Das klingt schon echt gut, eines schoenen Tages muss ich mir mal ein Projekt mit dem Zeug suchen.

Japp. Das Java Platform Module System hat hauptsächlich für die Modularisierung und Wartung des JREs selbst geholfen und dem Ziel, wie @Flown schon sagte, kleine Runtimes assemblen und ausliefern zu können durch klare Dependency-Deklarationen der JRE-Module (und nicht third-party Libraries).
Von den Zielen/Goals von Project Jigsaw: https://openjdk.java.net/projects/jigsaw/ können wir eigentlich zwei hervorheben:

Das erste und dritte Ziel sehe ich persönlich nicht erfüllt oder zumindest nicht _besser_ erfüllt, als mit den Mechanismen, die es schon seit Jahrzehnten gibt.

Stimme ich dir zu, das war so auch mein Stand...nur habe ich bis jetzt noch wenig an die JVM gedacht, ja.

Nicht daß das Kapselungssystem nicht noch verbesserungsbedürftig wäre – ich persönlich könnte einen vierten Sichtbarkeitsmodifizierer gut gebrauchen – aber das ist eine andere Baustelle.

Ja. package-private ist der Teufel und meiner Meinung nach sollten protected die Sachen nicht fuers Paket oeffnen. Da waere sowas wie friend um die Luecke zu fuellen schoen.

Das JRE8 ist bei mir 206 MB groß, das 17er-JDK noch nicht mal 300MB - also so groß wie eine Word-Datei

Ich will's nicht wissen ich will's nicht wissen ich will's nicht wissen ich will's nicht wissen ich will's nicht wissen ich will's nicht wissen ich will's nicht wissen...

Die Größe ist mir einfach egal, wer es klein haben will soll eben Assembler programmieren.

Naja, Nein. Aber wir muessen hier zwischen JVM (einmalig) und Applikationen (viele) unterscheiden. Wenn du dir 200MB JVM installierst, hast du die einmal. Wenn du dir 100 Java Applikationen mit ~20MB ziehst hast du mehr als mit einer einmaligen JVM Installation. Ich finde es auch nicht schlimm dass man die JVM Installation vorraussetzt, aber wie gesagt, es gibt da ein Betriebssystem welches in der Hinsicht biszchen kacke ist.

Ein weiterer Nachteil von Native Images faellt mir hier gerade auf: Man kann sie nicht mit einer neueren oder aelteren JVM ausfuehren (Bugs und Bug-Fixes).

 

[httpdigest]

Sorry, das ist vielleicht etwas nitpicking/Haarspalterei von mir, aber: Immer dann, wenn du "JVM" schriebst, meintest du eher das JRE, bzw. genauer gesagt die "Class Library" des JREs. Die JVM ist ja nur der Teil, der für die Ausführung von per Bytecode bereitgestellten Klassen zuständig ist (also im OpenJDK eben HotSpot). Die "Class Library" ist das, was ich meinte mit der Modularisierung des JREs. Und das JRE selbst ist JVM + Class Library. Und dann gibt's ja noch das JDK. Das ist quasi JRE + Development-Tools wie javac, javap, jlink, jarsigner, etc. sowie C Header Files für JNI Programmierung, was man alles nur für die Entwicklung aber nicht für die Ausführung von Java-Programmen braucht.

 

[Robert Zenz]

Hast du vollkommen Recht.

 

[White_Fox]

package-private ist der Teufel

Hm, warum das? (Nur aus Neugier, ich hab ja von Programmierung keine Ahnung. Ich rede hier ja auch nur mit um dazuzulernen.
)

meiner Meinung nach sollten protected die Sachen nicht fuers Paket oeffnen

Das tut protected doch auch nicht, das öffnet die Sichtbarkeit ja nur für Vererbungsbaummitglieder...oder überseh ich da was?

 

[Robert Zenz]

Hm, warum das?

Weil es, meiner Meinung nach, furchtbares Design ist wenn du Klassen hast welche ueberall verwendet werden, aber von niemandem auszerhalb verwendet werden duerfen. Das, und viele verwenden es falsch. Zum Beispiel JavaFX hat eine MVC-Teilung, also das Steuerelement, die Logik und das Aussehen getrennt. Dummerweise sind viele dieser Implementierungen package-private, und haengen von einander ab. Teilweise hingen sogar die Steuerelemente selbst von den package-private Klassen ab, was nauterlich bedeutet dass du, als Aussenstehende, das niemals erweitern kannst. Vaadin hatte da auch so ein paar Probleme in der Hinsicht.

Klassisches Beispiel ist das man aus Versehen so eine API baut:

public class Machine {
    public List<Part> getParts() { /* ... */ }
}

class Part {
    // ...
}

Faellt dir nicht auf, da du dich immer im selben Paket bewegst, aber jedem anderen schon. Ein weiteres Beispiel waere zum Beispiel so etwas:

public class Machine {
    public void operate() {
        for (Part part : parts) {
            if (part instanceof CustomPart) {
                ((CustomPart)part).someComplexOperation();
            }
        }
    }
}

public class Part {
    // ...
}

class CustomPart extends Part {
    void someComplexOperation() { /* ... */ }
}

Du willst jetzt die Funktionalitaet erweitern...wie macht man das? Richtig, man erzeugt sich eine Klasse im selben Paket wie CustomPart damit man darauf zugreifen kann. Damit verteilt man die Funktionalitaet welche man braucht natuerlich ueber mehrere Pakete statt diese "im eigenen" zu halten.

Noch besser sind dann solche Sachen:

public class MachineFactory {
    public Machine create() {
        return new Machine(new CustomPart());
    }
}
public class Machine {
    public Machine(CustomPart part) { /* ... */ }
}

public class Part {
    // ...
}

class CustomPart extends Part {
    // ...
}

Oder so etwas:

public class Machine {
    public void operate() {
        part.complexOperation();
    }
}

public class Part {
    void complexOperation();
}

Also package-private erlaubt es, quasi querbeet, auf irgendwelche "internen" Dinge zu greifen, was meiner Meinung nach darauf hinweist dass man da schlechtes Design hat. Entweder die Sachen sind private weil nur diese Klasse darauf zugreifen muss, oder sie sind irgendwie oeffentlich gemacht fuer alle, aber wenn "B" und "C" auf internes von "A" zugreifen ohne eine gut definierte Schnittstelle, zeigt dass das irgendwie was nicht stimmt. Zum Beispiel:

public class Machine {
    List<Part> parts = new ArrayList<>();
    
    public Lis<Part> getParts() {
        return Collections.unmodifiableList(parts);
    }
}

public class SomeOtherClass {
    public void doYourThing() {
        machine.parts.add(new CustomPart());
    }
}

Offensichtlich sollten "parts" nur readonly sein, auszer "fuer die Klasse da weil...". Alles schon gesehen, alles Kacke wenn man da d'rum herum arbeiten muss. package-private ist der Teufel.

Das tut protected doch auch nicht, das öffnet die Sichtbarkeit ja nur für Vererbungsbaummitglieder...oder überseh ich da was?

Ja, naemlich dass es genau das tut. Ich tue aber immer so als wuerde es dies nicht (ist auch besser so).

 

[White_Fox]

Hm...keine Frage, die Beispiele die du da zeigst sind grober Käse.

So ganz verteufeln würde ich aber package private dennoch nicht...manchmal kann es schon praktikabler sein, denke ich. Ich hatte mal das Problem, das eine Klasse zwar eine einzige Aufgabe hatte, um diese Aufgabe zu bewerkstelligen aber vier Teilaufgaben notwendig waren und die Klasse am Ende ca. 1.000 Codezeilen hatte.
Die Lösung bestand dann am Ende darin, die vier Teilaufgaben in andere Klassen auszulagern.
Allerdings wollte ich verhindern, daß man von außen die vier Teilaufgaben nach Belieben ausführen kann - davon soll bitte auch niemand irgendwas vererben. Also wurden diese vier Teilklassen (und noch jede Menge anderes Zeug mehr) package-private. Öffentlich zugänglich war am Ende lediglich eine Klasse mit ein paar Methoden.

Ich bin eigentlich ein großer Freund davon, Sichtbarkeit erstmal total zu verbieten und nur wenn nötig, schrittweise freigzueben und dann auch nur dem, der es braucht.

 

[Robert Zenz]

So ganz verteufeln würde ich aber package private dennoch nicht...manchmal kann es schon praktikabler sein, denke ich. Ich hatte mal das Problem, das eine Klasse zwar eine einzige Aufgabe hatte, um diese Aufgabe zu bewerkstelligen aber vier Teilaufgaben notwendig waren und die Klasse am Ende ca. 1.000 Codezeilen hatte.
Die Lösung bestand dann am Ende darin, die vier Teilaufgaben in andere Klassen auszulagern.
Allerdings wollte ich verhindern, daß man von außen die vier Teilaufgaben nach Belieben ausführen kann - davon soll bitte auch niemand irgendwas vererben. Also wurden diese vier Teilklassen (und noch jede Menge anderes Zeug mehr) package-private. Öffentlich zugänglich war am Ende lediglich eine Klasse mit ein paar Methoden.

Da wuerde ich im ersten Moment an Inner-Klassen denken. Aber laesst sich jetzt von meiner Warte aus leicht sagen.

Ich bin eigentlich ein großer Freund davon, Sichtbarkeit erstmal total zu verbieten und nur wenn nötig, schrittweise freigzueben und dann auch nur dem, der es braucht.

Ich bin eigentlich auf der gegenteiligen Schiene unterwegs, eher zugaenglich machen als verstecken. Ich bin einmal zu oft von einer Bibliothek abhaengig gewesen welche final viel zu groszzuegig verwendet. Also eher protected anstatt private, aber natuerlich unter dem Gesichtspunkt dass man die Paketzugaenglichkeit ignoriert und nicht verwendet (der Teufel!).

Also nach dem Grundsatz "Wenn jemand die Klasse erweitern muss, braucht er auch Zugang zum Zustand und die Moeglichkeit diesen zu aendern".

Mein Beispiel ist da so eine Klasse:

public class ComplexAction {
    private int valueA = 0;
    private int valueB = 0;
    
    public ComplexAction(int valueA, int valueB);
    
    public int performAction(int parameterA, int parameterB);
    private int calculateValueC(int parameterA);
    private int calculateValueD(int parameterB);
}

Die Klasse ist "Standard", aber an der kann man nichts erweitern. Die ist quasi final aber ohne dass zuzugeben. Wenn man jetzt zum Beispiel die Berechnung von "C" austauschen will, muss man die gesamte Klasse kopieren. Also effektiv und konsequent muesste man sie eigentlich so schreiben:

public final class ComplexAction {
    private final int valueA;
    private final int valueB;
    
    public ComplexAction(int valueA, int valueB);
    
    public final int performAction(int parameterA, int parameterB);
    private int calculateValueC(int parameterA);
    private int calculateValueD(int parameterB);
}

Ist naemlich eigentlich ident. Wohingegen wenn man Zugriff erlaubt:

public class ComplexAction {
    protected int valueA = 0;
    protected int valueB = 0;
    
    public ComplexAction(int valueA, int valueB);
    
    public int performAction(int parameterA, int parameterB);
    protected int calculateValueC(int parameterA);
    protected int calculateValueD(int parameterB);
}

Dann hat eine Erweiterung zumindest die Chance etwas an der Logik zu Klasse tatsaechlich zu erweitern. Klar, ist jetzt auch nicht das Gelbe vom Ei eigentlich, aber meiner Meinung nach besser als die Quasi-final Variante. Man kann ja den Zugriff dann noch weiter strukturieren fuer Ableitungen:

public class ComplexAction {
    private int valueA = 0;
    private int valueB = 0;
    
    public ComplexAction(int valueA, int valueB);
    
    public int performAction(int parameterA, int parameterB);
    protected int calculateValueC(int parameterA);
    protected int calculateValueD(int parameterB);
    protected final int getValueA();
    protected final int getValueB();
    protected final void setValueA(int valueA);
    protected final void setValueB(int valueB);
}

Damit kann dann die Klasse auch Bedingungen fuer die Werte von "A" und "B" durchsetzen.

 

[Robert Zenz]

Duplikat durch Server-Fehler...bitte ignorieren...ich sagte ignorieren, hoer auf zu lesen! ... Ich mein' das ernst! Hoer auf...gut, dann hoer halt ich zuerst auf...bah...

 

[mihe7]

Ich bin einmal zu oft von einer Bibliothek abhaengig gewesen welche final viel zu groszzuegig verwendet. Also eher protected anstatt private, aber natuerlich unter dem Gesichtspunkt dass man die Paketzugaenglichkeit ignoriert und nicht verwendet (der Teufel!).

Da kommt es m. E. darauf an, was die Intention der Lib ist.

Beim Design eines Frameworks sollte im Kopf behalten werden, dass es gerade Sinn und Zweck der Sache ist, nur die Basis zur Verügung zu stellen. In Swing wurde das m. E. recht gut gelöst, im Gegensatz zu JavaFX, wo praktisch alles private ist, was nur irgendwie private sein kann.

 

[Robert Zenz]

In Swing wurde das m. E. recht gut gelöst, im Gegensatz zu JavaFX, wo praktisch alles private ist, was nur irgendwie private sein kann.

Ja, das ist auch meine Erfahrung. Komponenten von JavaFX erweitern zu muessen hat mich zu dem package-private und final Hasser gemacht der ich bin.

Da kommt es m. E. darauf an, was die Intention der Lib ist.

Die Intention einer Lib sollte es immer sein Funktionalitaet zur Verfuegung zu stellen. Arbitraere Limitationen "weil einem danach ist" oder "das ist gaengige Praxis (in der Akademik)" sind da nicht so toll. Also einfach jede Klasse final in einer Lib bringt echt wenig, weil man dann einfach dem Verwender jede Moeglichkeit nimmt es auf einen leicht abweichenden Anwendungsfall anzupassen. Da gibt es dann nur zwei Loesungsmoeglichkeiten: Andere Lib nehmen oder Code kopieren und anpassen...und beides sollte vermieden werden.

Klar gibt es Faelle wo es Sinn macht, aber so flaechendeckend und freizuegig wie in vielen Projekten sicher nicht. Da ist mir lieber ich schiesze mir dreimal in den Fuss weil ich etwas ueberschrieben habe was nicht dafuer gedacht war, als dass ich anfangen muss um die Lib zu arbeiten.

 

[mihe7]

Komponenten von JavaFX erweitern zu muessen hat mich zu dem package-private und final Hasser gemacht der ich bin.

LOL, bei mir beschränkt sich das Gefühl auf FX

 

[Gelöschtes Mitglied 65838]

in javafx zerschießt du dir halt das verhalten mal leicht mit dem überschreiben von methoden
und es ist wichtiger anscheinend dass die klassen verhalten gleich bleiben anstatt dass man sie erweitern kann


aber mir ist ansich noch kein fall aufgefallen wo man jetzt so eine exzessive vereerbung bräuchte?
wenn du deinen eigenen node bauen willst musst du das sowieso über eine stackpane und rechtecken und labels lösen die kann man auch über delegation lösen was glaub ich nicht so gneial ist wie ichs mir gerade denk xD


PS:
wenn ich mir die methoden so anseh wie bei der borderpane getChildren.... usw...usw.. war das ganze nicht ganz soo durchdacht

 

[mihe7]

aber mir ist ansich noch kein fall aufgefallen wo man jetzt so eine exzessive vereerbung bräuchte?

Was heißt exzessiv? Wir hatten hier mal ein ganz popliges Beispiel, da ging es um ein Label, das abhängig vom Inhalt den Text entweder einfach abschneiden oder mit "..." versehen sollte (soweit ich das noch in Erinnerung habe, ist schon was her), wenn der zur Verfügung stehende Platz nicht ausreicht. Kann auch andersrum gewesen sein: wenn der Platz reicht, noch Text ergänzen. Müsste ich jetzt im Forum raussuchen.

Du kannst Label schon erweitertn, nur nützt Dir das nix, weil überall alles private ist. Im Endeffekt müsstest Du den kompletten Code kopieren - was nicht nur technischer Schwachsinn ist, sondern lizenzrechtlich ein Problem darstellen könnte.

 

[Gelöschtes Mitglied 65838]

du kannst doch einfach ein rechteck drüber clippen => umweg gehen was so ziemlich immer der fall ist


du hast halt das problem das Javafx eine Top level gui lib ist .... man sollte nicht im kern rum spielen man sollte auf basis von dem was da ist rum spielen

swing ist da viel liebevoller vorallem bei zb eigene Nodes erstellen dda kannst in swing einfach mal so einen kreeieren ... in javafx puh... wenn man den node nicht aus dem zusammen buaen kann was es schon gibt dann sitzt man schon mal nen tag

 

[LimDul]

Es gibt sehr gute Gründe möglichst viele Dinge private oder package private zu machen.

Weil es einfach keine API ist, die man erweitern/nutzen soll. Sobald ich etwas public oder protected mache, kann ich es nicht mehr ändern, ohne das es einen API-Break gibt. Das hat zur Folge:

* Anwender der Bibliothek steigen nicht auf die neuere Version um, weil es zu viele API-Breaks gibt
* Bei kommerziellen Lizenzen muss man als Hersteller ggf. Support bei der Umsetzung leisten

Man limitiert sich - insbesondere bei stark genutzten Bibliotheken - massiv in der Weiterentwicklung, wenn zu viele Dinge von außen erweiterbar oder zugreifbar sind.

Natürlich ist es schwierig da das richtige Maß zu finden. Denn es gibt Dinge, wo es einfach sinnvoll ist etwas überschreiben zu können oder auf Methoden zuzugreifen.

 

[mihe7]

du hast halt das problem das Javafx eine Top level gui lib ist ....

Ich habe gar kein Problem, weil ich FX nicht verwende Allerdings wurde FX lange Zeit als Swing-Nachfolger gehandelt und dazu passt es einfach nicht, weil - wie Du ja auch schreibst - FX einfach nur eine GUI-Lib ist.

 

[Gelöschtes Mitglied 65838]

was sie sich da gedacht haben mit javafx weis ich nicht

viele versprechen wurden nicht eingehalten... dass es das non plus ultra frmaework für RIA ist? naja... gibt zwar 10000 tutorials wie man mit javafx einen browser baut aber bitte... wie viele browser brauhct man denn

hätten sie stattdessen eine API geschrieben die websiten anfordert und diese Filtern lässt somit ich dann mit dem gefilterteten mein programm aufbau wäre wahrschienlich sinnvoller gewesen aber was weis ich schon davon... hab mir 3 mal RIA definition durchgelesen und bis heute nicht verstanden wofür ich das bruahcen sollte

"javafx läuft auf allen plattformen" joaaa ... IOS und android lassen grüßen auf android gehts zwar aber keine geile erfahrung

und das javafx ein ersatz für swing ist wird sehr wahrscheinlich niemals kommen ... alleine schon davon dass jede property sich bei ejdem frame meldet ist es schon langsamer als wie bei swing wo man selbst entscheidne kann wann und wo was angezeigt wird


deswegen werd ich fürs erste bei unity mit c# bleiben... in der arbeit muss ich eh bald mit swing hantieren mal gucken wie das ausgeht

 

[mihe7]

in der arbeit muss ich eh bald mit swing hantieren mal gucken wie das ausgeht

Viel Spaß Das Problem bei Swing ist, dass es schon zu rudimentär ist.

 

[White_Fox]

Soweit ich das verstanden habe, wollten die in JavaFX viele Model-Controller-Mechanismen einbauen.
Meines Erachtens war das auch eine konzeptionelle Schwäche...irgendwas will man doch immer anders machen als es sich die Entwickler gedacht haben.

Ich habe mal ganz kurz überlegt, eine Node für eine tabellarische Ansicht zu schreiben (das war bei mir der Grund, von Swing auf JavaFX zu wechseln, nur um dann festzustellen daß es in JavaFX zwar besser, aber nur ein ganz kleines bisschen besser geht).
Dann hab ich mir den Code von der SpreadsheetView angesehen – scheiße, eine einzelne Klasse mit >1.000 Zeilen – und hab das Unterfangen sofort wieder vergessen.

 

[Gelöschtes Mitglied 65838]

man wollte zu viel und hat nicht abliefern können

die meisten "mängel" die man so findet sind "das und das war scheiße damals in javafx darum hab ich aufgehört"
weil zu viel versprochen wurde was nicht eingehalten wurde

 

[mihe7]

Soweit ich das verstanden habe, wollten die in JavaFX viele Model-Controller-Mechanismen einbauen.

Die gibts in Swing auch, allerdings nicht auf Container-bzw. Frame Ebene. Den FXML-Ansatz finde ich gar nicht schlecht.

 

[mihe7]

man wollte zu viel und hat nicht abliefern können

Für meine Begriffe hat man zu viel abgeliefert

Zum Beispiel: StringProperty. Erweitert StringReadOnlyProperty, die wiederum StringExpression. Es werden die Interfaces Observable, Property<String>, ReadOnlyProperty<String>, ObservableObjectValue<String>, ObservableStringValue, ObservableValue<String>, WritableObjectValue<String>, WritableStringValue, WritableValue<String> implementiert.

Gehts noch?!?

Dann die irreführende Bezeichnung: StringProperty is-a StringReadOnlyProperty, weil es aus dem ReadOnly ein Writable macht. Wieso wird mir StringProperty dann als StringReadOnlyProperty verkauft? Müsste es in Anlehnung an WrtiableStringValue nicht korrekterweise ReadableStringProperty (oder ObservableStringProperty) statt ReadOnlyStringProperty heißen?

Vor allem aber: was will ich damit? Das sind FX-Klassen, die in meinem Model nichts zu suchen haben.

 

[Gelöschtes Mitglied 65838]

versuch mal 3 mal hintereinander

SimpleReadonlyDoubleWrapperProperty

zu sagen

in meinem projekt hat alles in controller und view funktioniert bis ich zum model gekommen bin ... da macht die property sachen eher mittelmäßig sinn

 

[mihe7]

in meinem projekt hat alles in controller und view funktioniert bis ich zum model gekommen bin ... da macht die property sachen eher mittelmäßig sinn

Genau das ist ja der Punkt: da wird die ganze Collection-API dupliziert, um es Observable zu haben, ein in meinen Augen gar fürchterliches Binding-Framework eingerichtet, das auf FX-Typen aufbaut und wofür das Ganze? Damit ich am Ende im UI einfach Properties aneinander binden kann. Keine Ahnung, vielleicht gibt es Anwendungen, die das exzessiv brauchen.

Ich muss allerdings dazusagen, dass ich mich dann auch nicht weiter mit FX beschäftigt habe und es durchaus sein kann, dass ich etwas übersehe.

Die Beispiele, die man so findet, sind jedenfalls für die Tonne: man nehme eine Person-Klasse, spendiere dieser StringProperty-Felder und schon kann man das UI dran binden. Vor allem hat der unbedarfte Entwickler mal eben FX-Klassen in sein Model eingeführt...

 

[Gelöschtes Mitglied 65838]

naja verglichen mit wpf oder maui ... javafx ist einfach ... sehr einfach


es ist schwer was gutes daraus zu machen aber für den einsteiger langts ... ich hatte es mit meinem projekt versucht zu ändern dass im model gar keine properties mehr drin sind sondern der controller alle properties hat ja gut............ gewonnnen? nicht wirklich ... ich muss halt wie in swing kein paint oder sonst was aufrufen dass es angezeigt wird das ist halt einfach

 

[White_Fox]

Sehr geil ist auch die TableView. Die sucht in der Klasse der Objekte, die sie auflisten soll, eine Methode "getName", und schreibt dann in den Spaltenkopf "Name".

Ich meine, das ist doch super wenn man ein Programm in mehreren Sprachen anbieten will - ich frag mich echt, welcher Idiot kommt denn auf so eine Idee? Doch nur wenn man vom HelloWorld direkt zu Reflexion überleitet ohne jemals auch nur ein einziges halbwegs ernsthaftes Programm wenigstens geschrieben haben zu wollen. Ob die schon jemals eine Refaktur gemacht haben?

 

[Gelöschtes Mitglied 65838]

javafx 1 wurde ja verworfen

 

[White_Fox]

Nee, das war auch in FX2 noch enthalten...das war mein erster Versuch einer tabellarischen Ansicht in JavaFX. Das war sowieso recht übersichtlich dokumentiert, ich bloß ein Tutorial mit etwas Beispielcode gefunden und konnte anfangs nicht glauben daß das so gebaut wurde.

Und selbst wenn sie es wieder rausgeworfen haben – es ist ja schön, wenn Fehler korrigiert werden. Aber gelegentlich ist die Tatsache, daß ein spezieller Fehler überhaupt auftreten konnte weitaus schlimmer als der Fehler an sich.

Wie mit der Krumme-Gurken-Verordnung der EU. Auch wenn dieses unsägliche Stück Bürokratie nach zwei Jahren wieder zurückgenommen wurde – die Tatsache, daß jemand überhaupt auf diese Idee gekommen ist sagt schon alles, was man über diese Institution wissen muß.

 

[Gelöschtes Mitglied 65838]

wenn du nur die geraden gurken nimmst passen mehr in eine kiste


ich hasse die tableview aber witzigerweise ist für büro anwendungen diese anscheinend nicht weg zu denken

 

[Robert Zenz]

Wie mit der Krumme-Gurken-Verordnung der EU.

Oi, muessen wir hier noch weiter vom Thema weg? Bei der "EU Gurkenverordnung" ging es darum dass **die Industrie** eine europaweite Klassifizerung von Gurken wollte. Ware mit der Bezeichnung "Class 1" (glaube ich, vielleicht auch "Extra") musste eine gewisse Groesze und Form haben. Die Industrie wollte das damit sie sagen koennen wieviele Gurken in der Kiste drinnen sind die sie da blind kaufen. Entsprachen die Gurken nicht "Class 1", waren sie halt "Class 2". Thema uninteressant.

Gab mal eine tolle Webseite von der EU mit einer elendslangen Liste an Euromythen (komischerweise immer UK Zeitungen als Urheber), aber die scheint jetzt nicht mehr da zu sein.

 

[Robert Zenz]

Und nachdem sich die Diskussion sonst wohin bewegt, kann ich das Thema abschlieszen mit: Module sind fuer mich komplett uninteressant (zum Glueck).

Ich Danke allen Beteiligten fuer's Mitspielen und wuensche noch einen guten Abend.

 

[White_Fox]

Oi, muessen wir hier noch weiter vom Thema weg?

Hey, das war nur ein Vergleich für das vorher (zu Recht) gefledderte JavaFX...aber ja, du hast Recht, der Thread ist ganz schön ins Nirvana abgedriftet.

Im Nachbarthread fragte doch jemand ob er bei JDK8 bleiben kann, wegen JavaFX...und nachdem ich meinen letzten Rant über JavaFX geschrieben habe wollte ich schon das Thema dort verlinken, ob er wirklich wegen FX da bleiben will, den Modulmist habe ich da schon ganz vergessen gehabt.