[PATCH] Allow usage of external zlib copy

[Phil Race]

Diego 'Flameeyes' Pettenò wrote:
> On Fri, 11 May 2007 08:40:54 -0700
> Phil Race <Phil.Race at Sun.COM> wrote:
>
>   
>> The JDK's libjpeg is not the standard  IJG one. It has additional
>> stuff in it and exposes only the
>> symbols needed by the JDK. So in no way is it interchangeable.
>>     
>
> This might be a problem. The exposure of symbols shouldn't be a problem
> on its own (used as a shared library, the symbols exported are generic
> enough); the additional stuff instead can be a problem indeed.
>
> I can't seem to find a detail of what the changes are, but I can tell
> that using the jpeg library in Gentoo let OpenJDK build fine at least.
>   

Building isn't the problem, Running is. The exported symbols in the 
JDK's libjpeg are accessed via JNI
calls so until you get an UnsatisfiedLinkError at runtime when  some JDK 
component tries
to use it you won't know there's a problem. 

> I haven't sent any patch yet because I have to find a way to test it
> out first. (zlib was easier). Note that also Gentoo's jpeg is not
> totally vanilla, it contains a few patches coming from Debian, and a
> security fix to keep a large allocation of memory from killing the
> system. If the additional stuff might be of help, and wouldn't break
> software written with vanilla jpeg in mind, it might as well be
> possible to backport those changes in Gentoo's jpeg library.
>
> As far as I can see a good deal of the changes replaces the symbol main
> with _main, the functional changes are at a minimum, I see a change in
> the way EQTs are emitted, and an error downgraded to warning, and a
> change in INT32 definition. I see some sprintf() calls changed to
> jio_snprintf() too.
>
> After all, it doesn't seem like a difficult task to get the external
> jpeg library to work fine with OpenJDK.
>   

At the very least you'd need to find somewhere else to put the JNI 
native methods and then
have them able to locate libjpeg.

Also our build process has to be on all platforms. We need JPEG sources 
in the JDK
since you aren't likely to find it on windows ..
 
Complicating matters further there are some additonal changes not in the 
'openjdk' until we
sort out more legal issues. If we can't work those out these embedded 
changes would mean
the commercial JDK would simply not be able to use  an external libjpeg. 
and  there'd be
an  annoying difference betwen the two builds

A libjpeg has been baked into JDK since 1.0 I really don't think I want 
to change that now.
I just don't see the value.  Instead I see a lot of churn
> I've seen there are also copies of libpng and giflib, are those
> modified in some way, too? I'm now running a build with those used
> external too.
>
>   

They are not, so far as I know modified, except to remove exraneous stuff.
These are used by the AWT splashscreen API, and so only need reading 
capability,

-phil.