Grenzen von Java überschritten

[Cheefrocker]

Hallo zusammen!
Habt ihr schonmal die Grenzen von Java erreicht? Sprich Projekte entworfen die um die 400 Eingabefelder haben, mehrere hundert Labels haben und noch paar Sachen. Selbst das auslagern bringt da nichts weil die gui mehr Code verbraucht als du für die maximale Methodenlänge hast.

Habt ihr ähnliche Erfahrungen gemacht und wie man diese wieder in den Griff kriegt?

 

[byte]

Mal ganz davon abgesehen, dass eine GUI mit 400 Eingabefeldern Blödsinn ist. Was kommt denn für eine Fehlermeldung? Was meinst Du mit "maximale Methodenlänge erreicht"? ???:L Gibts nen StackOverflow oder ist doch eher der Heap out of memory? In letzterem Fall kannst Du die Größe des Heaps ja erhöhen.

In den meisten Fällen ist die Grenze einer Sprache der Programmierer.

 

[thE_29]

Wahrscheinlich weil die Klasse nicht den Java Richtlinien entspricht?

Die lächerliche Klassenlimitierung auf xxx Zeilen ist für mich sowieso der größte Bullshit den ich je gelesen habe...

Okay, ne Methode sollte net allzulange sein (auf andere Methoden aufsplitten) aber ich gehe meine Klasse net aufsplitten weils irgendwo steht...

Außerdem ist meistens die Hälfte meiner Klasse Kommentare (oja, ich kommentiere )

 

[byte]

Bei wieviel Zeilen liegt denn die Limitierung? Hab sie noch nie erreicht. :roll:

 

[thE_29]

Glaub bei 1000 oder 4000?

javac meckert dann ja nicht es geht ja nur um "Richtlinien"

Genauso wie jede Klasse eigentlich als public final deklariert werden sollte und man eher nicht von JFrame/JDialog ableiten sollte..

 

[SnooP]

Also ich hatte schon Klassen mit mehr als 1000 Zeilen und auch schon Methoden mit einigen hundert... - aber nie lange, weil sie unmittelbar einem Refactoring zum Opfer gefallen sind, wie sich das auch gehört - die Limitierung würde mich daher auch interessieren.

Eine einzige Anwendung mit 400 Eingabefeldern kann ich mir jetzt auch nicht vorstellen... diese müssten ja auch noch gleichzeitig dargestellt oder zumindest im Speicher hängen, nur wozu? alle auf einen Bildschirm passen tun sie vermutlich nicht - und wenn hat man sowas wie ne tabelle - dann kann man die gleich nehmen

Ich bin an die Grenzen von Java gestoßen auf einem Mikrocontroller mit angepasster VM... dort hab ich dann viel mit Strings rumhantiert und sehr bald feststellen müssen, dass ohne die Verwendung von StringBuffern da bald gar nix mehr ging ...

 

[thomator]

Also mir sind da auch keine Grenzen bekannt, außer halt die Speicherreservierung für die VM. Ich habe mal ein Projekt übernommen, da hatten Klassen über 5000 Quellcodezeilen und die waren so ziemlich frei von Kommentaren!!
Die längste Methode war an die 1200 Zeilen Quellcode.
War nicht schön, sich da einzuarbeiten aber es hat funktioniert.

Ich kann mir nicht vorstellen, dass es da Grenzen geben soll.

und sehr bald feststellen müssen, dass ohne die Verwendung von StringBuffern da bald gar nix mehr ging

War wohl eher eine Performance-Geschichte im Zusammenhang mit der Speicherbelegung, oder? Weil so richtige Grenzen gibt es da eigentlich auch nicht soweit ich weiß.

 

[Guest]

Mal ganz davon abgesehen, dass eine GUI mit 400 Eingabefeldern Blödsinn ist. Was kommt denn für eine Fehlermeldung? Was meinst Du mit "maximale Methodenlänge erreicht"? ???:L Gibts nen StackOverflow oder ist doch eher der Heap out of memory? In letzterem Fall kannst Du die Größe des Heaps ja erhöhen.

In den meisten Fällen ist die Grenze einer Sprache der Programmierer.

