[BUG] a phantom Java Plug-in 1.6.0._07 remains installed in IE8

a phantom Java Plug-in 1.6.0._07 remains installed in IE8 although the new version 1.6.0._19 is also installed.
Look this screenshot: http://i40.tinypic.com/11mfhj6.png
Windows Vista SP2
Edited by: vistoso on Apr 9, 2010 12:04 PM

The same thing can happen to firefox/linux depending on how you install it. However applets automatically registered with the updated vm. To update firefox to test and use the update, open ~/.mozilla/firefox/fooo.default/mimeTypes.rdf and change or remove the jnlp section.

Similar Messages

  • Java Plug-in 1.4.2_01 error

    Hi,
    Sometimes when I access certain websites with java programs I get the following pop-up error
    "Java Plug-in 1.4.2_01 is not installed properly". It then asks if I would like to open a new browser as the one I'm using apparently won't support the version of java needed for the applet.
    I'm using IE 6.0
    When I click on the Tools --> Sun Java Console I get the same Java Plug-in error.
    I have installed:
    Java(TM) 2 SDK, Standard Edition Version 1.4.2
    Java(TM) 2 Runtime Environment, Standard Edition Version 1.4.2 (j2re1.4.2_01)
    in different folders. Could that be the conflict?
    Should I just uninstall/delete both of them and reinstall another version?
    Any help is much appreciated!

    Yes, I would uninstall the JRE and the SDK and reinstall the latest version, J2SE SDK 1.4.2_04. In my experiences, during install the setup application asks me if I want to use this JVM with the browsers it finds, IE and Netscape. I always leave the boxes checked for both browsers and that seems to do the trick for me.

  • Unable to run Demos applet in java plug in 1.3.1_04

    Hi
    This is dipak here, I am try to run sample appplets program from java 1.3 samples and codes page of java.sun.com, but I am getting a security warning saying that "Do you want to install and run Java Plug-in1.3.1_13".
    I already install J2RE , i.e. Java Plug-in 1.3.1_04.
    Please tell me what i have to do and Java Plug-in 1.3.1_04 is still supported by java1.3 samples and codes or not.
    Thanks in advance for help.
    Thanks and Regards
    Dipsy

    Apparently the applet you're trying to run is wanting the more recent version of Java, and is asking you to install it.
    The version you have (1.3.1_04) is very old and reached End-of-Life years ago. Updating to Java 5 would probably resolve the issue.

  • Java plug in 1.4.0.......????

    i installed java jdk1.4 and after that ,when running any applet
    on browser..it mension me that "java plug in 1.4.0 is not installed properly.."
    i unstalled java and installed it again and also ,it give me the same message ??????????????

    Are you using I.E.???
    If so try to deactivate the Sun Java in controlpannel of your Windows,...
    Jesus

  • How to install java plug-in in the client?

    I am coding a web including an applet that need support of java plug-in, if a client didn��t install the plug-in, the following codes will download and install it automatically (I copy these codes from jdk��s demo ��SwingSet2��) :
    <OBJECT
    classid="clsid:CAFEEFAC-0014-0000-0001-ABCDEFFEDCBA"
    WIDTH = 695 HEIGHT = 525
    codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0_01-win.cab#Version=1,4,0,10">
    <PARAM NAME = CODE VALUE = SwingSet2Applet >
    <PARAM NAME = CODEBASE VALUE = "." >
    <PARAM NAME = ARCHIVE VALUE = "SwingSet2.jar" >
    <PARAM NAME="type" VALUE="application/x-java-applet;jpi-version=1.4.0_01">
    <PARAM NAME="scriptable" VALUE="false">
    <COMMENT>
         <EMBED
    type="application/x-java-applet;jpi-version=1.4.0_01"
    CODE = SwingSet2Applet
    CODEBASE = "."
    ARCHIVE = "SwingSet2.jar"
    WIDTH = 695
    HEIGHT = 525
         scriptable=false
         pluginspage="http://java.sun.com/products/plugin/index.html#download">
         <NOEMBED>
              </NOEMBED>
         </EMBED>
    </COMMENT>
    </OBJECT>
    But my page is used in the LAN, clients cannot connect to the sun��s website, how can I let then install the plug-in automatically? I know that when install jdk, the plug in will be installed too, but the jdk is so large that I can��t ask all the user to install it. Is there an independent installation of plugin?
    Thanks a lot!!!

    Download the plugin and place a copy on your server. Then you simply amend the coebase tag:
    codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_0_01-win.cab#Version=1,4,0,10">
    so that it points to the relevant directory on your server.
    I copy these codes from jdk��s demo ��SwingSet2��) :Note that you can run your HTML file through the HTMLConverter located in javahome\bin to generate your HTML file.

  • Static variable, a bug in applet classloader, Java plug-in?

    I found a potential bug in java plug-in.
    Environment,
    1. IE 6.0
    2. Windows XP
    3. JRE 1.3.1.06 and JRE 1.4.1.01
    Steps,
    1. build a very simple applet (attached below)
    2. embed the applet into a .html page.
    3. enable java plug-in for IE and Netscape.
    4. launch the .html page in either of the two browsers.
    5. for the 1st time, I can see 'tmp = 0' in the java console window.
    6. keep the browser open, browse to 'www.google.com'
    7. click 'Back' button of the browser.
    8. I notice 'tmp = 1' in the java console window.
    9. if I browse to google.com and back again, it will display 'tmp = 2'. and the number will keep on increasing if I repeat those steps.
    10. But if I press F5 to refresh the page, the log message will go back to 'tmp = 0'. and if I press 'x' inthe console window to clean up the classloader cache, I will get 'tmp = 0'. If I close the browser and open a new one, I will still get 'tmp = 0', which is what the applet should output.
    11. If I click 't' in the console window to list the thread while I am in the 'google' page, I can't see the applet thread, which means the applet should have been destroyed.
    12. No matter I try 'g' to do garbage collect, or 'f' to finalize objects, the problem still happens. the only solution is what I did in the step 10.
    Is it a bug in the classloader or the JRE itself? Why the value of the static variable won't be cleaned up along with the applet?
    ----------- HERE IS THE APPLET --------------------
    import java.applet.Applet;
    public class AA extends Applet
    private static long tmp = 0;
    public void init() {
         System.out.println("tmp value = " + tmp);
    tmp++;
    public void start() {}
    public void stop() {}
    public void destroy() {}

    Static values are stored in the class. Once a class is loaded into a classloader, it cannot be unloaded (the only thing you can do is use another classloader).
    Apparently, the classloader cache allows sharing of classloaders between applet instances. Perhaps F5 (reload) causes the classloader cache to be cleared.
    I don't see any bug. When developing applications or applets that must run in the same JVM, you should program defensively and avoid using static values which can change over time.

  • Java Plug-in / JSObject support with IE and Firefox

    Hi there,
    Basicaly, the idea behind is to write objects in Java to replace or extend functionnalities of a web page (like XMLHttpRequest object). Those objects should support event handler writen in Javascript.
    My first idea was to create JavaBeans and instantiate them through OBJECT tags in HTML (not as ActiveX objects). I don't find a way to instatiate a Javabean which was not also an applet.
    Does someone knows how to ?
    Anyway, the OBJECT tag may not work with Netscape. So, I went to use the APPLET tag with the Sun Java Plug-in.
    I've made some tests with IE and Firefox and there is at least two differences between them (both use the Sun Java Plug-in) :
    1/ Firefox / JSObject
    When you pass a Javascript object to a Java method, it seems that you
    cannot use methods like 'getMember', 'call', etc on this object.
    (invocation of the method works but returns null)
    But, if you access the same object form inside Java starting by
    JSObject.getWindows(...) and so on, it works fine.
    IE works in all cases.
    Example, with the Java applet and HTML below :
    . Java applet :
    | package JavaJS;
    |
    | import netscape.javascript.*;
    |
    | public class FirefoxApplet
    |        extends java.applet.Applet {
    |   netscape.javascript.JSObject win = null;
    |  
    |   public void init() {
    |     win = netscape.javascript.JSObject.getWindow(this);
    |   }
    |
    |   public Object getJSObjectMember( netscape.javascript.JSObject jso, String member ) {
    |     return jso.getMember(member);
    |   }
    |
    |   public netscape.javascript.JSObject getJSObjectFromPath( String jsoPath ) {
    |     String [] jsoNames = jsoPath.split("\\.");
    |     netscape.javascript.JSObject jso = win;
    |
    |     for( int i = 0; ( i < jsoNames.length ); i++ )
    |       jso = (netscape.javascript.JSObject)jso.getMember(jsoNames);
    |
    | return jso;
    | }
    |
    | public Object getJSObjectPathMember( String jsoPath, String member ) {
    | return getJSObjectMember(getJSObjectFromPath(jsoPath),member);
    | }
    | }
    [i]. HTML page :| <HTML>
    | <HEAD>
    | <TITLE>FirefoxApplet</TITLE>
    | <META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    | <META http-equiv="Content-Script-Type" content="text/javascript">
    | <SCRIPT>
    | var ffxa = null;
    | var txa = null;
    |
    | var o = {
    | s : "object o, member s",
    | o : {
    | s : "object o.o, member s"
    | }
    | }
    |
    | function go() {
    | print(ffxa.getJSObjectMember(o,"s"));
    | print(ffxa.getJSObjectMember(o.o,"s"));
    | print(ffxa.getJSObjectPathMember("o","s"));
    | print(ffxa.getJSObjectPathMember("o.o","s"));
    | print(ffxa.getJSObjectMember(ffxa.getJSObjectFromPath("o"),"s"));
    | print(ffxa.getJSObjectMember(ffxa.getJSObjectFromPath("o.o"),"s"));
    | }
    |
    | function print( text ) {
    | txa.value = txa.value+text+"\n";
    | }
    |
    | function loaded() {
    | ffxa = document.getElementById("ffxa");
    | txa = document.getElementById("txa");
    |
    | }
    | </SCRIPT>
    | </HEAD>
    | <BODY onload="loaded()">
    | <APPLET id="ffxa"
    | code="JavaJS.FirefoxApplet.class"
    | width="0"
    | height="0"
    | MAYSCRIPT>
    | </APPLET><BR>
    | <INPUT type="button" onclick="go()" value="Go"><BR>
    | <TEXTAREA id="txa" rows="10" cols="40"></TEXTAREA>
    | </BODY>
    | </HTML>
    When the HTML page has loaded, a click on the Go button gives :
    . Firefox output :
    | null
    | null
    | object o, member s
    | object o.o, member s
    | null
    | null
    . IE output :
    | object o, member s
    | object o.o, member s
    | object o, member s
    | object o.o, member s
    | object o, member s
    | object o.o, member s
    2/ Internet Explorer / JSObject
    As we have seen in the previous example, passing Javascript object to
    an applet method works. Here, the problem comes when a Javascript object
    is pass to a method that's not an applet's method.
    If within the applet, you instantiate a new Java object and then
    call from Javascript a method on this object with a Javascript object as
    parameter then an Exception is raised when invoking that method.
    Firefox works fine here.
    Example, with the Java applet and HTML page below :
    . Java applet :
    | package JavaJS;
    |
    | public class IEApplet extends java.applet.Applet {
    |  
    |   public void init() {
    |   }
    |  
    |   public Object echo( Object object ) {
    |     return object;
    |   }
    |  
    |   public Object newEcho() {
    |     return new Echo();
    |   }
    | }
    . Java Echo class
    | package JavaJS;
    |
    | public class Echo {
    |  
    |   public Echo() {
    |   }
    |
    |   public Object echo(Object object) {
    |     return object;
    |   }
    | }
    . HTML page :
    | <HTML>
    |   <HEAD>
    |     <TITLE>IEApplet</TITLE>
    |     <META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    |     <META http-equiv="Content-Script-Type" content="text/javascript">
    |     <SCRIPT>
    |       var iea = null;
    |       var txa = null;
    |
    |       var o = {
    |         s : "object o, member s",
    |         o : {
    |           s : "object o.o, member s"
    |         }
    |       }
    |
    |       function go() {
    |         print(iea.echo(o));
    |         print(iea.newEcho().echo(o));
    |       }
    |      
    |       function print( text ) {
    |         txa.value = txa.value+text+"\n";
    |       }
    |
    |       function loaded() {
    |         iea = document.getElementById("iea");
    |         txa = document.getElementById("txa");
    |        
    |       }
    |     </SCRIPT>
    |   </HEAD>
    |   <BODY onload="loaded()">
    |     <APPLET id="iea"
    |             code="JavaJS.IEApplet.class"
    |             width="0"
    |             height="0"
    |             MAYSCRIPT>
    |     </APPLET><BR>
    |     <INPUT type="button" onclick="go()" value="Go"><BR>
    |     <TEXTAREA id="txa" rows="10" cols="40"></TEXTAREA>
    |   </BODY>
    | </HTML>When the HTML page has loaded, a click on the Go button gives :
    . Firefox output :
    | [object Object]
    | [object Object]
    . IE output :
    | [object Object]
    with this Exception on the second method invocation :
    | java.lang.ClassCastException
    |      at sun.plugin.com.DispatchImpl.convertParams(Unknown Source)
    |      at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
    |      at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
    |      at java.security.AccessController.doPrivileged(Native Method)
    |      at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
    | java.lang.Exception: java.lang.ClassCastException
    |      at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
    |      at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
    |      at java.security.AccessController.doPrivileged(Native Method)
    |      at sun.plugin.com.DispatchImpl.invoke(Unknown Source)There is a workaround for this, it's possible to wrap the Javascript object
    in a Java object with an applet method and then use this Java object as
    parameter.
    Anyway, my questions are : regarding points 1/ and 2/ are these bugs with the Sun Java Plug-in ? or someone could explain these behaviors ?
    Thanks for your reading.
    Software infos :
    . Firefox version 1.0.7
    . Internet Explorer version 6.0.2800.1106 / JScript version 5.6
    . Plug-in Java(TM): Version 1.4.2_08
    . JSDK version 1.4.2_08
    . Windows 2000 Server version 5.00.2195 sp4

    Please test with the new Java Plug-In available in 6u10 at http://jdk6.dev.java.net/6u10ea.html. The Java/JavaScript bridge has been completely rewritten and is now more complete and portable than ever before. Longstanding issues should be fixed with this new version. Please try it and post if you continue to have problems.

  • Applets and memory not being released by Java Plug-in

    Hi.
    I am experiencing a strange memory-management behavior of the Java Plug-in with Java Applets. The Java Plug-in seems not to release memory allocated for non-static member variables of the applet-derived class upon destroy() of the applet itself.
    I have built a simple "TestMemory" applet, which allocates a 55-megabytes byte array upon init(). The byte array is a non-static member of the applet-derived class. With the standard Java Plug In configuration (64 MB of max JVM heap space), this applet executes correctly the first time, but it throws an OutOfMemoryException when pressing the "Reload / Refresh" browser button or if pressing the "Back" and then the "Forward" browser buttons. In my opionion, this is not an expected behavior. When the applet is destroyed, the non-static byte array member should be automatically invalidated and recollected. Isn't it?
    Here is the complete applet code:
    // ===================================================
    import java.awt.*;
    import javax.swing.*;
    public class TestMemory extends JApplet
      private JLabel label = null;
      private byte[] testArray = null;
      // Construct the applet
      public TestMemory()
      // Initialize the applet
      public void init()
        try
          // Initialize the applet's GUI
          guiInit();
          // Instantiate a 55 MB array
          // WARNING: with the standard Java Plug-in configuration (i.e., 64 MB of
          // max JVM heap space) the following line of code runs fine the FIRST time the
          // applet is executed. Then, if I press the "Back" button on the web browser,
          // then press "Forward", an OutOfMemoryException is thrown. The same result
          // is obtained by pressing the "Reload / Refresh" browser button.
          // NOTE: the OutOfMemoryException is not thrown if I add "testArray = null;"
          // to the destroy() applet method.
          testArray = new byte[55 * 1024 * 1024];
          // Do something on the array...
          for (int i = 0; i < testArray.length; i++)
            testArray[i] = 1;
          System.out.println("Test Array Initialized!");
        catch (Exception e)
          e.printStackTrace();
      // Component initialization
      private void guiInit() throws Exception
        setSize(new Dimension(400, 300));
        getContentPane().setLayout(new BorderLayout());
        label = new JLabel("Test Memory Applet");
        getContentPane().add(label, BorderLayout.CENTER);
      // Start the applet
      public void start()
        // Do nothing
      // Stop the applet
      public void stop()
        // Do nothing
      // Destroy the applet
      public void destroy()
        // If the line below is uncommented, the OutOfMemoryException is NOT thrown
        // testArray = null;
      //Get Applet information
      public String getAppletInfo()
        return "Test Memory Applet";
    // ===================================================Everything works fine if I set the byte array to "null" upon destroy(), but does this mean that I have to manually set to null all applet's member variables upon destroy()? I believe this should not be a requirement for non-static members...
    I am able to reproduce this problem on the following PC configurations:
    * Windows XP, both JRE v1.6.0 and JRE v1.5.0_11, both with MSIE and with Firefox
    * Linux (Sun Java Desktop), JRE v1.6.0, Mozilla browser
    * Mac OS X v10.4, JRE v1.5.0_06, Safari browser
    Your comments would be really appreciated.
    Thank you in advance for your feedback.
    Regards,
    Marco.

    Hi Marco,
    my guess as to why JPI would keep references around, if it does keep them, is that it propably is an implementation side effect. A lot of things are cached in the name of performance and it is easy to leave things laying around in your cache. Maybe the page with the associated images/applets is kept in the browser cache untill the browser needs some memory and if the browser memory manager is not co-operating with the JPI/JVM memory manager the browser is not out of memory, thus not releasing its caches but the JVM may be out of memory. Thus the browser indirectly keeps the reference that it realy does not need. This reference could be inderect through some 'applet context' or what ever the browser uses to interact with JPI, don't realy know any of these details, just imaging what must/could be going on there. Browser are amazingly complicated beast.
    This behaviour that you are observing, weather the origin is something like I speculated or not, is not nice but I would not expect it to be fixed even if you filed a bug report. I guess we are left with relleasing all significatn memory structures in destroy. A simple way to code this is not to store anything in the member fields of the applet but in a separate class; then one has to do is to null that one reference from the applet to that class in the destroy method and everything will be relased when necessary. This way it is not easy to forget to release things.
    Hey, here is a simple, imaginary, way in which the browser could cause this problem:
    The browser, of course needs a reference to the applet, call it m_Applet here. Presume the following helper function:
    Applet instantiateAndInit(Class appletClass) {
    Applet applet=appletClass.newInstance();
    applet.init();
    return applet;
    When the browser sees the applet tag it instantiates and inits the new applet as follows:
    m_Applet=instantiateAndInit(appletClass);
    As you can readily see, the second time the instantiation occurs, the m_Applet holds the reference to the old applet until after the new instance is created and initlized. This would not cause a memory leak but would require that twice the memory needed by the applet would be required to prevent OutOfMemory.I guess it is not fair to call this sort of thing a bug but it is questionable design.In real life this is propably not this blatant, but could happen You could try, if you like, by allocating less than 32 Megs in your init. If you then do not run out of memory it is an indication that there are at most two instances of your applet around and thus it could well be someting like I've speculated here.
    br Kusti

  • Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed

    Cross-posting to reach a wider audience:
    Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed
    Author: remyb Jul 23, 2002 6:36 AM
    A IllegalStateException is thrown when the class loader
    try to load a class from my applet JAR file.
    The applet is embedded in a JSP page which use the Plug-In 1.4.0.
    That JSP is hosted by Tomcat 4.0.1.
    The applet JAR file is signed with a self-signed certificate.
    The applet has been compiled with JDK 1.4.0.
    The jar has been put in the Plug-in cache successfully.
    Here is the stack trace I got in the Java Console ...
    java.lang.IllegalStateException: zip file closed
    at java.util.zip.ZipFile.getEntry(Unknown Source)
    at java.util.jar.JarFile.getEntry(Unknown Source)
    at sun.plugin.cache.CachedJarFile.getEntry(Unknown Source)
    at java.util.jar.JarFile.getJarEntry(Unknown Source)
    at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)
    at sun.misc.URLClassPath.getResource(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    Please somebody help me !!
    Thanks !
    Re: Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed
    Author: mutmansky
    In Reply To: Java Plug-in 1.4.0 throws an IllegalStateException: zip file closed Jul 26, 2002 6:36 AM
    Reply 1 of 1
    I've got a very similar error, but unfortuneatly I don't have an answer yet. The only difference is that my Applet is embedded in a standard HTML page, and loaded via Apache. Once the Applet runs, it then communicates with the servlet via Tomcat. I also exchange data with another server task via CORBA.
    But everything else is the same, self-signed applet, applet compiles successfully, and jar is being put in the Plug-in Caceh successfully.
    I have narrowed the problem down a bit, and maybe you can tell me if you're in a similar situation:
    In my case, I need to encrypt the data that I'm sending through CORBA, so I create a Cipher object using Cipher.getInstance(). This method call seems to be the catalyst of my troubles. No matter where I move that call in my code, the next time the code tries to instantiate a class defined in my applet jar file after that "getInstance" call, I get the "zip file closed error." It's like the classloader is confused, because the Cipher.getInstance method would be accessing a different jar file or something. Are you trying to do something similar? Maybe not creating a Cipher, but creating some other object defined outside your own jar-file?
    To top it off, if I disable caching in the Plugin control panel, everything works fine. But that's not really an option for me, since it slows things down a lot, and I can't make all my users go into their control panels and disable caching. But at leasts it makes me confident that there's not a problem with my code.
    In my latest attempt to circumvent this problem, I even put the Cipher.getInstance() call in a static initializer. Here's the stack trace from that attempt:
    java.lang.IllegalStateException: zip file closed
    at java.util.zip.ZipFile.getEntry(Unknown Source)
    at java.util.jar.JarFile.getEntry(Unknown Source)
    at sun.plugin.cache.CachedJarFile.getEntry(Unknown Source)
    at java.util.jar.JarFile.getJarEntry(Unknown Source)
    at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)
    at sun.misc.URLClassPath.getResource(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    at com.uss.wbi.client.WBIClient.<init>(WBIClient.java:404)
    at com.uss.wbi.client.WBIApplet.init(WBIApplet.java:122)
    at sun.applet.AppletPanel.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
    In other words, since the getInstance method is in a static initializer, the next thing to run is the applet.init(), which is what is failing now. If I move the Cipher.getInstance method into the client constructor, the next time I instantiate a new object, I'll get the error there.
    Has anybody else seen anything like this? Or does anybody know how I can flush the Cache from the applet code? Or can I reset the ClassLoader in some way in the code?
    Thanks,
    Steve

    Well, I finally came to a solution that is acceptable at least to me, if not ideal. I've started using the BouncyCastle lightweight API. This makes my code somewhat more complicated, and I had to bundle up all the BouncyCastle classes that I'm using into a jar file, and download that to my applet along with my client jar file (after signing the jar files). Using this Lightweight API bypasses the Cipher.getInstance() method all together, and is a little harder to use, but at least everything is working consistently now.
    I still believe this to be a bug either in the ClassLoader or the Cipher.getInstance() method. I intend to try to write a test applet that reproduces the error in a more simple way and if I can pull that off, I'll submit a bug report to Sun.
    Thanks to all who responded!!
    Steve

  • Java Plug-in problems following installation of Oracle 9i

    I have been experiencing repeatable problems with the Sun Java Plug-in following installation of Oracle 9i on our servers. Our installation of the Sun JDK 1.3.1_04 or higher seems to conflict with the Oracle installation. Following the install, navigating to any web page that includes an applet reference results in a plug-in error stating that it cannot locate the registry key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.3.1_01. The key does exist however for the installed version of the plug-in. ie [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.3.1_07]. My only workaround to fix this is to add a new registry key 1.3.1_01 that contains the contents of the registry key for the installed plug-in (for example 1.3.1_07).

    The Oracle installation only inlcludes the JRE, which AFAIK isn't referenced outside the ORACLE_HOME directory. The internal JVM couldn't be causing the conflict either. Might be an installer bug of some sort, but not one I have heard of.

  • Java Plug-In 1.4.1 Crashes in Win2000 IE6.0.2600

    Hallo
    Please can somebody help with information on why the Java Plug-in ver 1.4.1 just crashes when I try to run an applet under windows 2000 Professional using IE6.0.2600. Also I cannot run the Java Console nor the Java Plug-in Control panel, all of which crash or do nothing. The console shows signs of wanting to run by displaying its window by it never completes this process and then it crashes, killing the browser in the process. When it does this, it resets the Internet Option "Java Console ENabled" in IE Internet Options>Advanced>Microsoft VM.
    Why cant I run the Java Console, the Java Plugin Control Panel or any applet no matter how simple.
    Any help will be greatly appreciated!!!
    Thanks

    I have the same machine configuration and Java Plug-in reboots my machine when download my application from a website. It also reboots machine when i click on 'Get Update' button on the Java Plug-in Control panel. Please help.
    Dose anybody know how to report this Critical bug to Sun.

  • Java plug-in 1.4.1 proxy configuration issue causes JTextField TAB problems

    I have an applet that has multiple JTextFields in it. I recently updated my Java plug-in to version 1.4.1, and now using TAB to navigate among text fields does not always work when I first bring up a browser and load the applet.
    I've found, however, that if I open the Java Console and hit "p" (reload proxy configuration), and then reload my applet (hit Refresh/Reload on my browser), the Tab key works as expected. I did not have this issue with releases prior to 1.4.1.
    Any clue on how I can ensure proper proxy configuration upon initial instantiation of the browser? I've seen the problem in both IE 6.0 and Netscape 7.0.
    Note that the reloading of the proxy configuration only appears to be necessary once per browser session.

    The navigation isn't working. I click in the first text field to give the initial field focus. I then hit TAB and nothing happens. I have a key listener set up for the ENTER key, and this is also supposed to navigate to the next field via:
    ((JTextField)evt.getSource()).transferFocus();
    To see if there was a problem with my build environment or threads in my application, I came up with the following dummy applet:
    import java.awt.BorderLayout;
    import javax.swing.BoxLayout;
    import javax.swing.JApplet;
    import javax.swing.JPanel;
    import javax.swing.JTextField;
    public class TestApplet extends JApplet {
    public void init() {
    super.init();
    public void start() {
    JPanel myPanel = new JPanel();
    myPanel.setLayout(new BoxLayout(myPanel, BoxLayout.Y_AXIS));
    JTextField textField1 = new JTextField("Text Field 1");
    myPanel.add(textField1);
    JTextField textField2 = new JTextField("Text Field 2");
    myPanel.add(textField2);
    JTextField textField3 = new JTextField("Text Field 3");
    myPanel.add(textField3);
    getContentPane().add(BorderLayout.CENTER, myPanel);
    public void stop() {
    super.stop();
    I then compiled this applet using the following:
    javac TestApplet.java
    I then put together the following HTML file:
    <HTML>
    <HEAD>
    <TITLE>Test Applet</TITLE>
    </HEAD>
    <BODY MARGINWIDTH="0" MARGINHEIGHT="0" BGCOLOR="white">
    <APPLET
    CODE=TestApplet.class
    WIDTH=635
    HEIGHT=500
    ALIGN=left
    VSPACE=10
    HSPACE=10
    >
    </APPLET>
    </BODY>
    </HTML>
    The results are the same. I am not able to navigate using the TAB key until I bring up the Java console and then close it again. I would think that if this was a bug in 1.4.1_01, I would have seen it all over the forums. Any help would be greatly appreciated.

  • Java Plug in 1.4 Performance

    I'm getting really poor performance on my applet using the Java plug in that I just installed from JDK 1.4 running under Win 2000.
    What's the deal?
    Hate to say it, but the MS VM blows this away as far as performance goes.
    Also, some of the applet resources (gif files) did not load from the JAR properly. I assume this is a bug, as it worked fine under JDK 1.3 / Java plug-in 1.3
    Drew

    Hey,
    I too have noticed really poor performance with the 1.4 plugin as well. I have spent the past couple of days banging my head against a wall trying to get to the bottom of the problem, but here is all that I have found (this is for 1.4.2_02):
    1. When you run the plugin to a web site that runs over https, the applet jar caching mechanism doesn't seem to work. Or at least, when I access my app/applet on my local box that runs over http, everything works fine. But when I try the app/applet combination against one of our staging environments that operates over https/SSL, I see the applet .jar files loaded multiple times. This definitely results in a slow down.
    2. We use RSA signed .jar files to deliver our applets (these are signed with the Netscape signtool). There is something about the signature confirmation that the plugin class loader is doing that is slowing the applet WAY down (3-4 times as slow). For example, if I run our applet code as a 'stand alone' application (i.e. run from a 'main' method using the same VM as the plugin) it take about 10-12 seconds to initialize. But if I run it as an applet from a singed .jar file in the plugin it takes about 60 seconds to initialize (ouch). Finally, if I use the plugin to run the applet but use UNSIGNED .jar files to deploy it, and add the correct policy entries into my java.policy file for the plugin so that the applet runs with full permissions, I'm back to running at 10-12 seconds. So these three things lead me to believe that the problem is not with the SSL implementation (in the third case I'm still using SSL to talk between the applet/server) but rather has to do with the signature confirmation performed by the plugin class loader.
    3. If I run my applet in the plugin but place the .jar files on my hard drive and then set them to be in the boot class path of the plugin (using the -Xbootclasspath/a flag) so that they are loaded using the default class loader, my applet also initialized in 10-12 seconds. Once again, this seems to point to the plugin class loader being the culprit for the slowdown.
    I hope this helps somebody, and that somebody can shine some light on my problems.
    Thanks
    Andy Peterson

  • Java plug-in fatal error

    When I try to open an applet on a site I get the message "Java plug-in fatal error- several Java virtual machines running in the same process caused an error". Checking my add/remove program I see that I have J2SE runtime environment 5.0 updates 7,9,10 and 11. Java 2 runtime environment standard edition version 1.3.1_02, 1.4.1_01, and 1.4.2_03. Also Java runtime environment 6 update 1. I'm running Windows XP service pack 2. Hope someone has a solution to my problem.

    This is an existing bug request:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6516270
    Providing this information could be handy:
    1) Does this occur on all browser(s) which includes Firefox, Mozilla other then Internet Explorer
    2) What is the outcome of running testvm applet:
    http://java.com/en/download/help/testvm.xml
    3) Does this error start appearing after updating to 6u01
    4) Have you attempted running the applet after deleting Java Plug-in and browser cache
    This could be an issue with memory management on the system.
    The possible workaround(s) are:
    1) Try setting virtual memory as System managed:
    Windows xp users start--->control panel--->System--->advanced---->Performance(setting)---->Advanced---->virtualmemory(change)--->Click system managed size--->set then Ok restart your computer
    2) Set JRE parameter less then 3/4 of actual physical memory present in the system.
    For example, 512 MB if RAM is 1024 MB.
    3) Disable any unwanted/new/confusing add-on in the browser (IE7).
    For example, Windows Live Sign-in add-on can restrict Java functioning due to unknown reasons. Disabling same, if installed could be helpful.

  • How to find my submitted bug report in Java bug database

    I just submitted a bug report in Java bug database and it told me that the submission is successful without its bug ID and no email notification is received from Oracle.
    And I cannot find the bug in bug database with the title I submitted.
    The bug's product/category is Java Plug-in in JRE7
    So how could I get the bug status? Will it be fixed and how is it going on?

    I just submitted a bug report in Java bug database and it told me that the submission is successful without its bug ID and no email notification is received from Oracle.Last time I did that it also said it wouldn't appear straight away. They have to qualify bugs you know.
    And I cannot find the bug in bug database with the title I submitted.How long ago?
    So how could I get the bug status?Wait till it turns up?
    Will it be fixed and how is it going on?How would anyone on this forum know?

Maybe you are looking for