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.
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.