Andreas Sewe <sewe@st.informatik.tu-darmstadt.de> wrote on 05/01/2012 01:34:02 PM:
> However, this was prior Jikes RVM supporting more than one class
> library, so such a direct compile-time dependency on GNU Classpath
> classes, even when the respective class is part of
> libraryInterface/GNUClasspath, may be undesirable, if only because it
> would confuse Eclipse when using the Harmony (or maybe OpenJDK) class
> library instead.

>

We usually deal with this by having multiple implementations of the "same" class, one in each of the libraryInterface sub directories.  The build then gets configured to pick up one or the other of them.

>
> Now, what would be appealing to me is the following in
> VMClassLoadingMXBeanImpl:
>
>   static {
>     INSTANCE = new VMClassLoadingMXBeanImpl();
>     Callbacks.addClassLoadedMonitor(INSTANCE);
>   }
>
> This way, VM.finishBooting() need only guarantee that the
> VMClassLoadingMXBeanImpl is initialized. However, predicting the exact
> monent of initialization is hard in Jikes RVM, as the class in question
> may end up in the bootimage, so maybe this is not the best solution.
>
> So, what's the preferred pattern for this kind of listener registration
> in Jikes RVM? (I'd rather not add yet another ad-hoc solution.)
>

For code where we want to carefully control when objects are created we have tended to avoid using static initializers and instead have "init" and "boot" methods on the class that are called during BootImageWriting and VM booting respectively.  Not always the most convenient idiom, but it is at least a pattern that has been used in a number of places in Jikes RVM.

--dave