Bug 38183 - [PATCH] Compatibility with GNU Classpath
[PATCH] Compatibility with GNU Classpath
Status: RESOLVED FIXED
Product: Batik - Now in Jira
Classification: Unclassified
Component: (RFE) Request For Extension
1.8
All All
: P2 enhancement
: ---
Assigned To: Batik Developer's Mailing list
: PatchAvailable
Depends on:
Blocks: 46513
  Show dependency tree
 
Reported: 2006-01-08 17:42 UTC by Jeremias Maerki
Modified: 2009-11-05 16:56 UTC (History)
3 users (show)



Attachments
A ZIP containing the patch and the output of a "svn status" on my local working copy (125.93 KB, application/zip)
2006-01-08 17:44 UTC, Jeremias Maerki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremias Maerki 2006-01-08 17:42:33 UTC
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...
Comment 1 Jeremias Maerki 2006-01-08 17:44:32 UTC
Created attachment 17366 [details]
A ZIP containing the patch and the output of a "svn status" on my local working copy
Comment 2 Jeremias Maerki 2006-01-08 17:53:40 UTC
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
Comment 3 Anthony Green 2006-01-09 19:30:09 UTC
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?
Comment 4 Thomas Deweese 2006-01-10 12:42:59 UTC
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?).
Comment 5 Jeremias Maerki 2006-01-10 13:06:27 UTC
(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. :-)
Comment 6 Jeremias Maerki 2006-02-11 14:26:07 UTC
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
Comment 7 Thomas Deweese 2006-02-15 01:52:39 UTC
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?
Comment 8 Jeremias Maerki 2006-02-15 19:22:16 UTC
(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. :-)
Comment 9 Thomas Deweese 2006-02-17 12:04:04 UTC
(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.