400 Eingabefelder braucht man sehr wohl. Wenn du z.B. eine Anwendung hast die 20 Reiterkarten hat. Jede Reiterkarte ist voll von speziellen Eingabefelder(Comboboxen,Radiobuttons etc..)

Tabellen kommen auch nocht dazu! Diese 20 Masken oder mehr man doch auch erstmal in die Hauptklasse deklarieren etc. Dabei kommste schon an die Grenzen wenn du nur den grafischen Teil nimmst!

Programmiert ihr nur anwendungen mit 10 Feldern? Danach kommt ne anderen Anwendung wenn es mal mehr Felder werden???

Bitte genauer erläutern

 

[Guest]

Also ich hatte schon Klassen mit mehr als 1000 Zeilen und auch schon Methoden mit einigen hundert... - aber nie lange, weil sie unmittelbar einem Refactoring zum Opfer gefallen sind, wie sich das auch gehört - die Limitierung würde mich daher auch interessieren.

Eine einzige Anwendung mit 400 Eingabefeldern kann ich mir jetzt auch nicht vorstellen... diese müssten ja auch noch gleichzeitig dargestellt oder zumindest im Speicher hängen, nur wozu? alle auf einen Bildschirm passen tun sie vermutlich nicht - und wenn hat man sowas wie ne tabelle - dann kann man die gleich nehmen

Ich bin an die Grenzen von Java gestoßen auf einem Mikrocontroller mit angepasster VM... dort hab ich dann viel mit Strings rumhantiert und sehr bald feststellen müssen, dass ohne die Verwendung von StringBuffern da bald gar nix mehr ging ...

ne eine Tabelle kann man nicht gleich nehmen Tabellen sind auch ein bestandteil der Anwendung....

 

[AlArenal]

Tabellen kommen auch nocht dazu! Diese 20 Masken oder mehr man doch auch erstmal in die Hauptklasse deklarieren etc. Dabei kommste schon an die Grenzen wenn du nur den grafischen Teil nimmst!

Was denn für Grenzen?
Wenn ich 20 Reiter habe, erschlage ich besser denjenigen, der sich das UI hat einfallen lassen. Hat wohl noch nichts von Usability gehört...

 

[Guest]

Mal ganz davon abgesehen, dass eine GUI mit 400 Eingabefeldern Blödsinn ist. Was kommt denn für eine Fehlermeldung? Was meinst Du mit "maximale Methodenlänge erreicht"? ???:L Gibts nen StackOverflow oder ist doch eher der Heap out of memory? In letzterem Fall kannst Du die Größe des Heaps ja erhöhen.

In den meisten Fällen ist die Grenze einer Sprache der Programmierer.

Blödsinn? Wie soll man es anders machen ihr schlaumeier :meld: :bae:

 

[Guest]

So was macht man dann evtl. Dialog-gesteuert, sprich mit separaten Masken, die nacheinander aufgerufen werden. Die Daten im Backend in Objekten zu halten ist wohl eher nicht das Problem sondern das enorm aufgeblasene GUI.
Wie gesagt, das kann man auch in verschiedene Frames packen und sequentiell abarbeiten (Windows-like zurück/weiter).

Bei 20 Tabreitern verliert man eh schnell den Überblick, finde ich.

 

[Guest]

Tabellen kommen auch nocht dazu! Diese 20 Masken oder mehr man doch auch erstmal in die Hauptklasse deklarieren etc. Dabei kommste schon an die Grenzen wenn du nur den grafischen Teil nimmst!

Was denn für Grenzen?
Wenn ich 20 Reiter habe, erschlage ich besser denjenigen, der sich das UI hat einfallen lassen. Hat wohl noch nichts von Usability gehört...

da hast du Recht! Aber kann man dann doch noch Herr der Lage werden? Gibt es möglichkeiten da was zu machen?

 

[The_S]

400 Eingabefelder braucht man sehr wohl. Wenn du z.B. eine Anwendung hast die 20 Reiterkarten hat. Jede Reiterkarte ist voll von speziellen Eingabefelder(Comboboxen,Radiobuttons etc..)

Hier könntest du z. B. die 20 Reiterkarten in andere Klassen auslagern .

Tabellen kommen auch nocht dazu!

