harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [general] compatibility packages
Date Mon, 14 Aug 2006 00:23:42 GMT
On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr 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 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


Mime
View raw message