BASE64Encoder class missing?

[Martin Cordova <ma...@gmail.com>]

Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
engine on Windows XP SP2. The first obstacle I hit was related to the
use of sun/misc/BASE64Encoder

I got a java.lang.NoClassDefFoundError exception.

Is there a workaround? was this class located under a different package?

Thanks a lot.
Martin Cordova
-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Martin Cordova <ma...@gmail.com>]

OK, now I understand the concern about it:

* http://java.sun.com/products/jdk/faq/faq-sun-packages.html

Whatever the case, I will remove this dependency from my code.

Thank you all for the quick feedback.

Regards,
Martin

On 8/9/06, Martin Cordova <ma...@gmail.com> wrote:
> Just to set the record straight, Winstone servlet engine does not have
> a dependency on this code - as far as I know, it's just some reusable
> code of mine that makes use of this Base64 API, not related to
> Winstone.
>
> My primary concern was getting all my code running on Harmony without
> significant changes, especially code that invokes JDK libraries. Since
> I saw it implemented on IBM's JVM (despite the sun.* namespace) I
> thought it would be present in Harmony.
>
> I have no problem calling another Base64 class, it is just that I did
> not expect this class to be missing in Harmony.
>
> Regards,
> Martin
> --
> Dinamica - RADical J2EE framework
> open source, easy and powerful
> http://www.martincordova.com
>
> On 8/9/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> > Regardless of how this turns out, I would suggest that someone (Martin?) log
> > an issue with Winstone to switch from using this class to something like
> > commons-codec.
> >
> > -Nathan
> >
> > > -----Original Message-----
> > > From: Martin Cordova [mailto:martin.cordova@gmail.com]
> > > Sent: Wednesday, August 09, 2006 2:34 PM
> > > To: harmony-dev@incubator.apache.org; geir@pobox.com
> > > Subject: Re: BASE64Encoder class missing?
> > >
> > > I was testing a servlet engine called Winstone v0.8.2 - very
> > > lightweight and minimalistic (winstone.sourceforge.net). It started
> > > very fast, and everything seemed to work nice until I reached the
> > > point of encoding a password...
> > >
> > > I also make heavy use of Resin servlet engine, I will test it with Harmony
> > > too.
> > >
> > > Is it possible to mantain the same package name for this Base64 class?
> > > any licensing issues regarding this? I use IBM JVM and they provide
> > > this class under the same package.
> > >
> > > I also tested a small program that uses some File I/O and a compact
> > > XML parser called Electric XML and parts of a framework that makes
> > > heavy use of HashMap and ArrayList. Did run fine and fast, inside
> > > Eclipse 3.2.
> > >
> > > I am really pleased with this JRE snapshot, so easy to install and
> > > test. Last time I tested gnu classpath with some open source JVM was a
> > > pain in the class. Don't take me wrong, I appreciatte a lot the effort
> > > of those guys, but I love simplicity a lot. By creating an easy to
> > > install snapshot you are also improving the feedback cycle, people (at
> > > least me) will feel more motivated to test and provide feedback.
> > >
> > > Regards,
> > > Martin
> > > --
> > > Dinamica - RADical J2EE framework
> > > open source, easy and powerful
> > > http://www.martincordova.com
> > >
> > >
> > > On 8/9/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > > > btw... which servlet engine?
> > > >
> > > > Did you get anything done before you ran into the missing class?  We're
> > > > interested in hearing how it went...
> > > >
> > > > geir
> > > >
> > > > Martin Cordova wrote:
> > > > > Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> > > > > engine on Windows XP SP2. The first obstacle I hit was related to the
> > > > > use of sun/misc/BASE64Encoder
> > > > >
> > > > > I got a java.lang.NoClassDefFoundError exception.
> > > > >
> > > > > Is there a workaround? was this class located under a different
> > > package?
> > > > >
> > > > > Thanks a lot.
> > > > > Martin Cordova
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>


-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Martin Cordova <ma...@gmail.com>]

Just to set the record straight, Winstone servlet engine does not have
a dependency on this code - as far as I know, it's just some reusable
code of mine that makes use of this Base64 API, not related to
Winstone.

My primary concern was getting all my code running on Harmony without
significant changes, especially code that invokes JDK libraries. Since
I saw it implemented on IBM's JVM (despite the sun.* namespace) I
thought it would be present in Harmony.

I have no problem calling another Base64 class, it is just that I did
not expect this class to be missing in Harmony.

Regards,
Martin
-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com

On 8/9/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> Regardless of how this turns out, I would suggest that someone (Martin?) log
> an issue with Winstone to switch from using this class to something like
> commons-codec.
>
> -Nathan
>
> > -----Original Message-----
> > From: Martin Cordova [mailto:martin.cordova@gmail.com]
> > Sent: Wednesday, August 09, 2006 2:34 PM
> > To: harmony-dev@incubator.apache.org; geir@pobox.com
> > Subject: Re: BASE64Encoder class missing?
> >
> > I was testing a servlet engine called Winstone v0.8.2 - very
> > lightweight and minimalistic (winstone.sourceforge.net). It started
> > very fast, and everything seemed to work nice until I reached the
> > point of encoding a password...
> >
> > I also make heavy use of Resin servlet engine, I will test it with Harmony
> > too.
> >
> > Is it possible to mantain the same package name for this Base64 class?
> > any licensing issues regarding this? I use IBM JVM and they provide
> > this class under the same package.
> >
> > I also tested a small program that uses some File I/O and a compact
> > XML parser called Electric XML and parts of a framework that makes
> > heavy use of HashMap and ArrayList. Did run fine and fast, inside
> > Eclipse 3.2.
> >
> > I am really pleased with this JRE snapshot, so easy to install and
> > test. Last time I tested gnu classpath with some open source JVM was a
> > pain in the class. Don't take me wrong, I appreciatte a lot the effort
> > of those guys, but I love simplicity a lot. By creating an easy to
> > install snapshot you are also improving the feedback cycle, people (at
> > least me) will feel more motivated to test and provide feedback.
> >
> > Regards,
> > Martin
> > --
> > Dinamica - RADical J2EE framework
> > open source, easy and powerful
> > http://www.martincordova.com
> >
> >
> > On 8/9/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > > btw... which servlet engine?
> > >
> > > Did you get anything done before you ran into the missing class?  We're
> > > interested in hearing how it went...
> > >
> > > geir
> > >
> > > Martin Cordova wrote:
> > > > Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> > > > engine on Windows XP SP2. The first obstacle I hit was related to the
> > > > use of sun/misc/BASE64Encoder
> > > >
> > > > I got a java.lang.NoClassDefFoundError exception.
> > > >
> > > > Is there a workaround? was this class located under a different
> > package?
> > > >
> > > > Thanks a lot.
> > > > Martin Cordova
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

Alex Blewitt wrote:
> On 10/08/06, Geir Magnusson Jr <ge...@pobox.com> 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 ...

I still think we should - for now - include suncompat.jar by default,
because we generally only get one first impression with people, and when
people's programs break on harmony - *even if it's their fault* -
there's reasonable chance that people will not look closely, decide it's
our fault, and move on.

I think that we need to take a 'soft' and supportive approach here...

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Martin Cordova <ma...@gmail.com>]

For this specific case, I found this code for Base64, which claims to
be very fast and very compact:

* http://migbase64.sourceforge.net/

Just a single class that I repackaged in my own namespaces, and
changed one line of code to remove my dependency on sun.* - now I can
run on Harmony.

I think that providing some alerts about this dependency on Harmony
website, explaining the problem (as the Sun article I posted before
does) and suggesting some alternatives like migBase64, will help
newcomers to understand how easy to overcome the dependency is, and
motivate them to do so.

Regards,
Martin

On 8/10/06, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Loenko wrote:
> > The problem is Base64 functionality is unavailable through the
> > standard API, so people have a choice either use unportable sun.*,
> > o.a.h.*, etc or create the coder from scratch
>
> Understood, I think people are 'driven' to using the non-API types
> though necessity rather than doing so by mistake.
>
> > Alternative to suncompat is separating all similar functionality into
> > a separate redistributable module that would be runnable on RI, so
> > that people could use it in their apps.
>
> If we could get people to change their apps then I would agree.  In fact
> I would expect that most of the non-API functionality in common usage is
> already available elsewhere there if apps wanted to change (well, maybe
> not Unsafe, but...).
>
> But we are trying to fix it on the Harmony side.
>
> I'll go ahead an put in the suncompat module, but don't let that be the
> end of the debate -- it is trivial to add it and I have no qualms about
> removing it later if that's what we choose to do.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Sun, Aug 13, 2006 at 06:34:47PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> 
> > First part of the problem was the JavaScript bridge, which allowed
> > access to sun.* code, and the second part was sun.misc.Unsafe, which
> > allows kicking the legs under the Java security mechanism in three lines
> > of pure Java code, once you get access to it.
> > 
> > The exploit only works on VMs with a sun.misc.Unsafe class, obviously.
> > Microsoft's JVM is not affected.
> 
> Are you suggesting that by the very nature of being named
> 'sun.misc.Unsafe' there's a problem or might it simply be a bug in the
> implementation?
> 

the way sun.misc.Unsafe works is that if you get access to it, you've
rooted the JVM, effectively, as you can perform 'unsafe' operations on
objects, basically a bit like having a good old raw C pointer to crack
your way through objects in memory. It's rather trivial:

Decompiled exploit code is at http://www.opensecnet.com/omfg.jad ,
details are at
http://www.idefense.com/intelligence/vulnerabilities/display.php?id=158
and a few further sites. It's been patched by Sun a while ago, too,
fortunately, but no details on the fix are available. ;)

> If we took the j.u.c code and renamed the package, we'd be ok?

We'd not share an actively used vulnerability vector with Sun's VM, at 
least. There was a CERT warning about the bug being exploited in the
wild just a few months ago, which makes me uncomfortable having the
class around in our VMs.

Sun's design in this case appears to be sub-optimal, as by having a 
public class that is accessible accross packages and can be used to 
perform unsafe operations, they are adding another line of defense, 
which must not fail, in order for the JVM to remain uncompromised. 
A better design for such unsafe operations seems to be to put them in 
package-private classes and to not expose them to arbitrary code in
other packages.

That's essentially what I suggested a few mails ago regarding j.u.c.
code: factoring the VM-specific, unsafe operating into their own
package-private classes, hopefully with APIs that make sense to us, and
using that instead of emulating the interna of Sun's VM.

cheers,
dalibor topic

> geir
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:

> First part of the problem was the JavaScript bridge, which allowed
> access to sun.* code, and the second part was sun.misc.Unsafe, which
> allows kicking the legs under the Java security mechanism in three lines
> of pure Java code, once you get access to it.
> 
> The exploit only works on VMs with a sun.misc.Unsafe class, obviously.
> Microsoft's JVM is not affected.

Are you suggesting that by the very nature of being named
'sun.misc.Unsafe' there's a problem or might it simply be a bug in the
implementation?

If we took the j.u.c code and renamed the package, we'd be ok?

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

RE: [general] compatibility packages

[Jeroen Frijters <je...@sumatra.nl>]

Dalibor Topic wrote:
> First part of the problem was the JavaScript bridge, which allowed
> access to sun.* code, and the second part was sun.misc.Unsafe, which
> allows kicking the legs under the Java security mechanism in 
> three lines of pure Java code, once you get access to it.

I respectfully disagree. The fact that the access controls around
sun.misc.Unsafe failed was the problem, not the functionality it
provides. You can clear the security manager with reflection too, but we
rely on the access controls in reflection to protect us against that, if
they fail, do you want to remove reflection as well?

> I am not aware of any other potentially useful code that uses
> sun.misc.Unsafe, but I'd appreciate pointers.

I've seen code that had their own implementation of
Object[In|Out]putStream, you cannot do that in pure Java (which is
lame), but they managed to do it by using sun.reflect.* classes I
believe.

Regards,
Jeroen

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Sat, Aug 12, 2006 at 08:50:42PM +0200, Jeroen Frijters wrote:
> Dalibor Topic wrote:
> > So if I can't run the sun.misc.Unsafe remote exploit on 
> > Harmony it is a failure? ;)
> 
> You keep referring to this, but IMO this is a mischaracterization of the
> exploit. The exploit used a bug in JavaScript that allowed access to the
> sun.* package, that was the real problem not the sun.misc.Unsafe class.
> 

sun.misc.Unsafe was used to replace the SecurityManager's security field
with null, which allowed the code to download a payload and Runtime.exec
it. It's a nifty little exploit, if you google around you should be able
to find the disassembled code.

First part of the problem was the JavaScript bridge, which allowed
access to sun.* code, and the second part was sun.misc.Unsafe, which
allows kicking the legs under the Java security mechanism in three lines
of pure Java code, once you get access to it.

The exploit only works on VMs with a sun.misc.Unsafe class, obviously.
Microsoft's JVM is not affected.

I keep bringing it up because it is a nice example for what I am saying:
copying Sun-specific classes without need is a liability, rather than an
advantage.

> You also keep hammering on CharToByteConverter as an example of bad code
> that should trivially be fixed (and it obviously should, if possible,
> but it's not always that easy), but there is also code out there that
> uses sun.* classes to do things that are impossible to do with the
> documented APIs. How would you fix those?

If someone deliberately writes VM-specific code, you can't always fix
it. There may be a good reason to do so, for example if you are doing
research on Sun's implementation and hook into their VM using their
internal interfaces. There is nothing to fix in such a case, the code
works as designed. We'll never be able to perfectly run all those 
intertwined RMI extensions that work by hooking themselves deep into 
the interna of Sun's implementation, but that's so by deliberate design
of the code: the authors wanted to take advantage of the interna of
Sun's implementation. Is that a problem for anyone? I don't think it is.

But there is no good reason in 2006 to use a Sun-internal Base64
implementation, or the sun.io APIs, afaik. The only reason why we care
about sun.misc.Unsafe is Doug Lea's code, which seems like it can be 
refactored to offer a cleaner interface to the underlying VM, as I 
explained. I am not aware of any other potentially useful code that uses
sun.misc.Unsafe, but I'd appreciate pointers.

> BTW, that was a retorical question, because I already know your answer:
> that's rubbish software that won't work reliably on Sun's JRE anyway, so
> why should we support it?

That's by far not the whole story. My apologies if it came accross as
that simplistic. I'd say there are three categories:

a) Simple mistakes people make by copying
mistakes other people make. Base64, sun.io, etc.

b) Choices of convenience: Base64, sun.io, etc were here as long as
there were no better choices to get the job done. For most things, there
are now, afaict.

c) VM-implementation specific code: a lot of extensions to VMs and class
libraries fall into this category by design.

Can we accurately support c? I seriously doubt it.

Can we accurately support b? Maybe, but code in b) tends to rather 
quickly move into a) as more interfaces are standardized over time, which 
means duplicate code to maintain for less benefit.

Can we suport a? Maybe, but do the benefits outweigh the negative sides?

cheers,
dalibor topic

> However, I've spoken with Mark Reinhold about this issue and he told me
> that Sun sometimes reverts changes to sun.* classes because a customer
> complains that it broke their code. I asked him if they would be
> documenting these classes when they do this, but he said they wouldn't.
> So they seem to live in a dream world where on the one hand they want to
> discourage usage of sun.* and on the other hand continue to support it.
>
> Like compatibility in general this is a hard problem and we need to take
> a pragmatic approach and I really like the current plan of having an
> optional suncompat module.
> 
> Regards,
> Jeroen
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Think Different!

:)

geir


Alex Blewitt wrote:
> Bear in mind that this isn't standard across all VMs. For example, Mac
> VMs use JAVA_HOME/../Classes/classes.jar, instead of rt.jar.
> 
> Alex.
> 
> On 14/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> I assume for #1 we'll offer a patch :)
>>
>> Or just create an rt.jar if someone needs that.  There is no reason not
>> to...
>>
>> geir
>>
>>
>> Anton Luht wrote:
>> > Hello,
>> >
>> > There's another issues on compatibility: some applications rely on the
>> > existence of "<JAVA_ROOT>/lib/rt.jar" - the example is [1]. Some
>> > require tools.jar [2]. Harmony doesn't have these jars now so
>> > applications can fail on it just because they're bound to the
>> > implementation specifics.
>> >
>> > [1]
>> >
>> http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar
>>
>> >
>> > [2]
>> >
>> http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar
>>
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Re: [general] compatibility packages

[Alex Blewitt <al...@gmail.com>]

Bear in mind that this isn't standard across all VMs. For example, Mac
VMs use JAVA_HOME/../Classes/classes.jar, instead of rt.jar.

Alex.

On 14/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I assume for #1 we'll offer a patch :)
>
> Or just create an rt.jar if someone needs that.  There is no reason not
> to...
>
> geir
>
>
> Anton Luht wrote:
> > Hello,
> >
> > There's another issues on compatibility: some applications rely on the
> > existence of "<JAVA_ROOT>/lib/rt.jar" - the example is [1]. Some
> > require tools.jar [2]. Harmony doesn't have these jars now so
> > applications can fail on it just because they're bound to the
> > implementation specifics.
> >
> > [1]
> > http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar
> >
> > [2]
> > http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

I assume for #1 we'll offer a patch :)

Or just create an rt.jar if someone needs that.  There is no reason not
to...

geir


Anton Luht wrote:
> Hello,
> 
> There's another issues on compatibility: some applications rely on the
> existence of "<JAVA_ROOT>/lib/rt.jar" - the example is [1]. Some
> require tools.jar [2]. Harmony doesn't have these jars now so
> applications can fail on it just because they're bound to the
> implementation specifics.
> 
> [1]
> http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar
> 
> [2]
> http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar
> 
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Anton Luht <an...@gmail.com>]

