# Java ohne IDE



## PencilHB (1. Sep 2014)

Hallo,

ich möchte mich (nur privat) etwas mit der Entwicklung von Java-Programmen für den PC beschäftigen. Bisher habe ich kleine Anwendungen für Android geschrieben (nichts Besonderes und es ging auch nicht in die Tiefe).

Im Internet habe ich den Ratschlag entdeckt, dass es durchaus Sinn macht, zuerst rein mit den Kommandowerkzeugen des JDK und der JRE (also den installierten Basis-Programmen von Oracle) zu arbeiten, weil man dadurch den besten Einblick in die Details der Werkzeuge bekommt.

Mir ist dieser Gedanke sehr sympathisch, weil ich für die bisherige Android-Entwicklung Eclipse einsetze und das Programm oftmals sehr langsam arbeitet (bereits der Start dauert seine Zeit - leider muss ich manchmal neu starten, was dann keinen Spass macht) und auch die automatische Umformatierung meiner Quelltexte zaubert dauerhaft kein Lächeln in mein Gesicht 

Ich habe vor, mir einige Batch-Dateien zu schreiben, die mir einen MAKE- und BUILD- Prozess ermöglichen. Natürlich brauche ich einen Syntax-Editor. Gibt es für Entwickler gute kostenlose (kleine+schnelle) Programme?

Was haltet ihr von dieser Idee?
(wie gesagt, es geht nur um den Hobby-Bereich und das Programmieren soll mir grossen Spass machen)


----------



## javampir (1. Sep 2014)

hi,
ja, ist eine gute Idee. Das habe ich auch eine Zeit lang gemacht, weil ich auf verschieden pcs gearbeitet habe und mal auf dem einen die eine IDE nicht lief und auf dem anderen die andere nicht.
Als software kann ich nur Notepad++ empfehlen, dan kann nicht nur das syntaxhighlighting von java, sondern von im Prinzip allem was du dir vorstellen kannst (und du kannst auch eigene Highlights erstellen).
Unter Linux hättest du als Ausweichmöglichkeit noch Geany. Dabei ist sehr praktisch, dass du dort drin glcih ein Kommandofenster hast.
Sehr geholfen hat es mir, die Fehlermeldungen in eine separate textdatei zu schreiben (aus der batch heraus, nur als tip  )
javampir


----------



## Gucky (1. Sep 2014)

Ich halte das für Forengerede aus derselben Schublade, wie "Nur ein geschriebenes GUI ist ein gutes GUI". Es gibt diese Werkzeuge und warum sollte ich sie dann nicht verwenden. Es muss ja einen Grund haben, dass alle Welt IDEs verwendet. 

Wenn eclipse dir zu langsam ist, dann such dir doch eine andere IDE aus, wie NetBeans, BlueJ (funktioniert auch ohne den ganzen "Lehrkram") etc. Wenn es dir an einem nicht mangelt, dann sind es IDEs. 



			
				PencilHB hat gesagt.:
			
		

> wie gesagt, es geht nur um den Hobby-Bereich und das Programmieren soll mir grossen Spass machen



Der Meinung bin ich auch aber wenn du dich um den ganzen, ich nenne es mal, Low-Level-Kram kümmern musst, dann bleibt vermutlich ein Teil vom Spaß auf der Strecke.



Ich will dich aber nicht entmutigen. Wenn du das machen willst, dann mach es und wenn du scheiterst, dann hast du zumindest eine Erfahrung mehr. 



PS: eclipse ist bei mir nicht langsam. Zwar verwende ich eine uralte Version aber sie läuft wie eine eins und ist bei weitem schnell genug.
PPS: Die automatische Umformatierung kannst du garantiert irgendwo abstellen.
PPPS: Wie startest du eclipse neu? Liegt es vielleicht daran, dass du nicht die restart Funktion benutzt?


----------



## PencilHB (1. Sep 2014)

@javampir
Vielen Dank, das bestätigt meine Grundhaltung.

