Hello I've been working for a while on and all java Windowing system.
My current version is written on top of the Swing toolkit. Which is
practically all Java.
Well it turns out even Swing is flawed.
The problem with Swing is the attempt to reuse Graphics context and not
being thread safe.
Plus it is removed from the hardware by the underlying windowing system
and is hacked to run at a higher level
of abstraction.
You get hosed sooner or later. I've have come to
some conclusions tonight. One if you wish to use any native graphics
above the level of basic device drivers
and a drawing package you will not e able to do it in a generic
manner. There are too many places were inconsistencies
cause basic problems. Second if you move to the swing model things get
better but you still suffer inconsistencies from trying to
save multiple graphics context's i.e. SwingGraphics does not really
work.
I think the guys at Id software or any other game developer could attest
to this. It's well understood in the gaming
community but ignored by the commercial GUI resellers.
In my opinion there are only three choices for a GUI in java.
1.) Allow each platform to expose its native interface this is akin to
the approach taken by Apple, Sun and Microsoft.
This results in continuos problems that can in my opinion never be
resolved.
2.) Try a middle ground this is the approach taken by Swing and
previously Apple/Next in Openstep.
This approach works a lot better but still results in some fairly basic
problem mainly resulting from not having direct
graphics hardware access across platforms and dealing with native
windows. This approach simply reduces the number
of problem which result from using the first approach. I does not
eliminate them.
The real problem results from graphics code having to go from very high
level draw object methods to low level blitting ops.
There is no way to support this on top of platform which contain even
simple differences.
Swing in my opinion will fail just as Openstep would have.
3.) The last resort is to support java directly at the primitive
graphics layer. This turns out to be the only viable solution.
This is the path I took and it works well. I did it not because
I originally though it would be the best solution but
simply because I wanted to build it. Now I feel its the only
viable solution. This is the approach taken by the Game
developers. They do it for speed for the most part but it turns
out to be the only way to build a stable consistent GUI system.
In reality a GUI is nothing more than a basic game.
The main reason I'm writing this is to one hope the Linux community
explores adding low level Java graphics support to
Linux. I believe that with ggi Linux could become one of the few
platforms were Java graphics work correctly.
You can continue to support X but Java graphics object must be first
class citizens with the native graphics.
This is not really a language issues but a simple matter of true java
support. To forget java for a moment.
I for one would not want to write some hybrid which supported both
KDE and Gnome but this is exactly what the
AWT is today. Next the Swing is again much better but is akin t
supporting Gnome inside KDE which leads to
some interesting problems. I don't think anyone would whant to
solve theres problems in C/C++ why would you expect
them to magically go away in Java. As another example Exceed is a fine X
windowing solution for Windows NT but
is suffers numerous integration problems. Most people don't worry about
them because it offers a solution but it
will never be as good as native Win32 or native X period.
This bring up a basic problem with Linux. It's intel centric. Although
linux runs on a multitude of CPU's it is still centered around
the intel cpu. It's offered e quit a bit of freedom in choosing a free
OS. but try finding binaries for the alternative platforms.
The percentages of Linux running on various cpu's closely mirrors that
of commercial offerings. Within the Linux community
few have left the intel dominated computer market.
This is a big problem IMHO.
Although Linux likes to represents a challenge to Windows it's actually
more threatening to the Intel side of the monopoly.
Once you chose and alternative OS moving to and alternative CPU is not
a big issue. Considering the number of seats of Linux
accumulating over the next few years and the fact they can easily switch
cpu designs. Then Linux could represent a viable
platform for a secondary cpu manufacture. This is one of the
unrecognized powers of linux. I suspect that Linus may have
realized this otherwise why is he working for Transmeta ???? I think the
only real problem is Linus is a systems programmer
and does not understand all the needs of applications programmers nor
should he. Its up to the application programmers
to express those needs to Linus and the other systems programmers.
Once they get out of assem to C they are done for the most part with
"porting" and OS. This is not the same porting issues
a Application programmer faces. The application programmer face tow
porting issues binary comaptibility and API's.
Next's MAB soution plus Openstep offered the only real solution for
Native code. And this would be the path
Linux would eventually have to be cross platform and have native
application binaries. However Java offers a far better solution.
Many Linux programmers are rejecting java today and for good reason but
it does have some powerful strengths.
These should not be thrown out because of Sun. java offers the
possibility of distributing binary versions
of free software that are easily run on any cpu. This addresses on of
the basic problems I find with free software.
If you try to move to a different OS/CPU combination your forced to
rebuild and possibly port the free software.
This is simply a big pain in the ass. I can say far more on the issue
: )
Java/Linux offers the choice of OS CPU and simple download installation
of binary free software.
Java server side programs are extremely portable assuming you don't
write them only on NT.
The NT thread model is flawed it allows race conditions.
Otherwise I have found it and excellent language to use even given the
present state of JVM's.
But on the GUI side its hosed as I out lined above.
The Linux OS is in a unique position it runs on many CPU's it has no
real amount of legacy gui apps to support
or accepted gui.
This factors and the problems with implementing Java on top of a
platform api leaves it in the
unique position of not only being able to provide the best java
environment for "standard" apps but
also provide it on multiple CPUs.
Most people consider the lack of a standard GUI for linux to be a
problem but I consider it to be a unique advantage.
We are the only platform that can truly support java if we take
advantage of it.
But to do that I feel that Java must be supported from the GGI level up.
Currently Gnome/KDE do not
support Java and IU hope there creators could consider supporting Java
deep in the internals of both.
This also offers a solution to the Multi native desktop problem. Provide
fundamental support for Java so Application
writers can always have a base platform to write to. This can be expose
in a C/C++ api also.
Although its not often done there is no reason why a C api cannot be
layered on top of java.
This fundamental support offers binary convience to free software plus
api stability. The KDE/Gnome battle
can continue forever but I get my applications.
The bottom line is Java is vital to Linux moving mainstream and being
truly CPU independent.
I believe that until I can get Linux binaries for any CPU then it only
get rid of one master Windows but keeps a
second intel. The current free software recompile crud is good for
geeks but cannot be taken mainstream.
And Linux binaries only for intel is not much of a choice.
Linux offers the only long term viable java solution since it's the
only platform
that can embrace portable Java in its core windowing environment.
I enjoy java programming and linux and hope that more people realize
how much they need each other.
Forget about Sun/Intel/Microsoft look at the technical issues. Java
graphics today are fatally flawed ,
to do it right Java support must be inclued in the basic windowing
system design. This can be done today in Linux.
IMHO
Mike
