[very much RFC][icedtea-web] fix for [Bug 564] NetX depends on sun.misc.BASE64Encoder
dbhole at redhat.com
Fri Oct 7 08:32:56 PDT 2011
* Jiri Vanek <jvanek at redhat.com> [2011-10-07 11:28]:
> I took the solving of this bug maybe to widely and complexly. Lets reviewer decide which parts to keep.
> The patch is trying to use apache-commons-codec's base64 as replacement for sun-misc's base64 proprietary api. The problem is, that although apach-commons-codec are available at f13 and higher, they are not avaiable for Rhel5 and not even for Rhel6.
The API is not proprietary. It is just not public.
> So autotools just check if some alternative base64 provider (currently just the apache ones) is avaiable. If so, marks location of jar and adds it to XBoothClasspath of javaws and plugin - I was surprised that adding it to normal classpath have taken no effect (and javaws was working also when classpath setted in luncher's $CP was empty. => Is this correct or bogus??
> Whether to use suns or 'alternative' base64 provider is done in runtime - although I'm delaying all reflection calls as alzy as possible and I'm aware of loosing compile time checking and java have no ifdef, _I'm hesitating if this aproach is safe correct_ . :(
> Part of the patch is set of unittests which are testing the base64 providers factory and functionality and one reproducer which is checking if build-time selected provider is really used.
> I have also kept CHECK_FOR_CLASS sun.misc.BASE64Encoder, but made it just optional. (Then I have added test for alternative apache implementation and added rule that at least one of this two must be available).
> Well I know that it is too much code (caused by not100% apache codec availability, even when ignoring tests) and so I'm thinking wheather really isn't better to add our own nearly copy-pasted-from-somewhere implementation...
I haven't looked into this in detail, but since you have -- what do you
think about just copying sun.misc.BASE64Encoder? It is GPL and we can
copy it into IcedTea-Web..
More information about the distro-pkg-dev