On 13/08/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Alex Blewitt wrote:
> On 12/08/06, Jeroen Frijters <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
