Initialization of ImageIO always loads of jpeg.dll (even if JPEGs are not processed).
This is because JPEGImageReader/WriterSPI performs explicit library loading.

It seems that the only reason to do this is to avoid throwing exceptions later on if 
library will not load sucessfully. 

On other hand if JPEG plugin will not be used then library was loaded without 
real need (and with negative impact on footprint and startup).
Please note that JPEGImageReader/Writer, i.e. classes which actually have native methods, will call LoadLibrary anyway.

Sample test:

--------
import javax.imageio.*;
import java.awt.image.*;
import java.io.*;

public class ImageIOTest {
   public static void main(String a[]) throws Exception {
      BufferedImage bi = ImageIO.read(new File("new.png"));
   }
}
----------

To run it use any non JPEG image and procmon tool to monitor disk file access.
Note that jpeg.dll was read.
Posted Date : 2007-11-19 13:41:09.0

Further analysis shows that com.sun.imageio.plugins.jpeg.JPEG has explicit dependency on 
ColorSpace that causes loading of several color profiles and initialization of CMM.

Note that some of public constants from this class are required for registration of JPEGImageReader/Writer. This means that CMM is initialized and loaded if ImageIO is initialized.

Clearly this extra work can be avoided.
Posted Date : 2007-11-19 14:07:02.0

N/A

It seems the simplest fix is to remove static blocks from both JPEGImageReaderSpi and JPEGImageWriterSpi.
Posted Date : 2007-11-19 13:41:09.0

For CMM initialization part we can consider creation of inner public static class in the JPEG. 

ColorSpace logic constants and static initialization logic can be moved to this inner class.
Alternatively, public constants needed for registration can be moved to this inner class.

Either way, we need to separate initialization of these public string constants and initialization of fields related to CMM.
Posted Date : 2007-11-19 14:07:02.0