Hello,

There's another issues on compatibility: some applications rely on the
existence of "<JAVA_ROOT>/lib/rt.jar" - the example is [1]. Some
require tools.jar [2]. Harmony doesn't have these jars now so
applications can fail on it just because they're bound to the
implementation specifics.

[1] http://koders.com/java/fid94A9F615DBE6674BB9423D1DF67C8256605B5C24.aspx?s=rt.jar
[2] http://koders.com/java/fidDE45C5B81C71D554A7E680A0E64FC1D564BA830A.aspx?s=tools.jar


-- 
Regards,
Anton Luht,
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Alex Blewitt wrote:
> On 14/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> 3) Clearly there's value in providing these [sun.* classes], as other
>> implementations
>> (BEA, IBM, Apple) include them.
> 
> Possibly true, but for different reasons. They license the source code
> bulk from Sun, not re-implement their own. (They have patches etc.
> that sit on top of them, of course.) As a result, there's a bunch of
> internal stuff that is exactly the same as Sun's, and so depends on
> the sun.* classes.

Depending on their license choice, we'll be able to do that soon :)  If
they'd just hurry up...

> 
> The value (to them) is that they don't have to spend time re-writing
> the sun.* classes instead of something else. There's no value
> necessarily to the end user; it's a selfish decision on their part,
> nothing more.

I agree with sentence 1 and 3 above, with s/selfish/pragmatic applied to
3.  I'd also bet that IBM wouldn't do it if they could avoid it - I
can't imagine they would ship sun.* unless there was customer demand.

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Tim Ellison <t....@gmail.com>]

I might have chosen to phrase it slightly differently, but yes IBM
licenses the Sun code, so the sun.* packages in an IBM JRE come from the
same original source (modulo any IBM applied changes).

Regards,
Tim

Alex Blewitt wrote:
> On 14/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>> 3) Clearly there's value in providing these [sun.* classes], as other
>> implementations
>> (BEA, IBM, Apple) include them.
> 
> Possibly true, but for different reasons. They license the source code
> bulk from Sun, not re-implement their own. (They have patches etc.
> that sit on top of them, of course.) As a result, there's a bunch of
> internal stuff that is exactly the same as Sun's, and so depends on
> the sun.* classes.
> 
> The value (to them) is that they don't have to spend time re-writing
> the sun.* classes instead of something else. There's no value
> necessarily to the end user; it's a selfish decision on their part,
> nothing more.
> 
> Alex.
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Re: [general] compatibility packages

[Alex Blewitt <al...@gmail.com>]

On 14/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> 3) Clearly there's value in providing these [sun.* classes], as other implementations
> (BEA, IBM, Apple) include them.

Possibly true, but for different reasons. They license the source code
bulk from Sun, not re-implement their own. (They have patches etc.
that sit on top of them, of course.) As a result, there's a bunch of
internal stuff that is exactly the same as Sun's, and so depends on
the sun.* classes.

The value (to them) is that they don't have to spend time re-writing
the sun.* classes instead of something else. There's no value
necessarily to the end user; it's a selfish decision on their part,
nothing more.

Alex.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

This is getting long :)  I'll respond inline because you've put so much
thought into this, but I want to try to start summarizing :

0) Lets keep things in perspective - we're in the 'snapshot' phase of
the project, and doing a release is a whole other story.  Also, we're
talking about a few simple utility classes.

1) We are talking about a selected few classes in sun.*, not all of
Sun's code.

2) We are in the really-early-adopter phase of things, and therefore
every single new user is incredibly valuable to the project.

3) Clearly there's value in providing these, as other implementations
(BEA, IBM, Apple) include them.

4) I'm very supportive of making it clear that we're not promising these
will always be here.  In fact, I'd be happy to make the statement that
they *won't* be included in any reasonably mature release (say, after
v0.5 or something) because that's an easy promise to break :)

I do believe that the probability of losing a "old" Harmony user when we
make suncompat.jar optional is nearly 0, whereas the probability of
losing a "new" Harmony user - someone just trying Harmony for the first
time, say at night after work - if suncompat.jar isn't there is very high.

Inline...

Alex Blewitt wrote:
> On 13/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Alex Blewitt wrote:
>> > On 12/08/06, Jeroen Frijters <je...@sumatra.nl> wrote:
>> >> However, I've spoken with Mark Reinhold about this issue and he
>> told me
>> >> that Sun sometimes reverts changes to sun.* classes because a customer
>> >> complains that it broke their code.
>> >
>> > And with this statement, you've highlighed precisely why we shouldn't
>> > include suncompat.jar by default. Because once we do, there's no going
>> > back -- ever. If we do, we risk the wrath of some user down in the
>> > future.
>>
>> I don't think we'll ship with suncompat.jar forever.  I'd probably say
>> it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in
>> bootclasspath by default...).
> 
> The problem (that I see) is that once you have something in a release,
> it's almost impossible to remove it at a later stage without running
> the risk of breaking something. I don't think it's reasonable to
> expect a reversal in decision at any point on this issue ...

Well, we aren't doing releases now.  Snapshots aren't releases.

I understand your argument and agree with it in general.  However, our
deliverable is Java SE 5.  Sun.* is just a 'marketing tool'.


> 
>> > (Very good related material can be found at
>> > http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and
>> > http://www.xom.nu/designprinciples.xhtml)
>>
>> Yah, but there's a difference between deprecated and what we're doing
>> here.  You deprecate when something that was part of the API contract
>> needs to go away.  We're never saying that suncompat is part of our API
>> contract.
> 
> The point being that once something is there, it's almost impossible
> to remove it. It doesn't matter whether it's called 'deprecated' or
> 'suncompat'; it's either there, or it isn't. Once it is there, it's
> very difficult to stop it being there without breaking something. The
> point of those links was to help emphasise that regardless of
> warnings, terminology, or semantics applied to those elements,
> removing them is almost impossible.

We're already "breaking" things from the perspective of the user.  If
you argue that it's not broken because people shouldn't be using sun.*,
then you can't have it both ways :)

> 
>> Maybe it's simply semantics, but I see that these are important
>> semantics.
> 
> I believe the fundamental difference is that you see it is possible to
> go from a 'enabled by default' to 'not enabled by default' -- my
> experience suggests otherwise. The semantics of the label attached to
> the library is irrelivant; it's whether you can go backwards or not. I
> do not believe you can.

We're just producing snapshots...

> 
>> > Surely we should be working towards that aim as well? I fail to see
>> > how this helps anyone in the medium or long term.
>>
>> Users will make or break us.
> 
> Yes, and they'll break us when, after some time shipping suncompat.jar
> by default, we disable it by default. Far better to train them to do
> the right thing from the beginning (enable it if they need it) than to
> throw them at a much later stage.

This makes sense on the surface, but when I think about it a little
more, I still don't agree.

Why?

Because we are trying to get people to use Harmony.  and rightly or
wrongly, they are coming into this with the expectation that when they
run their programs, they will work.  Yes, it's horrible that Sun let it
get to this point, and yes, I would prefer if we didn't have to deal
with this, but the fact is that we're trying to cover the same
functional ground that Sun's impl does, and like it or not, this is a
factor.

How about this - what if it was labeled "Harmony + suncompat" so it's
clear to people that we're adding this extra 'crutch' for them (with
appropos documentation)

Then it's clear that it's "something more".

> 
>> > If we include it by
>> > default *now*, we include it by default *for ever*. If we don't
>> > include it by default, but have a FAQ up that tells people about the
>> > workarounds, then those people for whom it's a problem can fix it, and
>> > the rest of the world can get on without it quite happily. But adding
>> > it by default is a one-way street that can never be reversed.
>>
>> I don't agree at all.
> 
> Yes, this is the fundamental objection I have, and you disagree with it.

Right - because we're just getting started with distributions people can
use, we're just starting to build momentum with users, and while every
user matters always, each user is so much more valuable now to help us
accelerate our adoption.

I see sun.* as a crutch to help out with that now.

> 
>> > There seems to be three options we can go forwards with:
>> >
>> > 1) Neither have suncompat.jar nor make it default (i.e. where we were
>> > before last week)
>> > 2) Have suncompat.jar, but don't make it default (instead, provide
>> > FAQs like
>> >
>> http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm)
>>
>> >
>> > 3) Have suncompat.jar, and make it default.
>>
>> I vote for #3, because at this stage of the project, we want to get rid
>> of the speedbumps, switching to #2 at some point.  As for #1, this is
>> open source... we can't dictate that.
> 
> And what if it were impossible to move from 3->2? Your decision would
> have locked us into shipping the sun.* packages for ever. Is that what
> you want?

I take calculated risks.  Harmony is a calculated risk.

Clearly IBM - for example - has decided that the cost of maintaining
some sun.* classes is worth it.  And honestly, I'm willing to "sell-out"
the purity of not having sun.* if it means that users migrate from Sun,
IBM and BEA. :)

That said, I don't think we're anywhere near the point of making that
decision.  Right now, we just want to add it to a nightly build to make
it easier for the early-early-adopters.

And how can anything be impossible?

> 
>> (Actually, that would be a howler wouldn't it... to become the RI for
>> sun.*...)
> 
> :-)
> 
>> > The transition from 1->2->3 is irreversible, and the decision to go
>> > down that path should be considered carefully for both immediate
>> > short-term (My app doesn't run on Harmony!) and medium- and long-term
>> > goals (non-Sun VMs shouldn't have/need sun. classes)
>>
>> I absolutely don't agree that the transition is irreversible.  I'd have
>> *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle
>> because at all times, we're going to make it clear what the situation is
>> and why we're doing it.
> 
> Let me get this straight:
> 
> You're happy to argue strongly enough *for* the suncompat.jar, that
> you think it should be the default (so that any application, no matter
> how badly written, will run without any changes).

Not "any".  Clearly there's a line.  But, yes,  there are some that are
so overwhelmingly popular that are easy to support and make people happy.

I can't believe that there's this much heat and light over a handful of
utility classes.

> 
> Yet you're happy for us to pull the rug out under the feet of those
> very same users at some point in the future? Possibly with just an
> entry in a README.TXT (and we know how much users want to read those)?

Yes.  Although I think that it should remain available for people to
include if they want to.

> 
> Tell me -- what's so special about the user *now* that you're willing
> to inflict pain on the same user *later*? Why not inflict pain from
> the get-go? What is so important in the period between now and later
> that makes it essential that we must enable it by default?

Because the amount of incremental benefit every user brings now to
Harmony is *huge*.

> 
> Even if we achieve some form of compromise (e.g. make it default for
> the alpha stages, disable it for the beta or release candiate stages)

We're not even near an alpha stage.

> how is a random user of Harmony going to feel when their app worked
> fine on all the pre-release builds, but fails on the 1.0 release? What
> is the big problem with making it fail *now*, and having a FAQ telling
> them how to fix it?

Because if we have a user that's happy and working on harmony, then when
suncompat goes away, the result will be "oh, I see" and they'll fix it
because they know Harmony, like Harmony, trust Harmony, understand that
Harmony is good and they want to use it.

When it's a early adopter coming to a codebase that's a snapshot that
has no users and no reputation, testing it out in a few minutes after
lunch or before bed, then "screw these clowns" is the likely response
even if *they* are wrong...

> 
> You mentioned elsewhere:
> 
>> What if the problem was in Weblogic?  What if the user couldn't get it
>> fixed?
> 
> This is still a solvable problem with either option 2 or 3. The former
> requires a little more work on the user's part.
> 
>> > Why should we support them when Sun don't even claim to?
>>
>> You know why we're doing this.  If Sun wanted to, I assume they could
>> fix the problem in the VM.
> 
> No, they can't. Do you know why? Because they let the cat out of the
> bag back in Java 1.0, and once released, you can't put it back in.
> They can *never* remove the sun.* classes, without breaking someone's
> code (indeed, the anecdotal evidence elsewhere in these conversations
> have suggested at some point they have tried to move it, and then put
> it back in again after customer complaints).

So by your argument, it's a shame, but the defacto Java API is the spec
+ sun.*?

Yes, I want to fix this this problem in Java, and the best way I see is
through having everyone use Harmony.
> 
> And yet you're espousing a route that will take us down *exactly* the
> same road that Sun went down, back in 1995. It's like the misnomer
> 'non-standard options -X' that are now so ubiquitous that they are
> almost part of the spec (and thus, Sun had to go down the next -XX
> level just to distinguish the non-non-standard from the non-standard
> options).

For consistency... I assume that you advocate we don't support -X options?


> 
> Even if I can't prove that I'm right, is it worth taking the risk? I'd
> really like not to be proven right through experience. Here's the risk
> table:
> 
> Alex is right: Option 2 (no risk; users can add suncompat.jar if
> needed); Option 3 (risk; we are stuck with suncompat.jar for ever)
> Geir is right: Option 2 (no risk; users can add suncompat.jar if
> needed); Option 3 (no-risk; we can move back to Option 2 when we want)
> 
> There really isn't any risk in going down the safe route (Option 2).
> OTOH if we go down Option 3, and you're right, there's no risk. But if
> we go down Option 3, and I'm right, we're stuck exactly where Sun is
> with a codebase that we are not able in any circumstance to remove
> suncompat for fear of breaking code (or, in the extreme cock-up case,
> we remove it and a bunch of bugs are filed saying their code doesn't
> work and we have to re-instate it by default for ever).
> 
> Let's look at the other side: what's the benefits of the above?
> 
> Option 2, user uses no sun.* code. Works perfectly.
> Option 3, user uses no sun.* code. Works perfectly.
> Option 2, user uses sun.* code. Doesn't work. Looks up FAQ to find out
> what to do, solves problem (or, gives up and uses a different VM like
> Classpth. Finds it doesn't work there. Uses proprietary JVM instead.)
> Option 3, user uses sun.* code. Works perfectly.
> 
> So, Option 3 works perfectly in both cases. Option 2 only works
> perfectly if no sun.* code is used. Realistically, this is most apps.
> I'd put in at least 90% on a guess. I expect the figure would be much
> higher.
> 
> So, what we're arguing about is 10% (or less, or whatever 100%-n works
> out as) of users where this may be a problem. Of those, if they've
> gone to through the process of getting hold of Harmony, they will
> either persevere enough to fix it, or give up. Other open-source
> libraries don't have this either, so if they are driven to use
> open-source for ethical reasons, they'll look into fixing it. If
> they're not, they'll switch to using a commercial JVM.
> 
> I don't see the risk of loosing 10% of users (or 100%-n) as
> outweighing the risk of being stuck with the sun.* classes for life.

50% of our users so far needed sun.* (actually one class...)  The
solution is cheap and easy.  I'm very happy to tell people that
suncompat.jar is in there for their convenience, and that it won't be in
1.0.  That's an easy promise to break.

And what's the real risk here?  That when we go from #3 to #2 that they
need to add the jar themselves?  Not a big deal.

> 
>> Because I want a user population the size of Sun's or IBM's, not GNU
>> Classpath's.
> 
> The existence of sun.* classes isn't going to inhibit Harmony's
> growth. It's going to fall into the same category of questions that
> most applications do, and hence the Frequent of the Frequenty Asked
> Questions entry.

Why do you think that IBM and others include them?  Could it be for
reasons of adoption?  I can't think of any other reason, short of Sun
requiring them to do so contractually, which I doubt.

> 
> Heck, we could even bodge the ClassLoader such that if the class
> loader requests a sun.* class, and the sun.* class isn't on the
> classpath, that the ClassNotFoundException's message is set to
> 'Harmony doesn't ship with sun.* classes by default, but by reading
> FAQ 1234, you can learn how to enable them'. Any half-decent
> application wil log such exception messages somewhere.
> 
>> > I strongly urge everyone to vote against the suncompat module being on
>> > the classpath by default. In two years time, we will be able to look
>> > back to this post and either congratulate ourselves on a wise decision
>> > made now, or rue the day that we gave up the chance to allow a strong
>> > stand on the restriction of sun.* packages for any running code.
>>
>> I think you are really overstating it right now.  This is a reasonable
>> fight to have at 1.0 time, but for snapshots?  Jeeze - I'm thrilled that
>> users want to spend time using our software right now.
>>
>> We just want to make it easy for early adopters.  We're not going to
>> "support" these classes.
> 
> So, should we start shipping with it by default now, when do we
> disable it by default? And what happens to those early adopters that
> you are campaigning for now when the switch is made?

They'll "oh, ok..." and put the jar in, if they even still need sun.*.

> 
> The problem is that there's an implicit guarantee that other users
> will see, when Harmony suddenly changes from having these classes to
> not having these classes. It's going to be just as much problem if we
> do the switch in 1 year as in 1 day. The difference is that we'll have
> 364 days worth of pissed off users that it used to work, but now
> doesn't. And if the users are going to read the README.TXT in 365 days
> time to figure out how they're going to re-enable the old behaviour,
> they're just as likely to read the README.TXT file *now* when they
> have a problem and need to enable the compatibility mode.

I don't buy this.  With good communications with the user base, we'll be
able to warn them.

And the point here isn't to endorse using sun.*, just make existing apps
work, and start the campaign to wean them off of it.

> 
> Heck, we could even include a non-non-non-standard option in the JVM
> args like -XXX:EnableSunClasses which would allow early adopters to
> enable the classes on the fly.

That would be cool.  I certainly would support that for any release we do.

> 
>> > PS The whole 'on the classpath for runtime but not for compile time'
>> > is completely bogus. If it's on the classpath, then an IDE such as
>> > Eclipse that provides its own compiler will still be able to compile
>> > against the class, as will e.g. references in JSPs for application
>> > servers that suppy their own compilers. It's either in the classpath,
>> > or it's not. If it's visible at runtime, then it's visible to any
>> > other 3rd party compiler, even if we hack Harmony's JavaC to refuse to
>> > compile against it.
>>
>> I wonder if we could come to some agreement with Eclipse to start for an
>>  annotation that achieves our goal here...  So then eclipse will point
>> out the problem...
> 
> AFAIK when you call a deprecated method, it draws a line through it.
> It doesn't display any message, though.

But this isn't deprecation....

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Re: [general] compatibility packages

[Alex Blewitt <al...@gmail.com>]

On 13/08/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Alex Blewitt wrote:
> > On 12/08/06, Jeroen Frijters <je...@sumatra.nl> wrote:
> >> However, I've spoken with Mark Reinhold about this issue and he told me
> >> that Sun sometimes reverts changes to sun.* classes because a customer
> >> complains that it broke their code.
> >
> > And with this statement, you've highlighed precisely why we shouldn't
> > include suncompat.jar by default. Because once we do, there's no going
> > back -- ever. If we do, we risk the wrath of some user down in the
> > future.
>
> I don't think we'll ship with suncompat.jar forever.  I'd probably say
> it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in
> bootclasspath by default...).

The problem (that I see) is that once you have something in a release,
it's almost impossible to remove it at a later stage without running
the risk of breaking something. I don't think it's reasonable to
expect a reversal in decision at any point on this issue ...

> > (Very good related material can be found at
> > http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and
> > http://www.xom.nu/designprinciples.xhtml)
>
> Yah, but there's a difference between deprecated and what we're doing
> here.  You deprecate when something that was part of the API contract
> needs to go away.  We're never saying that suncompat is part of our API
> contract.

The point being that once something is there, it's almost impossible
to remove it. It doesn't matter whether it's called 'deprecated' or
'suncompat'; it's either there, or it isn't. Once it is there, it's
very difficult to stop it being there without breaking something. The
point of those links was to help emphasise that regardless of
warnings, terminology, or semantics applied to those elements,
removing them is almost impossible.

> Maybe it's simply semantics, but I see that these are important semantics.

I believe the fundamental difference is that you see it is possible to
go from a 'enabled by default' to 'not enabled by default' -- my
experience suggests otherwise. The semantics of the label attached to
the library is irrelivant; it's whether you can go backwards or not. I
do not believe you can.

> > Surely we should be working towards that aim as well? I fail to see
> > how this helps anyone in the medium or long term.
>
> Users will make or break us.

Yes, and they'll break us when, after some time shipping suncompat.jar
by default, we disable it by default. Far better to train them to do
the right thing from the beginning (enable it if they need it) than to
throw them at a much later stage.

> > If we include it by
> > default *now*, we include it by default *for ever*. If we don't
> > include it by default, but have a FAQ up that tells people about the
> > workarounds, then those people for whom it's a problem can fix it, and
> > the rest of the world can get on without it quite happily. But adding
> > it by default is a one-way street that can never be reversed.
>
> I don't agree at all.

Yes, this is the fundamental objection I have, and you disagree with it.

> > There seems to be three options we can go forwards with:
> >
> > 1) Neither have suncompat.jar nor make it default (i.e. where we were
> > before last week)
> > 2) Have suncompat.jar, but don't make it default (instead, provide
> > FAQs like
> > http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm)
> >
> > 3) Have suncompat.jar, and make it default.
>
> I vote for #3, because at this stage of the project, we want to get rid
> of the speedbumps, switching to #2 at some point.  As for #1, this is
> open source... we can't dictate that.