‚Notepad++’ werde ich mir laden und genauer ansehen (danke für den Tipp). Ich bin gerade auf den Editor ‚PSPad’ gestossen. Die Beschreibung sieht gar nicht schlecht aus. Er kann wohl auch Ausgaben auf der Console auf Fehler hin prüfen und automatisch auf die Fehlerzeile springen – das wäre natürlich gigantisch (darauf lege ich aber momentan noch keinen Wert – für die Zukunft wäre das aber ein prima Pluspunkt)


@Gucky
Danke für den Hinweis. 

Mir geht es nicht darum, eine neue IDE zu entwickeln. Die vorhandenen IDEs (Eclipse und NetBeans) erschlagen mich aber im ersten Moment mit Einstellmöglichkeiten. Wie ich gelesen habe ist das nur eine weitere ‚Lernkurve’. 

Ich werde vielleicht später auf die IDEs zurückkommen, aber momentan will ich die ‚reine Arbeitsumgebung’ und das Verhalten des Compilers herausfinden. Dadurch kann ich später genau sagen, wo, welche Zeiten verloren gehen – ohne dieses Wissen muss ich der DIE vertrauen.

Ich bin der Meinung, dass es nie falsch sein kann Erfahrung über den Aufbau und die Funktion von Software zu sammeln. Zumindest werde ich vielleicht irgendwann sagen können welche Aufgaben die DIE erledigt und welche von den Basiswerkzeugen abgedeckt werden.


@All

Das habe ich vergessen zu schreiben: ich arbeite momentan unter Windows 7.

Ich habe schon etwas angefangen und ich sammle gerade Erkenntnisse, ‚wo’ sich  die Klassen befinden sollten, damit der Compiler (javac) sie auch mit einer ‚ package’-Angabe (in der Quelltextdatei) findet.

Ich möchte einige kleine Java-Test-Projekte realisieren, die sich in einem ‚Programm’-Verzeichnis befinden und neben diesem Programmverzeichnis möchte ich mir allgemeinen Code in einem RTL-Verzeichnis (RunTimeLibrary) aufbauen, um sie wieder zu verwenden. Das Ganze darf vorerst ruhig nur über Quelltexte in den Compilierprozess eingehen (nicht über JAR-Libraries), weil ich Erfahrungen über die Compiliergeschwindigkeit sammeln möchte.

Wie ich gelesen habe, entspricht der Compiliervorgang mit javac einem MAKE-Ablauf, d.h. er vergleicht die Dateizeiten von *.java und *.class und compiliert die ‚Unterschiede’. Für einen Build-Vorgang werde ich vermutlich einfach im Batch die *.class-Versionen löschen.

Ich muss noch klären, wie es javac verwaltet, wenn ich eine Konstante in Datei A.java ändere, die B.java einsetzt. Wenn er nur die Dateizeiten prüft, wird er wohl B.java nicht automatisch aktualisieren. Gibt es hierzu Erkenntnisse, wie javac mit Abhängigkeiten zwischen den Quelltexten umgeht bzw. wie die IDEs diese Abhängigkeiten beim Compilieren herstellen?


----------



## Gucky (1. Sep 2014)

Wenn dich die Einstellmöglichkeiten erschlagen, dann ignorier sie (so mach ich das ) oder du benutzt BlueJ. Da ist am Anfang viel abgeschaltet.
Aber wenn du den Hintergrund der IDEs wissen möchtest, dann werde ich dir das nicht schlecht machen 


Zu deiner Frage zu Konstanten: in der Java Insel steht, dass solche Probleme nur durch ein vollständiges Neukompilieren gelöst werden können.


----------



## PencilHB (1. Sep 2014)

@Gucky
Danke für den BlueJ-Tipp.

Compilieren mit Javac:
Ich habe es auch so festgestellt, dass das Ändern einer Quelltexttextdatei nicht zur automatischen Aktualisierung der anderen Dateien führt. Das ist aber kein Problem, so etwas muss man nur wissen. Eine BUILD-Batch, die alle *.class-Dateien löscht ist momentan eine akzeptable Lösung.


@All

Ich habe mir das BlueJ für Windows gerade installiert.
Der erste Eindruck ist:

Positiv:
- es unterstützt sehr viele Plattformen (gut zu wissen)
- es ist selbst nicht besonders gross und startet normal.

