JDK erweitern

[GUI-Programmer]

Hallo, ich bin auf der Suche nach einer Möglichkeit das jdk zu erweitern. Ich möchte eine .java Datei in den ZIP-komprimierten Ordner src bringen. Zuerst habe ich versucht, einfach durch kopieren und einfügen einer bestehenden .java Datein ins Packet java.awt diese dann zu verwenden. Allerdings, wenn ich die Klasse dann per import - Anweisung importieren möchte, meldet der Compiler, dass er die Klasse nicht gefunden hat.

Also was muss ich tun? (Ich möchte nicht ein eigenen Klassenverzeichnes mit der Umgebungsvariable CLASSPATH erstellen / verwenden, sondern das jdk (src) mit eigenen Klassen erweitern.)

 

[Ariol]

WARUM????


Nee, mal im Ernst: erstell ein Jar oder auch Zip mit deinen "kompilierten"! Klassen und leg das dabei.
Am JDK selbst spielt man nicht rum.

 

[ARadauer]

Was hast du grundsätzlich vor?
Es gibt keinen logischen Grund irgendetwas in java.awt Package zu packen und schon gar nicht die jkd jars zu patchen

 

[GUI-Programmer]

-->Ariol:

und leg das dabei.

Was meinst du damit, bzw. wie soll das gehen?

 

[Michael...]

-->Ariol: Was meinst du damit, bzw. wie soll das gehen?

Beantworte doch mal die Frage:

Was hast du grundsätzlich vor?

Dann kann man auch erläutern wie etwas geht.

 

[GUI-Programmer]

Ich habe vor, ein neues Layout ins jdk, im Packet java.awt einzubinden
Damit folgendes funktioniert:

import java.awt.MeinLayout;
...
setLayout(new MeinLayout());

 

[Gast2]

Dafür brauchst du das java.awt package nicht "erweitern", dein layout kann in einem beliebigen anderen package liegen..

Creating a Custom Layout Manager (The Java™ Tutorials > Creating a GUI With JFC/Swing > Laying Out Components Within a Container)

 

[ARadauer]

1. Das muss nicht im awt package sein. Das kann heißen wie du willst
2. Auch wenn du es ins awt package rein packst. Muss es nicht in die jdk rein.

 

[tommysenf]

Ich denke mich daran zu erinnern, dass die Packages java.* und javax.* für benutzerdefinierte Klassen gesperrt sind.
Der gängige Weg für das was du vorhast sollte sein, dass du

1. Einen anderen Package Namen wählst.
2. Deine Klasse/n in ein Jar packst und im Verzeichnis lib/ext des JDK/JRE ablegst

Damit ist dein Layout dann in allen Anwendungen die dieses JDK nutzen verfügbar.

 

[GUI-Programmer]

--> ElkeB: Das ist mir schon klar. Frage, ist es denn gar nicht möglich?. Eigentlich müsste es doch gehen, dann ich habe bereits jdom in org gebracht, mit einer .jar Datei. Nur, wie ich das selbst mit einer Klasse machen soll, ist mir eben unklar.

 

[Ariol]

Ich denke mich daran zu erinnern, dass die Packages java.* und javax.* für benutzerdefinierte Klassen gesperrt sind.
Der gängige Weg für das was du vorhast sollte sein, dass du

1. Einen anderen Package Namen wählst.
2. Deine Klasse/n in ein Jar packst und im Verzeichnis lib/ext des JDK/JRE ablegst

Damit ist dein Layout dann in allen Anwendungen die dieses JDK nutzen verfügbar.

Lasst doch den Blödsinn.
Sowas bringt beim besten Willen nur Probleme.

Er soll sich sein eigenes Jar machen und dann wie üblich in sein Projekt einbinden.
Dann kann er seine Projekte auch problemlos weiterverteilen.

 

[Ariol]

--> ElkeB: Das ist mir schon klar. Frage, ist es denn gar nicht möglich?. Eigentlich müsste es doch gehen, dann ich habe bereits jdom in org gebracht, mit einer .jar Datei. Nur, wie ich das selbst mit einer Klasse machen soll, ist mir eben unklar.

Indem du deine Klasse in ein Package java.wassweißich ablegst.
Aber nochmal: WARUM?

Die Klasse muss da nicht liegen!einself11!

 

[Gast2]

:noe:

 

[ARadauer]

--> ElkeB: Das ist mir schon klar. Frage, ist es denn gar nicht möglich?.

Klar ist es Möglich aber kompletter Blödsinn

 

[GUI-Programmer]

eigenes Jar machen und dann wie üblich in sein Projekt einbinden.

Wie funktioniert das? Gibt es ein Tutorial, oder kann es mir jemand kurz erklären?

 

