Java 1.6 Heisenbug involving startsWith

[Roedy Green]

I have an Applet that works fine in earlier JDKs but is failing in
1.6.

Code like this

public class StartsWithBug
{
/**
* test startsWith optimisation bug
*
* @param args a string possibly starting with snippets/
*/
public static void main ( String[] args )
{
//
String urlString = args[0];
System.out.println( urlString );

if ( !urlString.startsWith( "snippets/" ) )
{
urlString = "snippets/" + urlString;
}
System.out.println( urlString );
}
}


is failling to prepend the "snippets/" string.

Of coruse it works fine in this isolated snippet. I gather the hotspot
optimiser screws it up in some contexts.

 

[hiwa]

Of coruse it works fine in this isolated snippet.
Could you reproduce the failing condition?

 

[Roedy Green]

Could you reproduce the failing condition?

I can't get it to fail myself. I have prepared a new version to help
track the problem, but for some reason Mickey, who can get it to fail,
has been getting an old version.

 

[Mickey Segal]

I can't get it to fail myself. I have prepared a new version to help
track the problem, but for some reason Mickey, who can get it to fail,
has been getting an old version.

On a "virgin" computer that had never loaded the applet I don't get the
Exceptions. However, on the original computer, despite clearing the browser
caches in Internet Explorer and Firefox and setting IE to reload the new
version of a page each time I still get the error messages, presumably
meaning I'm getting the old version.

I don't think this is due to some different Java setting on the two
computers because I had removed Java and installed the new Java 1.6 weekly
build yesterday on each machine.

Is there some separate way of clearing a Java-specific cache? I don't see
such a command in the Sun Java Console.

 

[Roedy Green]

On a "virgin" computer that had never loaded the applet I don't get the
Exceptions. However, on the original computer, despite clearing the browser
caches in Internet Explorer and Firefox and setting IE to reload the new
version of a page each time I still get the error messages, presumably
meaning I'm getting the old version.

I don't think this is due to some different Java setting on the two
computers because I had removed Java and installed the new Java 1.6 weekly
build yesterday on each machine.

Is there some separate way of clearing a Java-specific cache? I don't see
such a command in the Sun Java Console.

Try going into to Java console in control panel | settings and poking
around.

the old version still should not be getting exceptions. It is just the
new version dumps more information and does more internal checks to
help me track down why they are happening.

You might want to use Wassup to verify you are indeed using 1.6 on
both. See http://mindprod.com/jgloss/wassup.html

 

[Mickey Segal]

Try going into to Java console in control panel | settings and poking
around.

In the Java Control Panel under the General tab there is a Temporary
Internet Files section. This caches applets in a way that survives
uninstalling Java and re-installing.

When I delete the material on the original computer the 4 applets still do
not work.

However, I get different set of error messages so it looks like we are
making some progress. I still can't explain why it doesn't work on the
original machine but it does work on the virgin machine. There seem to be
no different settings on the Java Control Panels of the original and virgin
computers.

 

[Roedy Green]

However, I get different set of error messages so it looks like we are
making some progress.

You have been emailing me data too. It looks like what was happening
in you were originally accessing an very old copy of JDisplay in
cache. Now you have nuked that and it can't seem to find the new one.

I can see it fine with JDK 1.5 from my website.

Is suspect the problem may be related to the use of

<applet archive="../applets/jdisplay.jar"

I suspect JDK 1.6 has lost the ability to support ../

I would think this was the browser's problem, converting hat to an
absolute URL. At least the browser has to inform Java of the url of
the current page so it can concoct an absolute URL for the jar. The
server knows nothing about ../

Then again maybe the server does support ../ Perhaps it sometimes can
figure out from a referring page URL.

I have to figure out a way to get one of my browsers using Java 1.6 so
I can packet sniff to see what the heck is going on.

If this bug in released on the world, it could cause havoc. I would
like it nailed prior to release.

 

[Mickey Segal]

