Erste Schritte Jar-Datei erstellen -?

  • Themenstarter Themenstarter LeChat
  • Beginndatum Beginndatum
L

LeChat

Gast
Hallo,

Habe ein paar Sachen ausprobiert um eine Jar-Datei zu erstellen.
Das erste File funktionierte, wobei die restlichen nicht mehr.

Hatte die Anleitung aus dem Buch "Java von Kopf bis Fuss" befolgt. Es stand es gibt verschiedene Möglichkeiten um eine Jar zu erstellen, aber sie empfohlen die sicherste.

Es stand man müsse eine Verzeichnisstrutur erstellen, (classes-de-files-file.class) und (source-de-files-file.java).

-Zuerst die Java-Datei ins unterste "source" Verzeichnis legen "files".
-Auf der cli in den "source" Ordner wechseln und "javac -d ../classes/ch/JFiles ch/JFiles/File.java" ausführen.
-Eine "manifest.txt" Datei erstellen, mit "Main-Class: de.files.filename (+ enter) drücken (Zeilenumbruch).
-Auf der cli in den "classes" Ordner wechseln und "jar -cvmf manifest.txt name.jar de" ausführen.

Aber beim ausführen der Jar-Datei kommt es zu einem Fehler, bei Doppelclick Exception-Dialog" und über die cli(Kommandozeileninterpreter) gibts einen Ausnahmefehler "Exception in thread "main" java.lang.NoClassDefFoundError:"

Habe die aktuellsten Jre und Jdk versionen.

Vielleicht kennt jemand dieses Buch besser, oder kennt sich gut mit Jar-Archiv erstellen aus ?

Vielen Dank für die Hilfe

LeChat
 
Bevor jemand antwortet, der das ganze gerne per Hand durchexerziert: So eine IDE wie z.B. Eclipse bietet ein einfaches "Export as JAR" an, damit spart man sich das alles meistens... ist das eine Option?
 
Mögliche Option ja. Aber habe nur ein zwei mal mit Eclipse gearbeitet, für den Anfang benutze ich immer noch einen normalen Editor.
Habe es mit der IDE probiert aber komme beim kompilieren nicht weiter, da zum in jar exportieren eine class-Datei vorhanden sein müsste.

Entschuldigt noch wegen der zusammen gewürfelten Erklärung vorhin, aber es könnte auch interessant sein zu wissen wie die jar- und javactools im Hintergrund arbeiten.

Gute Nacht
LeChat
 
könntet ihr BITTE mal damit aufhören anfänger immer zu einer IDE zwingen zu wollen ? wohin das führt haben wir doch mal gesehen als ein user mit angeblich 3 jahren erfahrung fragte was ein "terminal" sei und dachte wir meinten damit den output seiner IDE ...

erlich ... anfänger sollten wirklich die ersten schritte mit nem editor und nem terminal machen ... damit sie auch verstehen was eine IDE da im hintergrund mit ihren meist doch recht dämlichen build-tools macht ...

[OT]boar erlich ... jedes mal wenn ich das lese könnte ich sowas von kotzen ... und jeder der mir jetzt kommt mit von wegen ja erhöt produktivität und bla ... ganz erlich ... mal als gegenantwort : ich arbeite seit 8 jahren OHNE IDE ... und bin damit durch aus produktiver als so manche IT-studies ... da ich kein AUTO-COMPLETE oder der gleichen brauche sondern das alles selbst recht schnell schreibe ...
auch brauch ich keine komplizierten libs ... ich mach das meiste mit der SE-API ... ergo : läuft auf allen VMs ohne das ich mich drum kümmern muss wie und wo irgendwelche libs liegen ...

bevor als der nächste beim nächsten anfänger wieder gleich losprahlt : nutz ne IDE ... sollte er sich VORHER mal überlegen was dann dieser anfänger in einigen jahren als "fortgeschrittener" für "anfängerfragen" stellen kann eben weil er diese einfachen grundlagen nie kennen gelernt hat ...

danke ... und jetzt back to topic
[/OT]
@TO
hmm ... an sich schon mal gar nicht so richtig

