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.

Bug 247795

Summary: Packages do not provide Implementation Vendor
Product: platform Reporter: Tomas Zezula <tzezula>
Component: Module SystemAssignee: Tomas Hurka <thurka>
Status: REOPENED ---    
Severity: normal CC: jtulach, marcop, mentlicher, mmirilovic
Priority: P3    
Version: 8.1   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 247860    

Description Tomas Zezula 2014-10-08 11:22:37 UTC
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
Comment 1 Tomas Zezula 2014-10-08 11:24:08 UTC
Fixed jet-main b82496bc1169
Comment 2 Quality Engineering 2014-10-18 05:10:36 UTC
Integrated into 'main-silver', will be available in build *201410180001* on (upload may still be in progress)

User: Tomas Zezula <>
Log: #247795:Packages do not provide Implementation Vendor
Comment 3 Jaroslav Tulach 2014-10-20 15:23:27 UTC
I believe the fix is not correct.
build fails on org.netbeans.core.startup.layers.CachingPreventsFileTouchesTest.testCachesDontUseAbsolutePaths
which reports that
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.
Comment 4 Tomas Zezula 2014-10-20 16:03:07 UTC
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!/
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 :-)
Comment 5 Tomas Zezula 2014-10-20 16:12:24 UTC
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.
Comment 6 Jaroslav Tulach 2014-10-21 07:44:11 UTC
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:, so things should be OK soon.
Comment 7 Tomas Zezula 2014-10-21 07:58:35 UTC
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/"
Comment 8 Tomas Zezula 2014-10-21 14:38:23 UTC
Reopen based on previous comment, the %xx encoding.
Comment 9 Tomas Zezula 2014-10-21 14:40:10 UTC
*** Bug 248072 has been marked as a duplicate of this bug. ***
Comment 10 Quality Engineering 2014-10-29 11:42:35 UTC
Integrated into 'main-silver', will be available in build *201410290913* on (upload may still be in progress)

User: Jaroslav Tulach <>
Log: Additional fix for #247795: Remove 'jar:file:' prefix.
Comment 11 marcop 2014-12-16 08:05:00 UTC
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?
Comment 12 Tomas Hurka 2015-02-24 15:13:46 UTC
This issue is till not fully fixed. I twill not be part of 802 patch. Removing 802patch1-candidate.