16
Aufruf von java über batch
Hallo,
ich weiss nicht, ob an dieser Stelle die Frage richtig plaziert ist.
Ein fremdes Java-Programm (normaler Aufruf: java -Xmx500m -Dfile.encoding=8859_15 -classpath ...) soll aus einer Assembly unter Vb.Net gestartet werden. Bislang gab es unter XP keine Probleme. Verschiedene 64er WIN 7 Rechner wollen das mitunter nicht mehr.
Unter XP ging es so:
Dim p As New Process
Dim psi As New ProcessStartInfo("javaw", JCode)
p.StartInfo = psi
p.Start()
in JCode steht der Text "-Xmx500m -classpath ...
Unter WIN 7 funktioniert das nicht mehr. Ich musste eine BatchDatei schreiben und diese wie folgt aufrufen:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Auf manchen Rechnern mit WIN 7 läuft auch das nicht. Startet man die batch durch Doppelklick, ist alles OK. Rufe ich sie aus Vb.Net heraus auf, klappt es nicht. Habe herausgefunden, dass der Aufruf von java fehl schlägt (Befehl falsch geschrieben oder Datei nicht gefunden). Wenn ich in psi die Argumente weglasse und nur das Command-Fenster erscheinen lasse, kann ich hier eintippen: prfModStart.bat und alles verläuft problemlos. Jedoch bekomme ich nun einen Returncode von -1073741510 zurück, der meine Auswerte-Routine durcheinander bringt.
Meine Assembly ist unter 32 Bit kompiliert. Die WIN7-Rechner sind 64 Bit Versionen. Liegt es vielleicht daran? Kann man auf einem Rechnern nebeneinander java 1.8 64 Bit und java 1.7 32 Bit benutzen? Dann würde ich das mal versuchen.
ich weiss nicht, ob an dieser Stelle die Frage richtig plaziert ist.
Ein fremdes Java-Programm (normaler Aufruf: java -Xmx500m -Dfile.encoding=8859_15 -classpath ...) soll aus einer Assembly unter Vb.Net gestartet werden. Bislang gab es unter XP keine Probleme. Verschiedene 64er WIN 7 Rechner wollen das mitunter nicht mehr.
Unter XP ging es so:
Dim p As New Process
Dim psi As New ProcessStartInfo("javaw", JCode)
p.StartInfo = psi
p.Start()
in JCode steht der Text "-Xmx500m -classpath ...
Unter WIN 7 funktioniert das nicht mehr. Ich musste eine BatchDatei schreiben und diese wie folgt aufrufen:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Auf manchen Rechnern mit WIN 7 läuft auch das nicht. Startet man die batch durch Doppelklick, ist alles OK. Rufe ich sie aus Vb.Net heraus auf, klappt es nicht. Habe herausgefunden, dass der Aufruf von java fehl schlägt (Befehl falsch geschrieben oder Datei nicht gefunden). Wenn ich in psi die Argumente weglasse und nur das Command-Fenster erscheinen lasse, kann ich hier eintippen: prfModStart.bat und alles verläuft problemlos. Jedoch bekomme ich nun einen Returncode von -1073741510 zurück, der meine Auswerte-Routine durcheinander bringt.
Meine Assembly ist unter 32 Bit kompiliert. Die WIN7-Rechner sind 64 Bit Versionen. Liegt es vielleicht daran? Kann man auf einem Rechnern nebeneinander java 1.8 64 Bit und java 1.7 32 Bit benutzen? Dann würde ich das mal versuchen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241824
Url: https://administrator.de/contentid/241824
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
Mal versucht, den kompletten Pfad zur Java-EXE zu übergeben?
Man kann beide installieren. Dann sollte man aber beim Aufruf unbedingt den Pfad mit angeben.
Gruß,
Gersen
Habe herausgefunden, dass der Aufruf von java fehl schlägt (Befehl falsch geschrieben oder Datei nicht gefunden).
Mal versucht, den kompletten Pfad zur Java-EXE zu übergeben?
Kann man auf einem Rechnern nebeneinander java 1.8 64 Bit und java 1.7 32 Bit benutzen?
Man kann beide installieren. Dann sollte man aber beim Aufruf unbedingt den Pfad mit angeben.
Gruß,
Gersen
Hallo.
Das ist ein VisualBasic-Script, kein Batch!
Wieso so umständlich?
Das Programmverzeichnis ist höchstwahrscheinlich nicht in deiner
Gruß,
@Snowman25
ich weiss nicht, ob an dieser Stelle die Frage richtig plaziert ist.
Ein fremdes Java-Programm (normaler Aufruf: java -Xmx500m -Dfile.encoding=8859_15 -classpath ...) soll aus einer Assembly unter
Vb.Net gestartet werden. Bislang gab es unter XP keine Probleme. Verschiedene 64er WIN 7 Rechner wollen das mitunter nicht mehr.
Unter XP ging es so:
Dim p As New Process
Dim psi As New ProcessStartInfo("javaw", JCode)
p.StartInfo = psi
p.Start()
in JCode steht der Text "-Xmx500m -classpath ...
Unter WIN 7 funktioniert das nicht mehr. Ich musste eine BatchDatei schreiben und diese wie folgt aufrufen:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Ein fremdes Java-Programm (normaler Aufruf: java -Xmx500m -Dfile.encoding=8859_15 -classpath ...) soll aus einer Assembly unter
Vb.Net gestartet werden. Bislang gab es unter XP keine Probleme. Verschiedene 64er WIN 7 Rechner wollen das mitunter nicht mehr.
Unter XP ging es so:
Dim p As New Process
Dim psi As New ProcessStartInfo("javaw", JCode)
p.StartInfo = psi
p.Start()
in JCode steht der Text "-Xmx500m -classpath ...
Unter WIN 7 funktioniert das nicht mehr. Ich musste eine BatchDatei schreiben und diese wie folgt aufrufen:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Das ist ein VisualBasic-Script, kein Batch!
Wieso so umständlich?
Das Programmverzeichnis ist höchstwahrscheinlich nicht in deiner
%PATH%-Variable vorhanden. Benutze den kompletten Pfad zur Java.exe.Meine Assembly ist unter 32 Bit kompiliert. Die WIN7-Rechner sind 64 Bit Versionen.
Dann brauchst du ein 32-Bit Java.Liegt es vielleicht daran? Kann man auf einem Rechnern nebeneinander java 1.8 64 Bit und java 1.7 32 Bit benutzen?
Ja kann man. Aber ACHTUNG! Die 64-Bit Version von Java hat keinen Auto-Updater.Gruß,
@Snowman25
Vielen Dank für den Hinweis. Das funktioniert! Also liegts wahrscheinlich nicht an der Diskrepanz zwischen 32 und 64 Bit. Nun stehe ich vor dem Problem, dass jeder Nutzer sein Java woanders hin installiert hat. Ich brauche also eine Funktion in Vb.Net, die mir den Pfad zur java.exe als String zurückgibt. Wie bekommt man den heraus? Kann ich ihn aus der Registry auslesen (die Funktion kenne ich)? Aber steht er bei jedem Java-Update im gleichen Zweig und Schlüssel? Oder gibts einen DOS-Befehl (ähnlich java -version), der mir den Pfad anzeigt? Wäre toll, wenn Du mir nochmals helfen könntest. Danke!
@Snowman25:
Habe Deinen Beitrag leider zu spät gesehen. Danke. Der Code ist Vb.Net und hat nichts mit der Batch zu tun. In der Batch steht nur der Aufruf von java mit den entsprechenden Parametern. Ich bin noch beim Basteln ...
Habe Deinen Beitrag leider zu spät gesehen. Danke. Der Code ist Vb.Net und hat nichts mit der Batch zu tun. In der Batch steht nur der Aufruf von java mit den entsprechenden Parametern. Ich bin noch beim Basteln ...
Es gibt alles - es kommt auf die Umgebungen an.
Es gibt unter Windows den Befehl "where" (Pendant zum Linux-"which").
Ein
gibt den ersten Fund anhand der Reihenfolge in der PATH-Variablen zurück. Bei mir: C:\Windows\System32\java.exe
Es gibt manchmal die System-Variable "JAVA_HOME".
Es gibt den Registry-Key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{hier kommt evtl. noch eine Versionsnummer}\JavaHome.
Gruß,
Gersen
Es gibt unter Windows den Befehl "where" (Pendant zum Linux-"which").
Ein
where java.exeEs gibt manchmal die System-Variable "JAVA_HOME".
Es gibt den Registry-Key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{hier kommt evtl. noch eine Versionsnummer}\JavaHome.
Gruß,
Gersen
Hörte sich sehr gut an. Ich war schon happy. Danke! Jedoch zu früh gefreut.
In WIN 7 --> perfekt! Aber unter XP gibt's WHERE nicht (sagt mir das System zumindest). Und einige Anwender fahren immer noch XP. Kann es also nicht nutzen.
Wenn sich in der Registry der Schlüssel ändert, weil beim Java-Update eine neue Versionsnummer eingetragen wird, nützt es mir auch nix. Denn dann kann ich den Schlüssel in meine Assembly nicht fest eincodieren.
Gibts noch ein anderes Tricky?
In WIN 7 --> perfekt! Aber unter XP gibt's WHERE nicht (sagt mir das System zumindest). Und einige Anwender fahren immer noch XP. Kann es also nicht nutzen.
Wenn sich in der Registry der Schlüssel ändert, weil beim Java-Update eine neue Versionsnummer eingetragen wird, nützt es mir auch nix. Denn dann kann ich den Schlüssel in meine Assembly nicht fest eincodieren.
Gibts noch ein anderes Tricky?
Du kannst die aktuelle Versionsnummer für den o.g. Registry-Zweig finden - der steht auch in der Registry.
Und zwar unter HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\CurrentVersion.
Mit dem Wert suchst Du dann HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Ergebnis aus oben}\JavaHome.
Und zwar unter HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\CurrentVersion.
Mit dem Wert suchst Du dann HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Ergebnis aus oben}\JavaHome.
Jaaaa! Prima. Und die java.exe ist dann immer im Unterordner Bin?
Dort legt es die Installations-Routine ab.
Ich gehe mal davon aus, dass Du Dein Programm dahingehend absicherst, dass Du prüfst, ob die Datei dort existiert. Im Negativfall findest Du die Datei(en) immer noch mal unter C:\Windows\System32...
Ich gehe mal davon aus, dass Du Dein Programm dahingehend absicherst, dass Du prüfst, ob die Datei dort existiert. Im Negativfall findest Du die Datei(en) immer noch mal unter C:\Windows\System32...
Perfekt! Vielen Dank nochmal. Tolles Forum!
Zitat von @Gersen:
gibt den ersten Fund anhand der Reihenfolge in der PATH-Variablen zurück. Bei mir: C:\Windows\System32\java.exe
where java.exegibt den ersten Fund anhand der Reihenfolge in der PATH-Variablen zurück. Bei mir: C:\Windows\System32\java.exe
Dann gäbe es aber das Problem nicht, dass java nicht aufgerufen werden kann.
Sobald es in der PATH steht kann man ja direkt
java.exe aufrufen.Es gibt den Registry-Key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{hier kommt evtl. noch eine
Versionsnummer}\JavaHome.
^ thisVersionsnummer}\JavaHome.
Da Snowman25 den Thread nochmal aufgemacht hat, erlaube ich mir, ihn fortzusetzen (kann ein Admin das "gelöst" entfernen ?).
Eine Anmerkung: Wenn ich ein Java Programm aus einer 32 Bit Assembly über eine Batchdatei aufrufe, brauche ich keine Java 32 Bit Version. Über das Cmd wird die richtige Java Version angezogen.
Die Anwender den Pfad zu Java in das PATH eintragen zu lassen, ist keine benutzerfreundliche Idee. Ich mache es jetzt so, dass ich den Pfad aus der Registry auslese. Das Java Programm ist ein Fremdprogramm und es ändert sich sehr oft (neue Variablen). Die Batchdatei muss also beim Starten dieses Progs sowieso jedesmal neu erstellt werden (ich passe deren Aufruf an meine Bedürfnisse an). Und dabei schreibe ich nun gleich den Pfad zu Java vorn dran.
Weshalb ich den Thread fortsetze ist eine weitere Frage zu diesem Thema. Wie ich schon geschrieben habe, funktioniert der Java-Aufruf aus meiner 32 Bit Assembly unter WIN 7 64 nicht mehr. Das hängt sicher damit zusammen, dass der Anwender dann auch unbedingt eine 32 Bit Java Version haben muss. Das kann ich nicht voraussetzen. Deshalb jetzt der Weg über eine Batchdatei. Aber: ich muss den Returncode des Java-Programms auswerten. Den fängt ja nun das Cmd auf. Reicht es diesen Wert durch zum Aufrufer der Batch??? Es gibt dabei nämlich nicht nur 0 und 1, sondern auch andere Werte, die dem Anwender spezielle Hinweise geben. Hier nochmal der Vb.Net Codeschnipsel:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Dim eCode As Integer = p.ExitCode
Select Case eCode
Case 0 ...
Hoffe sehr, dass sich nochmal jemand erbarmt.
Viele Grüße
Norbert
Eine Anmerkung: Wenn ich ein Java Programm aus einer 32 Bit Assembly über eine Batchdatei aufrufe, brauche ich keine Java 32 Bit Version. Über das Cmd wird die richtige Java Version angezogen.
Die Anwender den Pfad zu Java in das PATH eintragen zu lassen, ist keine benutzerfreundliche Idee. Ich mache es jetzt so, dass ich den Pfad aus der Registry auslese. Das Java Programm ist ein Fremdprogramm und es ändert sich sehr oft (neue Variablen). Die Batchdatei muss also beim Starten dieses Progs sowieso jedesmal neu erstellt werden (ich passe deren Aufruf an meine Bedürfnisse an). Und dabei schreibe ich nun gleich den Pfad zu Java vorn dran.
Weshalb ich den Thread fortsetze ist eine weitere Frage zu diesem Thema. Wie ich schon geschrieben habe, funktioniert der Java-Aufruf aus meiner 32 Bit Assembly unter WIN 7 64 nicht mehr. Das hängt sicher damit zusammen, dass der Anwender dann auch unbedingt eine 32 Bit Java Version haben muss. Das kann ich nicht voraussetzen. Deshalb jetzt der Weg über eine Batchdatei. Aber: ich muss den Returncode des Java-Programms auswerten. Den fängt ja nun das Cmd auf. Reicht es diesen Wert durch zum Aufrufer der Batch??? Es gibt dabei nämlich nicht nur 0 und 1, sondern auch andere Werte, die dem Anwender spezielle Hinweise geben. Hier nochmal der Vb.Net Codeschnipsel:
Dim p As New Process
Dim psi As New ProcessStartInfo("cmd")
psi.Arguments = "/c " & PrfModDir & "\prfModStart.bat"
p.StartInfo = psi
p.Start()
Dim eCode As Integer = p.ExitCode
Select Case eCode
Case 0 ...
Hoffe sehr, dass sich nochmal jemand erbarmt.
Viele Grüße
Norbert
Hallo,
vielleicht, indem Du die Batch-Datei etwa so aufbaust:
Ist ungetestet.
Gruß,
Gersen
vielleicht, indem Du die Batch-Datei etwa so aufbaust:
@echo off
rem ...
set errorlevel=
{Deine Java-Anweisung}
exit /b %errorlevel%Ist ungetestet.
Gruß,
Gersen
Danke, werde es versuchen. Woher ihr nur all sowas herwisst ...
Kann ich es irgendwie testen? Z.B. den Returncode simulieren?
Kann ich es irgendwie testen? Z.B. den Returncode simulieren?
Speichere folgenden Code (erfragt einen Zahlenwert und verlässt die Anwendung mit dem Zahlenwert als Returncode) in einer Datei namens "ExitCode.java" (auf dem Rechner muss zumindest die JRE installiert sein):
Das kompilierst Du über die Kommandozeile im Verzeichnis der Datei mittels
Du erhältst eine Datei "ExitCode.class".
Die kannst Du in Deiner Batch testweise einbauen.
(etwa -wenn die Datei unter C:\temp liegt-)
Gruß,
Gersen
import java.util.Scanner;
class ExitCode
{
public static void main(String args)
{
Scanner scan = new Scanner(System.in);
System.out.print("ExitCode eingeben: ");
int i = scan.nextInt();
System.exit(i);
}
} javac ExitCode.javaDie kannst Du in Deiner Batch testweise einbauen.
java -cp {Pfad zum Verzeichnis der ExitCode.class} ExitCodejava -cp C:\temp ExitCode)Gruß,
Gersen
Prima. Danke! Aber nun schliesse ich den Thread endgültig.