If this bug in released on the world, it could cause havoc. I
would like it nailed prior to release.

What makes this hard to figure out is that a virgin computer with JRE 1.6
works fine, but the other does not. This sounds like either some cache we
have not nailed, affecting both browsers, or some setting we have not found
(but all the Java Control Panel settings are the same).

It would be interesting to know whether other computers with JRE 1.6 have
problems, but clearly some work fine.

Regardless of the cause it would be good to know what is going on so these
problems don't occur for our users.

 

[Roedy Green]

It would be interesting to know whether other computers with JRE 1.6 have
problems, but clearly some work fine.

you might compare the policy files on both. See
http://mindprod.com/jgloss/policy.html

 

[Mickey Segal]

you might compare the policy files on both. See
http://mindprod.com/jgloss/policy.html

I looked at http://mindprod.com/jgloss/policyfile.html and found that the
policy files on both files were the same, the default versions created when
I installed the new Java 1.6 build on 27 January. While looking around I
noticed that on the computer that was virgin to
http://mindprod.com/jgloss/properties.html there was a folder for JRE 1.5
even though it was uninstalled. It had only one file, QTJava.zip, buried
deep in a nest of folders. This got me wondering whether the supposedly
virgin computer was showing signs of experience with JRE 1.5.

I then uninstalled JRE 1.6 and JDK 1.6 from both computers, deleted the JRE
1.5 folder from the supposedly virgin computer, reinstalled JDK and JRE 1.6
from http://download.java.net/jdk6/binaries/, and now I get the 4 applets
failing on both machines. It is not clear how the JRE 1.5 folder caused a
difference, but it seems that was the case.

The good part of this experiment is that we now have what seems to be a
reproducible way of eliciting the problem. Following the procedure above
should demonstrate the problem.

The bad part of this experiment is that it shows how hard it is to know the
state of Java on a user's computer.

 

[Roedy Green]

The bad part of this experiment is that it shows how hard it is to know the
state of Java on a user's computer.

Ok what about OTHER applets? Is it just JDisplay that fails?

What about say
http://mindprod.com/applets/converter.html
http://mindprod.com/jgloss/mime.html
http://mindprod.com/applets/wassup.html
one of the Sun test applet you can get to via
http://mindprod.com/jgloss/swing.html

 

[Mickey Segal]

Ok what about OTHER applets? Is it just JDisplay that fails?

I haven't looked at the pages in detail to see which parts use applets, but
here is what fails on each page:

On http://mindprod.com/jgloss/properties.html the 4 applets with the
following text before them fail and all other content works:
1. For Applets, there is a similar PARAM mechanism that generates a
properties table.
2. Look at any *.properties files file to see an example. It will look
something like this example
3. You could access a property in a sample.properties file like this:
4. Beware, unused properties will return null, not the default.

What about say
http://mindprod.com/applets/converter.html

The top left applet fails.

http://mindprod.com/jgloss/mime.html

The top applet fails.

http://mindprod.com/applets/wassup.html

The applet fails.

one of the Sun test applet you can get to via
http://mindprod.com/jgloss/swing.html

This page works fine.

 

[Roedy Green]

This page works fine.

no I meant something like

Test your JRE browser's ability to run Applets in general by
running Sun's

http://java.sun.com/applets/archive/beta/LED/index.html

LED Sign demo.

 

[Roedy Green]

The top left applet fails.

So NO Applet at all works on my site. What is the console saying, same
thing about not being able to find the class?

I wonder if Sun has changed its dot class convention. On their site
they used .class in all the <applet tags, so so did I.

I will take the .class off one and see if that lets it work.

see if http://mindprod.com/jgloss/mime.html works.

 

[Mickey Segal]

no I meant something like

Test your JRE browser's ability to run Applets in general by
running Sun's

http://java.sun.com/applets/archive/beta/LED/index.html

LED Sign demo.

This works fine, as do many other applets I seen. The only failures I've
seen are the ones I indicated on the mindprod.com site.