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 31676 - jh-1.1.3.jar is signed - causes startup time regression
Summary: jh-1.1.3.jar is signed - causes startup time regression
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Help System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: PERFORMANCE
Depends on: 32303
Blocks:
  Show dependency tree
 
Reported: 2003-03-05 08:22 UTC by Petr Nejedly
Modified: 2008-12-22 17:55 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Don't verify jars from our code (3.61 KB, patch)
2003-03-06 16:02 UTC, Petr Nejedly
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Nejedly 2003-03-05 08:22:24 UTC
Signed jars need to be verified and also fetches 
all the signature verification classes to memory,
which significantly hurts startup performance.
Please repackage the jh-1.1.3.jar to not
contain the signature.
Comment 1 Petr Nejedly 2003-03-05 08:23:24 UTC
Should be done also for release35
Comment 2 _ tboudreau 2003-03-05 14:40:58 UTC
Transferring per Jesse's request
Comment 3 Jesse Glick 2003-03-05 17:14:28 UTC
Core is supposed to use JarFile(File,false) constructor consistently.
I thought it did already - apparently not.
Comment 4 Petr Nejedly 2003-03-06 11:44:47 UTC
Not enough!
We will keep running to the brick wall again and again as long
as there is a single jar: URL.
The JarURLHandler will kindly verify the jar for you.
sun.net.www.protocol.jar.URLJarFile (ex JarFile) constructor just
calls  super(ParseUtil.decode(url.getFile()));
which in turn calls JarFile(file, true, OPEN_READ)
and you can't teach it otherwise.

So in short term I'm for repackaging JH, in long term
get rid of the magic introduced by using jar: URLs.

Comment 5 Jesse Glick 2003-03-06 12:28:01 UTC
All right. In fact I really doubt that any jar: URL from jh.jar is
constructed during startup. However it is likely one would be created
during showing help, and causing excess loading/time there is not
desirable either.
Comment 6 Petr Nejedly 2003-03-06 16:02:31 UTC
Created attachment 9295 [details]
Don't verify jars from our code
Comment 7 Petr Nejedly 2003-03-06 16:04:53 UTC
OK, the above patch ensures that the jars are not verified
by our code. It removes the mentioned startup time regresstion.
You're right that the time to verify the JH jar is then shifted
to the first usage of the JavaHelp.
Comment 8 Jesse Glick 2003-03-11 19:08:29 UTC
committed   * Up-To-Date  1.9        
core/bootstrap/src/org/netbeans/Main.java
committed   * Up-To-Date  1.47       
core/src/org/netbeans/core/modules/Module.java
Comment 9 Jesse Glick 2003-03-11 21:09:03 UTC
Merged.

committed   * Up-To-Date  1.8.2.1    
core/bootstrap/src/org/netbeans/Main.java
committed   * Up-To-Date  1.46.2.1   
core/src/org/netbeans/core/modules/Module.java
Comment 10 Petr Nejedly 2003-03-25 10:36:52 UTC
Still not enough.
On Solaris, due to fix of issue 22455, the jh.jar is prepended
to the bootclasspath, which means its manifest is parsed during
the startup using jar:file: URL.

Moreover, the workaround from #22455 is active even if I use different
JDK which don't link the jh library.

Part of the extended startup log:
          @3967 - ModuleSystem.loadBootModules started
            @3980 - got all manifests dT=13
            @5075 - processed
jar:file:/a/studio5_se/modules/autoload/ext/jh-1.1.3.jar!/META-INF/MANIFEST.MF
dT=1095
            @5079 - processed
jar:file:/a/studio5_se/lib/ext/boot.jar!/META-INF/MANIFEST.MF dT=4
            @5081 - processed
jar:file:/a/studio5_se/lib/ext/cmd.jar!/META-INF/MANIFEST.MF dT=2
  
Comment 11 Jesse Glick 2003-03-25 14:58:03 UTC
Leave as a separate item.
Comment 12 Marian Mirilovic 2004-03-14 10:56:50 UTC
verified in NB3.6