Gilbert,
That is all fine and dandy, but there is nothing we can do about the
incompatibilities that Sun introduces. Sun has created a standard, and
whether that standard is flawed or perfect, we are responsible to implement
that standard so that every application behaves like it is running in an
environment exactly compatible with the version of the standard it was
written to. If we do not implement the standard, and instead try to
'correct' it, we are ourselves introducing incompatibilities into the
platform. Suddenly someone writing an application on JOS doesn't
automatically get compatibility with Java on Win32.
The best thing we can do is to work around those incompatibilities. We can
implement the class libraries once for each version of the JDK. When we run
an application written to 1.02, we run it with the 1.02 class libraries.
When we run an application written to 1.2, we run it with 1.2 class
libraries. If an application was written to Swing 1.0.3, then we run it
with Swing 1.0.3. If the latest and greatest, then we run it with the
latest and greatest. It means that the user will have to configure what
versions are to be used with what applications. (using your registry,
perhaps?) It means that we have to provide mulit-process support in our JVM
so that every application behaves like it is running alone in a seperate
instance of the JDK, because that is the assumption the JDK makes. This is
the only reasonable thing we can do to solve this problem such that every
application runs robustly as the developer expected it to when he wrote it,
whichever JDK he wrote it for.
In the meantime, we have a technical issue brought about by Sun's decisions.
We don't have the capabliity described above yet, though we will try to work
towards it. Let the developers do what they need to do in the meantime to
just make it work.
Regards,
Avery J. Regier
> -----Original Message-----
> From: Gilbert Carl Herschberger II [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, July 21, 1999 11:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JOS-UI] peer-ui mappings
>
> At 01:31 PM 7/21/99 +1000, you wrote:
> >Gilbert Carl Herschberger II wrote:
> >>
> >> On Tuesday, 20 July 1999, Sean Cribbs wrote:
> >> >I have Heise's code. It doesn't work on the new JDK.
> >>
> >> Heise's code
> >> should work today on a JDK 2.0 just as it did when it was written.
> >
> >SwingToolkit isn't exactly a 100% pure Java application. The sort of
> >task SwingToolkit is designed to do requires a lot of trickery and you
> >can't expect it to work when Sun makes the slightest change to its
> >libraries. This is the sort of software that needs to be updated
> >frequently to be compatible with new JVMs. Any code that is close to the
> >core of JOS is likely to have this same attribute.
>
> When you build a platform, you must act responsibly. You must not
> undermine
> your own customers. I do expect it to work. I can and should expect it to
> work. What gives Sun the right to break all my code? What gives Sun the
> right to make even the slightest change to its libraries? There is no
> justification for it. We're all worse off because Sun imagines that it's
> acceptable. Why do you accept it? It doesn't have to be this way.
>
> >I don't expect that standard JOS applications will run into the same
> >problems. I have certainly not encountered any problems.
>
> You need to raise your expectations. Java, with its interface mechanism
> and
> very large namespace, has the potential to maintain perfect compatibility.
> Java has this potential even if Sun doesn't see it.
>
> Haven't you suffered poor quality software long enough? It is poor quality
> to build a platform that doesn't last. Java 1.1 is a platform. In spite of
> what Sun wants, that platform is going to be around for more than two
> years. People have invested heavily in Java 1.1. What gives Sun the right
> to throw all their customer's code away? Who's code is it anyway?
>
> And I don't want JOS to become obsolete the moment that Java 3.0 is
> released by Sun Microsystems. Why should I waste my time?
>
> >> Isn't that what Write Once really means?
> >No. Write Once means that if you write an application against Swing
> >1.02, it will run on any Java platform that has Swing 1.02 without
> >having to rewrite it. If a Java platform has Swing 1.1, your application
> >needs to be upgraded to work with the new Swing. It is possible to have
> >both versions of Swing installed on your computer and run different
> >applications against different versions of swing as necessary.
>
> Think about what you're saying. You're saying that it is acceptable to
> port
> your Java applications from one version of Java to the next...when you
> don't have to. I think Write Once means Write Once, without qualification.
> It does not mean what Sun Microsystems says it means. It does not write
> once per version. There must be no fine print.
>
> I don't want to write once per version. Neither do any of my customers. To
> hear that it was possible to write once, and only once, was an inspiration
> to us all. It got the whole industry excited again. Sun doesn't mean write
> once when they say Write Once. Sun is lost. That doesn't mean that I have
> to be lost just like they are.
>
> >Having two versions of the JDK installed is another thing, though, and
> >could be difficult to handle in JOS. Luckily, JDK 1.2 is largely
> >backward compatible with JDK 1.1. One obvious difference is in the
> >threads API but Java developers have had sufficient warning to stop
> >calling stop() that there are unlikely to be many problems when
> >upgrading to JDK 1.2.
>
> Largely backward compatible is another way of saying incompatible. It is
> either compatible or it's not. If it's mostly compatible, almost
> compatible, slightly compatible, it is incompatible. Incompatible is
> unacceptable.
>
> Sufficient warning is another way of saying insufficient architecture.
> There should be no reason to warn people about added functionality.
> Warning
> implies that there is some kind of threat. How could added functionality
> be
> a threat to you? When you add functionality properly, there is no warning,
> only good news. You can do things that you've never been able to do
> before.
> You can do things with less effort than before.
>
> We add functionality all of the time. That is the mainstream of what we
> do.
> That may be all we do. We should not be afraid of adding functionality. It
> should not the enemy. If it is, there can be only one conclusion: we are
> doing something wrong.
>
>
> _______________________________________________
> UI maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/ui
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