And what if it were impossible to move from 3->2? Your decision would
have locked us into shipping the sun.* packages for ever. Is that what
you want?

> (Actually, that would be a howler wouldn't it... to become the RI for
> sun.*...)

:-)

> > The transition from 1->2->3 is irreversible, and the decision to go
> > down that path should be considered carefully for both immediate
> > short-term (My app doesn't run on Harmony!) and medium- and long-term
> > goals (non-Sun VMs shouldn't have/need sun. classes)
>
> I absolutely don't agree that the transition is irreversible.  I'd have
> *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle
> because at all times, we're going to make it clear what the situation is
> and why we're doing it.

Let me get this straight:

You're happy to argue strongly enough *for* the suncompat.jar, that
you think it should be the default (so that any application, no matter
how badly written, will run without any changes).

Yet you're happy for us to pull the rug out under the feet of those
very same users at some point in the future? Possibly with just an
entry in a README.TXT (and we know how much users want to read those)?

Tell me -- what's so special about the user *now* that you're willing
to inflict pain on the same user *later*? Why not inflict pain from
the get-go? What is so important in the period between now and later
that makes it essential that we must enable it by default?

Even if we achieve some form of compromise (e.g. make it default for
the alpha stages, disable it for the beta or release candiate stages)
how is a random user of Harmony going to feel when their app worked
fine on all the pre-release builds, but fails on the 1.0 release? What
is the big problem with making it fail *now*, and having a FAQ telling
them how to fix it?

You mentioned elsewhere:

> What if the problem was in Weblogic?  What if the user couldn't get it
> fixed?

This is still a solvable problem with either option 2 or 3. The former
requires a little more work on the user's part.

> > Why should we support them when Sun don't even claim to?
>
> You know why we're doing this.  If Sun wanted to, I assume they could
> fix the problem in the VM.

No, they can't. Do you know why? Because they let the cat out of the
bag back in Java 1.0, and once released, you can't put it back in.
They can *never* remove the sun.* classes, without breaking someone's
code (indeed, the anecdotal evidence elsewhere in these conversations
have suggested at some point they have tried to move it, and then put
it back in again after customer complaints).

And yet you're espousing a route that will take us down *exactly* the
same road that Sun went down, back in 1995. It's like the misnomer
'non-standard options -X' that are now so ubiquitous that they are
almost part of the spec (and thus, Sun had to go down the next -XX
level just to distinguish the non-non-standard from the non-standard
options).

Even if I can't prove that I'm right, is it worth taking the risk? I'd
really like not to be proven right through experience. Here's the risk
table:

Alex is right: Option 2 (no risk; users can add suncompat.jar if
needed); Option 3 (risk; we are stuck with suncompat.jar for ever)
Geir is right: Option 2 (no risk; users can add suncompat.jar if
needed); Option 3 (no-risk; we can move back to Option 2 when we want)

There really isn't any risk in going down the safe route (Option 2).
OTOH if we go down Option 3, and you're right, there's no risk. But if
we go down Option 3, and I'm right, we're stuck exactly where Sun is
with a codebase that we are not able in any circumstance to remove
suncompat for fear of breaking code (or, in the extreme cock-up case,
we remove it and a bunch of bugs are filed saying their code doesn't
work and we have to re-instate it by default for ever).

Let's look at the other side: what's the benefits of the above?

Option 2, user uses no sun.* code. Works perfectly.
Option 3, user uses no sun.* code. Works perfectly.
Option 2, user uses sun.* code. Doesn't work. Looks up FAQ to find out
what to do, solves problem (or, gives up and uses a different VM like
Classpth. Finds it doesn't work there. Uses proprietary JVM instead.)
Option 3, user uses sun.* code. Works perfectly.

So, Option 3 works perfectly in both cases. Option 2 only works
perfectly if no sun.* code is used. Realistically, this is most apps.
I'd put in at least 90% on a guess. I expect the figure would be much
higher.

So, what we're arguing about is 10% (or less, or whatever 100%-n works
out as) of users where this may be a problem. Of those, if they've
gone to through the process of getting hold of Harmony, they will
either persevere enough to fix it, or give up. Other open-source
libraries don't have this either, so if they are driven to use
open-source for ethical reasons, they'll look into fixing it. If
they're not, they'll switch to using a commercial JVM.

I don't see the risk of loosing 10% of users (or 100%-n) as
outweighing the risk of being stuck with the sun.* classes for life.

> Because I want a user population the size of Sun's or IBM's, not GNU
> Classpath's.

The existence of sun.* classes isn't going to inhibit Harmony's
growth. It's going to fall into the same category of questions that
most applications do, and hence the Frequent of the Frequenty Asked
Questions entry.

Heck, we could even bodge the ClassLoader such that if the class
loader requests a sun.* class, and the sun.* class isn't on the
classpath, that the ClassNotFoundException's message is set to
'Harmony doesn't ship with sun.* classes by default, but by reading
FAQ 1234, you can learn how to enable them'. Any half-decent
application wil log such exception messages somewhere.

> > I strongly urge everyone to vote against the suncompat module being on
> > the classpath by default. In two years time, we will be able to look
> > back to this post and either congratulate ourselves on a wise decision
> > made now, or rue the day that we gave up the chance to allow a strong
> > stand on the restriction of sun.* packages for any running code.
>
> I think you are really overstating it right now.  This is a reasonable
> fight to have at 1.0 time, but for snapshots?  Jeeze - I'm thrilled that
> users want to spend time using our software right now.
>
> We just want to make it easy for early adopters.  We're not going to
> "support" these classes.

So, should we start shipping with it by default now, when do we
disable it by default? And what happens to those early adopters that
you are campaigning for now when the switch is made?

The problem is that there's an implicit guarantee that other users
will see, when Harmony suddenly changes from having these classes to
not having these classes. It's going to be just as much problem if we
do the switch in 1 year as in 1 day. The difference is that we'll have
364 days worth of pissed off users that it used to work, but now
doesn't. And if the users are going to read the README.TXT in 365 days
time to figure out how they're going to re-enable the old behaviour,
they're just as likely to read the README.TXT file *now* when they
have a problem and need to enable the compatibility mode.

Heck, we could even include a non-non-non-standard option in the JVM
args like -XXX:EnableSunClasses which would allow early adopters to
enable the classes on the fly.

> > PS The whole 'on the classpath for runtime but not for compile time'
> > is completely bogus. If it's on the classpath, then an IDE such as
> > Eclipse that provides its own compiler will still be able to compile
> > against the class, as will e.g. references in JSPs for application
> > servers that suppy their own compilers. It's either in the classpath,
> > or it's not. If it's visible at runtime, then it's visible to any
> > other 3rd party compiler, even if we hack Harmony's JavaC to refuse to
> > compile against it.
>
> I wonder if we could come to some agreement with Eclipse to start for an
>  annotation that achieves our goal here...  So then eclipse will point
> out the problem...

AFAIK when you call a deprecated method, it draws a line through it.
It doesn't display any message, though.

Alex.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr wrote:

>> Because I want a user population the size of Sun's or IBM's, not GNU
>> Classpath's.
> 
> If you've got credible numbers, I'd appreciate seeing them. The numbers
> I've got show that more people are using GNU Classpath through Kaffe &
> gcj than Sun's or IBM's VM on Debian by a large margin (~ 100%).

I don't have numbers, but Sun, BEA, IBM  have millions of users that
depend on those codebases for the life of their business.

I've never heard of anyone using kaffe+classpath for the life of their
business.

Now, that's not intended to disparage Kaffe or Classpath, as I realize
that like Harmony, they aren't done,  but I was simply responding to the
comparison of the approach to this issue that Sun, IBM and BEA take vs
Kaffe/GNUCLasspath.

While the point was simply that there may be things to learn from the
successful commercial vendors on this, I realize now that it would have
been prudent to just keep my mouth shut :)

> 
> See 
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=sun-java5-jre%2Ckaffe%2Cjava-gcj-compat&show_installed=on&show_vote=on&want_percent=on&want_legend=on&beenhere=1
> 

What exactly are we looking at here?

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Alex Blewitt wrote:
> > On 12/08/06, Jeroen Frijters <je...@sumatra.nl> wrote:
> > 
> >> However, I've spoken with Mark Reinhold about this issue and he told me
> >> that Sun sometimes reverts changes to sun.* classes because a customer
> >> complains that it broke their code.
> > 
> > And with this statement, you've highlighed precisely why we shouldn't
> > include suncompat.jar by default. Because once we do, there's no going
> > back -- ever. If we do, we risk the wrath of some user down in the
> > future.
> 
> I don't agree because we'll be clear about why we have sun.* classes -
> they are a crutch to help people switch to Harmony.  Sun can't avoid
> having sun.* classes :)
> 
> I don't think we'll ship with suncompat.jar forever.  I'd probably say
> it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in
> bootclasspath by default...).
> 
> And at all times, we are going to make big noises about why it's there
> and how people should use it...
> 
> > 
> > (Very good related material can be found at
> > http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and
> > http://www.xom.nu/designprinciples.xhtml)
> 
> Yah, but there's a difference between deprecated and what we're doing
> here.  You deprecate when something that was part of the API contract
> needs to go away.  We're never saying that suncompat is part of our API
> contract.
> 
> Maybe it's simply semantics, but I see that these are important semantics.
> 
> > 
> >> I asked him if they would be documenting these classes when they do
> >> this, but he
> >> said they wouldn't. So they seem to live in a dream world where on the
> >> one hand
> >> they want to discourage usage of sun.* and on the other hand continue
> >> to support it.
> > 
> > Surely we should be working towards that aim as well? I fail to see
> > how this helps anyone in the medium or long term. 
> 
> Users will make or break us.
> 
> > If we include it by
> > default *now*, we include it by default *for ever*. If we don't
> > include it by default, but have a FAQ up that tells people about the
> > workarounds, then those people for whom it's a problem can fix it, and
> > the rest of the world can get on without it quite happily. But adding
> > it by default is a one-way street that can never be reversed.
> 
> I don't agree at all.
> 
> > 
> >> Like compatibility in general this is a hard problem and we need to take
> >> a pragmatic approach and I really like the current plan of having an
> >> optional suncompat module.
> > 
> > There seems to be three options we can go forwards with:
> > 
> > 1) Neither have suncompat.jar nor make it default (i.e. where we were
> > before last week)
> > 2) Have suncompat.jar, but don't make it default (instead, provide
> > FAQs like
> > http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm)
> > 
> > 3) Have suncompat.jar, and make it default.
> 
> I vote for #3, because at this stage of the project, we want to get rid
> of the speedbumps, switching to #2 at some point.  As for #1, this is
> open source... we can't dictate that.
> 
> (Actually, that would be a howler wouldn't it... to become the RI for
> sun.*...)
> 
> > 
> > The transition from 1->2->3 is irreversible, and the decision to go
> > down that path should be considered carefully for both immediate
> > short-term (My app doesn't run on Harmony!) and medium- and long-term
> > goals (non-Sun VMs shouldn't have/need sun. classes)
> 
> I absolutely don't agree that the transition is irreversible.  I'd have
> *no* problem moving suncompat from #3 to #2 at anytime in our lifecycle
> because at all times, we're going to make it clear what the situation is
> and why we're doing it.
> 
> > 
> > I strongly disagree with the suggestion that we must do 3 to support a
> > tiny proportion of apps that may go against Sun's FAQ
> > (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed,
> > they go as far as saying that:
> > 
> > "The sun.* packages are not part of the supported, public interface.
> > A Java program that directly calls into sun.* packages is not
> > guaranteed to work on all Java-compatible platforms. In fact, such a
> > program is not guaranteed to work even in future versions on the same
> > platform.
> > "In general, writing java programs that rely on sun.* is risky: they
> > are not portable, and are not supported."
> > 
> > Why should we support them when Sun don't even claim to? 
> 
> You know why we're doing this.  If Sun wanted to, I assume they could
> fix the problem in the VM.
> 
> > Furthermore,
> > by taking a stance of 1) or 2), we are actively helping push Sun's
> > advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors
> > who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a
> > strong stand against these packages.
> 
> Because I want a user population the size of Sun's or IBM's, not GNU
> Classpath's.

If you've got credible numbers, I'd appreciate seeing them. The numbers
I've got show that more people are using GNU Classpath through Kaffe &
gcj than Sun's or IBM's VM on Debian by a large margin (~ 100%).

See 
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=sun-java5-jre%2Ckaffe%2Cjava-gcj-compat&show_installed=on&show_vote=on&want_percent=on&want_legend=on&beenhere=1

cheers,
dalibor topic

> 
> > 
> > Harmony will be great, regardless of whether the sun.* packages are
> > there. There will be at least one program that doesn't work because of
> > this (but that's been fixed already) -- there will be others in the
> > future. The adoption of Harmony as an open-source JVM will happen
> > regardless of the sun.* packages. Some people will complain, some will
> > vociferously declare that the suncompat module should be there by
> > default. Some programs won't work. If we go with option 2), they can
> > be made to work or to raise the issue that the program is not a
> > portable Java application (or both).
> > 
> > I strongly urge everyone to vote against the suncompat module being on
> > the classpath by default. In two years time, we will be able to look
> > back to this post and either congratulate ourselves on a wise decision
> > made now, or rue the day that we gave up the chance to allow a strong
> > stand on the restriction of sun.* packages for any running code.
> 
> I think you are really overstating it right now.  This is a reasonable
> fight to have at 1.0 time, but for snapshots?  Jeeze - I'm thrilled that
> users want to spend time using our software right now.
> 
> We just want to make it easy for early adopters.  We're not going to
> "support" these classes.
> 
> geir
> 
> > 
> > Alex.
> > 
> > PS The whole 'on the classpath for runtime but not for compile time'
> > is completely bogus. If it's on the classpath, then an IDE such as
> > Eclipse that provides its own compiler will still be able to compile
> > against the class, as will e.g. references in JSPs for application
> > servers that suppy their own compilers. It's either in the classpath,
> > or it's not. If it's visible at runtime, then it's visible to any
> > other 3rd party compiler, even if we hack Harmony's JavaC to refuse to
> > compile against it.
> 
> I wonder if we could come to some agreement with Eclipse to start for an
>  annotation that achieves our goal here...  So then eclipse will point
> out the problem...
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Alex Blewitt wrote:
> On 12/08/06, Jeroen Frijters <je...@sumatra.nl> wrote:
> 
>> However, I've spoken with Mark Reinhold about this issue and he told me
>> that Sun sometimes reverts changes to sun.* classes because a customer
>> complains that it broke their code.
> 
> And with this statement, you've highlighed precisely why we shouldn't
> include suncompat.jar by default. Because once we do, there's no going
> back -- ever. If we do, we risk the wrath of some user down in the
> future.

I don't agree because we'll be clear about why we have sun.* classes -
they are a crutch to help people switch to Harmony.  Sun can't avoid
having sun.* classes :)

I don't think we'll ship with suncompat.jar forever.  I'd probably say
it's 50/50 that we'd ship it with 1.0 (and 50/50 that it would be in
bootclasspath by default...).

And at all times, we are going to make big noises about why it's there
and how people should use it...

> 
> (Very good related material can be found at
> http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and
> http://www.xom.nu/designprinciples.xhtml)

Yah, but there's a difference between deprecated and what we're doing
here.  You deprecate when something that was part of the API contract
needs to go away.  We're never saying that suncompat is part of our API
contract.

Maybe it's simply semantics, but I see that these are important semantics.

> 
>> I asked him if they would be documenting these classes when they do
>> this, but he
>> said they wouldn't. So they seem to live in a dream world where on the
>> one hand
>> they want to discourage usage of sun.* and on the other hand continue
>> to support it.
> 
> Surely we should be working towards that aim as well? I fail to see
> how this helps anyone in the medium or long term. 

Users will make or break us.

> If we include it by
> default *now*, we include it by default *for ever*. If we don't
> include it by default, but have a FAQ up that tells people about the
> workarounds, then those people for whom it's a problem can fix it, and
> the rest of the world can get on without it quite happily. But adding
> it by default is a one-way street that can never be reversed.

I don't agree at all.

> 
>> Like compatibility in general this is a hard problem and we need to take
>> a pragmatic approach and I really like the current plan of having an
>> optional suncompat module.
> 
> There seems to be three options we can go forwards with:
> 
> 1) Neither have suncompat.jar nor make it default (i.e. where we were
> before last week)
> 2) Have suncompat.jar, but don't make it default (instead, provide
> FAQs like
> http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm)
> 
> 3) Have suncompat.jar, and make it default.

