On 12/08/06, Jeroen Frijters <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
