On Sun, Aug 13, 2006 at 06:46:26PM -0400, Geir Magnusson Jr 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 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
