At work we use a Personnel Administration System that uses Java Web Start.
We use Java 8.40, Internet Explorer 11 and Windows 7. Mostly 64-bit Windows but some 32-bit.
The computers with Windows 7 32-bit have trouble starting the application every morning. They have to try between 2 and 10 times before the application starts. Once they get in they can close the application and it will start without any problems.
Chrome usually works a little better but there is a policy at work that IE should be used.
I have followed Oracles Java troubleshooting guides and other online resources without any luck.
I have i.e.:
checked Anti-Virus and Firewall configuration.
made sure that Java is activated in the browser
checked different configurations in Java Control Panel
removed temporary files in IE and Java Control Panel
I've made sure that we use 32-bit JRE
tested to run IE without add-ons
and a lot of other stuff
This link is one of the more useful ones I've found on fine tuning Java.
When I choose to Show Console in Java Control Panel and enabled tracing and logging, this is what happens when the application doesn't start:
the console appears and starts to log events
the console suddenly closes
Java loading image never appears
Java and Windows log files don't show any errors.
Although Java seems to crash there are no error files (hs_err_pid*) to be found anywhere. I've searched the whole disk and even tried to set the JVM parameters to set a path for the error file (thanks Saeid)
I've also run Process Monitor during the start of the application with filters on jp2launcher process and the path of the Java cache folder but that didn't give me any useful information.
I want to emphasize that the application eventually starts. The 32-bit users just have to try several times. The 64-bit users don't seem to have any problems.
This is what Process monitor shows at the moment when the Java Console Window abruptly closes:
This is what the trace file look at the same moment:
and the log file:
Related
When I was trying to profile my local Java application by running Java Mission Control (jmc), I wasn't able to connect to the application. It displayed 'Flightrecorder is not supported for non hotspot JVMs' in the description of all JVM processes displayed in the left pane.
My environment: Windows 7, Java 8u25
Because I wasn't able to find solution for this problem anywhere on the net, I want to share the solution that I luckily discovered for other people (and my future self) who might run into the same problem in the future.
Here I am posting the solution and observations that lead to the solution.
When I (by coincidence) tried to run jvisualvm it displayed error "Local Java applications cannot be monitored". On http://visualvm.java.net/troubleshooting.html in section titled "Local Applications Cannot Be Monitored (Error Dialog On Startup)" I found that on Windows system there could be problem with one exact folder name if the account name contains capitalized letters.
Solution was to alter the name of folder %TMP%\hsperfdata_username in a way that the capitalization corresponds with the my username (there was 'e' instead of 'E' in the folder name).
After this change, both jmc and jvisualvm started to work again.
Note: you need to kill all currently running Java applications before changing the name of the folder.
Last night a new Java 7 update has been released: 7u65. I have a web application where a service applet is loaded, and after the update, my tests on different PCs did not show issues nor wrong behaviors.
Later, I started to receive issue reports related to my product's Java service applet. All the reports came from users who updated Java JRE to 7u65 (from 7u60):
The applet was not loading at all. I display a "Loading" screen when the application starts, and this was not being displayed. Also, all the services provided by my Java applet were unavailable.
After changing the Java Control Panel's advanced configuration to always show the console (in one of the PCs where this issue happened), I discovered that the applet was not even launching the Java console.
Using the same station where the error happens, trying to access java.com to check the current java version, the Java applet is loaded and the console is displayed without errors.
All tests were performed after clearing Browser and Java Cache, and even after removing the installed certificates (mine is a valid signed applet).
I checked the Java 7u65 release notes and none of the mentioned changes seem to affect my applet. Also, there were no issues while using Java 7u60.
I don't have any clues about what is going on, perhaps because the java update was released hours ago. As the Java console can not be displayed even if I configure Java Control Panel to do so, I can not tell if there is any exception. I can not reproduce the issue in my PCs (Windows 8, nor Windows 7, both at 64 bits), but the issue has been reported on Windows 7 PCs.
One of my friends told me that this seems to be happening on machines where Java 7u60 was in use, and then it was updated to Java 7u65 with no deinstallations. Also, this tends to happen in older OS (ie: WinXP) which is more natural.
I write this question because it seems very odd that some PCs have this issue, and some others not. I'd like to know if any one else is having this issue, knows what could be the reason, or has discovered/applied any solution to it. Also, I'd like to share the solution if I ever happen to find it.
Thanks.
Edit:
External references, related to the same Java version (JRE).
Internet Explorer crashing after updated Java to 7u65: An issue with the same JRE version, this time with Internet Explorer and Firefox.
RS Loading Issue (Java) ~ READ: An issue related to the same JRE version update, this time, in a Java Game.
The future of Java on Windows XP:
This end of support announcement has been misread as "Java no longer works on Windows XP" or "Oracle will stop Java updates from being applied on Windows XP". These statements are not correct.
I just ran into this exact problem with one of my applets.
It looks like some changes were made to the handling of the 'java-vm-args' and 'java_arguments' params in 7u65.
'java_arguments' seems to no longer work, when it is specified, my applet will silently fail without even launching the JVM.
I have had the same problem.
I delete C:\Users\${USER}\AppData\LocalLow\Sun
When i reloaded the web page containg the appelets. The JRE recreated this folder again.
And evrything was OK.
There is no big difference between the folders contents .. but it worked.
It seems to be a bug in the jRE
It seems that oracle has changed something with processing default plugin java arguments,
that caused problem in new java.
When upgrading from older version of java it is possible that value for
deployment.javaws.jre.0.args (or deployment.javaws.jre.1.args)
is not defined in
C:\Users\${USER}\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
If you add
deployment.javaws.jre.0.args=
to deployment.properties, applet will work.
It can be done through Java Control panel also:
Java -> View -> double click on Runtime Parameters cell for java 7u65 to enter edit mode -> OK -> Apply
java-jvm-args solution didn't work for me, applet was launched but arguments were ignored.
Oracle has released an update that resolves this specific issue via version 7u67
http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html
As Miloš Ratković wrote, if customer hasn't string in deployment.properties
deployment.javaws.jre.X.args=
where x is number of java installation for version 7_65 (number of java installation for particular version is X in string deployment.javaws.jre.X.product=1.7.0_65), Java applet failed to start.
For my case I have a solution - don't pass any arguments for my applet.
In my javascript code for starting applet I'm just comment
<param name="java_arguments" value="some arguments">
string
Also, if you delete the directory C:\Users\${USER}\AppData\LocalLow\Sun, during next startup of java applet java write new deployment.properties with correct java args string
Uninstall java 7 update 65 and reinstall java 7 update 55 Download the windows x86 offline version
Go to Java control panel and uncheck: automatic update
When the next window comes up, click on "do not check"
then click on "apply" and "ok"
close all browsers and reopen them to continue your work
This has worked for me every time so far and I have been doing this for the last two weeks now with "0" issues.
Sorry, this is not the answer. I was trying to verify the feedback about JRE 7u65 not able to accept "java_arguments"; however, I setup a Windows x32 and installed (new) 7u65 without upgrade from any older version. With the "java_arguments", the machine is able to load the applet in IE8 and FF30, when few specific PCs do fail the same applet with upgraded u65.
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.
Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.
The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...
had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.
I am using Tomcat 5.5.23, JDK 1.5 on HP Unix. We have an application which when invoked form tomcat starts an applet. It was working fine till JDK 1.4. But now we have moved to JDK 1.5 and the applet does not start. The exception thrown is -
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
I then added JAVA_OPTS="-Djava.awt.headless=true" to catalina.sh file. But still I get the same Headless exception, but this time without the X11 Display message.
Any help would be appreciated.
Odd.. you're trying to run an applet (I assume you are talking about a subclass of java.awt.Applet) inside tomcat? Generally this won't work because there's no display on which to display the applet.
Assuming you don't want the applet to display anywhere and you just want to execute some portion of it programmatically, you may be able to get by using a virtual X server such as Xvfb or Xvnc. Once you have Xvfb or Xvnc running on your host running tomcat, you might try to set the DISPLAY inside the tomcat startup scripts to use the display of the virtual X server.
-Djava.awt.headless=false
add above in your Tomcat startup script. it will work 100%
You are maybe using something in your Java code that can not work on a headless system, such as graphics components (Swing objects, images, etc.). Some of these components, instead of being directly handled by Java, are handled by underlying platform (Windows kernel itself or X-Window server on Unix). This way the overall performance of application is boosted.
So the question now is, ok if it was working on Java 1.4, why doesn't it work on 1.5? My bet, given the peformance boost since Java 1.2 that Swing has received over time, is that Sun has moved the management of some graphic objets to OS level to increase performance. So if you can not stick to 1.4, then you should revise your code.
This good article will help you understand how to modify your application to make it headless-friendly.
Applets are going to have a hard-time running server-side. They are designed to run inside of a container, such as a web browser. The exception is getting thrown most likely because the applet is trying to draw it's GUI -- and the server is providing no support for this. I'm surprised that it worked in JDK 1.4 -- I don't know what changed between the two revisions which would have affected this.
You may also have to install the x11 libraries, or at least explicitly export the path to them.
/usr/X11R6/lib
Open $CATALINA_HOME/bin/startup.sh file with your preferred text browser
Paste this line export CATALINA_OPTS="$CATALINA_OPTS -Djava.awt.headless=false" at the beginning of the file
Save and close the file
Restart Tomcat
In spring boot with database access, when you specify asterisks: **** as username and password, it will try to prompt the user for a username and password (you read that right), and it will throw this HeadlessException if it's not a gui application.