The Batik framework uses Sun's proprietary, non-standard image codecs. This was already reported to Sun to be problematic [1] and, according to the report, support for the classes will be dropped in JDK 7 [2]: the new Java version, although apparently without an official release schedule yet, may occur somewhere in second semester 2009 [3]. Feasibility to fix this issue was somehow pending on the drop of Java 1.3 support, as the Java Image I/O API was only introduced in Java 1.4 [1]. The Java 1.3 drop was made in revision 666001 (Batik version 1.8). Using these classes fires lots of annoying warnings ("warning: com.sun.image.codec.[*] is Sun proprietary API and may be removed in a future release") while compiling - apparently, when using JDK 1.5+. My initial proposal was to disable the warnings in the meantime, using @SuppressWarnings [4], but it didn't help [5]. The main advantage I see in this is (potentially) achieving compatibility with more open Java implementations such as IcedTea, GNU Classpath (found a related mailing list thread [6]) and Apache Harmony. Nevertheless, this is quite a bit speculative as I'm not familiar enough with the Batik framework nor with those Java implementations to assure that this is the only code portion blocking full compatibility. Disclaimer: this report was created without a deep analysis of the work involved in this task - the main purpose was to create a placeholder for possible interested to subscribe to (through the "CC" field of the report), gather patches, stimulate further investigation, etc.. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962 [2] https://jdk7.dev.java.net/ [3] http://knol.google.com/k/alex-miller/java-se-7/1f092vcri65lh/2#Planning [4] http://java.sun.com/javase/6/docs/api/java/lang/SuppressWarnings.html [5] http://forums.java.net/jive/message.jspa?messageID=158989 [6] http://www.nabble.com/batik-rasterizer.jar-(cant-convert-jpg-from-svg)-to13948656.html
See also: http://wiki.apache.org/xmlgraphics/GnuClasspathCompatibility Preparations for that are pretty much finished already. If anyone can confirm that the ImageIO replacements (which are already in place, but apparently disabled) for reading and writing images are working correctly (especially the finer aspects of PNG), the org.apache.batik.ext.awt.image.codec.jpeg can simply be removed (along with the respective entries in the META-INF/services files). I wish Batik would also finally start using XML Graphics Commons and among other things switch to the ImageWriter there and removing the local one. The duplication of code has been long-standing.
(In reply to comment #1) > See also: http://wiki.apache.org/xmlgraphics/GnuClasspathCompatibility Given that bug 38183 was already fixed for quite some time, exactly what is keeping this from being fixed also? (The following, perhaps?) > Preparations for that are pretty much finished already. If anyone can confirm > that the ImageIO replacements (which are already in place, but apparently > disabled) for reading and writing images are working correctly (especially the > finer aspects of PNG), the org.apache.batik.ext.awt.image.codec.jpeg can simply > be removed (along with the respective entries in the META-INF/services files). Is there a procedure for enabling and testing these classes for correctness? One could have a look at this, if there were instructions on how to... :-)
(In reply to comment #2) > Is there a procedure for enabling and testing these classes for correctness? > One could have a look at this, if there were instructions on how to... :-) This is basically a reply to self... Bug 38183 comment #7 states that: > So the code is in to switch the I/O all you need to do is > muck with the services file. So this is basically in: http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/resources/META-INF/services/org.apache.batik.ext.awt.image.spi.RegistryEntry?view=markup (One only needs to uncommented the lines with "imageio" and comment the "sun.image" ones.) Should this be marked as a dup. of 38183 or should we leave this one for tracking progress on the "imageio" testing? (I'd vote for the latter.)
*** Bug 49898 has been marked as a duplicate of this bug. ***
Definitely we should make this issue block the 1.8 release (see bug 50045). It's a long standing issue which causes the framework to be non-portable among Java implementations. Also, it's breaking GUMP automated builds (which messages are lately "haunting" the batik-dev mailing list). Increasing importance in the hope of gathering more effort around this. :-)
*** Bug 50341 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > > So the code is in to switch the I/O all you need to do is > > muck with the services file. [...] > (One only needs to uncommented the lines with "imageio" and comment the > "sun.image" ones.) Done. Added some documentation there reflecting the classes are deprecated and reordered and separated the entries so one can more easily figure out what to comment/uncomment when desired. This issue became quite more tricky since the introduction of JDK 7, where the Sun codecs have been "retired" (they are available in run-time although the "classes are not located when compiling"): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962 This was also reflected in the JDK 7 release notes (see "The Non-standard com.sun.image.jpeg.codec Package is Retired"): http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities This fact has already confused users and has been brought in the mailing list: http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201201.mbox/%3CCAJTzQMBqN9b9GhRwL8zHJ5M1ehFxv80-ZXyBntsyhCtP7hzCFA%40mail.gmail.com%3E I've also modified build.xml to accommodate for this tricky behavior: the classes will still be compiled in JDK 6 and previous Sun JDK versions, although the services file are now targeting the Image I/O classes by default. Fixed in r1366666.