Eclipse Tipps im Kontext der MGWs

[Axel_Janssen]

Hi,

die MGWs sind nicht an eine bestimmte IDE gebunden. Da Eclipse aber die beste IDE ist, gibt es dafür extra - Tipps.

Ein extra feature die gerade zum Lernen sinnvoll sein können, sind die sogenannten scrapbook pages.

Das funktioniert so:
1. Eclipse öffnen.
2. Neues Projekt über: File\New Project --> Dort links Java, rechts Java Project wählen.
3. Next drücken
4. Als Namen MGW eintippen (oder sonstwas).
5. In Java Perspective wechseln. Falls ihr da nicht schon seid. Perspektive wechseln geht über  das Icon mit dem Pluszeichen links oben. Unterhalb des Icons mit dem Zauberstab.
6. Mit rechter Maustaste auf das Projekt im linken Explorer klicken.
7.  New/Scrapbook-page wählen.
8. Namen eingeben (z.B. ArrayTest).
9. Finish klicken.
10. Den folgenden code in die Scrapbookpage kopieren:

Code

String [] arCities = {"Köln", "Hannover", "Berlin"};

for (int i = 0; i < arCities.length; i++) {
   System.out.println(arCities[i]);
}

11. Den gesamten code highlighten. Rechte Maustaste und Excecute in Kontextmenü. .

So kann man schnell immer code Schnippsel testen, ohne direkt eine neue Klasse zu erstellen.

NACHTEIL: Wenn ein Fehler auftaucht, bekommt man keine Meldung, in welcher Zeile der ist.

Fehlermeldungen werden in die Scrapbookpage geschrieben. Es wird immer nur der gehighlightete Text ausgeführt.

Scrapbookpages, jpage files sind kein Standard sondern IBM proprietär. Kann ganz praktisch sein, wenn man weiss wie es geht.

[Axel_Janssen]

Weiterer Tipp:
Du hast im google sinnvollen code gefunden, den du in dein Projekt einbinden möchtest.

Der ist nun aber überhaupt nicht formatiert (Tabs-Einrückungen und so).
Was machen?
Rechte Maustaste auf den Editor. Im PopUp Menü Source (5ter Eintrag von unten). Da Format auswählen. Fertig.

[Axel_Janssen]

Noch ein Tipp:
Wenn du mit Eclipse ein neues Java File erzeugst sieht das so aus:

Code

/*
 * Created on 20.09.2003
 *
 * To change the template for this generated file go to
 * Window>Preferences>Java>Code Generation>Code and Comments
 */
package de.aja.blboerse.integration.dao;

/**
 * @author Axel
 *
 * To change the template for this generated type comment go to
 * Window>Preferences>Java>Code Generation>Code and Comments
 */
public class Test {

}

Wo läßt sich nun das template für die Kommentare verändern?

Wähle Menü Window/Preferences.
Dort im Linken AuswahlBaum Java/Code Generation.
Dort 2.ter Tab: Code and Comments.
In Code and Comments Code/New Java File auswählen.
Edit button klicken.
Dort das folgende reinpasten:

Code

/* ${file_name}
* Created on ${date}
*/
${package_declaration}
${typecomment}
${type_declaration}

Apply Klicken.

Dann Comments / Types klicken (wo du vorher Code/New Java File gewählt hast).
Edit Button.
Das folgende reinpasten:

Code

/**
* Add one sentence class summary here.
* Add class description here.
*
* @author ${user}
* @version 1.0, ${date}
*/

Apply drücken. Ok drücken.

Testweise eine neue Java Klasse erzeugen.
Der automatisch generierte code sieht nun so aus:

Code

* Test1.java
* Created on 20.09.2003
*/
package de.aja.blboerse.integration.dao;
/**
* Add one sentence class summary here.
* Add class description here.
*
* @author Axel
* @version 1.0, 20.09.2003
*/
public class Test1 {

}