I vote for #3, because at this stage of the project, we want to get rid
of the speedbumps, switching to #2 at some point.  As for #1, this is
open source... we can't dictate that.

(Actually, that would be a howler wouldn't it... to become the RI for
sun.*...)

> 
> The transition from 1->2->3 is irreversible, and the decision to go
> down that path should be considered carefully for both immediate
> short-term (My app doesn't run on Harmony!) and medium- and long-term
> goals (non-Sun VMs shouldn't have/need sun. classes)

I absolutely don't agree that the transition is irreversible.  I'd have
*no* problem moving suncompat from #3 to #2 at anytime in our lifecycle
because at all times, we're going to make it clear what the situation is
and why we're doing it.

> 
> I strongly disagree with the suggestion that we must do 3 to support a
> tiny proportion of apps that may go against Sun's FAQ
> (http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed,
> they go as far as saying that:
> 
> "The sun.* packages are not part of the supported, public interface.
> A Java program that directly calls into sun.* packages is not
> guaranteed to work on all Java-compatible platforms. In fact, such a
> program is not guaranteed to work even in future versions on the same
> platform.
> "In general, writing java programs that rely on sun.* is risky: they
> are not portable, and are not supported."
> 
> Why should we support them when Sun don't even claim to? 

You know why we're doing this.  If Sun wanted to, I assume they could
fix the problem in the VM.

> Furthermore,
> by taking a stance of 1) or 2), we are actively helping push Sun's
> advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors
> who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a
> strong stand against these packages.

Because I want a user population the size of Sun's or IBM's, not GNU
Classpath's.

> 
> Harmony will be great, regardless of whether the sun.* packages are
> there. There will be at least one program that doesn't work because of
> this (but that's been fixed already) -- there will be others in the
> future. The adoption of Harmony as an open-source JVM will happen
> regardless of the sun.* packages. Some people will complain, some will
> vociferously declare that the suncompat module should be there by
> default. Some programs won't work. If we go with option 2), they can
> be made to work or to raise the issue that the program is not a
> portable Java application (or both).
> 
> I strongly urge everyone to vote against the suncompat module being on
> the classpath by default. In two years time, we will be able to look
> back to this post and either congratulate ourselves on a wise decision
> made now, or rue the day that we gave up the chance to allow a strong
> stand on the restriction of sun.* packages for any running code.

I think you are really overstating it right now.  This is a reasonable
fight to have at 1.0 time, but for snapshots?  Jeeze - I'm thrilled that
users want to spend time using our software right now.

We just want to make it easy for early adopters.  We're not going to
"support" these classes.

geir

> 
> Alex.
> 
> PS The whole 'on the classpath for runtime but not for compile time'
> is completely bogus. If it's on the classpath, then an IDE such as
> Eclipse that provides its own compiler will still be able to compile
> against the class, as will e.g. references in JSPs for application
> servers that suppy their own compilers. It's either in the classpath,
> or it's not. If it's visible at runtime, then it's visible to any
> other 3rd party compiler, even if we hack Harmony's JavaC to refuse to
> compile against it.

I wonder if we could come to some agreement with Eclipse to start for an
 annotation that achieves our goal here...  So then eclipse will point
out the problem...


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: RE: [general] compatibility packages

[Alex Blewitt <al...@gmail.com>]

On 12/08/06, Jeroen Frijters <je...@sumatra.nl> wrote:
> You also keep hammering on CharToByteConverter as an example of bad code
> that should trivially be fixed (and it obviously should, if possible,
> but it's not always that easy), but there is also code out there that
> uses sun.* classes to do things that are impossible to do with the
> documented APIs. How would you fix those?

You can't trivially fix such problems; in each case, someone has to
debug and find out where the dependency is. And let's face it, if
someone refers to sun.foo.Bar (and it's not in suncompat.jar in the
first instance) they're going to be in exactly the same situation.
It's only really for the benefit of people who aren't the first to
fall over (e.g. the BASE64 encoder).

> However, I've spoken with Mark Reinhold about this issue and he told me
> that Sun sometimes reverts changes to sun.* classes because a customer
> complains that it broke their code.

And with this statement, you've highlighed precisely why we shouldn't
include suncompat.jar by default. Because once we do, there's no going
back -- ever. If we do, we risk the wrath of some user down in the
future.

(Very good related material can be found at
http://inside-swt.blogspot.com/2006/06/deprecated-is-lie.html and
http://www.xom.nu/designprinciples.xhtml)

> I asked him if they would be documenting these classes when they do this, but he
> said they wouldn't. So they seem to live in a dream world where on the one hand
> they want to discourage usage of sun.* and on the other hand continue to support it.

Surely we should be working towards that aim as well? I fail to see
how this helps anyone in the medium or long term. If we include it by
default *now*, we include it by default *for ever*. If we don't
include it by default, but have a FAQ up that tells people about the
workarounds, then those people for whom it's a problem can fix it, and
the rest of the world can get on without it quite happily. But adding
it by default is a one-way street that can never be reversed.

> Like compatibility in general this is a hard problem and we need to take
> a pragmatic approach and I really like the current plan of having an
> optional suncompat module.

There seems to be three options we can go forwards with:

1) Neither have suncompat.jar nor make it default (i.e. where we were
before last week)
2) Have suncompat.jar, but don't make it default (instead, provide
FAQs like http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm)
3) Have suncompat.jar, and make it default.

The transition from 1->2->3 is irreversible, and the decision to go
down that path should be considered carefully for both immediate
short-term (My app doesn't run on Harmony!) and medium- and long-term
goals (non-Sun VMs shouldn't have/need sun. classes)

I strongly disagree with the suggestion that we must do 3 to support a
tiny proportion of apps that may go against Sun's FAQ
(http://java.sun.com/products/jdk/faq/faq-sun-packages.html). Indeed,
they go as far as saying that:

"The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not
guaranteed to work on all Java-compatible platforms. In fact, such a
program is not guaranteed to work even in future versions on the same
platform.
"In general, writing java programs that rely on sun.* is risky: they
are not portable, and are not supported."

Why should we support them when Sun don't even claim to? Furthermore,
by taking a stance of 1) or 2), we are actively helping push Sun's
advice; as opposed to other commercial (IBM, Apple etc.) JVM vendors
who have folded. Other VM libraries (e.g. Gnu Classpath) have taken a
strong stand against these packages.

Harmony will be great, regardless of whether the sun.* packages are
there. There will be at least one program that doesn't work because of
this (but that's been fixed already) -- there will be others in the
future. The adoption of Harmony as an open-source JVM will happen
regardless of the sun.* packages. Some people will complain, some will
vociferously declare that the suncompat module should be there by
default. Some programs won't work. If we go with option 2), they can
be made to work or to raise the issue that the program is not a
portable Java application (or both).

I strongly urge everyone to vote against the suncompat module being on
the classpath by default. In two years time, we will be able to look
back to this post and either congratulate ourselves on a wise decision
made now, or rue the day that we gave up the chance to allow a strong
stand on the restriction of sun.* packages for any running code.

Alex.

PS The whole 'on the classpath for runtime but not for compile time'
is completely bogus. If it's on the classpath, then an IDE such as
Eclipse that provides its own compiler will still be able to compile
against the class, as will e.g. references in JSPs for application
servers that suppy their own compilers. It's either in the classpath,
or it's not. If it's visible at runtime, then it's visible to any
other 3rd party compiler, even if we hack Harmony's JavaC to refuse to
compile against it.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Sun, Aug 13, 2006 at 06:38:13PM -0400, Geir Magnusson Jr wrote:
>>
>> Dalibor Topic wrote:
>>> On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote:
>>>> Dalibor Topic wrote:
>>>>> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
>>>>> but you should trust us anyway on our other claims)' is not a very 
>>>>> compelling tag line either.
>>>> But this isn't what we're trying to say, so please don't put words in
>>>> our mouth.
>>>>
>>>> The issue is removing speedbumps (no matter who put them there) on the
>>>> road to users working with Harmony.
>>>>
>>>> People are busy, and don't generally have a lot of free time to tinker.
>>>>    Time is a very valuable and scarce thing.  If someone chooses to
>>>> *invest* some of their time trying out Harmony, lets make it as smooth
>>>> as possible, and be as appreciative as possible.
>>>>
>>>> Sure, they may be doing the Wrong Thing by using software that makes the
>>>> common mistake of using an internal Sun class, but that's really a
>>>> secondary concern.
>>> I believe you've largely misunderstood what I said, unfortunately. There
>>> is no them vs. us here, and I am not trying to put words in mouths, or
>>> playing wiesel wording and framing games. 
>> Ok - sorry.
>>
> 
> My apologies as well, for not being clear enough.
> 
>>> Look, I agree with pretty much with all you say, my point is that we 
>>> can't compete with Sun on the ability to run 100% of code written for 
>>> their VM, suncompat.jar or not. As Stefano said (he got the meaning 
>>> of what I tried to get accross), that's not a game we can win. But 
>>> we've got other qualities, as you've mentioned, and which matter to our 
>>> users. Noone is using our VMs for their sun.* classes.
>> And we're not doing this to be able to compete with Sun on their
>> implementation of sun.*.  We're doing it simply to make it easy for
>> people to *try* Harmony *right now*.
> 
> I agree, I just don't think not having sun.* (on a case by case basis)
> makes a negative difference. It doesn't stop people from trying our code right 
> now easily. It only stops them from using functionality we haven't
> implemented yet, but then the user experience is not going to be particularly 
> different from them trying out other code where we haven't got an
> implementation for. Given that we're all working on works in progress, a
> few rough edges along the way should be expected by the kind tester, and
> that our target audience is very intelligent and realizes that, I don't
> see a particularly burning issue wrt to sun.* classes specifically.
> 
> See, what makes me very uncomfortable about it is the sort of
> maintenance issues that Sun and IBM and whoever else needs to maintain
> sun.* classes in their VMs, have to go through, as Jeroen described it:
> backing out changes in order to keep broken code around since some
> customer may need it. That's not a good thing. I'd rather carefully consider
> if there is no better way to avoid such problems from the start on a 
> case by case basis, than copying Sun's implementation's internals without 
> weighing the merits and disadvantages of their designs. As Alex said,
> it's a one way road that we can't go back from, once we start including
> proprietary class library extensions, and have users relying on them.

<sigh>

I don't agree that weaning people off is impossible.   And even if it
is, right now we're talking about one base 64 encoding class....

> 
>>> The only interaction we've had with users so far on this issue has
>>> shown that the user was able to spot a problem in his code, improve
>>> it, and contributed useful feedback. The first two things would not have
>>> happened if we had a suncompat.jar, and everyone seems to be better off
>>> with the current outcome. Was it a speedump? Maybe. It helped the user,
>>> though, and we should be as appreciative as possible about having such helpful
>>> speedbumps, IMHO, that make people aware of potential migration issues
>>> with their code, and make users come to us to give us their appreciatd 
>>> feedback in the first place, rather than speeding through without a ...
>>> (and here I lack a suitable driving analogy, but I hope you catch my 
>>> drift anyway)
>> What if the problem was in Weblogic?  What if the user couldn't get it
>> fixed?
> 
> I don't know. We could simply wait and see what happens when someone
> tries to run Weblogic on our VMs. That hasn't happened so far, at least
> not that I heard of it, so we could adopt the YAGNI approach for now.

You're missing the point.  I don't want to play fetch me a rock here -
for all the Martin's of the world that send us a mail, look into the
problem, decide to take action, etc. there are probably at least 100 who
just say "eh. it's broken. figures.  open source crap..." and move on.

Right now, we need to engage those 100 people.  Even if we never can
stop supporting that base64 encoder class, I don't think it's a high
price to pay.  After all, we know Sun isn't going to change it :)

> 
> I mean, if we are lucky, by the time our users start doing that, Weblogic 
> may no longer be relevant for them, because they all switched to Geronimo, 
> for example, right? ;)

I hope we've got a pretty strong story mid next year, and I'm fairly
sure that BEA will still be around :)

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Sun, Aug 13, 2006 at 06:38:13PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> > On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote:
> >>
> >> Dalibor Topic wrote:
> >>> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
> >>> but you should trust us anyway on our other claims)' is not a very 
> >>> compelling tag line either.
> >> But this isn't what we're trying to say, so please don't put words in
> >> our mouth.
> >>
> >> The issue is removing speedbumps (no matter who put them there) on the
> >> road to users working with Harmony.
> >>
> >> People are busy, and don't generally have a lot of free time to tinker.
> >>    Time is a very valuable and scarce thing.  If someone chooses to
> >> *invest* some of their time trying out Harmony, lets make it as smooth
> >> as possible, and be as appreciative as possible.
> >>
> >> Sure, they may be doing the Wrong Thing by using software that makes the
> >> common mistake of using an internal Sun class, but that's really a
> >> secondary concern.
> > 
> > I believe you've largely misunderstood what I said, unfortunately. There
> > is no them vs. us here, and I am not trying to put words in mouths, or
> > playing wiesel wording and framing games. 
> 
> Ok - sorry.
> 

My apologies as well, for not being clear enough.

> > 
> > Look, I agree with pretty much with all you say, my point is that we 
> > can't compete with Sun on the ability to run 100% of code written for 
> > their VM, suncompat.jar or not. As Stefano said (he got the meaning 
> > of what I tried to get accross), that's not a game we can win. But 
> > we've got other qualities, as you've mentioned, and which matter to our 
> > users. Noone is using our VMs for their sun.* classes.
> 
> And we're not doing this to be able to compete with Sun on their
> implementation of sun.*.  We're doing it simply to make it easy for
> people to *try* Harmony *right now*.

I agree, I just don't think not having sun.* (on a case by case basis)
makes a negative difference. It doesn't stop people from trying our code right 
now easily. It only stops them from using functionality we haven't
implemented yet, but then the user experience is not going to be particularly 
different from them trying out other code where we haven't got an
implementation for. Given that we're all working on works in progress, a
few rough edges along the way should be expected by the kind tester, and
that our target audience is very intelligent and realizes that, I don't
see a particularly burning issue wrt to sun.* classes specifically.

See, what makes me very uncomfortable about it is the sort of
maintenance issues that Sun and IBM and whoever else needs to maintain
sun.* classes in their VMs, have to go through, as Jeroen described it:
backing out changes in order to keep broken code around since some
customer may need it. That's not a good thing. I'd rather carefully consider
if there is no better way to avoid such problems from the start on a 
case by case basis, than copying Sun's implementation's internals without 
weighing the merits and disadvantages of their designs. As Alex said,
it's a one way road that we can't go back from, once we start including
proprietary class library extensions, and have users relying on them.

> > 
> > The only interaction we've had with users so far on this issue has
> > shown that the user was able to spot a problem in his code, improve
> > it, and contributed useful feedback. The first two things would not have
> > happened if we had a suncompat.jar, and everyone seems to be better off
> > with the current outcome. Was it a speedump? Maybe. It helped the user,
> > though, and we should be as appreciative as possible about having such helpful
> > speedbumps, IMHO, that make people aware of potential migration issues
> > with their code, and make users come to us to give us their appreciatd 
> > feedback in the first place, rather than speeding through without a ...
> > (and here I lack a suitable driving analogy, but I hope you catch my 
> > drift anyway)
> 
> What if the problem was in Weblogic?  What if the user couldn't get it
> fixed?

I don't know. We could simply wait and see what happens when someone
tries to run Weblogic on our VMs. That hasn't happened so far, at least
not that I heard of it, so we could adopt the YAGNI approach for now.