1) du hast einen SOURCE / SRC ordner ... in dem deine projekt-struktur liegt ... also z.b. SRC/ch/JFiles/*.java .. packages schreibt man aber klein ... also "jfiles" ... und entsprechend in deinen klassen auch
2) dann hast du einen BINARY / BIN / CLASS ordner in den deine sturktur dann landet ... hier hast du den ersten fehler ... es reicht lediglich das ziel-dir anzugen ... also so : [c]javac -d ..\BIN ch\jfiles\*.java
dadurch wird automatisch in BIN/ch/jfiles/*.class erzeugt ...
wenn man wie "-d ..\BIN\ch\jfiles" nutzen würde würde dort erst die struktur erstellt ... also : "BIN/ch/jfiles/ch/jfiles/*.class" ... und das ist ja nun mal FALSCH
3) man erzeugt in der regel KEIN eigenes manifest ... zumindest nicht wenn man NUR Main-Class angeben will ... denn dafür besitzt "jar" die option "e" mit der die zustartene klasse direkt angegeben werden kann ... erst wenn es dann noch mit Classpath und anderen attributen losgeht die man nicht via cli an "jar" übergeben kann erzeugt man ein manifest ... also würde dieser schritt bei dir rausfliegen
4) da du kein eigenes manifest nutzt und auch sonst lieber den ganzen pfad nutzen solltest würde sich dann "jar" wie folgt ändern : "jar vcef ch.jfiles.Main deinJarFile.jar ch\jfiles\*.class" wobei die reihenfolge von "e" und "f" zu beachten ist ...


@alle die jetzt mit build-tools kommen wollen

ganz erlich : ich versteh nicht was so umständlich sein soll sich ein bisschen mit den cli-tools auszukennen und seine ordner-struktur selbst entsprechend festzulegen anstatt sich mit irgendwelchen build-tools und deren scripten rumzuschlagen ...
und für alle die jetzt noch kommen mit : "und wie bindet man resourcen ein ?" die gucken dann bitte selbst in die DOC unter Java Platform Standard Edition 7 Documentation
 
@TO
hmm ... an sich schon mal gar nicht so richtig

1) du hast einen SOURCE / SRC ordner ... in dem deine projekt-struktur liegt ... also z.b. SRC/ch/JFiles/*.java .. packages schreibt man aber klein ... also "jfiles" ... und entsprechend in deinen klassen auch
2) dann hast du einen BINARY / BIN / CLASS ordner in den deine sturktur dann landet ... hier hast du den ersten fehler ... es reicht lediglich das ziel-dir anzugen ... also so : [c]javac -d ..\BIN ch\jfiles\*.java
dadurch wird automatisch in BIN/ch/jfiles/*.class erzeugt ...
wenn man wie "-d ..\BIN\ch\jfiles" nutzen würde würde dort erst die struktur erstellt ... also : "BIN/ch/jfiles/ch/jfiles/*.class" ... und das ist ja nun mal FALSCH
3) man erzeugt in der regel KEIN eigenes manifest ... zumindest nicht wenn man NUR Main-Class angeben will ... denn dafür besitzt "jar" die option "e" mit der die zustartene klasse direkt angegeben werden kann ... erst wenn es dann noch mit Classpath und anderen attributen losgeht die man nicht via cli an "jar" übergeben kann erzeugt man ein manifest ... also würde dieser schritt bei dir rausfliegen
4) da du kein eigenes manifest nutzt und auch sonst lieber den ganzen pfad nutzen solltest würde sich dann "jar" wie folgt ändern : "jar vcef ch.jfiles.Main deinJarFile.jar ch\jfiles\*.class" wobei die reihenfolge von "e" und "f" zu beachten ist ...

Hallo,

Danke für die Antworten.

Werde die Ordnernamen klein schreiben.
Der Schalter "-d" von "javac", müsste die Ordenerstruktur unterhalb von "classes" automatisch erstellen, so stehts auch im Buch. Aber komischerweise landen die class-Dateien immer im Ordner "classes" und es werden auch keine Unterordner erstellt oder sieht man die nicht im Dateiverzeichnis, wobei die class-Datei sichtbar ist.

Meinst du ich sollte den Schalter "e" benutzen um den Einstiegspunkt der main() Methode anzugeben.
Im Buch stand man sollte eine manifest.txt erzeugen und die jar-Datei funktioniert ja auch.
Also classpath, sollte vom OS konfiguriert sein, falls die jar-Datei auf einem anderen System läuft, müsste ich indemfall eine manifest-Datei erzeugen ?

Wie ist das mit der Reihenfolge von den Schaltern, "vcef" v-verbose(was macht das?) , c-create(jar erstellen) , e-einstiegspunkt(main-methode) , f-file(class-files-ort) ?
"jar vcef ch.jfiles.Main deinJarFile.jar ch\jfiles\*.class" e=ch.jfiles.Main , f= deinJarFile.jar ch\jfiles\*.class ?

Vielen Dank
LeChat
 
nun ... ich vermute dann hast du in deinen files kein package deklariert ...
die daten liegen in SRC/ch/jfiles ... also müssen alle daten auch ganz oben als erste zeile [c]package ch.jfiles;[/c] stehen haben ... andernfalls kann es natürlich zu fehlern kommen ...

zum manifest : wie gesagt ... so lange es nur darum geht MAIN anzugeben kann man das ruhig mit "e" machen ... falls allerdings noch mehr infos rein sollen muss man ein eigenes manifest erstellen (richtige dateiendung wäre übrigens MF .. und nicht TXT) und dies dann mit "m" angeben ... wobei dann "e" wegzulassen ist ... (wird glaub ich eh ignoriert falls "m" angegeben wird) ...

die reihenfolge der switches ist desshalb wichtig da javac entsprechend die parameter sortiert ...

gibt man "vcef" an so erwartet jar erst die klasse mit main und dann den namen des zu erzeugenden jar-files ... verwendet man aber z.b. "cfm" so erwartet jar erst das man den namen angibt und dann den pfad zum eigenen manifest ...
die reihenfolge der switches gibt also an in welcher reihenfolge die parameter kommen ... wenn man hier was vertauscht funktionierts nachher nicht ...

"v" steht für "verbose" und erzeugt zusätzlichen info-output ... meist kann man damit schon ne ganze menge fehler beheben wenn am ende was nicht funktioniert da jar hier genau ausgibt was es macht ... und sollte zu debug-zwecken eigentlich immer verwendet werden ...
 
Ich finde es auch nicht richtig, dass sich Anfänger gleich, ohne die Hintergrundgeschehnisse zu verstehen, sich auf eine IDE stürzen.
Allerdings: Ich bin auch dafür, dass man sich Werkzeuge baut, die einem die Arbeit leichter machen.
Weil, wenn man sich vertippt, schreibt man eine lange Zeile evtll. noch mal.

Daher gibts zum Erstellen von Jar-Dateien in der FAQ einen schönen Beitrag und auch eine Batchdatei, die einem etwas Arbeit abnehmen kann.
 
Weil, wenn man sich vertippt, schreibt man eine lange Zeile evtll. noch mal.

hmm ... wenn deine terminals so konfiguriert sind das man nicht mit "UP" durch die vorherigen befehle gehen und diese editieren kann mag das bitte dein problem sein ... CMD.exe unter modernen windows-versionen verwendet standard-mäßig DosKey ... womit es eben entfällt eine lange zeile noch mal komplett schreiben zu müssen ... man drückt einfach "UP" ... geht an die stelle wo der fehler ist ... korrigiert diesen und drückt return ...

zum build-tool : hmm ... braucht man eigentlich eher weniger ... und kann auch teilweise manchmal eher zu fehlern führen wenn man es an einer stelle in einer gewissen weise verwendet die so nicht gedacht war ... dann kommt nämlich auch nur murks bei raus
 
nun ... ich vermute dann hast du in deinen files kein package deklariert ...
die daten liegen in SRC/ch/jfiles ... also müssen alle daten auch ganz oben als erste zeile [c]package ch.jfiles;[/c] stehen haben ... andernfalls kann es natürlich zu fehlern kommen ...

zum manifest : wie gesagt ... so lange es nur darum geht MAIN anzugeben kann man das ruhig mit "e" machen ... falls allerdings noch mehr infos rein sollen muss man ein eigenes manifest erstellen (richtige dateiendung wäre übrigens MF .. und nicht TXT) und dies dann mit "m" angeben ... wobei dann "e" wegzulassen ist ... (wird glaub ich eh ignoriert falls "m" angegeben wird) ...

die reihenfolge der switches ist desshalb wichtig da javac entsprechend die parameter sortiert ...

gibt man "vcef" an so erwartet jar erst die klasse mit main und dann den namen des zu erzeugenden jar-files ... verwendet man aber z.b. "cfm" so erwartet jar erst das man den namen angibt und dann den pfad zum eigenen manifest ...
die reihenfolge der switches gibt also an in welcher reihenfolge die parameter kommen ... wenn man hier was vertauscht funktionierts nachher nicht ...

"v" steht für "verbose" und erzeugt zusätzlichen info-output ... meist kann man damit schon ne ganze menge fehler beheben wenn am ende was nicht funktioniert da jar hier genau ausgibt was es macht ... und sollte zu debug-zwecken eigentlich immer verwendet werden ...

Vielen Dank für Eure Antworten sind hilfsreich und informationsreich.

Irgendwie war die Kopie von meiner Main-Datei ohne package angabe, aber bei den nächsten jars werde ich das sicher auch so eintragen.

Noch eine Frage zur jar Erstellung und Ausführung. Wie ist das mit den verschiedenen JRE-Versionen und Betriebsystemen, funktioniert eine mit java7 erstellte jar auch auf java6 oder älter?

Für den Moment gehts mit dem editor und cli gut, bei etwas grösseren werde ich die ide nehmen, aber auch so mal anschauen und probieren.

Nochmals Danke

Schönen Abend
LeChat
 
funktioniert eine mit java7 erstellte jar auch auf java6 oder älter?
Die Jar-Erstellung dürfte nicht das Problem sein. Ich denke, dass sich da das Dateiformat nicht weiter verändert hat.
Aber viel wichtiger ist zu wissen, dass Java nur aufwärts kompatibel ist. Also aktuelle Interpreter können mit älteren Compilern kompilierten Java-Code ausführen. Nur anders herum geht das nicht.
Ältere Interpreter können mit Bytecode neuerer Compiler nichts anfangen.
 
Hallo,

Danke für die weiteren Antworten.

Das mit dem -target müsste man in der cli aufrufen.
Wobei es steht [c]If -source is not specified, the value of -target is 1.6[/c]
womit von version 1.6 bis zur neusten, es möglich wäre die Datei auszuführen. So hab ich es momentan verstanden.

Habe aber noch eine Frage zum oberen Problem. Die jar-Datei die ich momentan testen wollte, funktioniert nicht, sie wurde gleich erstellt wie eine andere, habe auch den Inhalt kontrolliert mit "-tf" und "-xf" und nichts ungewöhnliches bemerkt.

Die eine die funktioniert ist eine GUI, die andere die nicht funktioniert ist eine Konsolenanwendung.
Habe irgendwo gelesen, dass Konsolenanwendungen nicht als jars ausgeführt werden können, ausser mit etwas Umweg.
Die problem jar probierte ich auf der Konsole auszuführen mit "java -jar file.jar" wobei die Fehlermeldung kam "Datei nicht gefunden!", aber die Datei wurde erstellt und liegt im richtigen Verzeichnis, was auch mit "dir" auf der Konsole und in der Gui zusehen ist.

Wie könnte man das noch etwas genauer analyisieren ?

Vielen Dank
LeChat
 
Also meiner Erfahrung nach braucht man keine Umwege, um eine Konsolen Anwendung als Jar von der Konsole auszuführen.

Ist "Datei nicht gefunden!" denn die genaue Fehlermeldung?
 
Noch eine Aktualisierung zum Problem. Die Fehlermeldung habe ich beseitigt, es war ein println("Datei nicht gefunden!") von einer FileNotFoundException, die beim Testen nicht vorkam.

Komisch, weil im Code, ein Befehl vorkommt, der die Java-Klasse [c]Processbuilder[/c] benutzt die ein Konsolenbefehl(Windowstool) aufruft welcher eine Datei erzeugt und etwas reinschreibt.
Ohne jar funktionierts. Mit jar, bei Doppelclick oder über CLI passiert nichts.

Vielleicht kann aus der jar nichts geschrieben werden ?

Möglicherweise kennt jemand die vorgehensweise der jar besser ?

Hier der topic, wo ich gelesen habe das jars keine Konsolenanwenugen ausführen:

http://www.java-forum.org/java-basics-anfaenger-themen/129327-jar-datei-ausfuehren.html


Vielen Dank
LeChat
 
Wobei es steht [c]If -source is not specified, the value of -target is 1.6[/c]

leider hat Marco nur auf v6 der doc gelinkt ... wenn du das selbe auf der v7 doc liest steht dort "-target is 1.7" ... also immer die Version die du installiert hast ...

grundlegend ja : man kann z.b. mit "-source 1.6 -target 1.6" angeben das code für ne 6er VM erzeugt wird und die dann auch lauffähig ist .. aber ansonsten ist der code nur auf mindestens der selben Version wie der Compiler und aufwärts lauffähig
 
leider hat Marco nur auf v6 der doc gelinkt ... wenn du das selbe auf der v7 doc liest steht dort "-target is 1.7" ... also immer die Version die du installiert hast ...

grundlegend ja : man kann z.b. mit "-source 1.6 -target 1.6" angeben das code für ne 6er VM erzeugt wird und die dann auch lauffähig ist .. aber ansonsten ist der code nur auf mindestens der selben Version wie der Compiler und aufwärts lauffähig

Vielleicht 1.1 angeben dann sollte es auch auf ein paar Jahre ältere Geräte laufen.

Momentan brauch ich nur die neueste, aber leider stimmt etwas nicht mit der jar.

Danke
LeChat
 
Noch eine Aktualisierung zum Problem. Die Fehlermeldung habe ich beseitigt, es war ein println("Datei nicht gefunden!") von einer FileNotFoundException, die beim Testen nicht vorkam.

Komisch, weil im Code, ein Befehl vorkommt, der die Java-Klasse [c]Processbuilder[/c] benutzt die ein Konsolenbefehl(Windowstool) aufruft welcher eine Datei erzeugt und etwas reinschreibt.
Ohne jar funktionierts. Mit jar, bei Doppelclick oder über CLI passiert nichts.

Vielleicht kann aus der jar nichts geschrieben werden ?

Möglicherweise kennt jemand die vorgehensweise der jar besser ?

Hier der topic, wo ich gelesen habe das jars keine Konsolenanwenugen ausführen:

http://www.java-forum.org/java-basics-anfaenger-themen/129327-jar-datei-ausfuehren.html


Vielen Dank
LeChat


Ich hab' das Topic mal überflogen aber nicht festgestellt wo da jemand behauptet, dass jars keine Konsolenanwendungen ausführen.

Es wird darauf hingewiesen, dass wenn man eine Konsolenanwendung geschrieben hat, diese auch per Konsole starten muss. Per einfachem Doppelklick passiert nichts, da keine GUI vorhanden ist.
 
Jar-Dateien sind von Hause aus mit dem javaw-Interpreter verknüpft, der aber bei seiner Ausführung im Gegensatz zum java-Interpeter keine Ausgaben in der Konsole macht, weil er keine Konsole öffnet.
Daher müssen Konsolenprogramme, die in Jar-Dateien zusammengefasst sind, mit dem java-Interpreter ausgeführt werden.

Code:
java -jar MeinKonsolenProgramm.jar
 
wie ich schon damals in dem gelinkten thread sagte : wenn man eine terminal-anwendung entwickelt muss man diese auch in einem terminal ausführen ... da "JAR" so normalerweise beim doppelklick ohne ein terminal ausgeführt wird (oder besser : es wird dafür gesorgt das dies "versteckt" ist)

wenn ich z.b. ganz einfach in eine main() nur ein sysout schreiben würde und die fertige JAR dann normal auf dem desktop per doppelklick starte ist es völlig normal das "nichts passiert" ... denn das was passiert passiert ja im terminal ... das aber so nicht sichtbar ist ...

wenn man also eine app haben will bei der auch was passiert wenn man diese einfach so startet muss man schon eine GUI dazu basteln die einem auch was anzeigt ...

oder habe ich jetzt irgendwas falsch verstanden ? was genau macht die app und was erwartest du das passiert ? ... und was passiert stattdessen .. oder eben : was passiert eben nicht ?

"funktioniert nicht" ist halt keine sinnvolle fehlerbeschreibung ...
 
wie ich schon damals in dem gelinkten thread sagte : wenn man eine terminal-anwendung entwickelt muss man diese auch in einem terminal ausführen ... da "JAR" so normalerweise beim doppelklick ohne ein terminal ausgeführt wird (oder besser : es wird dafür gesorgt das dies "versteckt" ist)

wenn ich z.b. ganz einfach in eine main() nur ein sysout schreiben würde und die fertige JAR dann normal auf dem desktop per doppelklick starte ist es völlig normal das "nichts passiert" ... denn das was passiert passiert ja im terminal ... das aber so nicht sichtbar ist ...

wenn man also eine app haben will bei der auch was passiert wenn man diese einfach so startet muss man schon eine GUI dazu basteln die einem auch was anzeigt ...

oder habe ich jetzt irgendwas falsch verstanden ? was genau macht die app und was erwartest du das passiert ? ... und was passiert stattdessen .. oder eben : was passiert eben nicht ?

"funktioniert nicht" ist halt keine sinnvolle fehlerbeschreibung ...

Danke für die Antworten.

Wollte das gleiche erklären und nicht etwas falsches sagen, dass jars die auf der GUI ausgeführt werden auch nur GUI-Programme beinhalten können und Konsolenanwendungen nur auf der Konsole ausgeführt werden können. Wobei GUI-jars mit javaw.exe und CLI-jars mit java arbeiten.

Zur Problem-Anwendung:

Java:
import java.util.*;
import java.io.*;

public class TaskRemove {
 String name;
 String Name;
 static Process builder1;
 static Process builder2;
 public static void main(String[] args) {
  new TaskRemove().los();
 }

 public void los() { 
  try {  
   FileReader datei = new FileReader("test.txt");
   BufferedReader dat_read = new BufferedReader(datei);
   name = dat_read.readLine();
   Name = "taskA.exe";
   while(name != null) {
    if(name.equals(Name)) {
     builder1 = new ProcessBuilder("cmd", "/c", "taskkill /F /IM taskA.exe /T").start();        
    }
    else {
     los2();
    }
    try {
     Thread.sleep(100);
    } catch(InterruptedException ix) {}
   }
   dat_read.close();
  } catch (FileNotFoundException e) {System.out.println("Datei nicht gefunden!");}
    catch (NullPointerException n) {n.printStackTrace();}
    catch (Exception e) {e.printStackTrace();}
 }

 public void los2() {
  try {
   if(name != AdName) {
    builder2 = new ProcessBuilder("cmd", "/c", "tasklist /SVC /FO LIST > test.txt").start();
    try {
     Thread.sleep(10000);
    } catch(InterruptedException i) {} 
   }
  } catch (Exception ex) {ex.printStackTrace();}
 }
}

Wenn diese Datei kompiliert und ausgeführt wird, funktionierts, nur mit einer jar nicht ?

Vielen Dank
LeChat
 
also beim überfliegen hab ich jetzt keine fehler entdeckt ... und es sollte egal sein wie dieser code ausgeführt wird oder in welcher form er vorliegt ...
das einzige was halt n unterschied macht ist das wenn du das ganze zu nem JAR packst und dieses dann einfach ausführst du nichts siehst ... denn alles passiert im "unsichtbaren" terminal ... also müsstest du das programm schon manuell im terminal starten um eventuelle ausgaben sehen zu können ...

auch die verwendung von CMD ist schwachsinn ... ProcessBuilder gibt ein Process objekt zurück an das InputStream und OutputStream gekoppelt werden können so das man selbst eingaben tätigen und ausgaben lesen und eventuell umleiten kann ... CMD ist kein all-heil-mittel .. sondern zeigt nur das man entweder nicht weis wie man richtig mit sub-prozessen arbeitet oder zu faul dafür ist ... bei dir würde ich aber sagen das du es einfach nicht weist ...

und wenn du das ganze als JAR packst und dann wirklich NICHTS passiert ... also die commandos nicht gecallt werden ... würde ich vermuten das du beim zusammenbauen des JAR irgendwas falsch gemacht hast ... denn an sich sollte der code so funktionieren ...
 
Auch: Was ist "AdName"? Und warum vergleichst du damit den String "name"? Obendrein noch mit !=. Auch bin ich mir nicht sicher, ob du nur eine Zeile aus der Datei einlesen willst oder alle. Denn deine while-Schleife ist im Moment eine Endlosschleife, da "name" niemals verändert wird.

Was genau möchtest du also erreichen? Wie soll das Programm arbeiten?
 
also beim überfliegen hab ich jetzt keine fehler entdeckt ... und es sollte egal sein wie dieser code ausgeführt wird oder in welcher form er vorliegt ...
das einzige was halt n unterschied macht ist das wenn du das ganze zu nem JAR packst und dieses dann einfach ausführst du nichts siehst ... denn alles passiert im "unsichtbaren" terminal ... also müsstest du das programm schon manuell im terminal starten um eventuelle ausgaben sehen zu können ...

auch die verwendung von CMD ist schwachsinn ... ProcessBuilder gibt ein Process objekt zurück an das InputStream und OutputStream gekoppelt werden können so das man selbst eingaben tätigen und ausgaben lesen und eventuell umleiten kann ... CMD ist kein all-heil-mittel .. sondern zeigt nur das man entweder nicht weis wie man richtig mit sub-prozessen arbeitet oder zu faul dafür ist ... bei dir würde ich aber sagen das du es einfach nicht weist ...

und wenn du das ganze als JAR packst und dann wirklich NICHTS passiert ... also die commandos nicht gecallt werden ... würde ich vermuten das du beim zusammenbauen des JAR irgendwas falsch gemacht hast ... denn an sich sollte der code so funktionieren ...

Danke für die Antworten.

Zu den Sub-Classes habe ich nur in der API unter Proccessbuilder etwas gefunden. Ich denke ich müsste mehr darüber lesen, um etwas zu verbessern.

Habe diesen Text im Internet gefunden, der ascheinend besagt das man unter Windows gewisse nur über CMD aufrufen kann ?

On a Microsoft Windows platform, commands such as "dir" are internal to the command processor so the single command-line argument would be the quoted string: "cmd /c dir" (again, output would depend on the contents of the directory).

Hast du mit den sub-prozessen so etwas wie im unteren Code gemeint ?

Java:
ProcessBuilder pb = new ProcessBuilder("myCommand", "myArg1", "myArg2");
File log = new File("log");
pb.inheritIO()
pb.getOutputStream() = log;

@X5-599

Die Variabel "AdName" ist ein Schreibfehler, sollte "Name" heissen.
Die Variabel Name vergleiche ich auf Ungleichheit, weil wenn "name != Name" (oder besser [c]!name.equals(Name)[/c]) ist, sollte der Text von der Taskliste in die Datei Test.txt geschrieben werden und wenn "name.equals(Name)" sollte der entsprechende Task gestopt werden.
Mit [c]name = dat_read.readLine();[/c] sollte jede Zeile durchgelesen werden, nicht ?

Vielen Dank

Gute Nacht
LeChat
 
naja ... interne kommandos des befehlsprozessors kannst du so natürlich nicht direkt callen .. ich weis aber auch gerade garnicht ob "tasklist" ein solcher interner befehl ist ... laut "HELP" ist er es aber ...

und "String != String" macht keinen sinn denn ... denn "String == String" wird ja nur zutreffen wenn es ein und das selbe objekt ist ... was sicher nicht der fall sein dürfte ... desshalb dürfte auch "String != String" niemals "false" werden und du rennst somit IMMER in den if-block .. hier MUSST du wirklich "!String.equals(String)" schreiben damit dieser ausdruck auch "false" wird wenn beide strings "gleich" sind ...
 
Danke für die Antworten.

@X5-599

Die Variabel "AdName" ist ein Schreibfehler, sollte "Name" heissen.
Die Variabel Name vergleiche ich auf Ungleichheit, weil wenn "name != Name" (oder besser [c]!name.equals(Name)[/c]) ist, sollte der Text von der Taskliste in die Datei Test.txt geschrieben werden und wenn "name.equals(Name)" sollte der entsprechende Task gestopt werden.
Mit [c]name = dat_read.readLine();[/c] sollte jede Zeile durchgelesen werden, nicht ?

Vielen Dank

Gute Nacht
LeChat

Das mit dem != gegenüber equals wurde ja bereits erwähnt (Zum String Vergleich immer equals() nehmen). Das "name = dat_read.readLine();" ist schon richtig. Das liest eine neue Zeile ein. Allerdings steht dieser Aufruf außerhalb deiner while-Schleife und wird somit nur einmal aufgerufen. Darum die Endlosschleife.

Vielleicht hast du's aber schon selbst gelöst. Kannst dich ja nochmal melden falls nochwas unklar sein sollte.
 

Zurück
Oben