Negativ:
-	die zwei Fenster-Layout-Einteilung ist etwas gewöhnungsbedürftig. In den kleinen Editoren, die ich bisher in Betracht ziehe, gibt es eine Projekt-Datei-Liste neben dem Editierbereich, was ich sehr gerne benutze. 
-	Die Syntaxdarstellung mit den farbigen Rechteckblöcken ist etwas gewöhnungsbedürftig.
-	Ich habe gerade eine Beispieldatei editiert und wollte über UNDO das Löschen mehrerer Bezeichner rückgängig machen. Resultat: die UNDO-Taste ist mittlerweile deaktiviert, aber meine Bezeichner sind immer noch nicht vorhanden. Des weiteren kann ich komischerweise den Cursor nicht mehr mit der Tastatur nach oben bewegen (nur noch mit der Maus). Derart gravierende Fehler im Editor sind ein NOGO.



Des weiteren habe ich gerade Notepad++ installiert und mein kleines Projekt integriert. 

Positiv:
- es gibt eine Projektverwaltung (ich hab sie fast nicht gefunden ), die mir genügen würde
- der Editor macht einen sehr guten Eindruck (auch meine Batch-Dateien erhalten Syntax-Farben)

Negativ:
-	Momentan kann ich nur sagen, dass Notepad++ im Vergleich zu PSPad schlechter abschneidet, weil PSPad die direkte Integration meiner Batch-Dateien erlaubt und die Consolen-Ausgabe, wie ich vermutet habe, tatsächlich in einem LOG-Fenster auffängt und automatisch auf Fehlerpositionen springt.

Momentan verwende ich deshalb PSPad als Java-Editor und auch zur Ausführung meiner Batch-Dateien (eigentlich wollte ich hierfür nur ein 'einfaches' Consolen-Fenster einsetzen, aber so ist es natürlich genial gut – da sag ich nicht nein ).


----------



## Gucky (1. Sep 2014)

Ich wette mit dir, dass man die Nachteile bei BlueJ beseitigen kann, wenn man die richtigen Einstellungen tätigt.

Die farbigen Rechtecksblöcke kamen in Version 3 hinzu und lassen sich bestimmt abschalten.

UNDO: Versuch mal strg + z. Das geht sowieso schneller


Ein Argument hab ich noch: Werden dir Syntaktische Fehler im Code angezeigt?


----------



## PencilHB (1. Sep 2014)

@Gucky
Ich weiss nicht: Das mit dem mangelnden Rückgängigmachen und der danach nicht mehr funktionierenden Cursorplatzierung scheint mir eher ein Fehler zu sein – ob dieser Fehler von einer gerade aktiven Einstellung herrührt, kann ich natürlich nicht sagen.

Es ist richtig, syntaktische Fehler werden mir in dieser einfachen Umgebung nicht angezeigt – aber das habe ich noch nie vorausgesetzt. Es ist eine nette Funktion, nur wenn dadurch das Schreiben und Anzeigen von Code verlangsamt wird, brache ich es nicht. 

Genauso die Schnellauswahl von Funktionen/Methoden: nett, aber wenn ständig meine Cursorbewegungen in plötzlich erscheinenden Unterfenstern landen, dann stört mich das.

Gerade habe ich im PSPad einen ‚Code Explorer’ entdeckt, d.h. eine Listendarstellung meiner aktuellen Quelltext-Datei. Zuerst dachte ich ‚toll’, mit einem Klick springe ich zwischen den Funktionsteilen hin und her – aber dann wurde mir klar, dass ich es nicht einsetzen werde, weil es noch nie zu meiner Arbeitsweise gehört hat. Also selbst in diesem ‚kleinen’ Programm befindet sich schon Funktionalität, die ich nicht brauche.

Viel wichtiger sind mir Bookmarks. Der PSPad hat eine gute Verwaltung von ‚unbenannten’ Bookmarks, die man sehr schnell anlegen und löschen kann. Auch das Navigieren ist kinderleicht. Bei Exclipse habe ich auf diese Funktion verzichtet, weil mir das Anlegen zu umständlich vorkam (vielleicht habe ich auch einfach nicht herausgefunden, wie es schnell geht – aber ‚nicht finden’ und ‚nicht da sein’ ist in diesem Fall das Gleiche).

