Improving Java for Linux
Jim Pick
jim at jimpick.com
Thu Nov 6 13:50:28 PST 1997
EAD-Frank.Stefani at t-online.de (Frank Stefani) writes:
> Java development currently goes very fast. It's a commercial race
> condition between Sun an M$. Volunteers don't even have a chance
> to hold this speed.
What this says to me is that we have to caution people against using
anything Sun draws up into a spec.
Because things are being driven by commercial considerations, and not
technical ones -- any Java APIs Sun puts forward ought to be approached with
a healthy dose of caution.
In particular, I don't think the free software java community should be
attempting to clone every one of the Java APIs put forward by Sun.
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.
Because Sun controls Java as a proprietary product, they can enlarge the
set of APIs they support via cross-licensing of code and patents. Any
free software implementations of these APIs may be problematic as they
may tread on corporate toes and raise patent infringement issues.
Microsoft is right. Sun is trying to turn the Java platform into a
proprietary environment which only Sun controls. Microsoft is hesitant
to support all of the Sun APIs as many of them do not integrate nicely
with the Microsoft environment. I think we are going to have the same
integration issues with Java and our free software environment.
I propose that we deal with this in essentially the same way Microsoft is
dealing with it. We can support the core Java APIs we need. And develop
our own "proprietary" libraries that consist of alternative functionality
to what Sun is trying to push. Fortunately, we can't do something stupid
like sign a Sun license - so we can't be pushed around. :-)
For instance, it will be extremely difficult to clone Sun's "swing" widgets
(part of JFC - all written in Java). I believe a better approach is to
provide a JVM (kaffe) which is capable of running Sun's class libraries.
But advocate that free software should not use Sun's libraries - but use
a free software implementation (such as Biss-AWT) instead.
Or perhaps we might develop some bindings to gtk, so that free software
Java programs could integrate with other free software in the Gnome
project.
Likewise, we could build bridges to other free software packages (such
as ILU) and whatever evolves to be our component object model (maybe
JavaBeans will work, maybe not).
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.
It's hard to make the "proprietary" label stick to free software.
Kaffe already runs on many platforms. Even on Win32 using Cygnus's
GNU-Win32. Tt only take some additional porting effort to make it
run on even more platforms.
I think this is a fairly important issue - as I am seeing free software
projects such as FreeBuilder which are planning to build their apps using
classes such as JFC and JavaBeans - when there are currently no free
software projects on the horizon to provide free software equivalents.
(sortof like the KDE/Qt thing all over again, arrrgh)
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..)
Cheers,
- Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 345 bytes
Desc: not available
Url : http://kaffe.org/pipermail/kaffe/attachments/19971106/8e08524b/attachment-0003.pgp
More information about the kaffe
mailing list