Develop Reference

how to start a java application system-independent at Windows startup

I want to automatically run a Java application under Windows at startup time, but not depending on a specical Windows or a special JRE-version.
Generally, a good way to run programs at Windows login time would be to add a registry entry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
But it seems as if the system PATH is not evaluated when Windows tries to run the programs listed in the registry's RUN section.
So these both entries do work:
"C:\Program Files\Java\jdk1.8.0_111\bin\javaw" -jar c:\path\to\java.jar
"C:\ProgramData\Oracle\java\javapath\javaw" -jar c:\path\to\java.jar
But this one doesn't come up:
javaw -jar c:\path\to\java.jar
Now, the latter works when manually entered in a console window because there the required PATH exists and is evaluated:
PATH=....;C:\ProgramData\Oracle\Java\javapath;....
Now, I want to have the registry entry added from an automated installer programm and I would like to have it formed "windows-system-independent" (from Vista up to Win 10, and furthermore not depending from the version of the installed JRE). So I do not know a general path to the JRE and therefore I cannot add a specific RUN-command to the registry.
Does anyone know how to add JRE-calls system-independent correctly to the registry's RUN-section?
I've already tried with a command-file, e.g. "startup.cmd" with content java -jar file.jar there, have added a call of this file to the registry, and yes that worked, java was found, the application was started, but when using this method I have an annoying black command terminal window staying open all the time while the java app is running.
Thanx,
Tombo

Change your startup.cmd, from
java -jar file.jar
to
start java -jar file.jar
This will launch the java.exe in a new process an let your batch executor terminate.

Output of application based on Eclipse on Windows command line only visible when piped (not directly in cmd)

We have a Java application based on Eclipse (main class implements IApplication) that is started from the Windows command line. Its output on System.out is not visible/printed into the command window from which it is started. Nevertheless, when piping the output to more, the output is fine. How come?
For example, consider helloworld.exe. When running C:\>helloworld.exe in a command window, the application simply returns. But when running C:\>helloworld.exe | more, the screen shows
C:>helloworld.exe | more
hello world
C:>
On linux, the output is fine. How to see the output on Windows, too?
Some reqested information:
The application is quite large. And I probably cannot cut it down. The output are simple calls to System.out.prinln("xxx");
Java version 1.8.0_60, Eclipse 3.6.2
Using >std.txt 2>err.txt shows that output is indeed on stdout.
Line endings are CR/LF
the .ini file is as follows
--launcher.suppressErrors
-vmargs
-Xms256m
-Xmx4096m
-Djava.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
-Djava.library.path=plugins
Maybe this issue is related?

If your application is somehow started via eclipse.exe (has no console attached to it) change the call to use the eclipsec.exe (has a console attached to it, note the c in the application name).

You can launch Eclipse RCP based applications using equinox launcher as shown below:
java -jar plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
Of course you have to find the correct version of equinox launcher you are using in your RCP Application.
This way you would see the console logs.
You can read more about it here: http://wiki.eclipse.org/index.php/Starting_Eclipse_Commandline_With_Equinox_Launcher
EDIT: The reason you don't get console logs when eclipse.exe based launcher is used is because eclipse.exe on Windows spawns a separate process which brings up another command prompt window.

You'd better use a framework to handle your logs like logback
This is much more portable and maintainable.

In your example it seems that you have created an exe from your java code. My guess is that the packager you used to create the exe made some changes to the output target because it is a wrapper for your java program.
Try creating a jar instead and try executing it by java -jar helloworld.jar.

Is the string going to stderr in place of stdout? (or the other way around depending on your expected behaviour).
https://support.microsoft.com/en-us/kb/110930

Output to Eclipse console from jar running externally

I have been developing a Java app with Eclipse on Mac OS X. Up to this point, I have been running the app through Eclipse and printing to the Eclipse console with System.out.println().
After I bundle my jar into a Mac app and run it by itself, console output no longer works for obvious reasons. Is there any way to print to the Eclipse console from my externally running jar? Thanks for any help.