Es kann sein, dass ich in den nächsten Tagen noch in eine ‚Sackgasse’ hineinlaufe, aber momentan reagieren alle Teile vernünftig und der ‚Freizeit-Spass’ ist vorhanden, denn es geht im Grunde gut voran.

Kleines Manko: Der javac-Compiler ist etwas langsam. Für einen Java-Make-Durchgang benötigt er bei mir zwischen 4 und 6 Sekunden. Sollte ich später eine IDE finden, die hier viel schneller ist, umso besser - momentan ist es noch kein Problem.


----------



## PencilHB (3. Sep 2014)

Mittlerweile arbeite ich bereits mehrere Tage mit dem Batch-System und ich bin begeistert.

Es erledigt sämtliche Aufgaben rund um die JAR-Erstellung ohne Probleme und ist überall erweiterbar.

Ich habe mir folgende Batch-Funktionen geschaffen:

M.bat = Make (Aktualisierung)
B.bat = Build (komplette Neuerstellung)
R.bat = Run (Ausführung)
RB.bat = Run (mit vorheriger Neuerstellung)
RM.bat = Run (mit vorheriger Aktualisierung)

Für das ‚Compilieren’ benutze javac.exe aus dem JDK-BIN-Verzeichnis.
Für das ‚Linken’ benutze jar.exe aus dem JDK-BIN-Verzeichnis.
Für die Ausführung benutze ich java.exe für Consolen-Anwendungen und javaw.exe für Fensteranwendungen aus dem JRE-Verzeichnis.

Um jedes einzelne Projekt komfortabel konfigurieren zu können, habe ich eine ‚project.bat’ angelegt, in der Projekt-Einstellungen wie in einem Formular ausgefüllt werden können (Titel der JAR-Datei, Hauptklasse, Quelltext-Verzeichnisse, JAR-Verzeichnisse, Ausgabeverzeichnisse, zusätzliche Daten für die JAR-Datei usw.).

Aus diesen Projekt-Daten erstellen die Batch-Abläufe automatisch die MANIFEST.MF-Datei (damit die JAR-Datei durch Doppelklick gestartet werden kann).

Beim Compilieren unterscheide ich zwischen DEBUG und RELEASE-Version (dieser Modus ist über project.bat einstellbar.

Die DEBUG-Version enthält detaillierte Traceausgaben (in eine Txt-Datei).

Die RELEASE-Version führt keine Traceausgaben durch und ist vom Code-Umfang reduziert. In wie weit ich eine Code-Reduktion mit PROGGUARD einbauen werde, weiss ich noch nicht (momentan ist das nicht so wichtig). Genauso werde ich bestimmt noch über das Signieren der Jar-Datei nachdenken – evtl. schreibe ich für diese Vorgänge eine eigene Batch.

Als besonderes ‚Highlight’ verwende ich einen Präprozessor (über dieses Programm werden auch die Traceausgaben bei DEBUG eingebunden und bei RELEASE ausgeklammert). Mir ist nicht ganz klar, warum JAVA auf die Funktionalität von Conditional-Defines verzichtet, denn ich kann damit, über meine Projekteinstellungen den Codeumfang von allgemeinen Bibliotheken individuell für meine jeweilige Anwendung regeln. Hier im Forum habe ich gelesen, dass jemand Probleme hat, unterschiedliche Versionen von einem Codebereich mit einer IDE zu gestallten – mit dem Präprozessor konnte ich dieses Problem (für mich) ohne grosse Überlegungen lösen.

Mein momentanes Urteil über den Aufbau ist:
Die Abläufe gestalten sich schön einfach und verhalten sich gleich bleibend ruhig und unauffällig im Hintergrund. Wann immer ich eine Veränderung haben wollte, hatte ich sofort eine Stelle um sie zu realisieren. Auch der Editor arbeitet sehr zuverlässig (bisher keine Probleme). Das einzige Manko beim Editor ist: ich kann nur für eine Batch eine Tastenkombination hinterlegen – die anderen Batch-Dateien kann ich aber über Doppelklick aus dem Editor heraus starten – wie ich gesehen habe, haben schon andere Benutzer diese Funktion nachgefragt und vielleicht wird es sich in einer neuen Version ändern) 

