CODEWITHSUNDEEP
javanetbeansjarsign
tejoe
tejoe

Reputation: 171

Netbeans Classloader slow on resource loading with signed jar

I am developing a rich client application, now I migrated it to run within the NetBeans RCP. So far everything works smoothly.

Recently I build the first release and saw, that the startup took almost a minute instead of 10 seconds. When starting from within the IDE everything is as fast as before.

After profiling everything I saw, that loading of several thousand XML files (configuration for JPA) takes 10-20 times more then before. I added some printlns and saw, that the loading took about 50ms instead of <1ms like before per File. I figured out, that the problem only occurs with signed jar files. When I start the exact same application with unsigned jar, it is back to 10 seconds. When I start the application without NetBeans integration with signed jars it also only takes 10 seconds.

From the code point the loading of that resources has not changed at all. At runtime the difference is most likely in classloading. NetBeans offers a class loader hierachy. I tried to set any of these as context class loader, but it makes no difference in performance. I also checked with a memory profiler, the class of classloader used is the same with or without NetBeans integration

I tried profiling but this is a mess. The profiler(JProfiler) does not show the stack of classloading, only shows, that resources have been loaded. Even the "-verbose option" of java only shows, that resources have been loaded.

Without knowing the exact classloading algorithm, I assume it consists of the following parts. But those parts should be the same for my signed application, no matter with or without NetBeans integration.

  • finding the resource in the classpath
  • loading the resource
  • verifiing
    • test checksum
    • validate certificate with CA (maybe http request, but only once (hopefully))

Do you have any idea, of what might be the reason for that behavior.

integration Information:

The old application used one JFrame and multiple JInternalFrames to handle multiple windows. When we start with NetBeans, it graps the old JFrame and instead of showing our content in a JInternalFrame, we show it in a dynamically created Top Components. The main reason for integration, was the window managing in NetBeans (Docking, Floating...).

Upvotes: 0

Views: 390

Answers (1)

tejoe
tejoe

Reputation: 171

I found it myself. Here is the answer, if somebody else ever interested in it.

On startup NetBeans calls the following method, to disable all caching. This leads to reloading of jar files on each resource loading. For signed jars, this includes also a complete verification of the jar.

java.net.URLConnection.setDefaultUseCaches(boolean)

I reenabled this, for the period of JPA configuration and it works fine. I am not exactly sure, why NetBeans does it, but I guess it is about online updates of modules.

Upvotes: 1

Related Questions