Improving Java for Linux

Dave Glowacki dglo at SSEC.WISC.EDU
Thu Nov 6 14:55:10 PST 1997

> We should definitely clone the core set of Java APIs that are needed,
> and maintain 100% compatibility at that level.  And we should have virtual
> machines that are capable of running Sun's classes.
> But many of the more complex products and APIs (JFC, JavaBeans, JavaHelp,
> JavaBlend, JavaMedia, Java Management, etc, etc.) are just going to be too
> complex, too proprietary or too liquid for the free software community to
> do a decent job of cloning them.

[A bunch of examples of non-standard extensions to Java deleted]

> Some people will have strong objections to doing this (binding
> to a native platform libraries) - since this is essentially what Microsoft
> is advocating with many of their "extensions" to Java. ie. "Sacrificing
> portability for integration"
> But I think we can fix the portability argument by making sure our JVM
> runs just about anywhere.  Plus people who want portability using Sun's
> classes can still use those classes with our JVM.  Of course, those apps
> would not be considered "free software" if they are dependent on non-free
> software.
> So, does anybody else feel like it might be time to "diverge" a bit from
> Sun's definition of what the Java platform should be?  
> (Note: I'm not advocating diverging the JVM or the core API set - but
>        we should certainly take a long hard look at whether we want
>        AWT/JFC as our widget set, and JavaBeans..)

Sun's argument (and I agree with them) is that JFC (and JavaBeans) *are*
part of the core classes.  JFC adds *so much* to the language that not
including it means not working with any new apps.

Using a nonstandard extension also means that any Java program you write
won't be useable for anyone who isn't using your platform (which is why
Microsoft wants people to use their API)

Therefore, if you don't mind the fact that you won't be able to run other
people's apps and they won't be able to run yours, go ahead and ignore
the extensions.

Kaffe et al don't support JFC/JavaBeans/etc. because the support hasn't yet
been written and I can deal with that (though I feel guilty for not helping
out right now)

I'd hate to see the free software community actively branch itself off from
the main Java development for two reasons.

First, any free tools that actively avoided the java.* API would be
virtually useless to me.

Second, I'm a veteran of the Unix wars of the '80s so I've watched one
great technology Balkanize itself into obscurity.  I really don't want
to have that happen to Java, since it'd probably be another decade or so
before something else got up enough momentum to replace it.

In other words, I think a big gaping hole in the API is better than
a non-portable hack.

More information about the kaffe mailing list