Had a nice IM chat with Bob V about classloaders and ext/

The summary is that jre/lib/ext was not really used much before JFX came along, and that the JDK folks did not like the idea assuming the jars in there were trusted/pre-validated.

I suggested that there are really 3 classes of jars - core, bundled extras and 3rd party, and that bundled extras like JFX should be trusted/pre-validated before we package then in the JDK bundle. But short of a minor miracle happening in JDK8, we pretty much will not be able to count on a change until JDK9+jigsaw (which can prevalidate during module install), or possibly during the jrecreate for embedded.

Bob walked down the hall and talked to Karen K. though:

He said we should try with -Xverify:none and if we get the "bootclass loader performance" then we know that is the beast to address.

In that case they suggest that the "solution" to this problem is to include a custom class loader with JFX. It seems this has been done before for at least one of the other ext jars, and certainly for webstart. This custom classloader would fix the defineClass() call to disable verification. We would then need to jack in this classloader so that it is used when we have the right perms to do so (and for the right classes only).

We would also want to figure out how to pre-validate the classes we build. (Not sure if javac would ever not generate correct bytecode so maybe this is not needed).

Sounds from the discussions I have read that this would be worth the effort for embedded arm, and perhaps for desktop too.