[very much RFC][icedtea-web] fix for [Bug 564] NetX depends on sun.misc.BASE64Encoder

[Jiri Vanek]

On 10/07/2011 05:32 PM, Deepak Bhole wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2011-10-07 11:28]:
>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=564
>>
>>
>> Hi!
>>
>> 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...
>>

Well if you thing it is good idea then why not. Patch will be much more simple. I moreover tried to follow dr. Andrew's idea to reuse already prepared libray, which is still under improvement and updates. If ou believe in copypasting code from sun* packages, then maybe we can get rid of all the compiler "proprietary api" errors by this way.
Only drawback of copypasting this explicit code is that we lost possihl eupdates from third party (where is it much more used then in icedtea-web)
>
> 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..
>
> Cheers,
> Deepak