I'll create a suncompat component and see where we go from there... Tim
Alex Blewitt wrote: > On 10/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> Anthony Green wrote: >> > On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: >> >> Yes- the idea is to provide that "suncompat.jar" for that reason with >> >> those clases in the sun.* namespace that user apps depend on. >> > >> > This way lies madness. I urge you to take a strong stand against bad >> > applications. >> >> Oh, don't get me wrong - we really want to. But we want adoption of the >> harmony codebase as well. We think that we have a reasonable balance - >> provide the functionality in an separable, modular way at first to make >> it easy for people to try and adopt harmony. > > May I suggest that we try and: > > 1) Make available a suncompat.jar, which re-writes calls to o.a.h or > similar (or subclasses them ...) > 2) Explicitly don't make it part of the default classpath ala > 'tools.jar' in the standard Sun implementation when running HarmonyVM > code > 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the > suncompat in the classpath' > > That way, out-of-the-box we don't have it, but there's an easy fix for > people who trip up over it. However, if people just need to get it > running, then they have a trivial workaround that doesn't involve > changing their code. > > The same could also be provided for code that depends on sun.JavaC or > whatever ... > > Alex. > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
