[quote=Sen-Mithrarin]ich kenne erlich gesagt niemanden der bei großen komplexen Projekten sich wirklich die Mühe macht und eine GUI noch per Hand schreibt (würde zu viel Zeit kosten)[/quote]Ich mache das.
Die Zeit Die Du beim Malen im GUI-Builder sparst spare ich hinten raus bei der Fehlersuche, die ich nicht machen muss.
Mag sein dass sich dass mit JavaFX ändern wird…
bye
TT
Jetzt bringen wir die Sache doch mal bitte auf den Punkt.
Jeder redet hier von was anderem und plötzlich geht auch noch gleich eine GUI-Builder Diskussion los und das braucht es jetzt wirklich nicht.
Vollkommen uninteressant für einen Schüler im Moment!
„Unresolved Compilation Problem“
Ist ein Fehler der Ausgegeben wird wenn der Compiler bereits vor der Ausführung einen Fehler im Code bemerkt, das Programm aber trotzdem ausgeführt wurde.
Mit anderen Worten: Du suchst jetzt in Eclipse in deinem Projekt nach Dateien/Klassen die mit einem roten X markiert wurden und dann suchst du nach der Zeile die mit einer roten Zickzacklinie unterstrichen wurde.
Über diese Zeile gehst du mit deiner Maus, daraufhin sollte Eclipse einen Tooltip anzeigen mit dem Fehler der in dieser Zeile vorliegt.
Hinzu solltest du in catch-Blöcke, wenn du sie schon leer lässt, wenigstens
„e.printStackTrace();“
reinschreiben damit aufgefangene Fehler auch in der Konsole ausgegeben werden und nicht heimlich verschluckt werden.
Beste Grüße
TMII
@TMII
Klingt irgendwie widersprüchlich dein Post.
Wenn ein Compiler einen Fehler feststellt dann kommt in der Regel kein .class-File bei raus was überhaupt ausgeführt werden könnte. Wie soll man also Code ausführen den der Compiler nicht übersetzt ?
“Unresolved Compilation Problem” treten in der Regel auf wenn man zwei voneinander abhängige Klassen unabhängig voneinander compiled. Dass kann dann z.B. so aussehen dass man eine main-Klasse hat die halt eine Abhängigkeit zu einer Worker-Klasse hat, die Worker-Klasse aber nicht zur main-Klasse. Compiled man nun die main-Klasse braucht der Compiler vorher die Worker-Klasse und compiled diese ebefalls mit. Dabei werden Compile-Time checks durchgeführt und geprüft ob überhaupt alles passt. Nur wenn das erfolgreich durchläuft erhält man am Ende zwei .class-Files.
Ändert man nun aber die Worker-Klasse ab, so kann man diese unabhängig von der main-Klasse compilen. Es fehlen also Compie-Time-Prüfungen!
Führt man nun die main-Klasse mit einer veränderten Worker-Klasse aus passen beide plötzlich nicht mehr zusammen. ~ Sowas ist in der Regel die Ursache für geposteten Error.
ABER ! : wie bereits erwähnt : normalerweise steht dann im StackTrace auch drin was genau nicht zusammen passt und in welcher Zeile das passiert ist. Es ist mir bisher noch nie untergekommen das im Stack eine Zeile mit Methodensignatur als Ursprung angegeben wird - da es in einer solchen Zeile halt zu keinem Fehler kommen kann. Daher ist relativ klar dass die Exception nicht zum Code passt. Das wiederum lässt darauf schließen das Source und Class nicht zusammenpassen (z.B. auf Grund obenbeschriebener Änderung) ~ und in einer IDE gibt es für solche Probleme die Funktion “clean & build”. Es ist daher nicht weiter nötig das TO jetzt nach irgendwelchen (vermutlich nicht mal angezeigten Fehlern) sucht wenn er stattdessen erstmal sein Projekt aufräumen muss was vermutlich den Fehler schon beseitigt.
public class Testchamber42 {
public static void main(String[] args) {
int i = 1L;
}
}
Exception in thread "main" java.lang.Error: Unresolved compilation problem:
Type mismatch: cannot convert from long to int
at de.tmi.sciencx.testchamber42.Testchamber42.main(Testchamber42.java:6)
Inwiefern ich jetzt vergessen habe hier irgendwelche Abhängigkeiten zu bilden musst du mir gerade nochmal erklären.
Ich glaube du verwechselst hier C++ mit Java.
Der C++er braucht aus gutem Grund 5Minuten wofür der Java und C# Compiler nur 5 Sekunden braucht. Bei JITs sind die Anforderungen an einen Compiler nunmal um einiges höher.
Warum beim TO aber keine Fehlerspezifizierung steht ist eine unbeantwortete Frage und wahrscheinlich dem zu verschulden (wie du bereits sagtest) das Informationen weggelassen wurden und der Thread-Ersteller ist weiter gezogen - er ist immerhin aktiv in einem anderen Thread im Moment.
Ich schätze mal er hat das Problem bereits selber gefunden, also lohnt es wohl nicht weiter hier nachzugraben.
[QUOTE=Sen-Mithrarin]nicht zusammenpassen (z.B. auf Grund obenbeschriebener Änderung) ~ und in einer IDE gibt es für solche Probleme die Funktion
„clean & build“. Es ist daher nicht weiter nötig das TO jetzt nach irgendwelchen (vermutlich nicht mal angezeigten Fehlern) sucht wenn er stattdessen erstmal sein Projekt aufräumen muss was vermutlich den Fehler schon beseitigt.[/QUOTE]
So ist es leider.
Also noch mal, auch wenn ich mich da weit aus dem Fenster lehne. Eclipse ist in der Lage, weil es sich nicht /bin/javac.exe bedient, auch Source-Code auszuführen, der sich eigentlich nicht zu Bytecode übersetzen lässt, also compile time errors enthält. Dann entstehen diese kryptischen Fehlermeldungen, die kein Mensch mehr nachvollziehen kann, wir auch auch nicht. Source-Code sollte aber keine statischen und keine dynamischen… Fehler enthalten. Deswegen: Fehler suchen, was unterstrichelt ist, verbessern, Projekt clean-up, übersetzen, Programm starten, und lächeln. 
Außerdem:
Edit: Kann jemand toRoundString2 verbessern?
/**
* @author CB
*/
public class JavaApplication3 {
public static String toRoundString1(double value) {
value *= 100;
value = Math.round(value);
value /= 100;
return Double.toString(value);
}
/**
*
* @param value
* @return ...XXX,XX
*/
public static String toRoundString2(double value) {
if (value == 0) {
return "000,00";
}
value *= 100;
value = Math.round(value);
long lon_val = (long) value;
if (lon_val < 100) {
}
StringBuilder sb = new StringBuilder(Long.toString(lon_val));
while (sb.length() < 5) {
sb.insert(1, "0");
}
sb.insert(sb.length() - 2, ",");
return sb.toString();
}
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
System.out.println(-Math.PI * 1024);
System.out.println(toRoundString1((float) -Math.PI * 1024));
System.out.println(-Math.PI * 1024.1234);
System.out.println(toRoundString2((float) -Math.PI * 1024.1234));
System.out.println("");
System.out.println(-1024.0 * 1024 * 1024.1234);
System.out.println(toRoundString1(-1024.0 * 1024 * 1024.1234));
System.out.printf("%f%n", -1024.0 * 1024 * 1024.1234);
System.out.println(toRoundString2(-1024.0 * 1024 * 1024.1234));
System.out.println("");
System.out.println(-0.1234 * 0.1234);
System.out.println(toRoundString1(-0.1234 * 0.1234));
System.out.printf("%f%n", 0.1234 * 0.1234);
System.out.println(toRoundString2(0.1234 * 0.1234));
}
}```
-3216.990877275948
-3216.99
-3217.3785498094007
-3217,38
-1.0738712182784E9
-1.07387121828E9
-1073871218,278400
-1073871218,28
-0.01522756
-0.02
0,015228
200,00
Das sieht ja nun ganz falsch aus. Format bitte: 001,32 ([-], drei Vorkomma, zwei Nachkomma; keine wiss. Schreibweise).Geht es dir nur darum, selbst einmal die Aufteilung zu implementieren?
Ansonsten kannst du einfach die Klasse DecimalFormat nehmen. Wurde glaube ich auch schon angesprochen
(oder der NumberFormat?):
DecimalFormat decimalFormat = new DecimalFormat("000.00");
return decimalFormat.format(value);
}
Der rundet dir das Ganze auch.
Eigentlich müsste ich hier mal den ganz großen Banhammer schwingen … aber lassen wir das …
@TMII @CyborgBeta
ÄHM … W T und doppel F !
Lasse ich den Beispiel-Code durch den Oracle-Compiler rattern bekomme ich auch sauber einen compiletime error
D:\data\java>javac Testchamber42.java
Testchamber42.java:5: error: incompatible types: possible lossy conversion from long to int
int i=1L;
^
1 error
Ergo : es ist schon vorher klar das es hier zu Problemen kommt.
Wenn irgendeine IDE (um jetzt mal nicht speziell auf Eclipse rumzuhacken) sich eines eigenen Compilers bedient der solche Fehler ignoriert und den Code trotzdem übersetzt hat der Autor des Source zumindest nicht mehr ganz alleine Schuld daran das irgendwas nicht funktioniert. Sei es jetzt weil man eine Warnung (die auch noch mir völlig unverständlich eine Möglichkeit bietet diese dauerhaft zu ignorieren) wegdrückt oder der Compiler (bzw dessen Parser) gar keine Meldung erzeugt und stattdessen einfach stumpf Bytecode draus macht.
Sorry, aber ich verstehe erlich gesagt den Sinn dahinter nicht überhaupt einen solchen Compiler zu schreiben der Code baut der nach den Vorgaben der Sprache ungültig ist. Und wer jetzt auf die Idee kommt “ja aber zum testen/debuggen” der macht sicher auch solche Fehler wie catch(NPE) statt korrekt if(null).
Zumindest zeigt das Beispiel das eine entsprechende Fehlerbeschreibung erzeugt wird die TO höchstwahrscheinlich nicht mitkopiert/-gepostet hat.
Da aber, wie schon angemerkt, TO sich scheinbar nicht wirklich für interessiert hier noch aktiv mitzuwirken und wir mal wieder dabei sind kollektiv einen Thread zu hijacken erlaube ich mir mal auf den Button gelöst zu klicken.
[QUOTE=Sen-Mithrarin]Eigentlich müsste ich hier mal den ganz großen Banhammer schwingen … aber lassen wir das …
@TMII @CyborgBeta
ÄHM … W T und doppel F ![/QUOTE]
Du bist doch gar nicht Mod! Meinst du mich damit, mit Ban? Ich fande es eine gut Übung für ihn, in diesem Fall diese einfache Formatierungs-Funktion selber zu schreiben.
Unabhängig davon sollte Code mit Erorrs gar nicht kompiliert oder ignoriert werden, das macht Java normalerweise auch richtig.
Kollektiv Thema hijacken: Bist du der Meinung, wir hätten ihn verscheucht oder was? Und ich sei daran Schuld? Ne, den Schuh ziehe ich mir nicht an.
Komische Frage, halb komische Antwort. Hoffe auf eine Antwort von dir in max. 20 Min. : D
*** Edit ***
[QUOTE=Sen-Mithrarin;118964]@TMII
Klingt irgendwie widersprüchlich dein Post.
Wenn ein Compiler einen Fehler feststellt dann kommt in der Regel kein .class-File bei raus was überhaupt ausgeführt werden könnte. Wie soll man also Code ausführen den der Compiler nicht übersetzt ?
“Unresolved Compilation Problem” treten in der Regel auf wenn man zwei voneinander abhängige Klassen unabhängig voneinander compiled.[/QUOTE]
Edit: Damit ist eigentlich schon alles gesagt. Jedenfalls, der TO weiß nun bescheid.