At Fosdem 2005 the GNU Classpath, Kaffe and GCJ hackers will cooperate and give
demos of what will be possible with Kaffe 1.1.5 and GCC 4.0. The main
theme of the official program is building bridges with other communities and contains talks about IKVM .net integration, cooperations with Apache Jakarta, rapid desktop development with java-gnome. And demonstrations of Free AWT and Swing plus lightning fast native eclipse and jonas.
Escape the Java Trap at Fosdem 2005
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
There is a great selection of open java tools right now…we’re almost at the point where we can in fact supplant a modern Sun JDK (not 1.5, I know) with a free toolchain. BUT its not clear exactly where the limits are and what tools must be present in the chain. I know the classpath folks have a nightly compatibility suite, but how does this mesh with Kaffe for example? Its not clear to me how it all fits together…but one thing is for sure, open source coders are opening java whether Sun wants it or not (I explicitly use a small ‘j’ in ‘java’ instead of ‘Java’ to denote what the de fact standard is and what Sun ‘owns’).
Example :
http://people.redhat.com/overholt/nativeeclipse/
Under the topic Free AWT and Swing, there is mention of the gcjwebplugin. Way cool!!! If they get it working properly, we’ll have Java Applets on PPC Linux and other platforms that don’t have an official Sun JDK.
Free Java is important especially if you’re running non-mainstream operating systems.
Why can’t Sun make this (java-gnome and ‘native performance’) happen? They have adopted GNOME as an ‘official’ API on their JDS system, and it can’t be any clearer that nobody is prepared to adopt Java on the desktop as long as Swing is the ‘One True Widget Set’. Or rather, nobody is prepared to adopt it when it performs as poorly as it does.
IBM has managed to surpass Sun’s IDE with their continued Eclipse development, and anybody using Sun’s IDE on Sun’s OS (e.g. NetBeans on Solaris) must feel a bit burnt when they see how much faster and nicer Eclipse runs on Windows.
The OSS community can and will ‘route around’ this problem using measures like the ones outlined in the article, but I just can’t figure out why Sun is so intent on making it as difficult as possible to actually choose Java to write good applications with – the OSS community shouldn’t have to ‘route around’ Sun.
one thing that puzzles me though is Swing when threaded properly is not really a poor performer. When I program in java I always use the official packages from Sun in order to remain in compatibility.
The flash show you provided is just totally amazing! When you use AWT under Gnome environment, isn’t your JVM will use native environment automatically? So if you are using Gnome, your AWT widgets will be using Gnome?
> I know the classpath folks have a nightly compatibility suite, but how does this mesh with Kaffe for example?
An effort to merge Kaffe class libraries and Classpath had been an ongoing tasks, now for years. Actually, there’s even daily CVS snapshot diff between Kaffe and Classpath to help this task:
http://developer.classpath.org/compare/classpath-kaffe/kaffe-classp…
(Same is true for libgcj, by the way)
Most of classes are merged by now, except java.lang, java.lang.ref, java.util.zip (Kaffe uses zlib, Classpath has Java implementation), and AWT (Kaffe has peerless AWT, in addition to Classpath’s GTK peer).
Now days most of development happen in Classpath, and Kaffe merges from Classpath CVS daily — and from other sources, like GNU JAXP (now in Classpath, but wasn’t), Tritonus, JacORB.
Kaffe is the most fully featured free JDK currently. VM and JIT is mature, it runs on so many platforms (50 and counting), the most complete class libraries, gathered from many sources. You may think Kaffe as “distribution” of free Java projects. 🙂
They should call it 1.2.0, not 1.1.5!
When it comes to open source Java, Sable eats all hands down. http://sablevm.org/ , but yet, i love the Sun’s java most
Classpath has generics-branch that uses 1.5 features.
> Put it together for me.
Run Kaffe CVS then. Kaffe really is a “put-together” project. Or wait for a while and run soon-to-be-released Kaffe.
Andy,
Eclipse uses IBM’s Java Widget toolkit called SWT. SWT applications inherits the operating system’s native widgets. So on Linux if you are running GNOME, Eclipse and SWT apps will inherit your GTK+ themes.
One would have thought that as Mono begins to woo free software developers, especially some of the GNOME developers, SUN would pump resources into java-gnome as a counter measure given their connection with the GNOME project. I’m flabbergasted SUN decides to ignore the project. The only reason I haven’t switched to Mono, is Eclipse. As soon as Monodevelop is as mature as Eclipse I’m switching in a heart beat.
>The only reason I haven’t switched to Mono, is Eclipse. >As soon as Monodevelop is as mature as Eclipse I’m >switching in a heart beat.
You can program mono/C# in Eclipse using a plugin. BTW, I can’t see the advantage of switching to a Ms technology, really. :-[
I find it pretty hard for Sun to support Java-Gnome… as much as i would like that to happen, though. They could also support SWT, but they don’t. They’re pretty “happy” (don’t know how to say it exactly) with Swing.
But maybe RedHat could support Java-Gnome; since RH already is a great supporter of both Gnome and Free Java… that would be perfect.
Victor.
“I’m flabbergasted SUN decides to ignore the project. ”
sun put their ressource on java… it will not put ressource on another copy of ms technology
java-gnome is not an ms technology.
NetBeans as an IDE is quiet slick now…and though there are some issues and it is not as cool as Eclipse, I would say it is a pretty fast IDE now especially on Windows. I am currently using NetBeans for a project in school and it is scorching fast on my machine starting up in less than 15 seconds after a reboot! The UI is very nice too and intuitive tho IMHO nothing beats IntelliJ.
How good is the c# plugin, do you know? For GNOME development today, Mono makes far more sense than Java. Where Java has the advantage, especially for free software developers, is the tools (e.g. Eclipse). Otherwise, Mono pretty much is a done deal for many free software developers, especially for GNOME.
I don’t think that’s already “closed” like that. Why would Mono be a “done deal”? Java-Gnome can be just as good. In the end it’s just programming languages, you pick the one you like best. But for all purposes, the only “done deal” is that C is the main language in the Gnome world.
Victor.
Victor,
Java is still considered as closed. The free alternatives aren’t even as complete as SUN or IBM’s proprietary implementation. So if I’m to develop a GNOME java app, I’d have to instruct or expect my users to install a non-free version of Java. That defeats the purpose for developing for a platform like GNOME.
Mono on the other hand is free software. It was designed from the scratch to aid the GNOME project and developers. It uses a higher level productive language C#, which is arguable more attractive than Java. It has more bindings to for the GNOME libraries than java-gnome does. I can hack on the VM if I want. I can contribute patches easily, source code is available for free etc. It already has more momentum (Check out the number of Mono apps). Among several other benefits.
As a free software hacker, it just doesn’t make sense for me to use java-gnome. Also, from a technical perspective, I think Mono/.NET has an edge over the Java platform. That’s just a personal opinion though. As for C, not many people want to use C to desktop applications anymore. C is good for libraries and low level programming.
And who said Java was original?
It’s so interesting the way C is holding onto its foothold as the implementation language for the GNOME toolkit whilst C# rises as a major player in GNOME app development. What’s even funnier of course is that C# is consider such a giant leap forward over C and C++. I’ve been using garbage collection in C++ for years now, so what does C# buy me? A better object model? A virtual machine? Ewww.
“It’s so interesting the way C is holding onto its foothold as the implementation language for the GNOME toolkit whilst C# rises as a major player in GNOME app development.”
How is this so? C# is more likely barely a speck of dirt under the carpet in importance for development relative to C, C++, and Java. Mono is there to tickle the fancies of Windows developers who might want to migrate or port apps to Linux, but, otherwise, why use a language and API library that has no clear freedom from Microsoft bringing it all down with a patent bomb. FOSS developers who are very aware of software patents would loathe to expose themselves to such risk.
“ow is this so? C# is more likely barely a speck of dirt under the carpet in importance for development relative to C, C++, and Java. Mono is there to tickle the fancies of Windows developers who might want to migrate or port apps to Linux, but, otherwise, why use a language and API library that has no clear freedom from Microsoft bringing it all down with a patent bomb.”
I think you’re giving Mono too much credit :p
Saying Java is evel coz you can’t use Sun’s implementation im a way you wish (which one?) is silly. I can claim that c# is evel because I have no LGPL implementation of it from Microsoft running on Windows/Linux/Solaris…!!!
Both Mono and Classpath are incomplete yet, but at least I can use and distribute Sun (IBM, BEA) implementation on any platform for free. I even can take a look at the code.
About the war between SWT and Swing.
I has been programmed with SWT within a year (2003).
I undestand why IBM made it.
Thanks to SWT team coz now I have a good Swing implementation (it still could be better 😉
The only problem for me is that I can’t compile my Swing GUI with Jet compiler and get rid of all java API that i don’t use…
Anyway my vote is for Swing.
Cheers.
It’s probably the biggest failure of Java. Even with 1.5 there is no sub-pixel rendering. It’s mind-boggling that Sun doesn’t seem to grok the importance of native fonts. I can almost deal with a non-native look-n-feel, but crappy fonts that look like circa 1988 Amiga is ridiculous.
Even with 1.5 there is no sub-pixel rendering.
It’s going to be included in Mustang release. See here: http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4726365
That’s an RFE. Can you point me to a source where it says that it will be in Mustang? In any case, this should have been done years ago, but I guess Sun is happy having Java relegated to the server.
Yes I can, scroll down to Work Around Evaluation, last comment from 2005-1-26:
We are working on this for the mustang release. A very small amount of
new API will be involved but we expect Swing’s Windows L&F and GTK L&F’s
to pick it up automatically so apps using those won’t need to do anything
so long as their desktop is configured to use it too (ie Swing will honour
the desktop setting). Apps will also be able to explicitly request
it for text drawing on a Graphics2D by setting a simple RenderingHint.
Happy coding
Java is still considered as closed. The free alternatives aren’t even as complete as SUN or IBM’s proprietary implementation. So if I’m to develop a GNOME java app, I’d have to instruct or expect my users to install a non-free version of Java. That defeats the purpose for developing for a platform like GNOME.
I’m sorry, but you misunderstood what i said, and what you say is not correct. First, because when i said “closed” i wasn’t talking about “closed/open source”… i was talking about a “closed deal”, which was what the parent what sayin. Sorry if i made you think that, but that’s not what i was talking about.
But second, trust me, the free JVMs already are very good if you want to develop Java-Gnome apps. The part where the JVMs are lacking is Swing – but Mono doesn’t have a good implementation of Windows.Forms either.
However, if you go with Java-Gnome, Swing won’t be a problem for you. So, if you’re a free software developer, and wants to work with Gnome, you can go with Java.
To see what the free JVMs have already accomplished, see:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
thanks for the redhat video! java looks like fun now. i might actually want to learn it, anyone recommend a few good tutorials, i’m on os x.
Victor,
java-gnome still doesn’t have as much libraries as Mono has, for GNOME development. And why would I need windows.forms to develop apps on Linux/Unix? Developing and deploying a Mono application for GNOME/Linux is still a lot easier than a Java/java-gnome application.
The number of applications written for GNOME using Mono as opposed to java-gnome speaks volumes to justify my stance. The free JVMs are good, but they are not complete. Last I checked, the only parts of Mono that aren’t implemented yet are the Windows specific parts. So for a free software developer, Mono stands on firmer grounds than the free implementations of Java or java-gnome.
java-gnome still doesn’t have as much libraries as Mono has, for GNOME development. And why would I need windows.forms to develop apps on Linux/Unix? Developing and deploying a Mono application for GNOME/Linux is still a lot easier than a Java/java-gnome application.
You didn’t get my point about Swing. What i was saying is that the part of the free JVMs where it’s far from good it’s the gui: Swing. If you take that out, you can say the free JVMs are pretty complete, just like you say Mono is “complete” without Windows.Forms.
So you have the option to use Java-Gnome to solve that problem, and the free JVMs are actually usable if you use it that way. Period.
My comparison with Windows.Forms have nothing to do with Windows/Linux issues. I simply mentioned that the area where Mono lacks – as a .NET implementation – is the gui too, the Windows.Forms gui, which AFAIK is the “standard” .NET gui, just like Swing is the “standard” Java gui.
Now, you are correct that Mono that has more Gnome libraries than Java-Gnome (don’t know if i agree about being easier, i think it’s pretty much the same), because Mono has a company supporting it. But the whole point that made me start this thread is that Java-Gnome has just as much potential than Mono in the free software world, and it does “make sense” to use Java for free softwares.
Victor.
>Last I checked, the only parts of Mono that aren’t
>implemented yet are the Windows specific parts
So what % of .NET?
What is Mono?
a) unlicensed, incomplete .NET implementation for Linux.
b) c# implementation with some Linux-based API wrappers.
I don’t like both.
a)
Microsoft can (and will) change any part of the .NET platform and Mono will always be several years behind… until Microsoft stops it because of patents.
b)
I do not compile the idea of wrappers (like SWT) for the protected garbage collected environment… I’m not sure if Mono has enough resources to develop something like JDBC or Swing (not talking about J2EE).
If I had free c# Swing implementation – OK, but you can always help to CLASSPATH with Swing will it be easy???
Victor,
Mono has a stronger footing in the GNOME/Linux development sphere than Java/java-gnome has. Mono is a unified front and development platform for the GNOME project. java-gnome is just a binding. That’s why I called Mono a done deal for GNOME development and interested developers.
I don’t think java-gnome has as much potential as Mono, because they can’t even be compared. Maybe a Java/java-gnome combo may. But SUN has made Java an unattractive platform for free software developers. You don’t need to take my word for it. On your own accord, take a look at the number of GNOME applications developed using Mono, and compare it to those developed using Java/java-gnome. It’s a landslide victory for Mono.
Why is this so? I’ve answered that above. But here it is again. It’s easier to develop and deploy with Mono than with Java/java-gnome given all the barriers one has to scale to deploy a Java/java-gnome application on Linux/Unix. Plus SUN continues to ignore the requests of free/open source developers with regards to Java.
In my opinion, Mono is a done deal for desktop application development on much of Linux/Unix. Heck, Eclipse is the only thing holding me back on Java/java-gnome. Immediately, Monodevelop rivals Eclipse, I’m switching. For me, it’s all about the availability of powerful development tools, and ease of deployment and of course freedom.
Mono, first and foremost, is a free development platform. It includes a compiler for the C# language, a runtime engine and class libraries. The Mono class libraries try to implement Microsoft .NET APIs such as ADO.NET, ASP.NET and SYSTEM.WINDOWS.FORMS. Almost 90% of Linux/Unix developers don’t need or would never touch those libraries. In fact, the libraries primarily target Windows developers who want to develop cross platform applications.
In addition to the .NET compatible libraries mentioned above, Mono implements several class libraries not related to any Microsoft technology. Several of these libraries provide APIs, to graphic user interfaces–GTK#, open source database libraries–sqlite *sql libs, GNOME libraries and several 3rd party libraries. This is the part that mostly interests Linux/Unix developers. It doesn’t matter what MS does to their .NET libs, these libraries will continue to expand and involve.
As for the issues of patents, Java is patented too. And SUN as equal chances of using patents against Linux, seems they seem to hate it so much, as Microsoft those. These days, almost anything is patented that you might as well quit developing software if patents bother you.
With regards to Swing, from my perspective, it is unpopular. I don’t like it. I don’t believe in cross platform, peculiar, uncomformable look and feels. Swing applications look ugly, out of place and slow on any platform I use. I think it is a horrid idea. I think it should die. I think SUN would be better off investing in native GUIs that look, feel and act the same as other applications in native platforms as opposed to their demented cross platform look and feel idealogy. I could care less if Swing died a horrible death and I know many developers who share the same feelings.
Actually, Classpath’s AWT and Swing have been merged in as well. But you also have the option to use Kaffe’s peerless AWT without swing with Qt2/3/Embedded. x11 and nano-x backends, which is mostly interesting for embedded targets.
Other than that, yeah around two dozen classes to go, and each week they are growing less and less
Kaffe is in general the VM that tracks GNU Classpath very closely. I am responsible for keeping Kaffe and Classpath in sync, and Kaffe is usually no more than a day or two behind the latest changes in GNU Classpath.
cheers,
dalibor topic,
robilad on #kaffe on irc.freenode.org
Mono is pretty cool. It has pretty good developers with a charismatic, enthusistic leader, has a good amount of cash behind it, and most importantly doesn’t have pretty good free as in beer competition on their home platform.
GNU Classpath is fighting a harder battle because a lot of people try to compare Kaffe to Sun’s VM, and happily ignore the freedom aspect, focusing on where the free runtime is still behind the non-free counterpart, instead of looking at how much already works well (java-gnome, swt, etc), and how much progress has there been in the last years. Mono doesn;t suffer from that, because everyne writing free software applications in C# is writing them on Mono and pnet anyway. It’s different in the Java space, and it will take a while to fix the perception that free runtimes are inferior to non-free ones.
Sun’s vaporware marketing stunts about pseudo-open sourcing parts of their code additionally serve to keep people from contributing to GNU Classpath, gcj and Kaffe. The only reason Sun is starting to pseudo-‘open up’ their code lately is because they are starting to fear that people may realize sooner than later how irrelevant Sun’s proprietary code base has become.
Mono doesn’t have to deal with all that, fortunately for them. It’s quite clear that if you need interoperability with C#, you’ll go contribute your resources to Mono and portable .net. If you need that for Java, you first have to cut through all the Sun marketing speak about Java being ‘oh so open-source like’ to figure out that Sun’s code is not free to redistribute, port or modify without paying up for a commercial use license, and paying a hefty extra fee for their compliance test suite, without which you are not allowed to release your changes to Sun’s source anyway.
Microsoft is not playing pseudo-open source marketing games with Monos on their home platform, and is actively working on standardising parts of their language and class libraries, something Sun has always refused to do.
My impression is that Microsoft is doing a much better job of turning C# into a real, open standard than Sun has ever done with Java. So I’m glad that Mono is progressing so well, as they show how it could have been in the Java space, if it wasn’t for Sun.
cheers,
dalibor topic
java-gnome still doesn’t have as much libraries as Mono has, for GNOME development.
It should be mentioned that mono has, IMO, a large advantage in this area. P/Invoke is several orders of magnitude simpler than JNI. Basically, if a binding to a library is missing in java, you get to write C code to link it in to Java (similar to python modules) and deal with the build problems that creates, while with mono, you can write a *portable* wrapper in C# (similar to python’s ctypes :-).
For people who are not experts, the mono route is much, much less daunting a task. I was able to write a wrapper for gstreamer’s GstPlay class with no trouble. I probably would have resorted to spawning gst-launch using Java. I would say that the mono path leaves the developer feeling better overall.
-Mark
“My impression is that Microsoft is doing a much better job of turning C# into a real, open standard than Sun has ever done with Java.”
But at least I can download the Linux JDK from Sun, and Apple takes care of the OS X JDK, my impression is that MS doesn’t care at all about cross platform .Net.
Mono is a unified front and development platform for the GNOME project. java-gnome is just a binding.
Wow. Well, if you take at look at mono-project.com, it says:
“Mono is a comprehensive open source development platform based on the .NET framework that allows developers to build Linux and cross-platform applications with unprecedented productivity.”
Hmm, no “GNOME” word in there. So no, Mono, is not a “development platform for the Gnome project”. It’s just a .NET implementation, and you may use it for KDE, Windows, whatever you want. Just like the Java platform. It just happened to get more attention in the Gnome world because it was started by Ximian.
But SUN has made Java an unattractive platform for free software developers.
Ok, you don’t wanna compare Sun’s past history with Microsoft’s past history, do you? What i mean is, i could say the same about MS, that it made .NET an unattractive plaform for free software developers.
You don’t need to take my word for it: just take a look at all the “what about the patents??” threads that popup everytime someone talks about Mono.
On your own accord, take a look at the number of GNOME applications developed using Mono, and compare it to those developed using Java/java-gnome. It’s a landslide victory for Mono.
Why is this so? I’ve answered that above.
You haven’t. But i will: there are many more Mono apps because Mono has a big company behind it, and that made it evolve much faster than Java-Gnome, obviously.
It’s easier to develop and deploy with Mono than with Java/java-gnome given all the barriers one has to scale to deploy a Java/java-gnome application on Linux/Unix. Plus SUN continues to ignore the requests of free/open source developers with regards to Java.
Well, if you use a free JVM, you don’t need to worry about Sun. Sun doesn’t have much to do with this discussion, really. But about the barries to deploy java apps on Linux/Unix… oh come on, Java – unlike .NET – was made to be cross-platform.
Victor.
Victor,
Question 19: How is Mono related to GNOME?
In a number of ways. This project was born out of the need of providing improved tools for the GNOME community, and will use existing components that have been developed for GNOME when they are available. For example, we plan to use Gtk+ and Libart to implement Winforms and the Drawing2D API and are considering GObject support.
Mono team members work actively on the Gtk# project: a binding of the GNOME class libraries for .NET and Mono.
http://www.mono-project.com/about/faq.html#gnome
You claim Mono has a big company behind it. How about Java? Does it have a small company behind it?
Victor,
Java/java-gnome is not popular because, thanks to SUN, it is not attractive to free software hackers, period. Python/pygtk does not have big company behind, yet there are more GTK+ programs written in python than in any other language binding for GTK/GNOME. Your “big company” theory is flawed here.
Well, if all you want is non-free C# runtimes for non-Microsoft manufactured operating systems, Microsoft has actually ported/paid people to port their ‘shared source’ implementation called Rotor to a handful of platforms.
I have no idea why one would want to use them instead of Mono, but hey, you asked, and it seems that Microsoft does care about cross-platform .net. See http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7… for their cross-platform implementation. The license is actually much saner than Sun’s, afaict, though still very useless. Otoh, it’s hard to match the l33t software license mis-writing skills of the people that cobbled together Sun’s Java source code license, the SCSL.
cheers,
dalibor topic
You can’t do anything with this, looking at it is enough for use to go after you with a baseball bat.
The SCSL, (use to?) say about the same. But that is just the Source! The MS offering is for BSD implementation!
SCSL does not cover the Linux imp.
The SCSL covers any Java(TM) implementation using Sun’s source code, including IBM’s, Blackdown’s, BEA’s and Sun’s. Prior to Java 1.5 it was not possible to have an open source implementation and be compatible with Sun, because Sun required implementors to ship SCSL covered code. The SCSL is Sun’s idea of ‘compatibility through big sticks’.
Sun’s binaries are licensed under different SCSL-derivatives, which all say the same as the SCSL, except that they do not talk so much about the source code.
Sun’s Java licenses are designed to go after people they do not like with a big, fat baseball bat. That’s the same for their source code, and their binary licenses, which is why Debian, Ubuntu, Fedora and other Linux distributions do not ship Sun’s implementation.
Sun’s grip on Java is just a bit more firm than Microsoft’s on .net, other than that it’s just the same nonsense in a different wrapping.
cheers,
dalibor topic
P/Invoke is several orders of magnitude simpler than JNI. Basically, if a binding to a library is missing in java, you get to write C code to link it in to Java (similar to python modules) and deal with the build problems that creates, while with mono, you can write a *portable* wrapper in C# (similar to python’s ctypes :-).
So you’ve successfully wrapped a single class written in C using P/Invoke, and then generalize to say that ‘P/Invoke is several orders of magnitude simpler’. I certainly think it has a shorter learning curve, and works well for small C api wrapping tasks like yours.
The Qt/KDE api has around C++ 1000 classes and about 25000 methods – it’s huge and there’s no way you can wrap something that large without an automated tool.
KDE uses method overloading where methods have the same name and only differ in their argument types. P/Invoke doesn’t have a standard way of interfacing with C++, only C, and so it doesn’t have any naming scheme for overloaded methods, whereas JNI does. As P/Invoke doesn’t know anything about compiler specific C++ name mangling, it means you have to wrap your C++ api in C, just like JNI.
The only way you’re ever going to wrap an api as large as the KDE one, is with an automated tool anyway. If it spits out P/Invoke stuff or JNI stuff, it’s roughly the same amount of work. I maintain the Qt/KDE java bindings – they are autogenerated via a perl script and it takes less than half a day to regenerate the bindings for a new KDE release.
The best interface to C++ code from Java is via gcj’s CNI; it allows you to combine C++ and Java in a very natural way. It is easier to use and more efficient than both JNI and P/Invoke for wrapping C++ apis. But I’m not sure many people know about it unfortunately.