This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The j.l.Package created by the NetBeans module ClassLoader does not provide implementationVendor, implementationVersion, etc. These package attars should be loaded from Implementation-Vendor, Implementation-Version attars in Manifest. This regression causes the Puzzle-Gis platform application to fail. The Puzzle-Gis uses jai-imange-core which requires j.l.Package implementationVendor, see https://svn.java.net/svn/jai-imageio-core~svn/trunk/src/share/classes/com/sun/media/imageioimpl/common/PackageUtil.java.
Fixed jet-main b82496bc1169
Integrated into 'main-silver', will be available in build *201410180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/b82496bc1169 User: Tomas Zezula <tzezula@netbeans.org> Log: #247795:Packages do not provide Implementation Vendor
I believe the fix is not correct. http://deadlock.netbeans.org/job/ergonomics/5267/ build fails on org.netbeans.core.startup.layers.CachingPreventsFileTouchesTest.testCachesDontUseAbsolutePaths which reports that userdir0/var/cache/package-attrs.dat file contains absolute path to a JAR. It is JNA JAR file, but there used to be one all the time, so I suspect the change in handling packages to be the real cause.
I doubt that the patch is incorrect. It just enables package attributes to be written and encodes the missing attires to single char strings 0x0000. The problem is in the untouched code: PackageAttrsCache.findImpl:111 which makes the key of the cache an URL like jar:file:///foo!/javax.foo using src.toExternalForm() however the Stamps.testWritePath cannot work with URLs just paths -> it stores the absolute path. So it's not a problem of the fix but 3rd issue in the PackageAttrsCache :-)
You probably need something like this: @@ -108,7 +111,14 @@ } final String[] findImpl(URL src, Manifest man, String path) { - String key = src.toExternalForm() + "!/" + path; + String fp; + try { + fp = new File(src.toURI()).getPath(); + } catch (IllegalArgumentException | URISyntaxException e) { + //Todo: better recovery needed unescape %xx chars + fp = src.getPath(); + } + String key = fp + "!/" + path; String[] arr; if (cache instanceof HashMap) { arr = extractFromManifest(man, path); But it's question how the new File(src.toURI()) affects performance.
Sure, it an existing error revealed by your fix. It is just surprising it did not get caught when running tests of the o.n.bootstrap module. Anyway I think I have a fix: http://hg.netbeans.org/ergonomics/rev/e77a157761f0, so things should be OK soon.
I think there is no test testing the absolute paths in the o.n.bootstrap module. I believe that the fix is not correct, the problem is that the URL may contain encoded special characters like %20. So the URL.toExternalForm().substring(9) for "jar:file:/Users/Tomas%20Zezula/nb/ide/modules/foo.jar" is "/Users/Tomas%20Zezula/nb/ide/modules/foo.jar" which does not start with "/Users/Tomas Zezula/nb/ide/"
Reopen based on previous comment, the %xx encoding.
*** Bug 248072 has been marked as a duplicate of this bug. ***
Integrated into 'main-silver', will be available in build *201410290913* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e77a157761f0 User: Jaroslav Tulach <jtulach@netbeans.org> Log: Additional fix for #247795: Remove 'jar:file:' prefix.
We have the same problem as Puzzle-Gis. For our project this issue is a blocker. It is good to see that it is already fixed but unfortunately it is not included in the RELEASE802. Can we expect that this is included in RELEASE803? If yes, when will this be published?
This issue is till not fully fixed. I twill not be part of 802 patch. Removing 802patch1-candidate.