As discussed and promised some time ago, I finally managed to get everything together and submit a patch to remove Batik's mandatory dependency on Sun-private classes in its codec classes. This patch introduces adapter classes to decouple the image decoding and encoding from the actual codec library used. The "internal codecs" as I called them are moved to a new source directory (sources-internal-codec), so their compilation can be made optional in an IDE and in the Ant build. In addition to adapter classes handling image loading and saving using these internal codecs, I've written implementations that use the Image I/O API that is available under JDK 1.4 (and later) and in GNU Classpath. Please note: So far I have not done any tests with GNU Classpath (GCJ, IKVM or whatever) for Batik. A few implementation notes: - I've not reimplemented every single feature in the various image transcoders for the Image I/O API as is available for the internal codecs. Examples are Gamma/Chromaticity handling and background color in PNG. - I've had endless loops in ImageIO.getImageWritersByMIMEType() and IIOMetadata.mergeTree() while trying to write TIFF images through the Image I/O API with the JAI Image I/O Tools in the classpath. (I think TIFF is only supported by Image I/O under a Sun JDK if the JAI Image I/O Tools are available) That means that there are probably a few bugs hidden in there. I didn't go too deep in order not to lose too much time. - I've experienced problems handling metadata and encoding parameters when writing JPEG images through Image I/O. The current code works for most use cases, though. - I created a new batik-codec.jar in the Ant build that contains the internal codec classes. I hope I got the dependencies right there. In addition to the above topic, the patch contains the following changes: - The TIFFTranscoder now supports specifying the compression method through a Transcoding hint (type String). - I've changed the code that prepares an XML parser to use JAXP in order to remove the mandatory dependency on Apache Xerces. I hope I did this the right way. Before applying the patch it is ESSENTIAL to do local SVN copy operations (versioned copies) for the following files: sources/org/apache/batik/ext/awt/image/spi/*RegistryEntry.java (--> sources-internal-codec) sources/org/apache/batik/ext/awt/image/codec/**/* (--> sources-internal-codec) resources/org/apache/batik/ext/awt/image/codec/properties (--> sources-internal-codec) Please see the status-log.txt file in the ZIP I'll attach. It shows how exactly I moved these classes (Watch for the "+"). Attaching the patch in a minute...
Created attachment 17366 [details] A ZIP containing the patch and the output of a "svn status" on my local working copy
Forgot to mention something: You can forcibly disable the compilation of the Sun-dependant internal codecs if you create a file (called "build-local.properties") in the same directory as build.xml and add the following line: sun-codecs.disabled=true You can also use this file to enable debug information in the compiled classes without having to change build.xml if you add this line to the above file: debug=true
Thanks for doing this! The Classpath hackers will have to implement a few missing bits to get this working now, including javax.imageio.plugins.jpeg.*. This is part of the last 2% we need to implement for 1.4 API coverage. See http://www.kaffe.org/%7Estuart/japi/htmlout/h-jdk14-classpath for details. When do you think your patch may be available in a standard batik release?
Thanks! a few comments: > The "internal codecs" as I called them are moved to a new source > directory (sources-internal-codec) I will probably not do this, I will move them all into a common package instead. >- I've not reimplemented every single feature in the various image > transcoders for the Image I/O API as is available for the internal > codecs. Examples are Gamma/Chromaticity handling and background > color in PNG. Hmm, gamma handling _is_ important for PNG (especially on decode). This is why we moved from using the JDK decoder to our own local one. Fortunately this is not the real problem area with the Batik codecs - so I will see what can be done. On Tiff it isn't the most important part. It would be nice for some use cases. > - I've experienced problems handling metadata and encoding parameters > when writing JPEG images through Image I/O. The current code works > for most use cases, though. This is a little more troubling, what sorts of problems? > - The TIFFTranscoder now supports specifying the compression > method through a Transcoding hint (type String). Sounds good! > - I've changed the code that prepares an XML parser to use JAXP in > order to remove the mandatory dependency on Apache Xerces. I hope > I did this the right way. This also looks good. > You can forcibly disable the compilation of the Sun-dependant > internal codecs if you create a file (called "build-local.properties") Is there any reason you didn't use 'build.properties' file? This file is only used for 'local' mods anyways (otherwise you would put them in the ant file wouldn't you?).
(In reply to comment #4) > Thanks! a few comments: > > > The "internal codecs" as I called them are moved to a new source > > directory (sources-internal-codec) > > I will probably not do this, I will move them all into a common > package instead. Ok, but that will make it more difficult to work with in an IDE. Now I can just remove the sources-internal-codec from the source dir list and work with Batik in a GNU-Classpath-compatible way. Sure, it's easy to keep the things apart in the Ant build but having a clean separation helps a lot, especially in showing the dependencies. I guess we're back to the same argument we had with XML Graphics Commons. > >- I've not reimplemented every single feature in the various image > > transcoders for the Image I/O API as is available for the internal > > codecs. Examples are Gamma/Chromaticity handling and background > > color in PNG. > > Hmm, gamma handling _is_ important for PNG (especially on decode). > This is why we moved from using the JDK decoder to our own local one. > Fortunately this is not the real problem area with the Batik > codecs - so I will see what can be done. I guessed as much. Thanks. > On Tiff it isn't the most important part. It would be nice for > some use cases. > > > - I've experienced problems handling metadata and encoding parameters > > when writing JPEG images through Image I/O. The current code works > > for most use cases, though. > > This is a little more troubling, what sorts of problems? The main problem is that the JPEG codec does not support setting the bitmap resolution through the standard metdata format. Image I/O has a good concept for handling metadata but the implementation is a catastrophe. Other problems mostly involved IIOMetadata.setFromTree/mergeFromTree(). Settings get lost when merging and stuff like that. A lot of trial and error was necessary to get this far and I've found almost no helpful resources on the net. > > - The TIFFTranscoder now supports specifying the compression > > method through a Transcoding hint (type String). > > Sounds good! > > > - I've changed the code that prepares an XML parser to use JAXP in > > order to remove the mandatory dependency on Apache Xerces. I hope > > I did this the right way. > > This also looks good. > > > You can forcibly disable the compilation of the Sun-dependant > > internal codecs if you create a file (called "build-local.properties") > > Is there any reason you didn't use 'build.properties' file? > This file is only used for 'local' mods anyways (otherwise you would > put them in the ant file wouldn't you?). I like to separate build.properties from build-local.properties, because that latter is normally in the ignores list, so people can override their build settings without accidentally committing their special settings to the repository. A build.properties can help a lot for specifying default behaviour and serving as a template for a build-local.properties. See FOP where this is done very cleanly. BTW, I'm very surprised about the amount of attention this patch already got. Looks like I picked something important. :-)
Today, it suddenly dawned on me that it would be better if we actually started to populate XML Graphics Commons with this. After all, FOP now uses the codecs directly (read and write) and it would be good if we also decoupled these Sun-dependent codecs from FOP. So why not just copy the codecs and add the ImageWriters to Commons? I think I'll just do that. We have to start at some point. :-) Still, the question remains about the placement of the sources. We will certainly need a java-1.3 and a java-1.4 directory for the GraphicsConfiguration classes coming from FOP. I think it would be good to place the codecs under java-sun-dep (as replacement for the "sources-internal-codec" suggested earlier). Thomas, I know you prefer to put everything under one tree but how opposed are you to such a (IMO) clean split? For those who don't know what XML Graphics Commons is: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
In reply to comment #6) > Today, it suddenly dawned on me that it would be better if we actually started > to populate XML Graphics Commons with this. After all, FOP now uses the codecs > directly (read and write) and it would be good if we also decoupled these > Sun-dependent codecs from FOP. So why not just copy the codecs and add the > ImageWriters to Commons? I think I'll just do that. We have to start at some > point. :-) Well I have this mostly working in my local area. I now have it passing the Batik regression tests... as long as it still uses the 'original' readers and writers. > Still, the question remains about the placement of the sources. We will > certainly need a java-1.3 and a java-1.4 directory for the GraphicsConfiguration > classes coming from FOP. I think it would be good to place the codecs under > java-sun-dep (as replacement for the "sources-internal-codec" suggested > earlier). Thomas, I know you prefer to put everything under one tree but how > opposed are you to such a (IMO) clean split? I don't understand the need to split these sources out... What I did in my local repository is created codec/jpeg|png|tiff|jiio packages and the source for that codec goes in that package. I've modified the build so that when it can it builds everything (i.e. on a "sun" JDK 1.4 and higher) Then the services class may reject some at runtime (like because it can't 'link' the JIIO code under jdk 1.3). > For those who don't know what XML Graphics Commons is: > http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents Depending on what others think I would like to check in what I have (preferably to trunk, but I could spin a branch). Since the jiio stuff still isn't quite right (however it's close) I'd probably comment them out of the services meta-inf file. Even if we move everything to commons this can be easier once everything is under SVN. What do people think?
(In reply to comment #7) > In reply to comment #6) > > Today, it suddenly dawned on me that it would be better if we actually started > > to populate XML Graphics Commons with this. After all, FOP now uses the codecs > > directly (read and write) and it would be good if we also decoupled these > > Sun-dependent codecs from FOP. So why not just copy the codecs and add the > > ImageWriters to Commons? I think I'll just do that. We have to start at some > > point. :-) > > Well I have this mostly working in my local area. I now have it > passing the Batik regression tests... as long as it still uses the > 'original' readers and writers. In that case, I'll wait with that and move on after you have committed the patch. One day I have to look at the Batik test system. I'm guilty of not running it before I posted the patch. > > Still, the question remains about the placement of the sources. We will > > certainly need a java-1.3 and a java-1.4 directory for the > GraphicsConfiguration > > classes coming from FOP. I think it would be good to place the codecs under > > java-sun-dep (as replacement for the "sources-internal-codec" suggested > > earlier). Thomas, I know you prefer to put everything under one tree but how > > opposed are you to such a (IMO) clean split? > > I don't understand the need to split these sources out... > > What I did in my local repository is created codec/jpeg|png|tiff|jiio > packages and the source for that codec goes in that package. I've > modified the build so that when it can it builds everything (i.e. > on a "sun" JDK 1.4 and higher) Then the services class may reject > some at runtime (like because it can't 'link' the JIIO code under > jdk 1.3). Yes, under Ant this is absolutely no problem. But setting this up in an IDE can be difficult. You can only set include/exclude patterns for source directories in Eclipse since version 3.1. And that means something. It makes the whole thing just much easier for people actually working on Batik. How do you handle this? Do you always compile with the Ant script? I'd freak out because of the performance. > > For those who don't know what XML Graphics Commons is: > > http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents > > Depending on what others think I would like to check in what > I have (preferably to trunk, but I could spin a branch). Since > the jiio stuff still isn't quite right (however it's close) I'd > probably comment them out of the services meta-inf file. > > Even if we move everything to commons this can be easier > once everything is under SVN. > > What do people think? Sounds good. I'll hold off then. It's not like I have no other things I can kill my free/fun time with. :-)
(In reply to comment #8) > Yes, under Ant this is absolutely no problem. But setting this up in an > IDE can be difficult. You can only set include/exclude patterns for > source directories in Eclipse since version 3.1. And that means something. > It makes the whole thing just much easier for people actually working on > Batik. Does it really? How many people are running eclipse using gcj as the eclipse compiler? Can such a thing even be done? I think this is the only place where anyone will "feel the pain" and even then they just need to update to a recent version of Eclipse. > How do you handle this? Do you always compile with the Ant script? > I'd freak out because of the performance. I'm not sure why you think performance is bad. A No-op compile (on a 2+yr old laptop) is 5sec, a full rebuild is 1min 22sec. That seems entirely reasonable to me (in most cases Squiggle takes several times longer to start than the compile takes). > Sounds good. I'll hold off then. It's not like I have no other things > I can kill my free/fun time with. :-) So the code is in to switch the I/O all you need to do is muck with the services file.