[Gast2]

Mit einer IDE deiner Wahl in ein paar Mausklicks.
Falls ne IDE für dich nicht in Frage kommt befrag google nach Classpath.

 

[GUI-Programmer]

Sorry, hab es selbst hingekriegt. Habe ein Package erstellt, das java heißt, darin ein Package awt, und darin die Datei MeinLayout.java compiliert, jar-File erstellt und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

 

[ARadauer]

File erstellt und in jdk.../lib/ext geschoben.

Nein! Rechte Maustaste aufs Projekt ->Properties -> Java build Path
Unter Libraries Add Jar oder Add External Jar.

Und du sollst deine Packages nicht java.awt nennen.

 

[Tomate_Salat]

... und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

Es wurde so oft gesagt und trotzdem tust du es :noe:. Wenn du die Jar in einem Projekt verwenden willst, dann erstellst du dir im Projekt-verzeichniss einen Ordner [c]lib[/c] und legst dort die jar ab. Danach machst du das, was ARadauer geschrieben hat.

 

[Ariol]

Sorry, hab es selbst hingekriegt. Habe ein Package erstellt, das java heißt, darin ein Package awt, und darin die Datei MeinLayout.java compiliert, jar-File erstellt und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

Ich...Kopfweh...!!!

 

[Gast2]

Sorry, hab es selbst hingekriegt. Habe ein Package erstellt, das java heißt, darin ein Package awt, und darin die Datei MeinLayout.java compiliert, jar-File erstellt und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

Wieso fragen manche Mitmenschen wenn sie die Antworten dann doch ignorieren... :noe:

 

[Gastredner]

Sorry, hab es selbst hingekriegt. Habe ein Package erstellt, das java heißt, darin ein Package awt, und darin die Datei MeinLayout.java compiliert, jar-File erstellt und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

Ja - genau solange, wie du das Programm auf deinem Rechner ausführst und neue JDK-/JRE-Versionen in den immergleichen Ordner installierst. Wechselst du auf einen anderen Rechner, musst du dessen JRE-Verzeichnis ebenfalls mit deinem eigenen Code "bestücken" - was bei einer größeren Anzahl von Klassen oder ganzen Bibliotheken dann schnell zu einer unwartbaren, benutzerunfreundlichen Abhängigkeitshölle wird.
Hör auf das, was dir geraten worden ist: pack deine Klasse in ein eigenes Package (niemand erwartet fremden Code in java.* oder javax.*!) und stecke diese Klasse entweder direkt in deine Projekte oder referenziere sie als externe Bibliothek. Wie du das machst wird in unzähligen Tutorials, Threads, Büchern und Videos erläutert.

 

[GUI-Programmer]

Der Vorschlag von ARadauer ist schon ganz gut:

Nein! Rechte Maustaste aufs Projekt ->Properties -> Java build Path
Unter Libraries Add Jar oder Add External Jar.

Jedoch arbeite ich nicht nur mit Eclipse!!!
Deshalb würde es mich interessieren, wie es mit NetBeans IDE und BlueJ funktioniert.


Außerdem: Ich muss zugeben, dass meine Lösung, mit "ins JDK bringen" wirklich untauglich war, da es
letztendlich sogar zu Fehlern im Programm und dann auch bei Fehlern beim Compilieren geführt hat (Compiler hat sich aufgehängt bei BlueJ).

 

[Gast2]

Funktioniert in Netbeans ähnlich, die Menüpunkte unterscheiden sich unter Umständen leicht, aber das wird marginal sein.
Wie das in BlueJ funktioniert... keine Ahnung, vllt greift da auch irgendwo ein wenig BlueJ-Magic ©

 

[Ariol]

Für BlueJ:
BlueJ - Tip Of The Week Archive

 

[Aldimann]

Deshalb würde es mich interessieren, wie es mit NetBeans IDE und BlueJ funktioniert.

Mein Rat: Vergiss BlueJ nimm Netbeans oder Eclipse. Jedenfalls wenn du wirklich Programme schreiben willst...

Außerdem: Ich muss zugeben, dass meine Lösung, mit "ins JDK bringen" wirklich untauglich war, da es
letztendlich sogar zu Fehlern im Programm und dann auch bei Fehlern beim Compilieren geführt hat (Compiler hat sich aufgehängt bei BlueJ).

Deswegen haben dir auch alle davon abgeraten .
Noch ein Tipp: Wenn dir jemand dringend von etwas abrät, du es aber doch für deine angestrebte Lösung hälst, dann frag solange nach bis du dein Gegenüber verstanden hast und seine Einwände abwägen kannst...

 

[Gast2]

