As stated in the title, my software won't launch unless the "Show console" option is selected in Java settings. I'm not sure what kind of code you'd like me to post, so please ask.
When I try to run it, the Java dialog pops up and the progress bar that loads the software completes before it closes. When the console is up, the software finally loads and displays afterwards. Without the console, nothing happens.
I've tried to run the web start on different computers, and they all had the same problem. The console doesn't print out any error messages, so I don't have anything to use for debugging the problem.
Some information about the software:
It's a JavaFX project, compiled using Oracle jdk 1.7.0_65 on OS X with Netbeans. It requires full security permission, and all jars (I use a bunch of libraries) are being signed using a key store from a trusted vendor.
EDIT
I tried to launch my program through console using the following command: javaws -viewer http://www.website.com/software.jnlp, and - without launching my software - it returned the following result to the terminal:
java.lang.NullPointerException
at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1003)
at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:998)
at sun.awt.SunToolkit.getSystemEventQueueImpl(SunToolkit.java:993)
at java.awt.Toolkit.getEventQueue(Toolkit.java:1749)
at java.awt.EventQueue.invokeLater(EventQueue.java:1245)
at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1290)
at com.oracle.deploy.update.UpdateCheck.updateStateChange(Unknown Source)
Could this be of any help?
For others who might have this problem, this is what caused it for me:
I had a thread running in the background that would show the stage once it was done loading all the assets. This stopped the whole thing from executing, so I had to change the loading logic inside of my code instead to allow for the primary stage to use the show-method in the UI-thread.
I am a beginner using eclipse for java programming. Recently I downloaded certain source code online and ran it in eclipse successfully. I want to learn how it runs. However, I failed to find a way to monitor the progress during the program running. For example, if I run the application and click certain button in the application GUI, how do I know which class/method is called? In other words, how can I use eclipse to monitor the process of program running?
The general answer is to use the debugger. For example, set a breakpoint in some method and then use "Debug As" instead of "Run As" to run the application within Eclipse.
Here are a couple of tutorials / articles on using the Eclipse Debugger.
http://www.vogella.com/articles/EclipseDebugging/
http://agile.csc.ncsu.edu/SEMaterials/tutorials/eclipse-debugger/
http://www.ibm.com/developerworks/library/os-ecbug/
Put a breakpoint(double click the left side of the line) on your method to be debugged and debug your program.
Simply put breakpoints in the code lines you need to look and run the application in the Debug mode then it'll wait at the relevant code lines you need to check.
I've just started working with javafx, it seems cool and NetBeans seems much more fun than Eclipse but I find it impossible to debug my application. I've added breakpoints, and I pressed the debug button, I see the debugger is registered to some port but it doesn't cause the application to start.
When I run the application and attach a debugger nothing seems to happen. This is extremely annoying since I am using an external library I've added to my project, and I can't edit its content (since I am getting 'java file cannot be locked as it is read only').
I am very new to java and especially javafx, thank you for your help I sure need it:)
First off, I'd start with downloading the latest version of NetBeans (6.7.1 as of today). Second, NetBeans will let you put breakpoints in places that don't make sense for the language. You're best off putting breakpoints in a function like the run() function and stepping from there.
One more thing: make sure you have your JavaFX project set as the main project if you use that Debug button since I believe that it acts on your main project only.
I've never done a Java Web start application before. I wrote my app's JNLP files and published them along with all the JARs to my Web server. However, after getting the initial splash screen where JWS loads the libraries, nothing happens. Do you have any suggestions on how to debug this, perhaps get some console output? I've tried cleaning the cache through "javaws -uninstall" but it doesn't help.
Any suggestion is appreciated.
In the Java Console you should enable full tracing and logging. This will tell you a lot about what happens under the covers when Web Start doesn't work.
See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
Hopefully this can get you started.
In the Java Control Panel, select Advanced > Java console > Show console. You will probably see some exception output. If the process is still running, you should be able to find it with jps from the command line.
Did you check the task manager to see if it had actually launched?
In my experience with a similar problem, the program itself was actually running, but it wasn't able to display anything.
Currently, the only information I have is a one-line error message in the browser's status-bar.
Do you know how I could get a stack-trace for example ?
Aside from the obvious use of the Java console and the applet viewer, starting from Java 6 update 7, you can use the VisualVM that comes with the JDK (JDK_HOME/bin/visualvm). It allows you to view the stack traces of each thread and even view all object instances.
AppletViewer is very handy, you can do a "Run as / Java Applet" from Eclipse to run, or "Debug As / Java Applet" to debug your applet classes.
However, sometimes to debug some security related stuff the browser plugin environment is just too different from appletviewer. Here's what you can do to effectively debug applets in the browser:
1) Obtain debugging info for the binaries
Backup the .jar files from JRE_HOME/lib
(Download and) Install a JDK for the same version as your JRE.
Copy the .jar files from JDK_HOME/jre/lib to JRE_HOME/lib
The files inside the JDK were compiled with the debugging information included (source-code line number information, variable names, etc) and the JRE files don't have this information.
Without this you won't be able to meaningfully step into core class code in your debugger.
2) Enable debugging for the Java Plug-in
Go to the Java Control Panel /
Java /
Java Runtime Settings /
View /
User /
Runtime Parameters
And add the options to enable debugging. Something like this:
-Djava.compiler=NONE -Xnoagent -Xdebug -Xrunjdwp:transport=dt_socket,address=2502,server=y,suspend=n
The interesting options are
the port (using 2502 here, you can use pretty much any free port, just write it down for later) and the suspend - if you need to debug the applet startup, classloading, etc, set this to "y". That way when you access an applet page, the browser will appear to freeze as the JVM immediately gets suspended waiting for a debugger to connect.
3) Use your favorite IDE to Remotely debug the Java Plug-in
In Eclipse, for instance, choose Run / Debug Configurations ... / Remote Java Application
Click on the "New" button.
Make sure connection type is "Socket Attach", choose localhost as the host if your browser is local, and the port you chose earlier (2502 in the example).
You might have to inlude the src.zip in your JDK on the sources tab to have the Java core class sources available.
Save the configuration, and once your browser is running the plug-in (with the JVM suspended or not) run the remote debugger to connect to the plug-in JVM, with a project containing your applet sources open.
This article is a bit old but is still relevant (including a section entitled "How to Debug Applets in Java Plug-in").
Edit: perhaps a better way to get stacktraces is to use the Java plugin console. If you hit "t" in that window, you'll see the following:
Prints out all the existing thread
groups. The first group shown is Group
main. ac stands for active count; it
is the total number of active threads
in a thread group and its child thread
groups. agc stands for active group
count; it is the number of active
child thread groups of a thread group.
pri stands for priority; it is the
priority of a thread group. Following
Group main, other thread groups will
be shown as Group , where name
is the URL associated with an applet.
Individual listings of threads will
show the thread name, the thread
priority, alive if the thread is alive
or destroyed if the thread is in the
process of being destroyed, and daemon
if the thread is a daemon thread.
The other command that I've used most often from that console is the trace level from 0-5:
This sets the trace-level options as described in the next section, Tracing and Logging.
From that page, you'll see that the levels look like this:
0 — off
1 — basic
2 — network, cache, and basic
3 — security, network and basic
4 — extension, security, network and basic
5 — LiveConnect, extension, security, network, temp, and basic
These tools can all be fairly useful as you're trying to unravel what in the world has gotten into the head of your applets. I know that they've worked for me.
The applet viewer supports debug options.
Stack traces from uncaught exceptions will appear to the console. This can be enabled from the Java Control Panel (Advanced > Java console > Show console) or some browsers have various options or plugins for enabling it.
You can attach a debugger to the running PlugIn process.
Perhaps the best way is not to debug at all. Write tests. Write code that doesn't couple to unnecessary assumptions - for instance that you are running as an applet. Unfortunately most GUI/applet example code is written very badly.
I faced issue doing remote applet debugging, every time while trying to connect from eclipse, its throws Connection refused error, my jre version was 64 bit and eclipse 32-bit, when I did replace with 32-bit jre, it worked for me. Also if we have install both 32-bit & 64-bit jre versions, IE by default uses 64-bit jre for applets, chrome and FF may use 32-bit jre versions.
Uncaught exceptions are sent to the console. You can also use System.out to write your own messages to the console. To view the results you'll need to open the console by right clicking the Java icon in the systray and opening the console (note this is different for Microsoft's VM).
To debug applets properly, you can setup Eclipse to debug applets. Right click the applet source file and click Debug as Applet. (If you have parameters for the applet you'll need to set this up.) Then you can step through the applet code as you would debug any other Java code.
For me the most important action to get applet debugging in eclipse, is to set in java control panel(tab java) the right binaries to use, that have debug symbols.
Only JRE included in jdk have this symbols.
So to debug applet in java control panel, tab java, press view button, after find the correct jre under jdk folder, for me for example "C:\Programmi\Java\jdk1.7.0_03\jre", and put check enabled only for this entry.
This is for me the clean way to do what Sami Koivu say.