I mean, if we are lucky, by the time our users start doing that, Weblogic 
may no longer be relevant for them, because they all switched to Geronimo, 
for example, right? ;)

cheers,
dalibor topic

> geir
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote:
>>
>> Dalibor Topic wrote:
>>> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
>>> but you should trust us anyway on our other claims)' is not a very 
>>> compelling tag line either.
>> But this isn't what we're trying to say, so please don't put words in
>> our mouth.
>>
>> The issue is removing speedbumps (no matter who put them there) on the
>> road to users working with Harmony.
>>
>> People are busy, and don't generally have a lot of free time to tinker.
>>    Time is a very valuable and scarce thing.  If someone chooses to
>> *invest* some of their time trying out Harmony, lets make it as smooth
>> as possible, and be as appreciative as possible.
>>
>> Sure, they may be doing the Wrong Thing by using software that makes the
>> common mistake of using an internal Sun class, but that's really a
>> secondary concern.
> 
> I believe you've largely misunderstood what I said, unfortunately. There
> is no them vs. us here, and I am not trying to put words in mouths, or
> playing wiesel wording and framing games. 

Ok - sorry.

> 
> Look, I agree with pretty much with all you say, my point is that we 
> can't compete with Sun on the ability to run 100% of code written for 
> their VM, suncompat.jar or not. As Stefano said (he got the meaning 
> of what I tried to get accross), that's not a game we can win. But 
> we've got other qualities, as you've mentioned, and which matter to our 
> users. Noone is using our VMs for their sun.* classes.

And we're not doing this to be able to compete with Sun on their
implementation of sun.*.  We're doing it simply to make it easy for
people to *try* Harmony *right now*.

> 
> The only interaction we've had with users so far on this issue has
> shown that the user was able to spot a problem in his code, improve
> it, and contributed useful feedback. The first two things would not have
> happened if we had a suncompat.jar, and everyone seems to be better off
> with the current outcome. Was it a speedump? Maybe. It helped the user,
> though, and we should be as appreciative as possible about having such helpful
> speedbumps, IMHO, that make people aware of potential migration issues
> with their code, and make users come to us to give us their appreciatd 
> feedback in the first place, rather than speeding through without a ...
> (and here I lack a suitable driving analogy, but I hope you catch my 
> drift anyway)

What if the problem was in Weblogic?  What if the user couldn't get it
fixed?

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> > 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
> > but you should trust us anyway on our other claims)' is not a very 
> > compelling tag line either.
> 
> But this isn't what we're trying to say, so please don't put words in
> our mouth.
> 
> The issue is removing speedbumps (no matter who put them there) on the
> road to users working with Harmony.
> 
> People are busy, and don't generally have a lot of free time to tinker.
>    Time is a very valuable and scarce thing.  If someone chooses to
> *invest* some of their time trying out Harmony, lets make it as smooth
> as possible, and be as appreciative as possible.
> 
> Sure, they may be doing the Wrong Thing by using software that makes the
> common mistake of using an internal Sun class, but that's really a
> secondary concern.

I believe you've largely misunderstood what I said, unfortunately. There
is no them vs. us here, and I am not trying to put words in mouths, or
playing wiesel wording and framing games. 

Look, I agree with pretty much with all you say, my point is that we 
can't compete with Sun on the ability to run 100% of code written for 
their VM, suncompat.jar or not. As Stefano said (he got the meaning 
of what I tried to get accross), that's not a game we can win. But 
we've got other qualities, as you've mentioned, and which matter to our 
users. Noone is using our VMs for their sun.* classes.

The only interaction we've had with users so far on this issue has
shown that the user was able to spot a problem in his code, improve
it, and contributed useful feedback. The first two things would not have
happened if we had a suncompat.jar, and everyone seems to be better off
with the current outcome. Was it a speedump? Maybe. It helped the user,
though, and we should be as appreciative as possible about having such helpful
speedbumps, IMHO, that make people aware of potential migration issues
with their code, and make users come to us to give us their appreciatd 
feedback in the first place, rather than speeding through without a ...
(and here I lack a suitable driving analogy, but I hope you catch my 
drift anyway)

cheers,
dalibor topic

> 
> > 
> > The 100% like Sun tag line has shown time over time to be false for IBM's 
> > VM for example, since IBM does not ship some of the classes Sun does, so 
> > vm-specific code using them fails in funny ways on it.
> > 
> > But that's how it is, 100% maching semantics is practially only possible by 
> > using the exact same sources. And we're deliberately not doing that, and 
> > making our own decisions on quirks of the spec.
> 
> And we're making decisions to behave like the RI.
> 
> Our goal - yours and ours - is to get people onto open source and
> free-as-in-Stallman implementations of Java.
> 
> Given that we're trying to be an alternative to proprietary
> implementations that are a) free-as-in-beer and b) technically excellent
> and that licensing is mostly irrelevant to a vast number of users,
> taking down the roadblocks is prudent.  We need to make the switching
> cost as low as possible.
> 
> > 
> > Harmony is *always* going to run fewer apps than the leading brand,
> > unless it uses the exact same set of sources, no matter what sort of
> > outlandish marketing claims we chose to use as tag lines.
> 
> We never chose any of those marketing claims.  You did.  Our goals are
> compatibility with the spec, high quality, portability, modularity and
> transparent, open community.  One of the tactics to achieve that is to
> hold our nose and implement necessary sun.* to help users switch.
> 
> At the same time, we can call attention to the problem, and we actually
> have a very good story for people - "bring apps over using our sun
> compatibility library, and assuming we do something like have it
> optionally log usages etc, and then let those logging/whatever features
> help you find and remove these problems..."
> 
> > 
> >> I believe that everyone wants to reduce dependencies on the non-API
> >> types.  It is a millstone for IBM and Sun and BEA etc if they cannot
> >> modify their implementations without customers coming down on them.  But
> >> at this point we cannot call the shots from Harmony.
> > 
> > We can't call the shots on IBM's, Sun's and BEA's implementation anyway,
> > unless they switch to Harmony ;) What we can do is to help people improve
> > their application code by helping them notice that they are using buggy,
> > implementation-dependant software.
> 
> Right.  And the only way they are going to do that is if they use
> Harmony, so we can tell them.  And they aren't going to use Harmony - at
> least right now - if we're in their face telling them that they are
> wrong, and therefore we won't let their programs run.
> 
> geir
> 
> > 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Marketing Harmony [was Re: [general] compatibility packages]

[Dalibor Topic <ro...@kaffe.org>]

On Sat, Aug 12, 2006 at 08:19:33PM -0400, Martin Cordova wrote:
> I think that Stefano points to the right direction. To be more
> specific, Harmony will gain market share if it can run the most
> popular java applications, mostly open source (tomcat, resin, jetty,
> eclipse, hsql, mckoi, etc), and providing an efficient implementation
> of the basic libraries.
> 
> To add an additional factor, in some countries like Venezuela,
> governments started a policy about adopting free/open software (in the
> GNU sense) for all its activities, whenever/wherever possible. In the
> particular case of Venezuela, it has been very aggressive, affecting
> the way of doing IT business with the public sector, and there was a
> lobby group that has put strong pressure trying to forbid the usage of
> Java as a technology based on the false statement that this is
> propietary technology, not compatible with the principles of free and
> open source software.

Yeah, I've been aware of that.

> 
> There has been a lot of discussion and lobby around the subject, and
> of course the subject of the forthcomming great Harmony JVM has been
> at the center of the debate. I was told that even the Kaffe people
> visited Venezuela and shared some time with the Ministry of Science
> and Technology, explaining the current state of free Java - I cannot
> confirm this. 

Interesting. I recall seeing slides about setting up Kaffe+Tomcat from
Venezuela, but don't know who from us Kaffe folks went there. If you
have more information on the usage of Kaffe in Venezuela, please send it
my way. Thanks for bringing this up!

cheers,
dalibor topic

> My company has invested some resources on this
> public-relations too, protecting our current and future position, as
> well as our investment on our Java framework
> 
> To make the long story short, all we need here is a free JVM + JIT
> that can run popular server-side webapps and Eclipse, and if possible
> as fast as the IBM JVM does ;) -- leaving other interpreted options as
> perl, php and ruby eating the dust...
> 
> Please Harmony commandos, hurry up!
> just joking :)
> 
> Regards,
> Martin
> 
> 
> On 8/12/06, Stefano Mazzocchi <st...@apache.org> wrote:
> >Dalibor Topic wrote:
> >
> >>> 'Harmony - runs fewer apps than the leading brand' is hardly a
> >>> compelling tag line.
> >>
> >> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish 
> >claim,
> >> but you should trust us anyway on our other claims)' is not a very
> >> compelling tag line either.
> >>
> >> The 100% like Sun tag line has shown time over time to be false for IBM's
> >> VM for example, since IBM does not ship some of the classes Sun does, so
> >> vm-specific code using them fails in funny ways on it.
> >>
> >> But that's how it is, 100% maching semantics is practially only possible 
> >by
> >> using the exact same sources. And we're deliberately not doing that, and
> >> making our own decisions on quirks of the spec.
> >>
> >> Harmony is *always* going to run fewer apps than the leading brand,
> >> unless it uses the exact same set of sources, no matter what sort of
> >> outlandish marketing claims we chose to use as tag lines.
> >
> >Let me try to be creative for a second, marketing wise.
> >
> >If we enter a pissing contest with Sun over who runs more apps, we lose.
> >This is not what it's all about.
> >
> >Look at HTTPD, they never had to claim that they were faster or more
> >secure or more useful than other web servers, they "just" needed to do
> >follow the protocols precisely and work under all circumstances and all
> >kinds of attack and respond quickly to vulnerabilities and to feature
> >requests.
> >
> >Just like HTTPD, we can't change the "protocol", but we can talk to
> >those who do, channeling ours and our users' feedback.
> >
> >Just like HTTPD, we don't win if we are faster, or if we have better
> >marketing brochures... we win if we can make our users happy.
> >
> >Harmony's first goal is to pass certification to be able to enter the
> >ball park (being legally admitted to play, that is).
> >
> >But the real game is to run the apps that our users care for.
> >
> >What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK...
> >and at comparable speeds. And guess what? it's open source: if you can
> >make it even faster, hook it up to your favorite profiler/debugger, or
> >whatever you feel you need to implement that won't ruin compatibility
> >with the spec, we'll love to incorporate your patches.
> >
> >It might take a while before "user innovation" really starts to kick in,
> >after that, but sure enough, we'll have our "tab browsing"-like or
> >"apache module"-like user-suggested feature that Sun's VM won't have but
> >will still allow us to pass certification.
> >
> >And *then* is when the real fun begins.
> >
> >--
> >Stefano.
> >
> >
> >---------------------------------------------------------------------
> >Terms of use : http://incubator.apache.org/harmony/mailing.html
> >To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> 
> -- 
> Dinamica - RADical J2EE framework
> open source, easy and powerful
> http://www.martincordova.com
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Marketing Harmony [was Re: [general] compatibility packages]

[Geir Magnusson Jr <ge...@pobox.com>]

Martin Cordova wrote:
> To make the long story short, all we need here is a free JVM + JIT
> that can run popular server-side webapps and Eclipse, and if possible
> as fast as the IBM JVM does ;) -- leaving other interpreted options as
> perl, php and ruby eating the dust...

+1

> Please Harmony commandos, hurry up!
> just joking :)

We're hurrying!  And if you want to help, please do!  We need it.

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Marketing Harmony [was Re: [general] compatibility packages]

[Martin Cordova <ma...@gmail.com>]

I think that Stefano points to the right direction. To be more
specific, Harmony will gain market share if it can run the most
popular java applications, mostly open source (tomcat, resin, jetty,
eclipse, hsql, mckoi, etc), and providing an efficient implementation
of the basic libraries.

To add an additional factor, in some countries like Venezuela,
governments started a policy about adopting free/open software (in the
GNU sense) for all its activities, whenever/wherever possible. In the
particular case of Venezuela, it has been very aggressive, affecting
the way of doing IT business with the public sector, and there was a
lobby group that has put strong pressure trying to forbid the usage of
Java as a technology based on the false statement that this is
propietary technology, not compatible with the principles of free and
open source software.

There has been a lot of discussion and lobby around the subject, and
of course the subject of the forthcomming great Harmony JVM has been
at the center of the debate. I was told that even the Kaffe people
visited Venezuela and shared some time with the Ministry of Science
and Technology, explaining the current state of free Java - I cannot
confirm this. My company has invested some resources on this
public-relations too, protecting our current and future position, as
well as our investment on our Java framework

To make the long story short, all we need here is a free JVM + JIT
that can run popular server-side webapps and Eclipse, and if possible
as fast as the IBM JVM does ;) -- leaving other interpreted options as
perl, php and ruby eating the dust...

Please Harmony commandos, hurry up!
just joking :)

Regards,
Martin


On 8/12/06, Stefano Mazzocchi <st...@apache.org> wrote:
> Dalibor Topic wrote:
>
> >> 'Harmony - runs fewer apps than the leading brand' is hardly a
> >> compelling tag line.
> >
> > 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim,
> > but you should trust us anyway on our other claims)' is not a very
> > compelling tag line either.
> >
> > The 100% like Sun tag line has shown time over time to be false for IBM's
> > VM for example, since IBM does not ship some of the classes Sun does, so
> > vm-specific code using them fails in funny ways on it.
> >
> > But that's how it is, 100% maching semantics is practially only possible by
> > using the exact same sources. And we're deliberately not doing that, and
> > making our own decisions on quirks of the spec.
> >
> > Harmony is *always* going to run fewer apps than the leading brand,
> > unless it uses the exact same set of sources, no matter what sort of
> > outlandish marketing claims we chose to use as tag lines.
>
> Let me try to be creative for a second, marketing wise.
>
> If we enter a pissing contest with Sun over who runs more apps, we lose.
> This is not what it's all about.
>
> Look at HTTPD, they never had to claim that they were faster or more
> secure or more useful than other web servers, they "just" needed to do
> follow the protocols precisely and work under all circumstances and all
> kinds of attack and respond quickly to vulnerabilities and to feature
> requests.
>
> Just like HTTPD, we can't change the "protocol", but we can talk to
> those who do, channeling ours and our users' feedback.
>
> Just like HTTPD, we don't win if we are faster, or if we have better
> marketing brochures... we win if we can make our users happy.
>
> Harmony's first goal is to pass certification to be able to enter the
> ball park (being legally admitted to play, that is).
>
> But the real game is to run the apps that our users care for.
>
> What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK...
> and at comparable speeds. And guess what? it's open source: if you can
> make it even faster, hook it up to your favorite profiler/debugger, or
> whatever you feel you need to implement that won't ruin compatibility
> with the spec, we'll love to incorporate your patches.
>
> It might take a while before "user innovation" really starts to kick in,
> after that, but sure enough, we'll have our "tab browsing"-like or
> "apache module"-like user-suggested feature that Sun's VM won't have but
> will still allow us to pass certification.
>
> And *then* is when the real fun begins.
>
> --
> Stefano.
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Marketing Harmony [was Re: [general] compatibility packages]

[Stefano Mazzocchi <st...@apache.org>]

Dalibor Topic wrote:

>> 'Harmony - runs fewer apps than the leading brand' is hardly a
>> compelling tag line.
> 
> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
> but you should trust us anyway on our other claims)' is not a very 
> compelling tag line either.
> 
> The 100% like Sun tag line has shown time over time to be false for IBM's 
> VM for example, since IBM does not ship some of the classes Sun does, so 
> vm-specific code using them fails in funny ways on it.
> 
> But that's how it is, 100% maching semantics is practially only possible by 
> using the exact same sources. And we're deliberately not doing that, and 
> making our own decisions on quirks of the spec.
> 
> Harmony is *always* going to run fewer apps than the leading brand,
> unless it uses the exact same set of sources, no matter what sort of
> outlandish marketing claims we chose to use as tag lines.

Let me try to be creative for a second, marketing wise.

If we enter a pissing contest with Sun over who runs more apps, we lose.
This is not what it's all about.

Look at HTTPD, they never had to claim that they were faster or more
secure or more useful than other web servers, they "just" needed to do
follow the protocols precisely and work under all circumstances and all
kinds of attack and respond quickly to vulnerabilities and to feature
requests.

Just like HTTPD, we can't change the "protocol", but we can talk to
those who do, channeling ours and our users' feedback.

Just like HTTPD, we don't win if we are faster, or if we have better
marketing brochures... we win if we can make our users happy.

Harmony's first goal is to pass certification to be able to enter the
ball park (being legally admitted to play, that is).

But the real game is to run the apps that our users care for.

What a slogan? Gump on Harmony runs *exactly* like Gump on Sun's JDK...
and at comparable speeds. And guess what? it's open source: if you can
make it even faster, hook it up to your favorite profiler/debugger, or
whatever you feel you need to implement that won't ruin compatibility
with the spec, we'll love to incorporate your patches.

It might take a while before "user innovation" really starts to kick in,
after that, but sure enough, we'll have our "tab browsing"-like or
"apache module"-like user-suggested feature that Sun's VM won't have but
will still allow us to pass certification.

And *then* is when the real fun begins.

-- 
Stefano.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
> but you should trust us anyway on our other claims)' is not a very 
> compelling tag line either.

But this isn't what we're trying to say, so please don't put words in
our mouth.

The issue is removing speedbumps (no matter who put them there) on the
road to users working with Harmony.

People are busy, and don't generally have a lot of free time to tinker.
   Time is a very valuable and scarce thing.  If someone chooses to
*invest* some of their time trying out Harmony, lets make it as smooth
as possible, and be as appreciative as possible.

