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 Sun, 13 Aug 2006 22:46:26 GMT

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

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

> 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

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


> 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

View raw message