Auch die kann man auslagern

Bitte genauer erläutern

Klar kann viel an GUI kommen, aber sowas kann man auch meistens irgendwie auslagern (kommt natürlich immer auf den Fall an) .

[edit] oh man, da hab ich mir ja wieder verdammt viel Zeit gelassen ^^

 

[hupfdule]

Die 400 Eingabefelder müssen nicht zwangsweise gleichzeitig vorhanden sein. Es reicht die Felder im Speicher zu halten, die auch angezeigt werden. Also immer nur für den aktiven Reiter. Dann wärst du ja bei ungefähr 20 Eingabefeldern am Stück.

 

[Guest]

400 Eingabefelder braucht man sehr wohl. Wenn du z.B. eine Anwendung hast die 20 Reiterkarten hat. Jede Reiterkarte ist voll von speziellen Eingabefelder(Comboboxen,Radiobuttons etc..)

Hier könntest du z. B. die 20 Reiterkarten in andere Klassen auslagern .

Tabellen kommen auch nocht dazu!

Auch die kann man auslagern

Bitte genauer erläutern

Klar kann viel an GUI kommen, aber sowas kann man auch meistens irgendwie auslagern (kommt natürlich immer auf den Fall an) .

Der Quellcode ist ausgelagert! Die GUI nicht! Aber dafür fehlt mir vielleicht auch die Verständnis!

Würde mich trotzdem freuen wenn Sich einer bereit erklärt mehr Details zu verraten?

 

[The_S]

Was willste denn ansonsten noch hören?

 

[Guest]

Was willste denn ansonsten noch hören?

Vielleicht nicht immer eine negative Einstellung von dir :lol:

 

[WieselAc]

Wenn man Designspezifikationen so vorgesetzt bekommt, um das im Pflichtenheft (von wem auch immer) so festgeschrieben wurde, kann man da wenig dran ändern. Jedenfalls kenn ich das so.

Dann ist es jedoch gerade deine Aufgabe das so umzusetzten, dass die Anwendung trotzdem bedinbar bleibt. Deshalb bist du ja schließlich Programmierer.
Es wird ja nicht verlangt, das alle, in diesem Fall, Reiter beim Programmstart geladen und vorgehalten werden müssen. Da muss man sich halt Speicherlade-, Datenwegschreib- und sonstige Lösungen einfalllassen und implementieren.

Ich behaupte mal mit Kreativität, Ergeiz und vorallem genügend Zeit kann man jedes derartige Problem lösen!

 

[Guest]

So was macht man dann evtl. Dialog-gesteuert, sprich mit separaten Masken, die nacheinander aufgerufen werden. Die Daten im Backend in Objekten zu halten ist wohl eher nicht das Problem sondern das enorm aufgeblasene GUI.
Wie gesagt, das kann man auch in verschiedene Frames packen und sequentiell abarbeiten (Windows-like zurück/weiter).

Bei 20 Tabreitern verliert man eh schnell den Überblick, finde ich.

Ok wäre eine Überlegung wert, ABER viele Masken sind miteinander verdrahtet,sprich kommunieren miteinander

 

[The_S]

Was willste denn ansonsten noch hören?

Vielleicht nicht immer eine negative Einstellung von dir :lol:

Lässt sich einrichten :

Natürlich gibt es auch Situationen wo es schlichtweg nicht zu vermeiden ist eine Riesenklasse zu haben. Und wenn es nicht anders geht, dann gehts halt nicht anders, aber man stöst deswegen noch lange nicht an "die Grenzen" einer Programmiersprache.

 

[Guest]

Was willste denn ansonsten noch hören?

Vielleicht nicht immer eine negative Einstellung von dir :lol:

Lässt sich einrichten :

Natürlich gibt es auch Situationen wo es schlichtweg nicht zu vermeiden ist eine Riesenklasse zu haben. Und wenn es nicht anders geht, dann gehts halt nicht anders, aber man stöst deswegen noch lange nicht an "die Grenzen" einer Programmiersprache.

:wink: geht doch

gibt mir doch mal bitte ein beispiel!

 

[The_S]

Und für was? Auslagerung von GUI-Komponenten? (hm ich setz noch n Smiley dahinter, damits freundlicher und nicht so negativ rüberkommt) :arrow:

 