Bekanntlich werden die /** Kommentare vom javadoc Tool genutzt, um automatisch eine Dokumentation im Html Format zu erzeugen.

[Axel_Janssen]

Noch ein Tipp:

Die Glühbirne (lightbuld).

Du willst ein ArrayList erzeugen:

Code

ArrayList users = new ArrayList();

Die Klasse ArrayList befindet sich aber im Java Paket java.util.* und ist noch nicht in den Import Statements der Klasse.
Am linken Rand des Editors erscheint ein rotes Kreuz (für Fehler) und eine Glühbirne.
Durch einen Klick auf die Glühbirne erhälst du eine Liste an Lösungsvorschläge von Eclipse, um den Fehler zu bereinigen.
Einfach auf das erste klicken:
import java.util.ArrayList

Eclipse fügt nun in den ersten Zeilen der Klasse automatisch die folgende Zeile ein:

Code

import java.util.ArrayList;

Das rote Kreuz und somit der Fehler ist weg.

Bei mehr als einer benötigten Klasse pro Paket im Import präferiere ich die Schreibweise

Code

 
import java.util.*;

als sowas wie z.B.:

Code

import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.Vector;
import java.util.ArrayList;

weil es übersichtlicher ist.
Aber das kann man ja schnell von Hand ändern.  

Die Lightbulb kann auch für andere Quickfixes benutzt werden. Da kann man sich sicher auch eigene Listeneinträge für Quickfixes hinterlegen. Weiß aber noch nicht wie.

[Axel Janssen temp]

Periodically clean caches and history to avoid Eclipse 'rot'
Today, a quick one.
If you work with a lot of projects, opening multiple Java files and performing big searches and refactorings from time to time, you'll notice that Eclipse becomes increasingly slower. This is somewhat similar with the infamous 'Windows rot'. Except, this time you have solutions other that complete reinstall.
Deleting "workspace/.metadata directory" is such a solution, but a violent one, since you lose all your settings and 'non-code' work. And while the settings can still be exported and reimported after the clean restart of Eclipse, there definitively is some data (such as the "Run" list) which has to be rebuilt from scratch. And if the list has tens of items, that's your precious worktime which is lost.
A nicer, less invasive solution is to delete only the resource history and the JDT caching. That means deleting all the content of the directory "workspace/.metadata/.plugins/org.eclipse.core.resources/.history" (but not the directory itself) as well as *.index files from "workspace/.metadata/.plugins/org.eclipse.jdt.core" and "savedIndexNames.txt" from this same directory.
I've also learned that some hard Eclipse crashes as well as dubious plugin uninstalls (via directory deletions) migh completely bork the workspace, then Eclipse isn't even able to restart ... again, the trick is to delete "workspace/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml" and restart with default workbench. (see also one of my older posts).

[Manfred Dillmann]

Hallo Axel,

schade, dass ich immer nur 1 Promille von dem Verstehe, was Du hier für tolle Sachen schreibst. Da muss ich nachfragen:

1. Was sind MGW?
Such bei google liefert TV-Streaming, was für den Gameboy usw.

2. Ich habe mir nach Deiner Mail zum Debuggen gestern Eclipse installiert. Ist ja wie WSAD, nur "weniger drin" (WSAD habe ich wieder deinstalliert, hat mich erschlagen).

Ich konnte dort auch Deinen Code "irgendwie" unterbringen und der ist auch gelaufen. Aber wie ist das mit dem Debuggen? Der Code wird ausgeführt und da ist nix mit "Einzelschritt-Modus" (so á la LS-Debugger), ich sehe keine Variablen-Inhalte - eigentlich so, wie wenn ich "Run" aufrufe.

Naja, war heute Morgen wieder 04:30 Uhr als ich ins Bett ging. Vielleicht sollte ich mal eine Java-Pause einlegen, ist alles zu neu und zu viel und viel zu viele Kürzel...

Gruss
Manfred

[Axel Janssen temp]

Hi,

MGW:
das hat "Java für Anfänger"-Forum historische Gründe. In meiner stürmischen Jugend glaubt ich Notes-Coder davon zu überzeugen, die Sun Certified Java Programmer Zertifizierung zu machen. MGW heisst Marcus Green Wochen (Marcus Green hat gute Texte für die Zertifizierungsvorbereitung geschrieben).
Hat sich aber nicht durchgesetzt.

Leider schweigt dieses ansonsten gute Tutorial über debugging:
http://www.3plus4software.de/eclipse/index.html

Die Ecliipse Menü: Help/Help Contents beschreibt das ganz gut unter:
Tasks/Running and Debugging / Local Debugging

Suspending Threads ist erst mal nicht so wichtig.
Leider wird in "Stepping through the execution of a program" nicht die Smarticons der verschiedenen debug-Aktionen angezeigt. Suche nach gelben Pfeilen und hoovere mit der Maus darüber.

Zum starten der debug session den Käfer-Smart-Icon.
Break point setzen in der grauen Leiste neben dem code (vor starten der debug-session).
Besser vorher Hilfe lesen.
ansonsten die bücher.

WICHTIG: verwirrend ist, dass der debugger auch die core Java Klassen debugt. Bei manchen ist quell-code dabei, bei anderen nicht (kommt die entsprechende Meldung). Bei solchen Methoden immer Step over (nicht step in) benutzen. Oder mehrere breakpoints setzen.
Gruß Axel

[Manfred Dillmann]

Hallo Axel !

>>Hat sich aber nicht durchgesetzt.<<

Mein lieber Axel - so treibst Du Einsteiger garantiert in den Wahnsinn...

>>Tasks/Running and Debugging / Local Debugging<<

Yippiee... es klappt. Was für eine Freude!

Sag mal, könnte es sein, das man nach Java süchtig wird, wenn man mal die ersten Hürden genommen hat?

Danke für den Hinweis!

Manfred

[Axel Janssen temp]

Sag mal, könnte es sein, das man nach Java süchtig wird, wenn man mal die ersten Hürden genommen hat?

problematisch wird es, wenn man diese Symptome an sich feststellt:
(in der Reihenfolge)
- man glaubt alle Nachrichten auf javaBlogs verfolgen zu müssen:  
http://www.javablogs.com/ViewDaysBlogs.jspa?date=6&month=0&year=2004
- man glaubt, alle threads auf der Ranch verfolgen zu müssen: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_daily
- versacken in meaningless drivel: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=32

[Manfred Dillmann]

Hallo Axel!

>>problematisch wird es, wenn man diese Symptome an sich feststellt:<<

Keines trifft bei mir bislang zu - kein Wunder: würde ja jetzt auch kaum ein Wort von dem verstehen, was die Leute da schreiben (nicht wegen meinem mittelprächtigen english).

Man soll ja im Anfall einer Euphorie keinen Unsinn schreiben, aber:
Ich habe jetzt schon den Eindruck, dass Eclipse - ich meine in erster Line den Debugger, den Rest blicke ich noch nicht - so 1 bis 2 Lichtjahre weiter ist als der von LS?

Schnell weg, dass mich keiner der HardCore Notes-Freude erschlägt...

Gruss
Manfred

[Semeaphoros]

Na ja, sagen wirs so, der LS-Debugger ist Jahre hinter der "state of the art" Technologie zurück. Da hatte ich vor 10 Jahren mit Periscope schon ein deutlich besseres Werkzeug zur Hand als der LS-Debugger. Schon nur die Unfähigkeit, die Items in einem Doc alphabetisch zu sortieren .........

[Axel_Janssen]

Trotz des Einwandes von Semaphoros mutmasse ich (ohne es wirklich beweisen zu können), dass objekt-orientierte Sprachen besonders für IDEs geeignet sind.
Smalltalk war ja auch immer bekannt für seine gute Entwicklungsumgebung.

Die ersten Java IDEs wie Visual Cafe waren trotzdem nicht nur meiner Meinung nach ziemlich instabiler Mist.

IBM hat mit Eclipse einen völligen Neuanfang gemacht. Hab jetzt vergessen wie das ältere Tool mit dem komischen Repository geheissen hat.

Eclipse ist gut.

Gruß Axel

[Semeaphoros]

Na ja, mein Einwand und Deine letzte Aussaga haben eigentlich ausser Deinem Bezug nichts miteinander zu tun. Der LS-Debugger ist einfach mangelhaft implementiert, das hat mit IDE, OO und ähnlichem eigentlich reichlich wenig zu tun.

Ueber den Rest Deiner Aussage wage ich eigentlich nichts zu sagen. Das ist eine ziemlich vage Vermutung, die Du da äusserst, es dürfte recht schwierig sein, zu beurteilen ob mehr richtig oder mehr falsch. Ganz schwarz-weiss geht das eh nicht.

[Axel_Janssen]

Ueber den Rest Deiner Aussage wage ich eigentlich nichts zu sagen. Das ist eine ziemlich vage Vermutung, die Du da äusserst, es dürfte recht schwierig sein, zu beurteilen ob mehr richtig oder mehr falsch. Ganz schwarz-weiss geht das eh nicht.

Jens, Du hast verdammt Recht.
So sollte man nicht argumentieren.