build 1.6.0_21-b07 Applet issues - Java Applet Development

#1 build 1.6.0_21-b07 breaks in seamonkey forcing you to use something else, and second it pops a BS
warning about signed and unsigned Objects being in existence when 100% of everything is in one or more properly signed jars. Don't know when this started but I am going back to the version that works.. Hmm 1.6.0_17 I think.


The Java Runtime Environment cannot be loaded from <\bin\server\jvm.dll>

I have been trying to use the java plug-in on the new JDK 1.5 in conjunction with older installations (1.4.2 and so on).
The very first time that I installed JDK 1.5 the plug-in worked fine and there were no problems.
If I tried to go into control panel and change which plugin is available or not all hell breaks loose and I suspect the only way to fix this is to unistall everything and reinstall everything.
I tried the latest snapshot build of JDK 1.5 (build 57). I had to unistall JDK beta2 and then install the beta. That didn't work either
This has been reported and dismissed by sun.
However I can assure you that this is a genuine bug.
Please somebody back me up. 
I'm having exactly the same problem. Did you even find a solution? I'm running Windows 2000 with JRE 1.5 beta 2 on an account that does not have admin priveledges if that matters. 
I am having the exact same problem.
Still no solution.... 
I have managed to fix my machine now.
Firstly I found I had an old JRE installed inside Oracle so I removed that and checked the JAVA_HOME environment variable pointed to the new 1.5 installation. Not sure if this fixed it though - just house keeping I think.
What fixed it for me, I am 99% sure, was going to c:\Documents And Settings\MyUserName\Sun and then deleting the entire Java directory.
Good luck,
Some old JRE/JVMs leave a jvm.dll in the Windows PATH. Look for jvm.dll files outside regular JRE/JVM installation directories and rename or delete them.
deleting the C:\Documents and Settings\[USERNAME]\Application Data\Sun did it for me... 
I renamed the Sun folder, just in case, and it worked for me also. On the first loading of an applet a new Sun directory was created. Any ideas on why this works? 
I removed my C:\Documents and Settings\<user name>\Application Data\Sun\Java directory and it worked, also.
Problem is that most novice users are not going to bother to read the stinking message much less do a search on it to find if anyone else had resolved the issue. They'll just say, "Java doesn't work", click the "Send Report" that Microsoft displays, watch their browser terminate and have a bad taste in their mouth. Is there any way to make someone who cares aware of this issue. It's clear that the install merely needs to remove the directory (screw the cache - make it work!) to avoid this. 
I share your concern, but I also think this happens to people who've been using Java for a while (some old JDK uninstaller left this file by error), so I don't think many beginners will face the problem.
If not, they can always reinstall Windows ;-)
I have managed to fix my machine now.
Firstly I found I had an old JRE installed inside
Oracle so I removed that and checked the JAVA_HOME
environment variable pointed to the new 1.5
installation. Not sure if this fixed it though - just
house keeping I think.
What fixed it for me, I am 99% sure, was going to
c:\Documents And Settings\MyUserName\Sun and then
deleting the entire Java directory.I would like to confirm what has already been described above. I was running J2SE 1.4.2 and I installed J2SE 5.0. I noticed that the Java plugin stopped working. So I deleted the Java directory in c:\Documents and Settings\MyUserName\Sun and it fixed the problem.
The problem... I think... may have to do something with the fact that there was already a Plugin in place when another one was installed over it. The Java directory in the directory that was deleted had a file that I looked at before deleting it. This hints towards the problem
#Wed Oct 20 23:24:57 EDT 2004
deployment.javaws.splash.cache=C\:\\Documents and Settings\\oiinamul\\.javaws\\cache\\splashes\\splash.xml
deployment.javaws.splash.index=C\:\\Documents and Settings\\oiinamul\\Application Data\\Sun\\Java\\Deployment\\cache\\javaws\\splash\\splash.xml
deployment.javaws.cache.dir=C\:\\Documents and Settings\\oiinamul\\.javaws\\cache
#Java Web Start jre's
#Wed Oct 20 23:24:57 EDT 2004
deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre1.5.0\\bin\\javaw.exe
#Java Plugin jre's
#Wed Oct 20 23:24:57 EDT 2004
deployment.javapi.jre.1.5.0.path=C\:\\Program Files\\Java\\jre1.5.0
Good luck,
I will back you up. I am having the same or similar problem with 1.5.0. Thank you for the bugid link.
I get the alert error dialog "The Java Runtime Environment cannot be loaded from <\bin\server\jvm.dll> ", and IE crashes after I click OK. I have no c:\Documents And Settings\MyUserName\Sun directory to delete. JAVA_HOME is not set in my M$ environment ( I set it in my cygwin .bash_profile). When I go into the MSWindows registry, there are Plug-In and JRE entries for 1.4 and 1.4.0 with JavaHome pointing to C:\Program Files\Java\jre1.5.0 (which should be valid?!). Now what do I try? Who do I bug? Help....
The process I go through to reproduce the crash is:
* uninstall 1.4.2_02 etc.
* leave Oracle JInitiator 1.3.x installed.
* install jdk 1.5.0
Hit a webpage with this entry:
classid = "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
codebase = "j2re-1_4_2_02-windows-i586-p.exe#Version=1,4,0,0"
<== end of useful data, beginning of whine** ==>
I have had endless troubles involving mixed plug-ins and web-start. Why can't sun provide a single plug-in control panel that support 1.3, 1.4, and 1.5 at the same time and have them play well together??? 
I have commented on the bug report too and I encourage everyone with this problem to do so. Perhaps there are mechanisms in place whereby someone will take notice. Also, if you know of any other way of getting Sun's attention try that
I also fixed this problem by deleting the Sun folder but it only fixed things for IE not my main browser Mozilla Firefox. The problem appears to be a result of the new installer not updating the configurations correctly (and/or old uninstallers not cleaning up properly).
Sun need to move on this quickly before dismiss Java as too problematic! I think the problem is in the installers/uninstallers rather than the JRE itself.
sheepish The problem did go away after I deleted "C:\Documents and Settings\MyUserName\Application Data\Sun".
It still bugged me that I can't seem to run both a 1.4 and 1.5 jvm at the same time. The 1.5 release seems to reengineer the plug-in controls again.
Also, what will happen if I upgrade my user base from 1.4 to 1.5? It is still a bug that sun should address.
I did get it working in Firefox in the end by uninstalling Firefox 1.0PR and installing the new Firefox 1.0 although this may have been due to the fact that when I uninstalled the old version of Firefox I deleted the Firefox installation directory (but not my profile directory). This directory may have contained some wrong configuration information about Java although I did previously run a search on files within this directory and couldn't find anything related to Java.
I noticed that before doing this upgrade to Firefox my file in the Sun settings folder did refer to Firefox via "deployment.browser.path=C\:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE" so maybe the fault in Firefox's case lies with Mozilla? I don't know.
Anyway, I am happy it works but either Mozilla or Sun (or both) need to ensure that they can work together on this (and Sun definately need to clean up the upgrade process - Java has been around a lot longer that Mozilla Firefox).
Short answer to your problems: Uninstall and delete programs, directories, registry entries (if you know what you are doing!) relating to Firefox and Sun and reinstall both again (browser first).
Hopefully someone from Sun reads this and fixes things or points people to the right solution. 
I am having this same exact problem. But since I am using applets I need to change the runtime parameter in Java Applet Runtime Settings to allow for a larger heap size (�Xmx1024).
So when I delete the sun/java folder that also deletes my runtime parameter!!!
So I am stuck in the spot of having a working applet with no runtime parameter, but if I change the parameter I get the wonderful java runtime enviroment cannont be loaded error!!