Ich werde auf jeden Fall die ersten Anwendungen mit diesem System erstellen und eine IDE muss schon prima Qualitäten bieten, damit ich wechsle.


----------



## Gucky (3. Sep 2014)

Das ist ja schön, dass es dir so gut gefällt. Willst du deine Batches vielleicht noch hier oder in einen Blog Eintrag posten, damit Andere davon profitieten können?


----------



## tommysenf (3. Sep 2014)

Schau dir mal Apache Ant an: Apache Ant - Welcome

ant ist sozusagen das make Tool  für die Java Welt und bietet eigentlich schon alles was du dir in deinen Batch Dateien gescriptest hast und noch vieles mehr.


----------



## PencilHB (3. Sep 2014)

@Gucky
Ja, es ist sogar ‚sehr schön’ 

Ich kann nicht erkennen, dass es viel Interesse gibt und ich müsste ein allgemein verständliches Paket aufbauen und mit Erklärungen versehen, was Arbeitszeit bedeutet.

Für mich ist diese Implementierung im Grunde abgeschlossen – vor allem mit dem Jikes-Compiler, den ich heute gefunden habe (dazu unten mehr).


@tommysenf
Ich wäre da nicht so schnell. Die Batch-Funktion ist zwar nur eine kleine Sprache, aber sie ist eine Sprache. Das ermöglicht es mir in einer einfachen Projekt-Datei Inhalte zu setzen, die in den ausgeführten Standard-Batchs ausgewertet und zu entsprechenden Reaktionen führen. D.h. ich trenne die Konfiguration und die Ausführung vollständig voneinander ab.

So habe ich z.B. gerade einen zweiten Compiler (Jikes) integriert. Ich kann jetzt auswählen, ob ich mit Javac oder Jikes arbeiten möchte. Jikes ist veraltet (‚nur’ Java 1.4 - aber tierisch schnell ), insofern muss ich oft umschalten können. Das Umschalten kann ich über meine Projekteinstellungen veranlassen oder ich führe einen Umschalt-Batch aus, der eine Datei erzeugt (in meinem Make-Batch schaue ich nach, ob diese Datei existiert und verwende dann den anderen Compiler) – ich bin also extrem flexibel in meinen Entwurfsmöglichkeiten. 

Im Idealfall werde ich nur noch die Projekt-Batch ausfüllen und die Hintergrundbatchs interpretieren diese Eingaben. Sollte irgendwann eine Funktion fehlen, kann ich sie sicherlich integrieren.

Ich habe mir die Doku zu ANT angesehen und muss sagen diese XML-Syntax sieht etwas unflexibel aus und die Entwickler schreiben selbst, dass ANT kein Allheilmittel ist. Ich vermute es ist der sequentielle Standardablauf, den ANT abdeckt. Sobald ich aber etwas Eigenes integrieren möchte sösst es an seine Grenzen - ist natürlich nur eine Vermutung. 

Die Doku scheint sehr umfangreich zu sein und ich müsste zuerst die Syntax lernen und das Verhalten kennen lernen – das ist immer ein Problem, denn es kann sein, dass sich ganz am Ende herausstellt: ‚ich kann es doch nicht gebrauchen’ – somit ist mir eine einfache (aber bekannte) ‚Shellsprache’ lieber.


@All
Ich habe ein paar Neuigkeiten über Compiler:

Eclipse:
Wie ich gelesen habe, benutzt Eclipse nicht JAVAC sondern einen eigenen Compiler, der es ermöglicht, dass die Quelltexte trotz Fehler in Teilen compiliert werden können – das ist wohl notwendig, um bei Tipppausen des Programmierers gleich ‚versteckt’ zu compilieren (das wird vermutlich auch der Grund sein, warum mir Exclipse manchmal sehr langsam vorkommt).

Javac:
Ich bin bisher davon ausgegangen, dass javac, als letzten Parameter, die Hauptdatei einer Anwendung bekommt und dann durch den Baum der Import-Anweisungen alle beteiligten *class und *.java Dateien vergleicht. Das stimmt nicht ganz. Es ist von dieser übergebenen Datei aus nur die ‚erste Stufe’, die aktualisiert wird. Falls aber in einer Datei eine Änderung vorliegt, die nicht direkt in der Hauptdatei benutzt wird, dann bearbeitet javac diese Quelltexte nicht.