Außerdem: Ich muss zugeben, dass meine Lösung, mit "ins JDK bringen" wirklich untauglich war, da es
letztendlich sogar zu Fehlern im Programm und dann auch bei Fehlern beim Compilieren geführt hat (Compiler hat sich aufgehängt bei BlueJ).

Wer hätte schon mit sowas gerechnet :noe:

Und dazu, dass du andere IDEs benutzt. Dann musst du dich halt mit denen beschäftigen. Wie man sie benutzt ect.

Am JDK rumzufummeln nur um sich nicht mit den korrekten Vorgehensweisen in der eigenen IDE "belasten" zu müssen ... nunja ...

 

[Dit_]

Sorry, hab es selbst hingekriegt. Habe ein Package erstellt, das java heißt, darin ein Package awt, und darin die Datei MeinLayout.java compiliert, jar-File erstellt und in jdk.../lib/ext geschoben. Nun funktioniert der import auch, wie ich es mir vogestellt habe.

und damit hast du jdk erweitert? :lol:

Dann gilt folgendes:

1. Du hast Lizenz um Java JDK modifizieren zu können
2. Dein Layout wurde natürlich unter Einhaltung aller Java(Beans) Konventionen implementiert
3. JavaDoc ist auch dabei
4. Die Erweiterung kann man von Oracle Seite bald runterladen

Spaß bei Seite. :noe:

Wenn ich ein C++ Hallo Welt Programm implementiere, kompiliere und als EXE und in den Ordner C:\Windows\System32 verschiebe, heißt es kaum dass ich Windows erweitert habe.

 

[Gast2]

und damit hast du jdk erweitert? :lol:

Dann gilt folgendes:

1. Du hast Lizenz um Java JDK modifizieren zu können
2. Dein Layout wurde natürlich unter Einhaltung aller Java(Beans) Konventionen implementiert
3. JavaDoc ist auch dabei
4. Die Erweiterung kann man von Oracle Seite bald runterladen

Spaß bei Seite. :noe:

Wenn ich ein C++ Hallo Welt Programm implementiere, kompiliere und als EXE und in den Ordner C:\Windows\System32 verschiebe, heißt es kaum dass ich Windows erweitert habe.

DAS stimmt natürlich auch wieder ^^ :applaus:

 

[Kr0e]

Es gibt hin und wieder Momente wo der Zugriff auf die default Klassen in manchen Paketen von Java echt gut wäre, an die man von außen eigentlcih nicht ran soll! Aber nicht bei einem Layout

 

[GUI-Programmer]

Vielen Dank für euere Beiträge. Ich weiß nun, wie ich bei welcher Entwicklerumgebung vorgehe!


Und übrigens:

Ich nutze vor allem NetBeans, dann kommt an 2. Stelle Eclipse.
Begründung:
Wenn ich größere Oberflächen programmiere erleichtert mir NetBeans das, da ich die Komponenten per Drag & Drop auf mein JPanel ziehen kann. Anschließend, wenn die View fertig ist, kopiere ich meist den Programmcode und füge ihn bei Eclipse ein, um ihn dort zu sortieren (Deklaration der Attribute möchte ich z.B. oben haben) und kommentieren und außerdem zu ergänzen (Controller & Model).

BlueJ verwende ich eigentlich nur dann, wenn ich ganz kurz mal ein kurzes Programm unter 50 Zeilen schreiben möchte, oder um meinen Kumpels etwas zu erklären (Habe es bis jetzt noch nicht geschafft sie von NetBeans bzw. Eclipse zu überzeugen!), d.h. Programm schreiben, ihnen das komplette BlueJ-Projekt geben.

 

[Gast2]

Wenn ich größere Oberflächen programmiere erleichtert mir NetBeans das, da ich die Komponenten per Drag & Drop auf mein JPanel ziehen kann.

Eclipse hat mit dem WindowBuilder Pro auch einen sehr guten GUI Builder.

 

[Gast2]

Eclipse hat mit dem WindowBuilder Pro auch einen sehr guten GUI Builder.

Imho ist der von eclipse auch besser, da man auch selbst geschriebenen gui code bearbeiten kann. Wenn man denn mag.

 

[GUI-Programmer]

OK, nochmals danke, werde dann demnächst mal den WindowBuilder Pro installieren und ausprobieren.
Vielleicht hat dann ja sogar NetBeans auch noch (mit BlueJ) ausgedient!!!

 

[Empire Phoenix]

Es gibt hin und wieder Momente wo der Zugriff auf die default Klassen in manchen Paketen von Java echt gut wäre, an die man von außen eigentlcih nicht ran soll! Aber nicht bei einem Layout

ERm, eigener Classloader? , Reflection manipulationen?
(ode es sein lassen weil es in 99% sinnvollere Lösungen gibt)