java.lang.InternalError: unimplemented at

First off, I have the java 1.4 plug-in and the latest sdk and jre..At first my applets were not even running in my browser.(IE and NS)..then I used the html-converter I finally got my applets to run..Now I have another problem:my applets run but the java console pops up with the error message "java.lang.InternalError: unimplemented at sun"..Also my applet gets distorted..For example,If I put a window on top of my applet and then bring my applet back to the actually see the contents of the other it gets painted on to my applet..Does anyone know how to solve this problem
I have had the same problem and found that the bug in the JDK uninstaller caused this. This bug never seems to get fixed. Basically on windows if you install 2 JREs/JDKs at the same time and then uninstall one the Current version value gets removed from the registry and the plugin then throws up this error. Have you uninstalled any JRE/JDK? If so if you are on windows run regedit and add CurrentVersion values (which contain the subkey of the version you want to use) into the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Works for me anyway!
Alternatively uninstall and install the JDK/JRE you are using.

OSX: RCP via JNLP causes org.eclipse.swt.SWTException: Invalid thread access

Hi, when I try to start our RCP-application on MAC with Webstart I get the above exception.According to a lot of sites in the internet I have to set -XstartOnFirstThread but this property is not allowed in the java-vm-args according the jnlp-syntax. I've also tries to run javaws -XstartOnFirstThread app.jnlp but get the same exception. :-( What can I do to get the app running on osx too? I'm using Java 1.7u67 from
No idea about startOnFirstThread or Macs, but historically you've had to use -J to pass command line arguments to Java tools (not counting the Java launcher itself), javaws -J-XstartOnFirstThread app.jnlp Could be worth going back to 7u60, there were problems with with 7u65 and passing arguments Web Start (there's a recent thread about it) and I'm not sure which problems the emergency patch 7u67 fixed. So try javaws -J-XstartOnFirstThread app.jnlp using 7u60 and if that doesn't work, then -XstartOnFirstThread is probably not the answer.
I could solve my problem - at least partially.  My jnlp contains resources with os independent jars and resources for platform specific jars. I had a j2se tag in the independet resources and only the resources for had an additional j2se tag with the default arguments and XstartOnFirstTbread In the combination above I got an invalid thread access. Then I removed the independed j2se and added on to each platform specific resources.  Now my clients starts - unfortunately only from command line with javaws from apples java 1.6.With the latest java from oracle I still get the exception. 
I've opened a Ticket:

