On 12/08/06, Jeroen Frijters wrote:
> You also keep hammering on CharToByteConverter as an example of bad code
> that should trivially be fixed (and it obviously should, if possible,
> but it's not always that easy), but there is also code out there that
> uses sun.* classes to do things that are impossible to do with the
> documented APIs. How would you fix those?
You can't trivially fix such problems; in each case, someone has to
debug and find out where the dependency is. And let's face it, if
someone refers to sun.foo.Bar (and it's not in suncompat.jar in the
first instance) they're going to be in exactly the same situation.
It's only really for the benefit of people who aren't the first to
fall over (e.g. the BASE64 encoder).
> 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.
(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)
> 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. 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.
> 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.
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 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? 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.
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.
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.
---------------------------------------------------------------------
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