Window pro builder ist wirklich echt gut, er erstellt zb code der von menschen gelesen und verarbeitet werden kann. (was bei netbeans eher begrenzt zutrifft) Zudem kann er noch SWT wenn mans mal benutzen muss.

 

[Kr0e]

@Empire Pheonix:

Klar, das ginge mit Reflection. Aber einfacher wäre es doch, wenn man seine Sourcedatei einfach in java.awt.* legen könnte. Spezieller Anwendungsfall: Swing ohne natives Fenster zeichnen zu lassen! - Es gibt da aber noch weitere Anwendungsfälle ;-)

Ich hab mich da mal durchgewühlt, doch um da anständig dran zu kommen, muss man halt entweder im Paket sein oder eben mit Reflection ein riesen Wirrwarr anzetteln.

 

[GUI-Programmer]

Habe nun den Window Builder Pro installiert und ausprobiert. Funktioniert perfekt. Werde nun komplett auf NetBeans verzichten (können).
Nochmals Danke!

 

[Kr0e]

Ich habe auch mit NetBeans immer gearbeitet, hab dann iwann mal Eclipse ausprobiert und fern ab vom Window Builder Pro, den es damals noch garnicht gab, gefiel mit Eclipse iwie besser... Ka.. Das Feeling ^^

 

[Ulathar]

Eclipse hat mit dem WindowBuilder Pro auch einen sehr guten GUI Builder.

Das ist aber evtl noch nicht bei allen Usern (vor allem bei Einsteigern) angekommen, da dieser GUI Builder ja erst seit der neuesten Eclipse 3.7 version dabei ist wenn ich nicht irre.
Der GUI Builder den man davor über das Eclipse Project bekam... wie hieß er noch gleich ... VE Builder oder so? War nämlich so dermaßen für die Tonne das einem für eine detailierte beschreibung glatt die Worte fehlen .
Jigloo wäre da noch ne gute Option, die ich lange in Eclipse verwendet habe. Aber ja, das Google Geschenk ist nach kurzer eingewöhnungsphase mit den Netbeans Bordmitteln sicher konkurenzfähig.

 

[Tomate_Salat]

WindowBuilder gibts und gab schon für 3.6 bis runter zu 3.4. Dank Google gibt es ihn seit Helios schon ne Zeit draußen war kostenlos und nun soll er in Indigo integriert werden. Meine Indigo-Version hatte ihn noch nicht standardmäßig implementiert (kein Wunder: eine 3.7-Version davon, war auch offiziel noch nicht zur verfügung), aber ich glaube, mittlerweile dürfte es soweit sein.

 

[GUI-Programmer]

Und noch was:
Der Window Builder hat für mich, neben der Tatsache, dass man den automatisch erstellten Code gut bearbeiten / ändern kann noch einen weiteren großen Vorteil:
Man kann Code erst selbst schreiben, der WB kann ihn dann trozdem anzeigen, obwohl nicht mit Drag & Drop erstellt.
Somit zeigt er sogar gezeichnetes an. Klasse, die von JComponent erbt. paintComponent(Graphics g) überschreiben, dann noch super.paintComponent(g);
Anschließend diese Klasse als Komponent einer mit den WB erstellten Klasse hinzugfügen, und schon sieht man das gezeichnete!!!

Falls Code-Beispiele gefragt sind, bitte wieder antworten.

 

[despikeexd]

Ohne mir jetzt das gesamte Topic durchgelesen zu haben

@TO

Mal ganz erlich : welchen effekt soll es haben wenn du ein java-File in das SRC.ZIP im JDK-Ordner einfügst ?
Dir ist scheinbar nicht bewusst das dieses Zip nur eine mit-auslieferung der im jdk compilten klassen ist. Wenn du wirklich am jdk rumspielen willst müsstest du das ganze ins lib/ct.sym patchen ... wobei ich bezeifel das sich irgend ein java-tool dazu auch nur anstiften lässt.

Vielleicht solltest du erstmal einige Grundlagen in den gebieten Klassen und Pakete lernen

btw : es wird von Sun (Oracle) deutlich darauf hingewiesen keine bereits vorhanden Pakete wie java.* oder javax.* als eigene paketnamen zu verwenden da der compiler dann nicht mehr weis welches von beiden paketen er importieren soll.
also pack dir da erstmal n eigenes präfix vor damit dein compiler auch weis was er machen soll

 

[GUI-Programmer]

Ohne mir jetzt das gesamte Topic durchgelesen zu haben

Hättest du es dir teilweise durchgelesen, wüsstest du:
Thema ist erledigt, habe für jede Entwicklerumgebung ne Lösung gefunden!