Slashdot Mirror


Initializing all Java classes at Start-Up

Jean-Marie Dautelle writes "Java classes are initialized at first-use only which can introduce significant runtime delays detrimental to real-time or games applications (for which accurate scheduling is often required). To solve this problem, the latest open-source Javolution library supports initialization of all Java classes at start-up (e.g. javolution.lang.ClassInitializer.initializeAll(); // Initialize runtime classes (rt.jar) and all classes in classpath). Note: Runtime class initialization (rt.jar) takes typically a few seconds and about 3 Mbytes of memory."

4 of 56 comments (clear)

  1. tumbleweed? by Cronky · · Score: 4, Funny

    system.tumbleWeed.initialise() ?

  2. Very, very rarely a good idea by /ASCII · · Score: 4, Interesting
    There are two reasons why lazy initialization is almost always the better solution:
    • Not all classes are used. Why pay a memory and performance penalty for having e.g. the Java2d API installed if your application never uses it?
    • Startup time will suffer. A 3 second startup penalty for only the bare minimum runtime, and probably much more for any non-trivial application is a huge deal.

    The advantage of doing eager initialization is predictability, and in the case where almost all classes get initialized sooner or later (which would be very rare considering the size of the Java API) a slight performance increase.

    Maybe some kinds of games would benefit from this, but almost all other applications would benefit from more lazy initialization, not less.
    --
    Try out fish, the friendly interactive shell.
  3. Shameless Plug or Valid Selfpromotion? by dorkygeek · · Score: 5, Interesting

    Let's see. Submitter of story: Jean-Marie Dautelle. Javolution project owner: Jean-Marie Dautelle.

    --
    Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
  4. Re:Benefits for anything other than games? by breadbot · · Score: 4, Interesting

    Sun has been talking about shared VMs for a while now -- I can't remember if it's scheduled for version 6 or 7 -- the object space would be partitioned among the running Java "processes", but only one JVM would be necessary. It would improve startup times, memory consumption, etc. They could all share one instance of rt.jar, for example, assuming it was process-safe (it may not be now, but fixing it would be something Sun would have to do for the actual release). I don't see it listed in the Java 6 (Mustang) notes (for example here), so I would guess that it's slated for versin 7 (Dolphin).