wt toolkit
Submitted by andyb on Tue, 05/04/2004 - 13:53.
I apologise if this is a stupid question, but why create a custom toolkit in jnode. Swing only needs a few peer components and then would it not be easier to implement awt and swt with the laos (awt back by swing) and swtswing (swt backed by swing) projects. This way swing becomes your default toolkit and swt/awt use that to do their drawing. No need for custom swing lnf, no need for custom implementation of native toolkit and you could have swing/awt/swt up and running much faster, and propably with a lot less bugs. Also adding a new widget toolkit is just going to confuse things, look at the mess in linux with apps written in qt/gtk/wxwindows/tk/motif/. Do you really want to create a mess like that up front. At lease in the abouve senario the three widget sets are all actually swing thus giving a consistant look and feel across the toolkits and also ensuring dnd and clipboard actions are all compatible.
- Login to post comments
news about SwtSwing
Have you seen the progress on SWTSwing (see here) ?
While looking at the
gallery of eclipse running on swing for Eos project, you can see that there is very promising progress.
Fabien
my blog (in english and french)
I agree
I agree with you. We thought about creating the basic widgets so that we can map the AWT on it but as you say we could just make swing runing and map AWT back to swing. The problem is that there is no opensource Swing implementation till today. At least I don't know any. The GNU classpath project has implemented just a small piece from it.
wt toolkit
I'm not an expert on the issue but...
considering the response to the original mail wouldnt it then be better to contribute to the GNU Classpath implementation of Swing and then use that as a basis for the architecture explained above?
GNU classpath, Swing and the like
Did you see this thread in GNU Classpath mailing-list :
http://mail.gnu.org/archive/html/classpath/2004-04/threads.html#00245 (known people there
The answer is not a good news for JNode IMHO.
Classpath developpers seem to like native methods and native methods are... everywhere in Classpath, especially in the GUI packages.
There are good arguments for this (fast and reliable low-level API, GTK+...) but these are not JNode's ones.
An easy way for providing hooks towards different underlying architectures would definitely help JNode... and make GNU Classpath even better.
p.b.
native methods redirected to a JAVA class ?
I don't know if JNode VM handle the native keyword or not.
Do you think that the native methods can be redirected to static methods (with same name) in a class (we can name it Native for example) ?
If possible, I think we have a way to use directly the class from Classpath. Of course, we always need to implements these native methods in JAVA but the JNode VM specificity remain outside of Classpath.
To go further, we can use many classes to implement these native methods. This avoid to put all native methods implementations in the same class. In these case, the Native class can have an invoke method that redirects the call to the effective method in another class.
This have many advantages :
- keep a unique and well identified entry point for native methods
- in Native.invoke(Object, String, Object[]), all unimplemented native calls can throw an exception (we can call it UnhandledNativeCallException)
Native methods
Since JNode took the pure Java way the native methods debate that favors native code seems somewhat out of place. In JNode there is one class that contains native methods: Unsafe. It would be good if this would not change (much).
However I bumped into native methods in an other way. I wrote a small test class that ahd one native method trying to run the code generated by the L2 compiler, outside JNode. This class was in the JNode source tree and when I tried to build JNode in the normal way during the creation of the JNode image I got an error at the named native method.
I just commented out the native method and the parts that used it and it worked again.
However, there is a lot of Java code out there that relies on native libraries, that people might want to run on JNode without changing it.
Though not the most important thing at the moent, this situation should be handled sometime. Here is a solution.
We defeine an archive format similar to the plugins that provides the functionality of the required native library in pure Java using the JNode APIs. The System.loadLibrary() could lookup the required archive based on the specified String. The native methods in the class should be linked to the implementing methods class loadtime or method compile time. A naming convention is needed for these archives that is compatible with the satndard naming convention used for native libraries in the JDK.
This or s similar method would provide a transparent and pure Java solution for the handling of native calls that we cannot change.
Levente
Yes, however we need to handle the native calls
I agree with you.
Outside of the Classpath debate, one day or another I think we will need to handle native calls with a solution like your.
For example, a commercial java application (with closed source code or obsuscated bytecode) with native calls. If we have access to the spec of the native calls (or the native library is open source), we can implement it in pure JAVA.
How ???
Sorry, I may be missing something obvious there...
Once you have delegated the code execution to native methods, you loose control over them, don't you ?
So... what if these native methods rely on an underlying *OS* ?
Let's take a GNU classpath example :
GlyphVector (pure Java) -> GdkGlyphVector (beginning of the end
-> GTK (native, open) -> Pango (native, open as well 
-> OS graphic primitives (say Windows GDI API) -> drivers -> hardware.
Of course, the main (and maybe only) problem is the "OS graphic primitives" step.
So... what am I missing ?
p.b.
implement all native libraries
All native (underlying) libraries need to be implemented, at least partially. But some layer may be eventually eliminated.
In your example : we only need to link GlyphVector or GdkGlyphVector with our graphic primitives (maybe JNodeGraphics).
But there is no need to implement all the used native libraries if it's what you mean. Yes, it may involve a lot of job.
All ?
"All" or "some" libraries ???
I can obviously understand that some "standard" libraries could be implemented but... all ?!
Really, I do think that a really functional Java OS would help in getting more and more full Java programs, I mean less and less "native-code to Java" wrappings
Here are *my* hopes in JNode ; where are yours ? 
)
Regarding links, you are definitely right :
GlyphVector (pure Java) -> GdkGlyphVector (beginning of the end
-> GTK (native, open) -> Pango (native, open as well 
-> OS graphic primitives (say Windows GDI API) -> drivers -> hardware.
... could (should ? must ?) be replaced by a full JNode's spirit chain, something like :
GlyphVector -> JNode graphic primitives (yet to be defined : get inspiration from Java-Gnome ?) -> drivers -> hardware.
If you like, have a look at a full-Java AWT replacement http://www.eteks.com/pja/en/ (french product
.
That could be a basic yet (almost) functional startpoint for JNode's GUI... if GNU Classpath project helps.
Regards.
p.b.
Not all, only the needed native wrapper
Yes I also want to reduce (or use absolutely no) native wrapper as far as possible. For Classpath integration, I think (I hope) we won't need native wrapper because their team will go in such a way that VM like JNode VM won't need native calls.
When I said JNodeGraphics, in fact it was org.jnode.awt.imageJNodeBufferedImageGraphics that is already in CVS. So, I think the primitives are already implemented.
OK
I think we now agree
Cheers,
Do native methods have sense in JNode ?
Of course, not !!!
Well... what's the problem ?
IMHO, GNU Classpath fellows want efficient core classes. Their interest is to come as soon as possible into native methods, which are presumed to be faster, more reliable...
To be short : the earliest, the best.
BTW : Sun's preoccupations are exactly the same
This preoccupation is *completely* opposite to JNode's which (should) prefers the latest, the best policy.
IMHO, if GNU Classpath were offering a sexy manner to create hooks towards native methods it would be a benefit to Jnode as well as to GNU Classpath.
Namely, something like :
build NativeMethodsAsSoonAsPossible stubs=GTK,powerfulIOLibrary,superSockets
vs.
build NativeMethodsAsLateAsPossible stub=Native_Java_JNode_Stubs
If you look at Sun's source code, you will notice that "low-level" classes (especially graphic-related ones) are hooked *very* early towards native (i.e. OS specific ones) methods. An easy way to blame the OS when benchmarks are bad...
)
More seriously, here is an example of how to short-cut OS' traditionnal job, namely for font management :
http://www.brawer.ch/software/fonts/
IMHO, this is what JNode should do. I hoped GNU Classpath guys had the same considerations for everybody's benefit...
p.b.
Should be in classpath
In Classpath, there is a discussion and tendency to move native methods to VM/Platform specific classes. This is how it should be done, making our own native redirection is not something i'd like to do.
Ewout
Swing
To contribute to Swing either in JNode or in Classpath is definetly a good thing as it will get soon or later into JNode anyway.
The Swing based GUI implementation was already debated several times. The main problem was that there was no free Swing implemntation at hand. However lately there is a lot of activity going on in the Swing packages of Classpath. The GNU Classpath 0.09 (released two days later than JNode 0.1.7) clearly shows this.
We should not forget that we still need a desktop and window manager for top level windows, WT can be a candidate for that.