Sure, they may be doing the Wrong Thing by using software that makes the
common mistake of using an internal Sun class, but that's really a
secondary concern.

> 
> The 100% like Sun tag line has shown time over time to be false for IBM's 
> VM for example, since IBM does not ship some of the classes Sun does, so 
> vm-specific code using them fails in funny ways on it.
> 
> But that's how it is, 100% maching semantics is practially only possible by 
> using the exact same sources. And we're deliberately not doing that, and 
> making our own decisions on quirks of the spec.

And we're making decisions to behave like the RI.

Our goal - yours and ours - is to get people onto open source and
free-as-in-Stallman implementations of Java.

Given that we're trying to be an alternative to proprietary
implementations that are a) free-as-in-beer and b) technically excellent
and that licensing is mostly irrelevant to a vast number of users,
taking down the roadblocks is prudent.  We need to make the switching
cost as low as possible.

> 
> Harmony is *always* going to run fewer apps than the leading brand,
> unless it uses the exact same set of sources, no matter what sort of
> outlandish marketing claims we chose to use as tag lines.

We never chose any of those marketing claims.  You did.  Our goals are
compatibility with the spec, high quality, portability, modularity and
transparent, open community.  One of the tactics to achieve that is to
hold our nose and implement necessary sun.* to help users switch.

At the same time, we can call attention to the problem, and we actually
have a very good story for people - "bring apps over using our sun
compatibility library, and assuming we do something like have it
optionally log usages etc, and then let those logging/whatever features
help you find and remove these problems..."

> 
>> I believe that everyone wants to reduce dependencies on the non-API
>> types.  It is a millstone for IBM and Sun and BEA etc if they cannot
>> modify their implementations without customers coming down on them.  But
>> at this point we cannot call the shots from Harmony.
> 
> We can't call the shots on IBM's, Sun's and BEA's implementation anyway,
> unless they switch to Harmony ;) What we can do is to help people improve
> their application code by helping them notice that they are using buggy,
> implementation-dependant software.

Right.  And the only way they are going to do that is if they use
Harmony, so we can tell them.  And they aren't going to use Harmony - at
least right now - if we're in their face telling them that they are
wrong, and therefore we won't let their programs run.

geir

> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

RE: [general] compatibility packages

[Jeroen Frijters <je...@sumatra.nl>]

Dalibor Topic wrote:
> So if I can't run the sun.misc.Unsafe remote exploit on 
> Harmony it is a failure? ;)

You keep referring to this, but IMO this is a mischaracterization of the
exploit. The exploit used a bug in JavaScript that allowed access to the
sun.* package, that was the real problem not the sun.misc.Unsafe class.

You also keep hammering on CharToByteConverter as an example of bad code
that should trivially be fixed (and it obviously should, if possible,
but it's not always that easy), but there is also code out there that
uses sun.* classes to do things that are impossible to do with the
documented APIs. How would you fix those?

BTW, that was a retorical question, because I already know your answer:
that's rubbish software that won't work reliably on Sun's JRE anyway, so
why should we support it?

However, I've spoken with Mark Reinhold about this issue and he told me
that Sun sometimes reverts changes to sun.* classes because a customer
complains that it broke their code. I asked him if they would be
documenting these classes when they do this, but he said they wouldn't.
So they seem to live in a dream world where on the one hand they want to
discourage usage of sun.* and on the other hand continue to support it.

Like compatibility in general this is a hard problem and we need to take
a pragmatic approach and I really like the current plan of having an
optional suncompat module.

Regards,
Jeroen

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Fri, Aug 11, 2006 at 03:11:48PM +0100, Tim Ellison wrote:
> Dalibor Topic wrote:
> > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
> >> Dalibor Topic wrote:
> >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
> >>>> Mikhail Loenko wrote:
> >>>>> The problem is Base64 functionality is unavailable through the
> >>>>> standard API, so people have a choice either use unportable sun.*,
> >>>>> o.a.h.*, etc or create the coder from scratch
> >>>> Understood, I think people are 'driven' to using the non-API types
> >>>> though necessity rather than doing so by mistake.
> >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
> >>> recommends using Apache Commons Codec for projects compatible with the
> >>> Apache license.
> >>>
> >>> Amateur developers use non-standard classes because they are too lazy 
> >>> to think for themselves, and accordingly copy broken code around projects. 
> >>> Alas, a language designed to appeal to the masses naturally attracts a 
> >>> lot of people who'd have trouble producing portable code in any programming 
> >>> language. :)
> >> I was being charitable.  For sure many such usages can be easily
> >> avoided, but in other cases no so easily; like CharToByteConverter would
> >> require duplicating a wad of data, and I don't know of any third-party
> >> impl. of Unsafe.
> > 
> > Is there something that CharToByteConverter does that
> > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> > code using CharToByteConverter in years.
> 
> If you want to duplicate the char conversion data then sure, but taking
> a multi-MB hit isn't palatable to many apps when sun.io is sitting there
> smiling at them.
> 

java.nio.charset.CharsetEncoder is right there, a standard API, and does
not add a multi-MB hit. ICU does, but when the choice is between
maintainable applications or software slapped together in hope that it
works, it's clear to me what to chose.

> I saw a few uses when testing apps, but maybe I was unlucky. For
> example, Xalan was using it until it was pointed it out last year
> (http://issues.apache.org/jira/browse/XALANJ-2087).

It kind of proves the point that there is no good reason to use sun.io
classes today.

> > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
> > to the JVM JSR not being ahead thinking enough to specify an API for low-level 
> > operations. It may or may not work depedending on how a VM interprets
> > the non-existent spec for that class, so it is practically useless,
> > unless it is running on the VM it was written on, i.e. Sun's. It may or
> > may not work by chance, rather than by virtue.
> > 
> > That holds in general for any code using implementation-specific 
> > interfaces.
> 
> Exactly.
> 
> >> We should appeal to app developers to change implementation dependent
> >> code (even provide a recipe book of recommended solutions), but be
> >> pragmatic about the need to run the current version.  In many cases it
> >> may be beyond the apps immediate sphere of influence (i.e. dependent
> >> libraries).  If everyone responded as quickly and effectively as Martin
> >> we would have no worries.
> > 
> > We've been doing that for years. See the GNU Classpath migration page in
> > the Wiki that describes how to fix such broken code in many cases.
> 
> Ack -- I see it here (just so others can find it too).
> http://developer.classpath.org/mediation/ClasspathMigration
> 
> > Being 'pragmatic' solves nothing, it just encourages people to
> > continue behaving in dumb ways, because their code still may run,
> > somehow, even if there is no way for Harmony to ensure that it will
> > behave as they expect from whatever buggy Sun JDK they are using to
> > run it usually in the corner cases, because there is no spec, and
> > there are no tests.
> 
> It's pragmatic because as I said, sometimes it is beyond the immediate
> control of the application, and sometimes you won't get a second chance
> to demonstrate your wares.

So if I can't run the sun.misc.Unsafe remote exploit on Harmony it is a
failure? ;)

> 'Harmony - runs fewer apps than the leading brand' is hardly a
> compelling tag line.

'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim, 
but you should trust us anyway on our other claims)' is not a very 
compelling tag line either.

The 100% like Sun tag line has shown time over time to be false for IBM's 
VM for example, since IBM does not ship some of the classes Sun does, so 
vm-specific code using them fails in funny ways on it.

But that's how it is, 100% maching semantics is practially only possible by 
using the exact same sources. And we're deliberately not doing that, and 
making our own decisions on quirks of the spec.

Harmony is *always* going to run fewer apps than the leading brand,
unless it uses the exact same set of sources, no matter what sort of
outlandish marketing claims we chose to use as tag lines.

> I believe that everyone wants to reduce dependencies on the non-API
> types.  It is a millstone for IBM and Sun and BEA etc if they cannot
> modify their implementations without customers coming down on them.  But
> at this point we cannot call the shots from Harmony.

We can't call the shots on IBM's, Sun's and BEA's implementation anyway,
unless they switch to Harmony ;) What we can do is to help people improve
their application code by helping them notice that they are using buggy,
implementation-dependant software.

> > Awarding incompetence doesn't solve the problem. That being said, kudos
> > to Martin for fixing the bug in his code. Had we had a Base64 class,
> > that bug wouldn't have showed up, and his code would have failed
> > elsewhere, or behaved differently on another VM. With the fix, his code
> > is portable, behaves in the same way on any VM, and may even be faster
> > than a vm-specific 'just for compatibility' implementation.
> > 
> > There is no downside to simply fixing the buggy code.
> 
> I agree, of course.
> 
> >>> On a side note, I seem to recall reading on Sun's javac engineer's blog
> >>> that javac won't allow access to sun internal classes sooner or later,
> >>> so idiot-proofing class libraries may not be very useful, anyway,
> >>> as people will have to rewrite such code, or preferrably, throw it away.
> >> It will be interesting to see what havoc is unleashed by attempts to
> >> reduce the visibility of sun internal packages by the compiler and at
> >> runtime.
> > 
> > I assume it will just cause unmaintained libraries to be substituted by
> > maintained ones, as people trade up to higher quality implementations of
> > functionality they need. Code that uses sun.* classes is a bad smell, to
> > invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> > something else that doesn't stink.
> 
> Where people who can fix it are made aware and choose not to then I
> agree, shame on them.
> 
> Regards,
> Tim
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote:
>>
>> Dalibor Topic wrote:
>>>
>>> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
>>> to the JVM JSR not being ahead thinking enough to specify an API for low-level 
>>> operations. It may or may not work depedending on how a VM interprets
>>> the non-existent spec for that class, so it is practically useless,
>>> unless it is running on the VM it was written on, i.e. Sun's. It may or
>>> may not work by chance, rather than by virtue.
>> I think you are being too harsh here, but that notwithstanding, one of
>> the things we can do as open implementations is petition the EG to
>> actually define these in the spec once we show that there's a good
>> reason to do so, namely the independent implementations.
> 
> The independant implementations are not using sun.misc.Unsafe. Why would
> anyone want to use an undocumented implementation-specific class from
> another implementation in their own? That makes no sense. There is no
> point in petitioning the EC to specify sun.misc.Unsafe since no one in
> their right mind uses it, except Sun, in the interna of their
> implementation. That's like asking the EC to specify org.kaffe.util.Ptr,
> or something equivalently pointless from DLRVM.

It makes sense if you wish to use Doug's concurrency package as-is, as
it has dependencies on sun.misc.Unsafe, which I think is a Good Thing.

After we do that, I think we then go back to the EG and point out that
in order for the world to reuse this code, we need to have
sun.misc.Unsafe defined (of course, it would be given another namespace...).

> 
> What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, 
> with a sane API that does not require computing field offsets manually, 
> like sun.misc.Unsafe seems to do. ;)

That would a good thing to ask for two - the two would make a nice request.

> 
> The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather
> simple bug in Doug Lea's java.util.concurrent implementation: using 
> Sun-specific classes directly, rather than delegating to some 
> java.util.concurrent.VMCompareAndSwap interface layer. That means anyone 
> adopting the code needs to repeat the mistakes of Sun's implementation 
> (which has, coincidentally, had a very straightforward remote execution 
> exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. 
> 
> Yay. :/
> 
> Other than Doug's code, sun.misc.Unsafe does not matter at all, unless
> you want "remote-execution-exploit-for-remote-execution-exploit"
> compatibility. I believe that's too much to ask for. ;)

I think we've been clear all along why we'd implement this - we want to
use Doug's code.

[SNIP]

>> Sure, but again, not everyone will be as wise as Martin - they'll just
>> bail on us.  They may even realize that there's a problem with their
>> code, but there may be nothing they can do about it.
> 
> People bailing on us is not a problem, as people *stuck with Sun-specific code* will
> (and should, IMHO) only use Sun's VM anyway. People blindly trusting us because
> we pretend to run some Sun-specific code according to some unspecified interface 
> is a problem, both for them, as their code will obviously behave differently from
> what it expects, in subtle ways, if they are very unlucky, and for us, as we have 
> to chase unreproducible behaviour as Sun changes their internal
> interfaces around. See the sad story of Ant's chasing around of
> sun.tools.javac.Main tail over and over again.

Oh, come on.  You talk like the rest of the spec is rock solid and
perfectly defined.  We're spelunking the RI through black-box testing
all the time in our drive to get full behavioral compatibility.  Adding
a few utility classes that people are unfortunately using - knowingly or
unknowingly - is simply good customer service, IMO.

> 
> The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is 
> already taken by Sun. There is no point in trying to compete with them on that, 
> or for the audience that wants and expects that. Been there, done that,
> etc. ;)

I think we'll have to continue to disagree on this one.  I do want
Harmony to work 100% like Sun to start because we want users to be able
to effortlessly transition to Harmony.  Software is nothing without users.

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
> >> Dalibor Topic wrote:
> >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
> >>>> Mikhail Loenko wrote:
> >>>>> The problem is Base64 functionality is unavailable through the
> >>>>> standard API, so people have a choice either use unportable sun.*,
> >>>>> o.a.h.*, etc or create the coder from scratch
> >>>> Understood, I think people are 'driven' to using the non-API types
> >>>> though necessity rather than doing so by mistake.
> >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
> >>> recommends using Apache Commons Codec for projects compatible with the
> >>> Apache license.
> >>>
> >>> Amateur developers use non-standard classes because they are too lazy 
> >>> to think for themselves, and accordingly copy broken code around projects. 
> >>> Alas, a language designed to appeal to the masses naturally attracts a 
> >>> lot of people who'd have trouble producing portable code in any programming 
> >>> language. :)
> >> I was being charitable.  For sure many such usages can be easily
> >> avoided, but in other cases no so easily; like CharToByteConverter would
> >> require duplicating a wad of data, and I don't know of any third-party
> >> impl. of Unsafe.
> > 
> > Is there something that CharToByteConverter does that
> > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> > code using CharToByteConverter in years.
> > 
> > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
> > to the JVM JSR not being ahead thinking enough to specify an API for low-level 
> > operations. It may or may not work depedending on how a VM interprets
> > the non-existent spec for that class, so it is practically useless,
> > unless it is running on the VM it was written on, i.e. Sun's. It may or
> > may not work by chance, rather than by virtue.
> 
> I think you are being too harsh here, but that notwithstanding, one of
> the things we can do as open implementations is petition the EG to
> actually define these in the spec once we show that there's a good
> reason to do so, namely the independent implementations.

The independant implementations are not using sun.misc.Unsafe. Why would
anyone want to use an undocumented implementation-specific class from
another implementation in their own? That makes no sense. There is no
point in petitioning the EC to specify sun.misc.Unsafe since no one in
their right mind uses it, except Sun, in the interna of their
implementation. That's like asking the EC to specify org.kaffe.util.Ptr,
or something equivalently pointless from DLRVM.

What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, 
with a sane API that does not require computing field offsets manually, 
like sun.misc.Unsafe seems to do. ;)

The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather
simple bug in Doug Lea's java.util.concurrent implementation: using 
Sun-specific classes directly, rather than delegating to some 
java.util.concurrent.VMCompareAndSwap interface layer. That means anyone 
adopting the code needs to repeat the mistakes of Sun's implementation 
(which has, coincidentally, had a very straightforward remote execution 
exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. 

Yay. :/

Other than Doug's code, sun.misc.Unsafe does not matter at all, unless
you want "remote-execution-exploit-for-remote-execution-exploit"
compatibility. I believe that's too much to ask for. ;)

> 
> > 
> > That holds in general for any code using implementation-specific 
> > interfaces.
> > 
> >> We should appeal to app developers to change implementation dependent
> >> code (even provide a recipe book of recommended solutions), but be
> >> pragmatic about the need to run the current version.  In many cases it
> >> may be beyond the apps immediate sphere of influence (i.e. dependent
> >> libraries).  If everyone responded as quickly and effectively as Martin
> >> we would have no worries.
> > 
> > We've been doing that for years. See the GNU Classpath migration page in
> > the Wiki that describes how to fix such broken code in many cases. Being
> > 'pragmatic' solves nothing, it just encourages people to continue behaving
> > in dumb ways, because their code still may run, somehow, even if there
> > is no way for Harmony to ensure that it will behave as they expect from
> > whatever buggy Sun JDK they are using to run it usually in the corner
> > cases, because there is no spec, and there are no tests.
> > 
> > Awarding incompetence doesn't solve the problem. That being said, kudos
> > to Martin for fixing the bug in his code. Had we had a Base64 class,
> > that bug wouldn't have showed up, and his code would have failed
> > elsewhere, or behaved differently on another VM. With the fix, his code
> > is portable, behaves in the same way on any VM, and may even be faster
> > than a vm-specific 'just for compatibility' implementation.
> > 
> > There is no downside to simply fixing the buggy code.
> 
> Sure, but again, not everyone will be as wise as Martin - they'll just
> bail on us.  They may even realize that there's a problem with their
> code, but there may be nothing they can do about it.

People bailing on us is not a problem, as people *stuck with Sun-specific code* will
(and should, IMHO) only use Sun's VM anyway. People blindly trusting us because
we pretend to run some Sun-specific code according to some unspecified interface 
is a problem, both for them, as their code will obviously behave differently from
what it expects, in subtle ways, if they are very unlucky, and for us, as we have 
to chase unreproducible behaviour as Sun changes their internal
interfaces around. See the sad story of Ant's chasing around of
sun.tools.javac.Main tail over and over again.

The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is 
already taken by Sun. There is no point in trying to compete with them on that, 
or for the audience that wants and expects that. Been there, done that,
etc. ;)