[Gast]

tztztztztz Stefan! no Comment dazu!

 

[byte]

Das Auslagern von GUI Code ist doch grade bei Swing denkbar einfach, weil man von den Komponenten eigene Klassen ableiten kann und somit die Initialisierung der GUI auf viele Klassen verteilen kann. Bei SWT ist das teilweise schon umständlicher, weil viele Widgets final sind und man somit keine eigenen Unterklassen bilden kann.

 

[The_S]

tztztztztz Stefan! no Comment dazu!

??????????????????????

[edit] keep on smiling

 

[Guest]

Das Auslagern von GUI Code ist doch grade bei Swing denkbar einfach, weil man von den Komponenten eigene Klassen ableiten kann und somit die Initialisierung der GUI auf viele Klassen verteilen kann. Bei SWT ist das teilweise schon umständlicher, weil viele Widgets final sind und man somit keine eigenen Unterklassen bilden kann.

da geb ich dir recht! Problem ist ja auch noch das teile davon SWT enthält.

 

[Azrahel]

Also ich baue auch an ner Anwendung rum, seit fast 2 Jahren. (JFrame mit nem DesctopPane als Hauptprogramm, JInternalframe für die aufzurufenden Programme). Wenn die Software beim Kunden läuft dann hat der auch schonmal 30-40 Unterprogramme auf, aber da treten bei mir keine HeapSpaceProbleme auf. Ich komm stellenweise auch auf die 400 eingabefelder (dynamisch erstellte Liste von Maschinen zum Eingeben von Daten usw. ) oder Aktuell hab ich da ein Programm in meiner Hauptanwendung laufen das je Maschine einen Zeitstrahl darstellt.

Da Komm ich auch bei 1 Standort a 10 Maschinen, 2 Monaten a 4 wochen, 7 Tage je Woche, 1 Panel zum Bemalen mit der Maschinenbelegung (Störung, Belegt, Rüsten, Frei, ...) auf 560 Panels, ohne den Rest der ja noch für die Gui benötigt wird.

Das einzige was mir ab und an Probleme bereitet ist das mir der Speicher vollläuft weil ich irgendwo nen Listener oder so nicht abgehängt hab und deswegen der GarbageCollector nicht alle nicht mehr benötigten Objecte löscht.

Also das es an der Menge der GuiComponenten liegt glaub ich weniger.

 

[AlArenal]

Ist wie mit dem Schwimmen und der Badehose, sage ich mal so. Die einen sind Java-Handwerker, die anderen sind Java-Künstler. Ich gehöre mehr zu den Handwerkern, die staunden Kusntwerke betrachten und hier und da im Chinese-Style was abschauen, aber nicht die Kretivität (a.k.a. Geekiness) besitzen von selbst große Kunst zu schaffen.

Ist aber auch nicht so schlimm. Wären wir alle nur Dichter und Denker, würden wir bereits kurz nach der Geburt verhungern.

 

[Ark]

Ich denke mal, solange hier nicht genau gesagt wird, wie die GUI-Komponenten miteinander kommunizieren, können wir hier nicht mehr viel ausrichten. Ich kann jetzt nur spekulieren und gehe mal davon aus, dass auch Folgendes möglich ist:

Eine (oder mehrere) Datenstruktur speichert — möglich platzsparend im Arbeitsspeicher oder schnell verwertbar auf Platte — alle Einstellungen, die in einem Dialog in Frage kommen. Jede Änderung wird — mittelbar oder unmittelbar — mit einem Integritätscheck nur(!) in dieser Datenstruktur quittiert. Sobald der Benutzer Mist eingegeben hat, muss er entsprechend darauf aufmerksam gemacht werden. Von den GUI-Elementen brauchen dann nur die wirklich im Arbeitsspeicher sein, die gerade gebraucht werden, die „Kommunikation“ erfolgt über die erwähnte Datenstruktur.

Das ist jetzt nur so eine Idee, man müsste genau wissen, was die Benutzerschnittstelle zur Verfügung stellen soll, denn evtl. ist meiner oder sogar Dein Ansatz völlig verkehrt!

MfG
Ark