Als Lösung für dieses Problem habe ich in dem Editor PSPad einfach eingetragen, dass die jeweils offene Quelltextdatei als ‚Hauptdatei’ compiliert wird. Ich denke, damit kann ich bereits den Grossteil dieses Problems erschlagen und für die ‚Extremfälle’ ist es ja sowieso schon so, dass eine komplette Neuerstellung durchgeführt werden muss (javac erkennt keine Dependencies).

Jikes:
Ein extrem schneller Compiler 
Das Problem: er unterstützt nur maximal Java 1.4 und wird anscheinend nicht weiter entwickelt – schade. Ich könnte mir trotzdem vorstellen, dass ich ihn für den Grossteil meiner Quelltexte einsetzen kann. Wenn ich für den Rest javac einsetze, kann Jikes die *.class-Dateien mit den neuen Java-Sprachelementen (Java >= 1.5) verwenden. Die Voraussetzung ist dann einfach ein schnelles Umschalten zwischen den Compilern.

Das werde ich auf jeden Fall versuchen.


----------



## Ruzmanz (4. Sep 2014)

> Das ist ja schön, dass es dir so gut gefällt. Willst du deine Batches vielleicht noch hier oder in einen Blog Eintrag posten, damit Andere davon profitieten können?



Das ist 0815 und wurde schon alles besser gelöst ... Wenn man alles nach seinem persönlichen Wunsch haben will, muss man Zeit in Doku lesen und Konfiguration investieren.


----------



## PencilHB (4. Sep 2014)

@Ruzmanz
Ich vermute, dass du über ein umfassendes und erschöpfendes Experten-Wissen verfügst. Allerdings sind deine Fähigkeiten, dieses Wissen in einen Kommentar zu schreiben, quasi ‚nicht vorhanden’. 


@All
Ich bin gerne bereit auf Sachargumente einzugehen. Auf inhaltsleere Kommentare werde ich aber nicht mehr reagieren.


----------



## Gucky (4. Sep 2014)

Ich glaube, das war an mich gerichtet, weil ich meinte, du könntest deine Batches posten.


----------



## PencilHB (10. Sep 2014)

Parallel zur Entwicklung der ersten Basisklassen und des *AWT-Bezier-Programmes* (Grafik-Beispiel als Antwort auf die Frage nach ‚kubischer Interpolation’ aus diesem Forum) habe ich versucht die Compilier-Abläufe weiter zu optimieren:

_Integration des Jikes-Compilers:_
Jikes hat Probleme beim Compilieren der JDK7 (wenn es um AWT-Klassen geht). Ich habe aber über das Internet eine Version des JDK6 gefunden – damit funktioniert es reibungslos (die Ausführung erfolgt über ‚javaw.exe’ aus dem JRE8)

_Ersetzen des JAR-Packers durch eine ZIP-Kommandozeilen-Version:_
Ich habe herausgefunden, dass der ZIP-Packer sehr viel schneller ist als der JAR-Packer. Durch das Ersetzen hat sich die Erstellungszeit weiter verbessert.

Wie ich bereits geschrieben habe, unterscheide ich zwischen DEBUG- und RELEASE-Version. Die obigen Optimierungen verwende ich ‚nur’ für den DEBUG-MAKE-Vorgang. Ansonsten wird Javac.exe und Jar.exe verwendet (die Umstellung erfolgt automatisch in den Batch-Jobs).

Die Durchlaufzeiten auf einem Rechner von 2009 mit zwei Prozessoren sind:

-Startzeit des Editors (bis zur Compilier-Bereitschaft)=2sec
-Build-Vorgang (Javac+Jar)=5.1sec
-Make-Vorgang (Javac+Jar)=3.2sec
-Build-Vorgang (Jikes+Zip)=nicht vorgesehen
-Make-Vorgang (Jikes+Zip)=0.9sec

Mein bisheriger/momentaner Eindruck ist, dass man so ohne Probleme arbeiten kann. Im Vergleich zu einem alten C++-Compiler sind diese Erstellungszeiten immer noch ‚hoch’, aber das merkt man kaum.


----------

