JDK-4416056 : Application requesting JRE 1.4.0-beta could not be launched (B58)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.0,1.0.1,1.3.0,1.3.1,1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98,windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2001-02-16
  • Updated: 2001-04-12
  • Resolved: 2001-04-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.3.1 betaFixed 1.4.0Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Happens on all Windows platform.

Reproduce:
- Install JWS 1.0.1, in preference panel, make sure JRE 1.3.1-beta (build 16)
  is available.

- Visit test case home page:
  http://comanche.eng.sun.com/jawstest/ladybird/

  Launch that hello jaws test case. The JWS will hung at the step of
  'starting application'.

Actually, JWS 1.0 also hung at this step. It might be some change in JRE 1.3.1.

yu.wang@eng 2001-02-15

Added a new customer call for JWS 1.0. Ladybird is considering bundling
JWS 1.0, need developer's review if this is possible.


yu.wang@eng 2001-02-16

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic ladybird-rc1 merlin-beta FIXED IN: ladybird-rc1 merlin-beta INTEGRATED IN: ladybird-beta merlin-beta VERIFIED IN: ladybird-beta merlin-beta
14-06-2004

EVALUATION charlie.lai@Eng 2001-02-28 this bug is related to 4359123. java.io.File.toURL was modified to perform character encoding. existing code that already calls File.toURL must first decode the file path before reconstructing a new File to guarantee you don't end up with a double-encoded path. sun.security.provider.PolicyFile calls File.toURL without decoding the file path first, resulting in a double-encoding. charlie.lai@Eng 2001-03-20 there's a bit more to the story. com.sun.javaws.security.JNLPClassPath has the exact same "problem" as sun.security.provider.PolicyFile at line 479 inside the method: private JarFile getJarFile(URL url) throws IOException we need to decode the path here before constructing a new File. to call the new 'decode' method in sun.net.www.ParseUtil we'd need to update the javaws makefiles to use jdk1.3.1 instead of jdk1.2.2. while tracing this problem i also came across a NullPointerException in some debugging code in AppPolicy at 170 DiskCacheEntry dce = InstallCache.getDiskCache().getCacheEntryFromFile(f);
11-06-2004