harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [general] compatibility packages
Date Mon, 14 Aug 2006 01:18:47 GMT
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.


Alex Blewitt wrote:
> On 13/08/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>> Alex Blewitt wrote:
>> > On 12/08/06, Jeroen Frijters <jeroen@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.


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

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....


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

View raw message