Applet, Registry key, Runtime error, diff versions

Hi there, i loaded jsdk1.2 awhile ago and recently compiled using the 'javac' command creating a '.class' file and then ran the 'java' command on that '.class' file and it worked fine! Then i loaded an old version of JBuilder that must be using an older version of the jdk, 1.1.6 probably, and that JBuilder loading must have hijacked the registry key, whatever that is, here is the error message:
C:\books\java2scratch\J2Scratch\Source\Chapter04>java Labels
ERROR >>>>> Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion' has value '1.1.6', but '1.2' is required.
It seems like JBuilder automatically takes over java files so i'm assuming it must have done something the 'registry key'
Any help on this would be much appreciated!
Thanks alot! 
You are trying to run an old Java binary file - probably copied to \windows\system32. Trouble is, the registry says that you have a newer current version of Java. Here's my advice:
Uninstall all Java related software, including the JDK
Search for and delete java.exe, javaw.exe and so on, but be careful to keep a backup somewhere in case you get the wrong thing. In particular, check the windows and system directories, because they are often first in the PATH.
If you are confident with the registry, go in and try to clean out some of the Javasoft entries. (non essential step)
Download and install a newer freaking JDK - 1.2.2 is ancient now.
The main problem is probably this extra java.exe - if you can find and delete it, your problem may go away

Java applet manifest - having Trusted-Library=true attribute still shows display warning in JRE 1.7 u45

As mentioned in link For applications and applets that are designed to allow unsigned components, the Trusted-Library attribute should be used. No warning dialog will be displayed and an application or applet may load jar files containing untrusted classes or resources. But with the the latest jre 1.7 u45 we are getting security warning prompts. It is recommednded that newer Caller-Allowable-Codebase attribute should be used to handle the warning prompt. However, if I used newer one it will break the in updated 40 , and if I am using both display prompt will continue to come in jre 1.7 u45 Is there any solution to above problem? How can we support backward compatibility? In what sequence can we use the attribute such that both jre 1.7 u40 and 45 should stop display warning message?