Bug in JRE 1.4.0

Hello,
My applet doesn't display properly with Sun's JRE 1.4.0. It doesn't properly repaint the applet area, so my applet appears frozen.
The applet: http://www.mandelmania.net/mandelmania.html
Is there a fix for this, or a workaround? For now I've uninstalled Sun's JRE, and fell back to using Microsoft's current JVM for Internet Explorer 6 (under Windows XP).
Thanks,
Ian

This is a potentially fatal situation for Sun Java.
I get the feeling that changes were made to the JRE 1.4.1
in order to prevent the microsoft JVM from interpreting new
Sun JDK applets, but this has resulted in all (?) applets
written for previous JRE's being broken.Nonsense. The Microsoft JVM won't even run code spec'ed
to Java 1.2. The current situation with the 1.4 JRE is
a bug and a serious one. But please don't use these forums
to spread FUD!
We may simply have to abandon Sun's Java and go here:
http://www.microsoft.com/java/sdk/
That's fine if you want to write simple applets for Windows
only, but we intend to support MacOSX, Linux, and anywhere
else Sun's JVM will run.

Similar Messages

Windows Crashes with JRE 1.4.2 When Moving around JDialog

Hi!
I work on a Java Applet/application that was originally written to run on java 1.1 -- only AWT that too. Recently I managed to convince my manager (and his manager and his manager) to migrate from the AWT framework on java 1.1 (Microsoft JVM that is ) to Swing/JFC on Sun Java 1.4.2 ... it took a lot of explaining, demostrating, begging, pleading etc., to get this project funded.
Now, my app is all developed in JFC and ready for deployment and during testing found a potential show stopper -- When a Dialog Box or any moveable componant (internal windows etc) is moved around (holding down the mouse on the title bar of a dialog and dragging it around), the OS simply froze up ... nothing could be done other than power cycling the PC. Does anyone know if its a bug in JRE 1.4.2 and if it has been fixed?? This could potentially result in rolling back to AWT :(( .... and of course me looking like a fool in front of my manager!!
..... Please provide any suggestion other than moving to JRE 1.5.x beta. I've also noticed this happening in other Java Applications (Netbeans for example). So, I think this is a major bug the JRE 1.4.2.
A million thanks and few Duke Dollars for anyone pointing me in the right direction.
Note:
1. This problem is not just with my app ... some other java apps that are installed on my workstation (like netbeans) behave the same when Moving Around dialog boxes.
2. The behaviour is very random. But it has happened multiple times (and the very first time my manager run our app on jre 1.4.2)
I would give a million dollars if I had them. But for now, please do with the million thanks and few duke dollars.

Have you tried this on another machine?Yes ... actually this has happened on a few workstations here ... all of them are Pentium IV based dell workstations running Windows 2000.
What exact version of 1.4.2 did you download?Java(TM) Plug-in: Version 1.4.2_04
Using JRE version 1.4.2_04 Java HotSpot(TM) Client VM
Have you searched the bug database? This one could be related to yours:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4673572
This sounds similar but the difference is its not just the app that feezes up (so that you could do an alt+ctrl+del and kill it)..... the OS freezes up and you can move the mouse around still the system even queu e is not full and eventuall all I hear is the beeping. At this point I've to power cycle.
Is there any way you could post the code or is it too big? Or, have you tried just creating a very small >application or applet that just shows one dialog, and if so, does that show the same problem? (What I'm >trying to get at here is - is it something in your code that is causing this, or something in the JRE, or >perhaps something to do with your machine's configuration/OS?)Unfortunately I cannot post the code ... its company rules and regulations. I've tried creating a very small app and it appears to work ok .... but randomly causes this freeze up. There is no definate pattern (except that it happens when you move around a JDialog or a JInternalFrame) . It could freeze up some time and work perfectly fine at other times. It has actually happened on other applications too (Netbeans, JEdit etc). That's why I suspect this might be a obscure bug in the JRE.
I'll try to find a pattern so that it can be re-produced by everyone.
Thanks for the help.

JRE 1.4.0 or 1.4.1?

Hallo,
we are running a Java Application with JRE 1.3.0 and planning to upgrade the JRE-VErsion to JRE-Version 1.4: which version would you suggest us to use?
We have heard that JRE version 1.4.1 has more bugs than JRE version 1.4.0: is this correct?
And what do you think of JRE version 1.4.2?
kind regards,
Christoph

I forgot to say:
we have made the praxis-test with JRE 1.4.1, and have fount many problems with it (including blocking system, printing problems, and so on); so we are thinking whether it can be caused with the JRE-version 1.4.1.

Windows Crashes with JRE 1.4.2

Hi!
I work on a Java Applet/application that was originally written to run on java 1.1 -- only AWT that too. Recently I managed to convince my manager (and his manager and his manager) to migrate from the AWT framework on java 1.1 (Microsoft JVM that is ) to Swing/JFC on Sun Java 1.4.2 ... it took a lot of explaining, demostrating, begging, pleading etc., to get this project funded.
Now, my app is all developed in JFC and ready for deployment and during testing found a potential show stopper -- When a Dialog Box or any moveable componant (internal windows etc) is moved around (holding down the mouse on the title bar of a dialog and dragging it around), the OS simply froze up ... nothing could be done other than power cycling the PC. Does anyone know if its a bug in JRE 1.4.2 and if it has been fixed?? This could potentially result in rolling back to AWT :(( .... and of course me looking like a fool in front of my manager!!
..... Please provide any suggestion other than moving to JRE 1.5.x beta. I've also noticed this happening in other Java Applications (Netbeans for example). So, I think this is a major bug the JRE 1.4.2.
A million thanks and few Duke Dollars for anyone pointing me in the right direction.
Note: I would give a million dollars if I had them. But for now, please do with the million thanks and few duke dollars.

I seriously doubt that it's a jvm flaw (possible, but very unlikely). Start stripping out code until you get down to a minimum size that still exhibits the problem. If then you can't clear it, post the minimal code and some information as to what's happening - you may want to try an analyzer.
If the problem appears to be a GUI issue, post into the Swing forum, otherwise post into the Java Programming forum - more people read those.

JRE 7 update 45

Hi,
After updating jre 7update 45 my applet is not working.The applet is signed with the trusted certificate.
Also accrding to release notes I have added the attributes
Permissions : all-permissions
codebase : *
Application-Name : Display
Application-Library-Allowable-Codebase : *
Caller-Allowable-Codebase : *
After adding the attribute I again siged the jar file using the same trusted certificate we have been using.
Still it gives some blue shield warning message.
Is there a bug in jre 7update 45.Or I am missing something because of which it is not working.
Is there any solution for suppressing these security warnings.

This is resolved and jar file is working fine without any warning message.
What I did is.I added the below attrributes to my jar file
Codebase : *
Permissions: all-permissions
Application-Allowable-Library-Codebase : *
Caller-Allowable-Codebase : *
I added these attributes by extracting the jar file contents through winzip.
After this I signed the jar file again with new trusted certificate anded used the following cermgr Command
to include the certificate in ROOT and trusted publisher
certmgr.exe -add <path of the certificate> -s -r localMachine ROOT
certmgr.exe -add <path of the cetificate> -s -r localMachine trustedpublisher
This made my jar file working fine with jre 7 update 45.

JRE 1.6.0_26 shows grant pop-up dialog even when usePolicy is in effect

I am testing JRE 1.6.0_26 (6u26 if you will) with our java.policy. Our policy starts with:
grant { permission java.lang.RuntimePermission "usePolicy"; };
and then adds specific grants for our internal java applets. With older JRE versions, this would suppress the pop-up dialog to ask the user to grant permission to signed and untrusted applets. This behavior is explained at http://java.sun.com/developer/technicalArticles/Security/applets/
With JRE 1.6.0_26 the dialog is shown, but pressing "cancel" or "run" gives the same result: the java.policy is used, not the user's decision.
Is this a bug in JRE 1.6.0_26 ?
I can still suppress the dialog by setting
deployment.security.askgrantdialog.show=false
in the the user's deployment.properties file. Is there a global way to set this property for all user?

After some more digging, here is the bug ID: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7047909

AWTPermission "accessClipboard" issue in JRE 1.6.0_07

Is AWTPermission check of "accessClipboard" removed from Java Applet AWTEvent event processing in JRE 1.6.0_07?
In JRE 1.6.0_07, I can now copy from JTextArea to system clipboard, without signing the applet and without granting the AWTPermission "accessClipboard" in java.policy.
In JRE 1.6.0_04, it didnt allow copy unless you sign the jar or grant the permission.
Is this a security bug in JRE 1.6.0_07? Or is it a new feature?
My second question is about EventQueue class. I used the following code to subclass EventQueue and register it to Event stack.
In JRE 1.6.0_07, this code doesnt allow copy from JTextArea to system clipboard unless I sign the jar or grant the "accessClipboard" permission in java.policy.
Is this expected? Is there any way to get around jar signing or granting permission?
Thanks in advance
class MyEQ extends EventQueue {
protected void register (){
    Toolkit.getDefaultToolkit().getSystemEventQueue().push(this);
protected void dispatchEvent(AWTEvent e) {
    doProcess(e);
    super.dispatchEvent(e);
private void doProcess(AWTEvent e) {
}

Reposted in the AWT forum.
[http://forums.sun.com/thread.jspa?threadID=5334933]

How to cache Applet using JRE 1.2.2

I have an applet that is about 500+ kb in size.
I will like to cache this Applet on the end user's
machine and to be downloaded only when the version
on the server has changed. I had done quite a lot
of search on java.sun.com and java usenet
newsgroups, but could not find definintive answer.
This what I had to use:
JRE Plugin 1.2.2 release 006, On Windows NT 4
with SP4 and IE 4.0 with SP1. I could not make
it cache on above platform as Cleint.
This is my understanding so far:
1> Java 1.2.2 jre/plugin depends on browser to cache
the Applet. There is nothing special you have to do.
Is above correct?
2>SOme of the message I had seen on usenet and sun site indicate that the people have problem opposite than me. i.e Applet is cached and they dont want that wherever I want it to be cached and it is not caching.
3> Is it true that for browser to cache the 1.2.2 Applet
(with pluguin installded on end user PC), it had to be
signed using the tools those come with JDK. Keytool
and Jarsigner etc. I tried both ways by using signed
and unsigned applet.
4> I heard that JDK1.3 plugin had additional
parameters i.e cache_option = "plugin" etc
where Applet JAR will be saved in a place other
than Browser's cache. Is it true above is not
available in JDK 1.2.2.
5> I have 'cache im memory' option checked in
Java Plugin control panel. But that did not help.
6> Is there any special way to put html tag for Applet
Jar to be cached. The Applet that needs to be cached
is already in production and html file is working fine
as such.
7>Is there any known bug with JRE 1.2.2 that will
prevent it from caching.
Any responses or pointer to responses appreciated.
TIA
Rakesh K Mittal

I am trying the same in order to implement a version control applet.
The proposal is that an applet runs previous to the main applet. It checks the JARs versions with the server and download the latest if they does not exist in the client. All the version are placed in the extensions directory of the plugin so when the main applet loads the clases it can pick them up lastest versions from the extensions directory.
It works for me. However there is some anoying bug to regard as 4215307.
However, in spite all the previous is working, I can not make it work through a proxy since Control Panel ignores when I set Browser settings or another proxy and always executes without proxy.
A caching proxy could also reduce the network traffic.
Any ideas??
([email protected])

JRE 1.4 vs. JRE 1.3

Hi out there,
We have a very complex Java Application running on JRE1.3. Cause we're using a lot of (big) JTables I thought I try running it with JRE 1.4 'cause of the wheel mouse support.
I just replaced to the runtime versions and it did work surprisingly. My first impression was quite good 'cause I could scroll with the wheel.
But then I realised all the other things that have changed:
- The font has changed completely. Much smaller and looks terrible.
- The JComboboxes are empty at startup (no item selected), in 1.3 there was always the first item selected
- The line PrinterJob printJob = PrinterJob.getPrinterJob(); causes a NullPointerException
... Probabely there are many more differences which I couldn't see in five minutes.
What's the reason for that? Do I have to change my code and adjust it to every new runtime version or are there other ways to get around it?
Has anyone had some experience with that?
Thanks
Jonas

I am not a professional programmer and I deal with Java only since 6 months. I've experienced some similar problems (I use Windows 98 SE):
1. - JBuilder 5 personal doesn't work properly with JRE 1.4.0 and SDK 1.4.0 (design modus is not working at all, also some null pointer errors) but the programm compiles with warnings. With JRE 1.4.0 and SDK 1.3.1 or SDK 1.3.0 there is no problem. With JRE 1.3.1 there are also no problems.
2.- Jext editor doesnt work properly with JRE 1.4.0. This problem is adressed in mailing list on Source Forge as bug with JRE 1.4, but it doesn't claim it's Sun's bug. The autor is reprogramming the app. to work with JRE 1.4.0.
3. - In Jython mailing list on Source Forge some people complained about Java 1.4.0, I can not remember why, and there are some other shy complains on comp.lang.java.** about other applications.
I must say again, I am not a professional programer, and I shouldn't make hard statements, but it seems that there is no guarantie that application compiled with 1.3.1 will run properly with JRE 1.4.0. I feel this is a serious issue. Imagine I buy some application, and then I have to stick with same runtime, in order for that application to run. It is easy to change SDK on my computer, but not JRE. I am also suprised that everything is so quiet in this matter.
Marijan Tadin

Multiple JREs and applets

I work in an environment that has, over the years, purchased a number of browser-based applications requiring different versions of JREs. We are now getting to the point of JREs clashing with each other.
I'm a little hesitant to believe that more recent versions of the JRE are not compatible with earlier versions of JREs, i.e. JRE 1_4_2_03 and JRE 1_4_2_05 (this is only a conceptual example).
Is it the application with these conficts, JAVA in general or both?
I feel like our environment may be missing something. We would like to be able to launch http://application1 using this JRE, 1.4.2.03 and http://application2 using another JRE, 1.4.2.05.
I aplologize for posting with such vagueness. Please direct me to a more appropriate forum if deemed appropriate.
Bart Perrier

Are those bona fide requirements, or are they just CYA requirements? They'd be the former if the application crashes with any other JRE and the latter if the designers happened to test with a particular JRE and therefore won't guarantee the application will work with anything else.
My bet would be on the latter (which would mean you don't need a large JRE collection), although it is possible that some of those applications ran into a specific bug in JRE version X which was fixed in version X.01.

NumberFormat parse() bug ? Please Help

It seems like parse() method of NumberFormat fails silently for string with a number in scientific notation such as "1.456000E+05" -- I had to use a doubleValue(0 from Double().
This very short piece illustrates it -- Can anyone please comment on any fallacies here ?
Thanks.
// Numberformat parse() fails when parsing
// string to get double value
// But Double.doubleValue() works
import java.io.*;
import java.text.*;
public class jf {
public static void main(String args[]) {
String str = "1.456000E+05";
System.out.println("Original string: str="+str);
NumberFormat nf = NumberFormat.getInstance();
try{
double val = nf.parse(str).doubleValue();
System.out.println("NumberFormat.parse() gives: val="+val);
} catch (Exception e) {;}
Double Val = new Double(str);
System.out.println("Double.doubleValue(): val="+Val.doubleValue());

Thanks, but changing to DecimalFormat ...
import java.io.*;
import java.text.*;
public class jf2 {
   public static void main(String args[]) {
      String str = "1.456000E+05"; // 145600.00 in E format
      System.out.println("Original string: str="+str);
      DecimalFormat df = new DecimalFormat();
      try{
         double val = df.parse(str,(new ParsePosition(0))).doubleValue();
         System.out.println("DecimalFormat.parse() gives: val="+val);
      } catch (Exception e) {;}
      Double Val = new Double(str);
      System.out.println("Double.doubleValue(): val="+Val.doubleValue());
}Still gave:
Original string: str=1.456000E+05
DecimalFormat.parse() gives: val=1.456
Double.doubleValue(): val=145600.0Does this indicate a bug ? jre is 1.3.1

OutOfMemory error in java.awt.image.DataBufferInt. init

We have an applet application that performs Print Preview of the images in the canvas. The images are like a network of entities (it has pictures of the entities involve (let's say Person) and how it links to other entities). We are using IE to launch the applet.
We set min heap space to 128MB, JVM max heap space to 256MB, java plugin max heap space to 256MB using the Control Panel > Java.
When the canvas width is about 54860 and height is 1644 and perform Print Preview, it thows an OutOfMemoryError in java.awt.image.DataBufferInt.<int>, hence, the Print Preview page is not shown. The complete stack trace (and logs) is as follows:
Width: 54860 H: 1644
Max heap: 254 # using Runtime.getRuntime().maxMemory()
javaplugin.maxHeapSize: 256M # using System.getProperties("javaplugin.maxHeapSize")
n page x n page : 1x1
Exception in thread "AWT-EventQueue-2" java.lang.OutOfMemoryError: Java heap space
     at java.awt.image.DataBufferInt.<init>(Unknown Source)
     at java.awt.image.Raster.createPackedRaster(Unknown Source)
     at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
     at java.awt.image.BufferedImage.<init>(Unknown Source)
     at com.azeus.gdi.chart.GDIChart.preparePreview(GDIChart.java:731)
     at com.azeus.gdi.chart.GDIChart.getPreview(GDIChart.java:893)
     at com.azeus.gdi.ui.GDIUserInterface.printPreviewOp(GDIUserInterface.java:1526)
     at com.azeus.gdi.ui.GDIUserInterface$21.actionPerformed(GDIUserInterface.java:1438)
     at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
     at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
     at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
     at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
     at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
     at java.awt.Component.processMouseEvent(Unknown Source)
     at javax.swing.JComponent.processMouseEvent(Unknown Source)
     at java.awt.Component.processEvent(Unknown Source)
     at java.awt.Container.processEvent(Unknown Source)
     at java.awt.Component.dispatchEventImpl(Unknown Source)
     at java.awt.Container.dispatchEventImpl(Unknown Source)
     at java.awt.Component.dispatchEvent(Unknown Source)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
     at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
     at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
     at java.awt.Container.dispatchEventImpl(Unknown Source)
     at java.awt.Component.dispatchEvent(Unknown Source)
     at java.awt.EventQueue.dispatchEvent(Unknown Source)
     at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
     at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
     at java.awt.EventDispatchThread.run(Unknown Source)
Drilling down the cause of the problem. The OutOfMemory occurred in the constructor of DataBufferInt when it tried to create an int array:
public DataBufferInt(int size) {
super(STABLE, TYPE_INT, size);
data = new int[size]; # this part produce out of memory error when size = width X height
bankdata = new int[1][];
bankdata[0] = data;
The OutOfMemory error occurred when size is width * height (54860 X 1644) which is 90,189,840 bytes (~86MB).
I can replicate the OutOfMemory error when initiating an int array using a test class when it uses the default max heap space but if I increase the heap space to 256MB, it cannot be replicated in the test class.
Using a smaller width and height with product not exceeding 64MB, the applet can perform Print Preview successfully.
Given this, I think the java applet is not using the value assigned in javaplugin.maxHeapSize to set the max heap space, hence, it still uses the default max heap size and throws OutOfMemory in int array when size exceeds the default max heap space which is 64MB.
For additional information, below is some of the java properties (when press S in java applet console):
browser = sun.plugin
browser.vendor = Sun Microsystems, Inc.
browser.version = 1.1
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = C:\PROGRA~1\Java\jre6\classes
java.class.version = 50.0
java.class.version.applet = true
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.6.0_17-b04
java.specification.version = 1.6
java.vendor.applet = true
java.version = 1.6.0_17
java.version.applet = true
javaplugin.maxHeapSpace = 256M
javaplugin.nodotversion = 160_17
javaplugin.version = 1.6.0_17
javaplugin.vm.options = -Xms128M -Djavaplugin.maxHeapSpace=256M -Xmx256m -Xms128M
javawebstart.version = javaws-1.6.0_17
Kindly advise if this is a bug in JRE or wrong setting. If wrong setting, please advise on the proper way to set the heap space to prevent OutOfMemory in initializing int array.
Thanks a lot.
Edited by: rei_xanther on Jun 28, 2010 12:01 AM
Edited by: rei_xanther on Jun 28, 2010 12:37 AM

rei_xanther wrote:
..But the maximum value of the int data type is 2,147,483,647. That is the maximum positive integer value that can be stored in (the 4 bytes of) a signed int, but..
..The value that I passed in the int array size is only 90,189,840...its only connection with RAM is that each int requires 4 bytes of memory to hold it.
new int[size] -- size is 90,189,840Sure. So the number of bytes required to hold those 90,189,840 ints is 360,759,360.
I assumed that one element in the int array is 1 byte. ..Your assumption is wrong. How could it be possible to store 32 bits (4 bytes) in 8 bits (1 byte)? (a)
a) Short of some clever compression algorithm applied to the data.

Java Web Start 1.6 fails to start application without Java Consol on Vista

Hi All,
I've faced with problem related to starting my application in IE 7 on Vista SP1 using Java Web Start (JRE 1.6.0_12 and 1.6.0_13). I suppose that issue appears after 11th update of JRE 1.6 since it works fine before.
There were set settings to indicate initial and maximal size of the Java heap in the JNLP file.
Application consist of 2 JAR files and they are signed with the same certificate.
When user tried to start application there is no any activity after accepting certificate. After starting application javaw.exe just disappeared from processes list without any message or error.
When I changed default setting in Java Control Panel to show Java Console, I noticed that the application began to start. But it's not a solution of the issue, since all customers cannot be required to turn on Java console.
I believe this is a bug in JRE as the application starts with Java console and doesn't without it.
When I browsed the web looking for the solution or an advice I found Release notes for 1.6.0_014 where it was said that 6u14 Java Web Start failed to launch and notifies that JARs were not signed, if an insecure Java system property was specified in a sandbox JNLP file. In spite of that 14th updated wasn't used and there was no notification I tried to start application without settings for the Java heap and it worked.
Could someone help me with advice, since the application cannot be started with default heap size settings.
Thanks in advance.
Edited by: vovanst on Jul 28, 2009 8:06 AM

Hi,
as the 6u15 just arrived and the above mentioned bug should've been fixed (though I was unable to verify through the release notes), the error is still in there.
We have no timestamped jars, neither ours nor the bouncy castle ones, all certs are valid, ours is self signed.
6u13 runs, 6u14/6u15 won't.
I followed the instructions here: http://bouncycastle.org/devmailarchive/msg10415.html to no avail.
The bcprov.jar is wrapped in its own jnlp and referred as extension from the "main" jnlp.
The interesting parts of the stack trace are these:
Caused by (via getCause): java.lang.SecurityException: JCE cannot authenticate the provider BC
     at javax.crypto.Cipher.getInstance(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
Caused by (via getCause): java.util.jar.JarException: Cannot parse https://localhost:8443/deploy/bcprov.jar
     at javax.crypto.SunJCE_c.a(DashoA13*..)
     at javax.crypto.SunJCE_b.b(DashoA13*..)
     at javax.crypto.SunJCE_b.a(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
     at javax.crypto.Cipher.getInstance(DashoA13*..)
For me it seems there's a problem with resolving the url of the bcprov.jar, which would explain the lack of a delay which normally occurs when JCE verifies the signature of the bcprov provider classes. The error pops up almost instantly.
I'm clueless what to do now. Did Sun really achieve to completely destroy JCE provider functionality in Javaws, forcing us to use an alternative implementation?
Patric

Can't parse xml file in jar file when can't connect to web server

My JNLP application throw ConnectException when trying to parse xml during web server offline.
Steps,
1. JNLP application has been launched once and all related jar and xml files are already downloaded to local cache.
2. Then I close web server to test offline launch.I launch the JNLP application using shortcut with -offline parameter.
3. However the JRE internal xml parser tries to connect to web server and report connection error as web server is down now.
My concern is the file is already in the cache, why java still try to connect URL. This error happens in JRE 1.5, but it doesn't happen in JRE 1.6. It only happens when web server is down in JRE 1.5.
I think it may be a bug of JRE, do any one can give me some hint about how to resolve?
Thanks in advance!!
I also moved the code piece to a simple web start example, following it the error and code pieces.
Error Trace in Java console,
ava.net.ConnectException: Connection refused: connect
     at java.net.PlainSocketImpl.socketConnect(Native Method)
     at java.net.PlainSocketImpl.doConnect(Unknown Source)
     at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
     at java.net.PlainSocketImpl.connect(Unknown Source)
     at java.net.Socket.connect(Unknown Source)
     at java.net.Socket.connect(Unknown Source)
     at sun.net.NetworkClient.doConnect(Unknown Source)
     at sun.net.www.http.HttpClient.openServer(Unknown Source)
     at sun.net.www.http.HttpClient.openServer(Unknown Source)
     at sun.net.www.http.HttpClient.<init>(Unknown Source)
     at sun.net.www.http.HttpClient.New(Unknown Source)
     at sun.net.www.http.HttpClient.New(Unknown Source)
     at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
     at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
     at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
     at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
     at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
     at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
     at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
     at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
     at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
     at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
     at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
     at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
     at EntXmlUtil.buildDocument(EntXmlUtil.java:57)
     at Notepad.testParseXML(Notepad.java:870)
     at Notepad.main(Notepad.java:153)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.sun.javaws.Launcher.executeApplication(Unknown Source)
     at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
     at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
     at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
     at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Notepad.java
public void testParseXML() {
     URL xmlURL=Notepad.class.getClassLoader().getResource("xml/Login.xml");
     try {
               org.w3c.dom.Document doc = EntXmlUtil.buildDocument(xmlURL);
               System.out.println("Test"+doc);
          } catch (Exception e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
EntXMLUtil.java
private static DocumentBuilderFactory dbf = null;
     static {
          dbf = DocumentBuilderFactory.newInstance();
          dbf.setNamespaceAware(true);
          dbf.setValidating(true);
          dbf.setIgnoringComments(true);
          dbf.setIgnoringElementContentWhitespace(true);
public static DocumentBuilderFactory getDocBuilderFactory() {
          return EntXmlUtil.dbf;
public static Document buildDocument(URL url, String systemId) throws Exception {
          DocumentBuilder db;
          Document doc;
          InputStream is;
          String sysId = null;
          if(systemId == null)
               sysId = url.toExternalForm();
          else
               sysId = systemId;
          db = EntXmlUtil.getDocBuilderFactory().newDocumentBuilder();
          is = url.openStream();
          doc = db.parse(is, sysId);
          is.close();
          return doc;
     }

I finally got a temperary work around for this issue, using JRE5 version lower than update 16(not include update 16).
i found Sun modify the URL which returned by XXX.class.getClassLoader().getResource("xml/Test.xml,") after update 15, previous it is related with the cache path, like C:\Users\epenwei\AppData\LocalLow\Sun\Java\Deployment\cache\javaws\http\Dlocalhost\P80\DMEntriView\DMapp\AMNotepad.jar!/xml/Test.xml, but after it changes to network path, like http://localhost/Notepad/app/notepad.jar!/xml/Test.xml. However, the latter address doesn't work in Sun's own class com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity if offline.It tried to create new URL then connect to web server. So exception is thrown since web server is down.
if (reader == null) {
stream = xmlInputSource.getByteStream();
if(stream != null && encoding != null)
declaredEncoding = true;
if (stream == null) {
URL location = new URL(expandedSystemId);
URLConnection connect = location.openConnection();
if (connect instanceof HttpURLConnection) {
     setHttpProperties(connect,xmlInputSource);
I am not sure whether it is a Java new bug since I only read the codes and didn't debug Sun code. But I am very curious that I have already specify <j2se version="1.5.0_12" href="http://java.sun.com/products/autodl/j2se" /> to specify update 12 for my jws application. And I also see the Java console display like following
Java Web Start 1.5.0_18
Using JRE version 1.5.0_12 Java HotSpot(TM) Client VM
Why java still uses my latest jre lib to run my application?
Edited by: wei000 on May 22, 2009 5:32 AM

StackOverflowError printStackTrace not working?

Hi,
I need to dump out the stack information when StackOverflowError is detected for debugging purpose.
However, I realized that JRE 14.2_05 does not provide the stack trace information anymore.
It works with JRE 14.1_02. Is this a bug in JRE 1.4.2? any work around to enable the printStackTrace?
The test sample code is as below
public void func(){
func();
When I use JRE 1.4.1 it will print out the stack and pin point where the problem is. However with JRE 1.4.2 only StackOverflowError is output. No stack information is provided anymore. It will be very hard to figure out where the problem code is.
Thanks,

This bug was introduced in 1.4.2 and fixed in 1.5. Unfortunately Sun does not seem to have the manpower to fix things in 1.4.2, all effort is going into 1.5.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4872096
any work around to enable the printStackTrace?The stacktrace is swallowed if native code blows the stack. You could disable compilation to native code altogether with "-Xint" while you're debugging.

Bug in JRE 1.4.0

Similar Messages

Maybe you are looking for