> > 
> >>> On a side note, I seem to recall reading on Sun's javac engineer's blog
> >>> that javac won't allow access to sun internal classes sooner or later,
> >>> so idiot-proofing class libraries may not be very useful, anyway,
> >>> as people will have to rewrite such code, or preferrably, throw it away.
> >> It will be interesting to see what havoc is unleashed by attempts to
> >> reduce the visibility of sun internal packages by the compiler and at
> >> runtime.
> > 
> > I assume it will just cause unmaintained libraries to be substituted by
> > maintained ones, as people trade up to higher quality implementations of
> > functionality they need. Code that uses sun.* classes is a bad smell, to
> > invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> > something else that doesn't stink.
> 
> Yah, but I think it's insane to enforce restrictions on one company's
> package namespace in the compiler.  This should be a general feature :)

Go ahead and start a JSR ...  I'd propose com.microsoft for a start. ;)

cheers,
dalibor topic

> geir
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Tim Ellison <t....@gmail.com>]

Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
>> Dalibor Topic wrote:
>>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
>>>> Mikhail Loenko wrote:
>>>>> The problem is Base64 functionality is unavailable through the
>>>>> standard API, so people have a choice either use unportable sun.*,
>>>>> o.a.h.*, etc or create the coder from scratch
>>>> Understood, I think people are 'driven' to using the non-API types
>>>> though necessity rather than doing so by mistake.
>>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
>>> recommends using Apache Commons Codec for projects compatible with the
>>> Apache license.
>>>
>>> Amateur developers use non-standard classes because they are too lazy 
>>> to think for themselves, and accordingly copy broken code around projects. 
>>> Alas, a language designed to appeal to the masses naturally attracts a 
>>> lot of people who'd have trouble producing portable code in any programming 
>>> language. :)
>> I was being charitable.  For sure many such usages can be easily
>> avoided, but in other cases no so easily; like CharToByteConverter would
>> require duplicating a wad of data, and I don't know of any third-party
>> impl. of Unsafe.
> 
> Is there something that CharToByteConverter does that
> CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> code using CharToByteConverter in years.

If you want to duplicate the char conversion data then sure, but taking
a multi-MB hit isn't palatable to many apps when sun.io is sitting there
smiling at them.

I saw a few uses when testing apps, but maybe I was unlucky. For
example, Xalan was using it until it was pointed it out last year
(http://issues.apache.org/jira/browse/XALANJ-2087).

> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
> to the JVM JSR not being ahead thinking enough to specify an API for low-level 
> operations. It may or may not work depedending on how a VM interprets
> the non-existent spec for that class, so it is practically useless,
> unless it is running on the VM it was written on, i.e. Sun's. It may or
> may not work by chance, rather than by virtue.
> 
> That holds in general for any code using implementation-specific 
> interfaces.

Exactly.

>> We should appeal to app developers to change implementation dependent
>> code (even provide a recipe book of recommended solutions), but be
>> pragmatic about the need to run the current version.  In many cases it
>> may be beyond the apps immediate sphere of influence (i.e. dependent
>> libraries).  If everyone responded as quickly and effectively as Martin
>> we would have no worries.
> 
> We've been doing that for years. See the GNU Classpath migration page in
> the Wiki that describes how to fix such broken code in many cases.

Ack -- I see it here (just so others can find it too).
http://developer.classpath.org/mediation/ClasspathMigration

> Being 'pragmatic' solves nothing, it just encourages people to
> continue behaving in dumb ways, because their code still may run,
> somehow, even if there is no way for Harmony to ensure that it will
> behave as they expect from whatever buggy Sun JDK they are using to
> run it usually in the corner cases, because there is no spec, and
> there are no tests.

It's pragmatic because as I said, sometimes it is beyond the immediate
control of the application, and sometimes you won't get a second chance
to demonstrate your wares.

'Harmony - runs fewer apps than the leading brand' is hardly a
compelling tag line.

I believe that everyone wants to reduce dependencies on the non-API
types.  It is a millstone for IBM and Sun and BEA etc if they cannot
modify their implementations without customers coming down on them.  But
at this point we cannot call the shots from Harmony.

> Awarding incompetence doesn't solve the problem. That being said, kudos
> to Martin for fixing the bug in his code. Had we had a Base64 class,
> that bug wouldn't have showed up, and his code would have failed
> elsewhere, or behaved differently on another VM. With the fix, his code
> is portable, behaves in the same way on any VM, and may even be faster
> than a vm-specific 'just for compatibility' implementation.
> 
> There is no downside to simply fixing the buggy code.

I agree, of course.

>>> On a side note, I seem to recall reading on Sun's javac engineer's blog
>>> that javac won't allow access to sun internal classes sooner or later,
>>> so idiot-proofing class libraries may not be very useful, anyway,
>>> as people will have to rewrite such code, or preferrably, throw it away.
>> It will be interesting to see what havoc is unleashed by attempts to
>> reduce the visibility of sun internal packages by the compiler and at
>> runtime.
> 
> I assume it will just cause unmaintained libraries to be substituted by
> maintained ones, as people trade up to higher quality implementations of
> functionality they need. Code that uses sun.* classes is a bad smell, to
> invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> something else that doesn't stink.

Where people who can fix it are made aware and choose not to then I
agree, shame on them.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
>> Dalibor Topic wrote:
>>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
>>>> Mikhail Loenko wrote:
>>>>> The problem is Base64 functionality is unavailable through the
>>>>> standard API, so people have a choice either use unportable sun.*,
>>>>> o.a.h.*, etc or create the coder from scratch
>>>> Understood, I think people are 'driven' to using the non-API types
>>>> though necessity rather than doing so by mistake.
>>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
>>> recommends using Apache Commons Codec for projects compatible with the
>>> Apache license.
>>>
>>> Amateur developers use non-standard classes because they are too lazy 
>>> to think for themselves, and accordingly copy broken code around projects. 
>>> Alas, a language designed to appeal to the masses naturally attracts a 
>>> lot of people who'd have trouble producing portable code in any programming 
>>> language. :)
>> I was being charitable.  For sure many such usages can be easily
>> avoided, but in other cases no so easily; like CharToByteConverter would
>> require duplicating a wad of data, and I don't know of any third-party
>> impl. of Unsafe.
> 
> Is there something that CharToByteConverter does that
> CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> code using CharToByteConverter in years.
> 
> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
> to the JVM JSR not being ahead thinking enough to specify an API for low-level 
> operations. It may or may not work depedending on how a VM interprets
> the non-existent spec for that class, so it is practically useless,
> unless it is running on the VM it was written on, i.e. Sun's. It may or
> may not work by chance, rather than by virtue.

I think you are being too harsh here, but that notwithstanding, one of
the things we can do as open implementations is petition the EG to
actually define these in the spec once we show that there's a good
reason to do so, namely the independent implementations.

> 
> That holds in general for any code using implementation-specific 
> interfaces.
> 
>> We should appeal to app developers to change implementation dependent
>> code (even provide a recipe book of recommended solutions), but be
>> pragmatic about the need to run the current version.  In many cases it
>> may be beyond the apps immediate sphere of influence (i.e. dependent
>> libraries).  If everyone responded as quickly and effectively as Martin
>> we would have no worries.
> 
> We've been doing that for years. See the GNU Classpath migration page in
> the Wiki that describes how to fix such broken code in many cases. Being
> 'pragmatic' solves nothing, it just encourages people to continue behaving
> in dumb ways, because their code still may run, somehow, even if there
> is no way for Harmony to ensure that it will behave as they expect from
> whatever buggy Sun JDK they are using to run it usually in the corner
> cases, because there is no spec, and there are no tests.
> 
> Awarding incompetence doesn't solve the problem. That being said, kudos
> to Martin for fixing the bug in his code. Had we had a Base64 class,
> that bug wouldn't have showed up, and his code would have failed
> elsewhere, or behaved differently on another VM. With the fix, his code
> is portable, behaves in the same way on any VM, and may even be faster
> than a vm-specific 'just for compatibility' implementation.
> 
> There is no downside to simply fixing the buggy code.

Sure, but again, not everyone will be as wise as Martin - they'll just
bail on us.  They may even realize that there's a problem with their
code, but there may be nothing they can do about it.

> 
>>> On a side note, I seem to recall reading on Sun's javac engineer's blog
>>> that javac won't allow access to sun internal classes sooner or later,
>>> so idiot-proofing class libraries may not be very useful, anyway,
>>> as people will have to rewrite such code, or preferrably, throw it away.
>> It will be interesting to see what havoc is unleashed by attempts to
>> reduce the visibility of sun internal packages by the compiler and at
>> runtime.
> 
> I assume it will just cause unmaintained libraries to be substituted by
> maintained ones, as people trade up to higher quality implementations of
> functionality they need. Code that uses sun.* classes is a bad smell, to
> invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> something else that doesn't stink.

Yah, but I think it's insane to enforce restrictions on one company's
package namespace in the compiler.  This should be a general feature :)

geir




---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [general] compatibility packages (was: Re: BASE64Encoder class missing?)

[Dalibor Topic <ro...@kaffe.org>]

On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
> Dalibor Topic wrote:
> > On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
> >> Mikhail Loenko wrote:
> >>> The problem is Base64 functionality is unavailable through the
> >>> standard API, so people have a choice either use unportable sun.*,
> >>> o.a.h.*, etc or create the coder from scratch
> >> Understood, I think people are 'driven' to using the non-API types
> >> though necessity rather than doing so by mistake.
> > 
> > Hardly. Many replacements for Base64 exists, for example GNU Classpath
> > recommends using Apache Commons Codec for projects compatible with the
> > Apache license.
> > 
> > Amateur developers use non-standard classes because they are too lazy 
> > to think for themselves, and accordingly copy broken code around projects. 
> > Alas, a language designed to appeal to the masses naturally attracts a 
> > lot of people who'd have trouble producing portable code in any programming 
> > language. :)
> 
> I was being charitable.  For sure many such usages can be easily
> avoided, but in other cases no so easily; like CharToByteConverter would
> require duplicating a wad of data, and I don't know of any third-party
> impl. of Unsafe.

Is there something that CharToByteConverter does that
CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
code using CharToByteConverter in years.

Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
to the JVM JSR not being ahead thinking enough to specify an API for low-level 
operations. It may or may not work depedending on how a VM interprets
the non-existent spec for that class, so it is practically useless,
unless it is running on the VM it was written on, i.e. Sun's. It may or
may not work by chance, rather than by virtue.

That holds in general for any code using implementation-specific 
interfaces.

> 
> We should appeal to app developers to change implementation dependent
> code (even provide a recipe book of recommended solutions), but be
> pragmatic about the need to run the current version.  In many cases it
> may be beyond the apps immediate sphere of influence (i.e. dependent
> libraries).  If everyone responded as quickly and effectively as Martin
> we would have no worries.

We've been doing that for years. See the GNU Classpath migration page in
the Wiki that describes how to fix such broken code in many cases. Being
'pragmatic' solves nothing, it just encourages people to continue behaving
in dumb ways, because their code still may run, somehow, even if there
is no way for Harmony to ensure that it will behave as they expect from
whatever buggy Sun JDK they are using to run it usually in the corner
cases, because there is no spec, and there are no tests.

Awarding incompetence doesn't solve the problem. That being said, kudos
to Martin for fixing the bug in his code. Had we had a Base64 class,
that bug wouldn't have showed up, and his code would have failed
elsewhere, or behaved differently on another VM. With the fix, his code
is portable, behaves in the same way on any VM, and may even be faster
than a vm-specific 'just for compatibility' implementation.

There is no downside to simply fixing the buggy code.

> > On a side note, I seem to recall reading on Sun's javac engineer's blog
> > that javac won't allow access to sun internal classes sooner or later,
> > so idiot-proofing class libraries may not be very useful, anyway,
> > as people will have to rewrite such code, or preferrably, throw it away.
> 
> It will be interesting to see what havoc is unleashed by attempts to
> reduce the visibility of sun internal packages by the compiler and at
> runtime.

I assume it will just cause unmaintained libraries to be substituted by
maintained ones, as people trade up to higher quality implementations of
functionality they need. Code that uses sun.* classes is a bad smell, to
invoke Fowler. If it doesn't get fixed, just get rid of it, and use
something else that doesn't stink.

cheers,
dalibor topic

> Regards,
> Tim
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

[general] compatibility packages (was: Re: BASE64Encoder class missing?)

[Tim Ellison <t....@gmail.com>]

Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
>> Mikhail Loenko wrote:
>>> The problem is Base64 functionality is unavailable through the
>>> standard API, so people have a choice either use unportable sun.*,
>>> o.a.h.*, etc or create the coder from scratch
>> Understood, I think people are 'driven' to using the non-API types
>> though necessity rather than doing so by mistake.
> 
> Hardly. Many replacements for Base64 exists, for example GNU Classpath
> recommends using Apache Commons Codec for projects compatible with the
> Apache license.
> 
> Amateur developers use non-standard classes because they are too lazy 
> to think for themselves, and accordingly copy broken code around projects. 
> Alas, a language designed to appeal to the masses naturally attracts a 
> lot of people who'd have trouble producing portable code in any programming 
> language. :)

I was being charitable.  For sure many such usages can be easily
avoided, but in other cases no so easily; like CharToByteConverter would
require duplicating a wad of data, and I don't know of any third-party
impl. of Unsafe.

We should appeal to app developers to change implementation dependent
code (even provide a recipe book of recommended solutions), but be
pragmatic about the need to run the current version.  In many cases it
may be beyond the apps immediate sphere of influence (i.e. dependent
libraries).  If everyone responded as quickly and effectively as Martin
we would have no worries.

> On a side note, I seem to recall reading on Sun's javac engineer's blog
> that javac won't allow access to sun internal classes sooner or later,
> so idiot-proofing class libraries may not be very useful, anyway,
> as people will have to rewrite such code, or preferrably, throw it away.

It will be interesting to see what havoc is unleashed by attempts to
reduce the visibility of sun internal packages by the compiler and at
runtime.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Dalibor Topic <ro...@kaffe.org>]

On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
> Mikhail Loenko wrote:
> > The problem is Base64 functionality is unavailable through the
> > standard API, so people have a choice either use unportable sun.*,
> > o.a.h.*, etc or create the coder from scratch
> 
> Understood, I think people are 'driven' to using the non-API types
> though necessity rather than doing so by mistake.

Hardly. Many replacements for Base64 exists, for example GNU Classpath
recommends using Apache Commons Codec for projects compatible with the
Apache license.

Amateur developers use non-standard classes because they are too lazy 
to think for themselves, and accordingly copy broken code around projects. 
Alas, a language designed to appeal to the masses naturally attracts a 
lot of people who'd have trouble producing portable code in any programming 
language. :)

On a side note, I seem to recall reading on Sun's javac engineer's blog
that javac won't allow access to sun internal classes sooner or later,
so idiot-proofing class libraries may not be very useful, anyway,
as people will have to rewrite such code, or preferrably, throw it away.

cheers,
dalibor topic

> 
> > Alternative to suncompat is separating all similar functionality into
> > a separate redistributable module that would be runnable on RI, so
> > that people could use it in their apps.
> 
> If we could get people to change their apps then I would agree.  In fact
> I would expect that most of the non-API functionality in common usage is
> already available elsewhere there if apps wanted to change (well, maybe
> not Unsafe, but...).
> 
> But we are trying to fix it on the Harmony side.
> 
> I'll go ahead an put in the suncompat module, but don't let that be the
> end of the debate -- it is trivial to add it and I have no qualms about
> removing it later if that's what we choose to do.
> 
> Regards,
> Tim
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Tim Ellison <t....@gmail.com>]

Mikhail Loenko wrote:
> The problem is Base64 functionality is unavailable through the
> standard API, so people have a choice either use unportable sun.*,
> o.a.h.*, etc or create the coder from scratch

Understood, I think people are 'driven' to using the non-API types
though necessity rather than doing so by mistake.

> Alternative to suncompat is separating all similar functionality into
> a separate redistributable module that would be runnable on RI, so
> that people could use it in their apps.

If we could get people to change their apps then I would agree.  In fact
I would expect that most of the non-API functionality in common usage is
already available elsewhere there if apps wanted to change (well, maybe
not Unsafe, but...).

But we are trying to fix it on the Harmony side.

I'll go ahead an put in the suncompat module, but don't let that be the
end of the debate -- it is trivial to add it and I have no qualms about
removing it later if that's what we choose to do.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Mikhail Loenko <ml...@gmail.com>]

The problem is Base64 functionality is unavailable through the standard API,
so people have a choice either use unportable sun.*, o.a.h.*, etc or create the
coder from scratch

Alternative to suncompat is separating all similar functionality into
a separate
redistributable module that would be runnable on RI, so that people could
use it in their apps.

Thanks,
Mikhail

2006/8/10, Tim Ellison <t....@gmail.com>:
> I'll create a suncompat component and see where we go from there...
>
> Tim
>
> Alex Blewitt wrote:
> > On 10/08/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Tim Ellison <t....@gmail.com>]

I'll create a suncompat component and see where we go from there...

Tim

Alex Blewitt wrote:
> On 10/08/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Re: BASE64Encoder class missing?

[Alex Blewitt <al...@gmail.com>]

On 10/08/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

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.

At the same time, since the API is completely optional, educate people
on how to ensure they have portable java code (remove the suncompat.jar
and restart your program...)

Then, when we have enough momentum, we deprecate it out of a release.

> 
> Experience tells us that application developers are happy to fix their
> programs once made aware of this issue. 

But there's a lag - sure, they want to fix it, but there might be a
dependency (like whatever this servlet engine is...) that is out of
their control.

> GNU Classpath users have
> already paved the way with the developers of many popular programs and
> libraries (Eclipse, OpenOffice.org, Azureus, a lot of Apache code like
> Batik and Tomcat, etc).  This is the only solution that makes sense for
> users and developers.