Run it from the command line.
run it from another Java program as a separate JVM process, and capture the InputStream, OutputStream, and ErrorStreams for input and output.

Java - System.out.println() viewable from application?

I have a Java application that runs great :) While uploading files, it uses the standard output to show progress : "System.out.println(...);".
When I run it in Eclipse, well it works perfectly, but when I run the JAR file, I don't see any console/terminal showing up and printing what I print through "System.out.println(...),".
How can I open a new terminal when my application is launched (it is a Swing application)?
Basically I want to be able to run the Swing application and show information on the side in a terminal / console. Why? Don't worry about why I want to do this ;)
Thanks a lot!
Regards.

Open terminal and run application as java -cp yourjar.jar YouMain or java -jar yourjar.jar if you jar is runnable.
I believe that you do not see output because you are running your application using javaw - the special windows-only variation of JVM that does not have STDOUT at all. If you want to click your application and see output map *.jar file to be opened using java instead of javaw. Alternatively write bat file that runs your application. In this case you will see console.

Use java instead of javaw to launch your application. Double-clicking on a jar executes it with javaw. Instead, open a command line window and type
java -jar thePathOfTheJarFile.jar
If you want to have something double-clickable, then write a shell script containing this command, and double-click the shell script instead of the jar.

Running a JAVA program as a scheduled task

I am trying to run a simple JAVA program once per day on a Windows 7 machine.
My code runs fine inside NetBeans. If I do a clean and build it suggests this:
C:\Program Files\Java\jdk1.7.0/bin/java -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
This does not work from the DOS prompt of course because of the space between program and files so I do this:
C:\Program Files\Java\jdk1.7.0/bin/java -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar" -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
This works from the DOS prompt.
I now create a task in Windows Scheduler to run:
C:\Program Files\Java\jdk1.7.0/bin/java
with arguments:
-jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
When I then run it, all I see is a DOS box flashing up for a second. I expect the code to take about 30 secs to run. The code should persist data to a database and no updates happen.
The code also uses java.util.logging so I should see log entries and I don't.
I strongly suspect that I am not running the JAVA command properly or that there's a bad classpath issue that it present when running via Scheduler that isn't there when running from the DOS prompt.
Help would be appreciated. If you've seen this before and can sort it that would be great. If you can tell me how to get a meaningful error trace from Scheduler than that would also be really helpful.
Thanks!

I Think that you could create a simple batch script that will launch your program in this way :
#echo off
REM Eventually change directory to the program directory
cd C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\
REM run the program
"C:\Program Files\Java\jdk1.7.0\bin\java.exe" -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
Copy it into the notepad and save as java_script.cmd and then schedule this script instead of the program directly.

I solved it after changing all fonts' references to "SansSerif"
I was using Jasper Reports inside Java to create a PDF file. It was working fine when I double click the batch file or Scheduler with Windows Server 2003 but not working with the Scheduler of 2008.
I tried many different things nothing worked so I though Could it be that Windows Server 2008 is blocking the access?.
Now is working perfect. So, if you are having problems check the references to anything you are using.

The scheduler will run under a different user unless you specify what user to run as. If it isn't running as your user then it won't be able to write to your directories.

The real problem to the original question is a java installation issue on Microsoft systems. Java jre installs into Program Files\java. The executable (java.exe) is only installed in that java\bin directory. Running from the command line, the os looks in the proper location for the java.exe. Running from other MS tools (such as VBA Excel or in this case TaskScheduler), it does not!
You can see that TaskScheduler is looking in the wrong place by viewing the tasks history in the TaskScheduler tool. Double click on some of the history events and one will list the action and return code. The action will show that the TaskScheduler is trying to run
"C:\Windows\system32\java.EXE"
So, copy java.exe from the java\bin directory into the place where the scheduler is looking, and now it will work.
Or update your task and provide the full path to java.exe.
You can also update the environment system path to look for java in the java\bin directory, but that has to apply to all users and sometimes this is faulty as well.