Well, I certainly agree that getting this practice out of the ecosystem
is the only sane way to go, but I think there is space for reasonable
differences of opinion on how to get there.  Remember, we're still
catching up to you :)

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Anthony Green <gr...@redhat.com>]

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.

Experience tells us that application developers are happy to fix their
programs once made aware of this issue.  GNU Classpath users have
already paved the way with the developers of many popular programs and
libraries (Eclipse, OpenOffice.org, Azureus, a lot of Apache code like
Batik and Tomcat, etc).  This is the only solution that makes sense for
users and developers.

AG





---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

Martin Cordova wrote:
> I was testing a servlet engine called Winstone v0.8.2 - very
> lightweight and minimalistic (winstone.sourceforge.net). It started
> very fast, and everything seemed to work nice until I reached the
> point of encoding a password...
> 
> I also make heavy use of Resin servlet engine, I will test it with
> Harmony too.
> 
> Is it possible to mantain the same package name for this Base64 class?
> any licensing issues regarding this? I use IBM JVM and they provide
> this class under the same package.

Yes- the idea is to provide that "suncompat.jar" for that reason with
those clases in the sun.* namespace that user apps depend on.


> 
> I also tested a small program that uses some File I/O and a compact
> XML parser called Electric XML and parts of a framework that makes
> heavy use of HashMap and ArrayList. Did run fine and fast, inside
> Eclipse 3.2.

Excellent.

> 
> I am really pleased with this JRE snapshot, so easy to install and
> test. Last time I tested gnu classpath with some open source JVM was a
> pain in the class. Don't take me wrong, I appreciatte a lot the effort
> of those guys, but I love simplicity a lot. By creating an easy to
> install snapshot you are also improving the feedback cycle, people (at
> least me) will feel more motivated to test and provide feedback.

Yes, that was the goal :)  Thanks so much for the feedback.

geir

> 
> Regards,
> Martin

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

RE: BASE64Encoder class missing?

[Nathan Beyer <nb...@kc.rr.com>]

Regardless of how this turns out, I would suggest that someone (Martin?) log
an issue with Winstone to switch from using this class to something like
commons-codec.

-Nathan

> -----Original Message-----
> From: Martin Cordova [mailto:martin.cordova@gmail.com]
> Sent: Wednesday, August 09, 2006 2:34 PM
> To: harmony-dev@incubator.apache.org; geir@pobox.com
> Subject: Re: BASE64Encoder class missing?
> 
> I was testing a servlet engine called Winstone v0.8.2 - very
> lightweight and minimalistic (winstone.sourceforge.net). It started
> very fast, and everything seemed to work nice until I reached the
> point of encoding a password...
> 
> I also make heavy use of Resin servlet engine, I will test it with Harmony
> too.
> 
> Is it possible to mantain the same package name for this Base64 class?
> any licensing issues regarding this? I use IBM JVM and they provide
> this class under the same package.
> 
> I also tested a small program that uses some File I/O and a compact
> XML parser called Electric XML and parts of a framework that makes
> heavy use of HashMap and ArrayList. Did run fine and fast, inside
> Eclipse 3.2.
> 
> I am really pleased with this JRE snapshot, so easy to install and
> test. Last time I tested gnu classpath with some open source JVM was a
> pain in the class. Don't take me wrong, I appreciatte a lot the effort
> of those guys, but I love simplicity a lot. By creating an easy to
> install snapshot you are also improving the feedback cycle, people (at
> least me) will feel more motivated to test and provide feedback.
> 
> Regards,
> Martin
> --
> Dinamica - RADical J2EE framework
> open source, easy and powerful
> http://www.martincordova.com
> 
> 
> On 8/9/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > btw... which servlet engine?
> >
> > Did you get anything done before you ran into the missing class?  We're
> > interested in hearing how it went...
> >
> > geir
> >
> > Martin Cordova wrote:
> > > Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> > > engine on Windows XP SP2. The first obstacle I hit was related to the
> > > use of sun/misc/BASE64Encoder
> > >
> > > I got a java.lang.NoClassDefFoundError exception.
> > >
> > > Is there a workaround? was this class located under a different
> package?
> > >
> > > Thanks a lot.
> > > Martin Cordova
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Martin Cordova <ma...@gmail.com>]

I was testing a servlet engine called Winstone v0.8.2 - very
lightweight and minimalistic (winstone.sourceforge.net). It started
very fast, and everything seemed to work nice until I reached the
point of encoding a password...

I also make heavy use of Resin servlet engine, I will test it with Harmony too.

Is it possible to mantain the same package name for this Base64 class?
any licensing issues regarding this? I use IBM JVM and they provide
this class under the same package.

I also tested a small program that uses some File I/O and a compact
XML parser called Electric XML and parts of a framework that makes
heavy use of HashMap and ArrayList. Did run fine and fast, inside
Eclipse 3.2.

I am really pleased with this JRE snapshot, so easy to install and
test. Last time I tested gnu classpath with some open source JVM was a
pain in the class. Don't take me wrong, I appreciatte a lot the effort
of those guys, but I love simplicity a lot. By creating an easy to
install snapshot you are also improving the feedback cycle, people (at
least me) will feel more motivated to test and provide feedback.

Regards,
Martin
-- 
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com


On 8/9/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> btw... which servlet engine?
>
> Did you get anything done before you ran into the missing class?  We're
> interested in hearing how it went...
>
> geir
>
> Martin Cordova wrote:
> > Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> > engine on Windows XP SP2. The first obstacle I hit was related to the
> > use of sun/misc/BASE64Encoder
> >
> > I got a java.lang.NoClassDefFoundError exception.
> >
> > Is there a workaround? was this class located under a different package?
> >
> > Thanks a lot.
> > Martin Cordova
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

btw... which servlet engine?

Did you get anything done before you ran into the missing class?  We're
interested in hearing how it went...

geir

Martin Cordova wrote:
> Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> engine on Windows XP SP2. The first obstacle I hit was related to the
> use of sun/misc/BASE64Encoder
> 
> I got a java.lang.NoClassDefFoundError exception.
> 
> Is there a workaround? was this class located under a different package?
> 
> Thanks a lot.
> Martin Cordova

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

Agreed.  That is what I meant when I asked what we could wrap...

geir


Paulex Yang wrote:
> FYI, Harmony has already a o.a.h.luni.util.Base64 utility in LUNI
> module, which is used by HttpURLConnection, IMO it would be nice to just
> choose one implementation to use across all the project.
> 
> Geir Magnusson Jr wrote:
>> I assume it's something we'd just want to copy, rather than add a
>> dependency ....
>>
>> geir
>>
>>
>> Matt Benson wrote:
>>  
>>> commons-codec and Ant both have base64 encoders AFAIK.
>>>
>>> -Matt
>>>
>>> --- Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>
>>>    
>>>> Martin Cordova wrote:
>>>>      
>>>>> Hi, I am testing the latest Harmony JRE (Aug-4-06)
>>>>>         
>>>> with a servlet
>>>>      
>>>>> engine on Windows XP SP2. The first obstacle I hit
>>>>>         
>>>> was related to the
>>>>      
>>>>> use of sun/misc/BASE64Encoder
>>>>>
>>>>> I got a java.lang.NoClassDefFoundError exception.
>>>>>
>>>>> Is there a workaround? was this class located
>>>>>         
>>>> under a different package?
>>>>
>>>> Not yet.  We were discussing this earlier.  Problem
>>>> obviously is that
>>>> the code is using sun specific code.
>>>>
>>>> I think that we should probably do this as well as
>>>> we've discussed,
>>>> sooner rather than later :
>>>>
>>>> 1) add a new module "suncompat" to make it clear
>>>> what it is
>>>> 2) have it produce a suncompat.jar that we include
>>>> by default.
>>>> 3) make users happy
>>>>
>>>> Anyone want to take a stab at this?  I assume we
>>>> have a base64 encoder
>>>> we can wrap?
>>>>
>>>> geir
>>>>
>>>>      
>>>>> Thanks a lot.
>>>>> Martin Cordova
>>>>>         
>>> ---------------------------------------------------------------------
>>>    
>>>> Terms of use :
>>>> http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail:
>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail:
>>>> harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>>       
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>>     
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>   
> 
> 


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Vladimir Ivanov <iv...@gmail.com>]

Seems, it will be good to add class to "sun..." package to translate methods
calls to o.a.h class.

 thanks, Vladimir


On 8/10/06, Paulex Yang <pa...@gmail.com> wrote:
>
> FYI, Harmony has already a o.a.h.luni.util.Base64 utility in LUNI
> module, which is used by HttpURLConnection, IMO it would be nice to just
> choose one implementation to use across all the project.
>
> Geir Magnusson Jr wrote:
> > I assume it's something we'd just want to copy, rather than add a
> > dependency ....
> >
> > geir
> >
> >
> > Matt Benson wrote:
> >
> >> commons-codec and Ant both have base64 encoders AFAIK.
> >>
> >> -Matt
> >>
> >> --- Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>
> >>
> >>> Martin Cordova wrote:
> >>>
> >>>> Hi, I am testing the latest Harmony JRE (Aug-4-06)
> >>>>
> >>> with a servlet
> >>>
> >>>> engine on Windows XP SP2. The first obstacle I hit
> >>>>
> >>> was related to the
> >>>
> >>>> use of sun/misc/BASE64Encoder
> >>>>
> >>>> I got a java.lang.NoClassDefFoundError exception.
> >>>>
> >>>> Is there a workaround? was this class located
> >>>>
> >>> under a different package?
> >>>
> >>> Not yet.  We were discussing this earlier.  Problem
> >>> obviously is that
> >>> the code is using sun specific code.
> >>>
> >>> I think that we should probably do this as well as
> >>> we've discussed,
> >>> sooner rather than later :
> >>>
> >>> 1) add a new module "suncompat" to make it clear
> >>> what it is
> >>> 2) have it produce a suncompat.jar that we include
> >>> by default.
> >>> 3) make users happy
> >>>
> >>> Anyone want to take a stab at this?  I assume we
> >>> have a base64 encoder
> >>> we can wrap?
> >>>
> >>> geir
> >>>
> >>>
> >>>> Thanks a lot.
> >>>> Martin Cordova
> >>>>
> >> ---------------------------------------------------------------------
> >>
> >>> Terms of use :
> >>> http://incubator.apache.org/harmony/mailing.html
> >>> To unsubscribe, e-mail:
> >>> harmony-dev-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail:
> >>> harmony-dev-help@incubator.apache.org
> >>>
> >>>
> >>>
> >> __________________________________________________
> >> Do You Yahoo!?
> >> Tired of spam?  Yahoo! Mail has the best spam protection around
> >> http://mail.yahoo.com
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

Re: BASE64Encoder class missing?

[Paulex Yang <pa...@gmail.com>]

FYI, Harmony has already a o.a.h.luni.util.Base64 utility in LUNI 
module, which is used by HttpURLConnection, IMO it would be nice to just 
choose one implementation to use across all the project.

Geir Magnusson Jr wrote:
> I assume it's something we'd just want to copy, rather than add a
> dependency ....
>
> geir
>
>
> Matt Benson wrote:
>   
>> commons-codec and Ant both have base64 encoders AFAIK.
>>
>> -Matt
>>
>> --- Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>     
>>> Martin Cordova wrote:
>>>       
>>>> Hi, I am testing the latest Harmony JRE (Aug-4-06)
>>>>         
>>> with a servlet
>>>       
>>>> engine on Windows XP SP2. The first obstacle I hit
>>>>         
>>> was related to the
>>>       
>>>> use of sun/misc/BASE64Encoder
>>>>
>>>> I got a java.lang.NoClassDefFoundError exception.
>>>>
>>>> Is there a workaround? was this class located
>>>>         
>>> under a different package?
>>>
>>> Not yet.  We were discussing this earlier.  Problem
>>> obviously is that
>>> the code is using sun specific code.
>>>
>>> I think that we should probably do this as well as
>>> we've discussed,
>>> sooner rather than later :
>>>
>>> 1) add a new module "suncompat" to make it clear
>>> what it is
>>> 2) have it produce a suncompat.jar that we include
>>> by default.
>>> 3) make users happy
>>>
>>> Anyone want to take a stab at this?  I assume we
>>> have a base64 encoder
>>> we can wrap?
>>>
>>> geir
>>>
>>>       
>>>> Thanks a lot.
>>>> Martin Cordova
>>>>         
>> ---------------------------------------------------------------------
>>     
>>> Terms of use :
>>> http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail:
>>> harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail:
>>> harmony-dev-help@incubator.apache.org
>>>
>>>
>>>       
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com 
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>
>>     
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Matt Benson <gu...@yahoo.com>]

I was assuming the same thing.  ;)

-Matt

--- Geir Magnusson Jr <ge...@pobox.com> wrote:

> I assume it's something we'd just want to copy,
> rather than add a
> dependency ....
> 
> geir
> 
> 
> Matt Benson wrote:
> > commons-codec and Ant both have base64 encoders
> AFAIK.
> > 
> > -Matt
> > 
> > --- Geir Magnusson Jr <ge...@pobox.com> wrote:
> > 
> >>
> >> Martin Cordova wrote:
> >>> Hi, I am testing the latest Harmony JRE
> (Aug-4-06)
> >> with a servlet
> >>> engine on Windows XP SP2. The first obstacle I
> hit
> >> was related to the
> >>> use of sun/misc/BASE64Encoder
> >>>
> >>> I got a java.lang.NoClassDefFoundError
> exception.
> >>>
> >>> Is there a workaround? was this class located
> >> under a different package?
> >>
> >> Not yet.  We were discussing this earlier. 
> Problem
> >> obviously is that
> >> the code is using sun specific code.
> >>
> >> I think that we should probably do this as well
> as
> >> we've discussed,
> >> sooner rather than later :
> >>
> >> 1) add a new module "suncompat" to make it clear
> >> what it is
> >> 2) have it produce a suncompat.jar that we
> include
> >> by default.
> >> 3) make users happy
> >>
> >> Anyone want to take a stab at this?  I assume we
> >> have a base64 encoder
> >> we can wrap?
> >>
> >> geir
> >>
> >>> Thanks a lot.
> >>> Martin Cordova
> >>
> >
>
---------------------------------------------------------------------
> >> Terms of use :
> >> http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail:
> >> harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >>
> >>
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> > 
> >
>
---------------------------------------------------------------------
> > Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > 
> > 
> > 
> 
>
---------------------------------------------------------------------
> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

I assume it's something we'd just want to copy, rather than add a
dependency ....

geir


Matt Benson wrote:
> commons-codec and Ant both have base64 encoders AFAIK.
> 
> -Matt
> 
> --- Geir Magnusson Jr <ge...@pobox.com> wrote:
> 
>>
>> Martin Cordova wrote:
>>> Hi, I am testing the latest Harmony JRE (Aug-4-06)
>> with a servlet
>>> engine on Windows XP SP2. The first obstacle I hit
>> was related to the
>>> use of sun/misc/BASE64Encoder
>>>
>>> I got a java.lang.NoClassDefFoundError exception.
>>>
>>> Is there a workaround? was this class located
>> under a different package?
>>
>> Not yet.  We were discussing this earlier.  Problem
>> obviously is that
>> the code is using sun specific code.
>>
>> I think that we should probably do this as well as
>> we've discussed,
>> sooner rather than later :
>>
>> 1) add a new module "suncompat" to make it clear
>> what it is
>> 2) have it produce a suncompat.jar that we include
>> by default.
>> 3) make users happy
>>
>> Anyone want to take a stab at this?  I assume we
>> have a base64 encoder
>> we can wrap?
>>
>> geir
>>
>>> Thanks a lot.
>>> Martin Cordova
>>
> ---------------------------------------------------------------------
>> Terms of use :
>> http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail:
>> harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Matt Benson <gu...@yahoo.com>]

commons-codec and Ant both have base64 encoders AFAIK.

-Matt

--- Geir Magnusson Jr <ge...@pobox.com> wrote:

> 
> 
> Martin Cordova wrote:
> > Hi, I am testing the latest Harmony JRE (Aug-4-06)
> with a servlet
> > engine on Windows XP SP2. The first obstacle I hit
> was related to the
> > use of sun/misc/BASE64Encoder
> > 
> > I got a java.lang.NoClassDefFoundError exception.
> > 
> > Is there a workaround? was this class located
> under a different package?
> 
> Not yet.  We were discussing this earlier.  Problem
> obviously is that
> the code is using sun specific code.
> 
> I think that we should probably do this as well as
> we've discussed,
> sooner rather than later :
> 
> 1) add a new module "suncompat" to make it clear
> what it is
> 2) have it produce a suncompat.jar that we include
> by default.
> 3) make users happy
> 
> Anyone want to take a stab at this?  I assume we
> have a base64 encoder
> we can wrap?
> 
> geir
> 
> > 
> > Thanks a lot.
> > Martin Cordova
> 
>
---------------------------------------------------------------------
> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: BASE64Encoder class missing?

[Geir Magnusson Jr <ge...@pobox.com>]

Martin Cordova wrote:
> Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet
> engine on Windows XP SP2. The first obstacle I hit was related to the
> use of sun/misc/BASE64Encoder
> 
> I got a java.lang.NoClassDefFoundError exception.
> 
> Is there a workaround? was this class located under a different package?

Not yet.  We were discussing this earlier.  Problem obviously is that
the code is using sun specific code.

I think that we should probably do this as well as we've discussed,
sooner rather than later :

1) add a new module "suncompat" to make it clear what it is
2) have it produce a suncompat.jar that we include by default.
3) make users happy

Anyone want to take a stab at this?  I assume we have a base64 encoder
we can wrap?

geir

> 
> Thanks a lot.
> Martin Cordova

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org