Design your application’s GUI look in XML, write the code in Java and plug the whole thing in to the GNOME desktop.
Developing GNOME Applications with Java
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Instead of using GLADE, why don’t we just use Java’s 1.5 built-in XML GUI presentation layer called “Synth”???
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/plaf/synth/pack…
Just my 2 cents
Thus, no synth.
All those Adapter classes are so freaking ugly and inelegant compared to events and delegates in C#.
Think about it. You’ve got these interfaces for your callbacks and then you’ve got these stubbed out methods in the Adapter classes that you can override particular methods of.
And I don’t hate Java. I’m still looking forward to a snapshot of Mustang coming out next week that will be the first release of Swing with subpixel-rendering enabled. I emailed one of the Java2d guys and he’s running an internal build and says it looks sweet.
I feel kind of bad for the Gnome/Gtk+ Java bindings guys because from the limited amount I’ve played with, it seems to be a really nice project. It’s just that nobody cares really. Everybody is either messing around with Python or Mono.
Your links seems to be down, but Swing is a non-starter for anything that would be officially included in Gnome.
There is a reason why java is not used that much for desktop applications. It sucks in that area. The layout managers are dumb and if you want to design a proper GUI they get nothing but in the way. If gnome turnes to java it will be its demise.
Java-GNOME is a wonderful project. I’m glad it’s getting some publicity.
“The layout managers are dumb and if you want to design a proper GUI they get nothing but in the way.”
Blame IBM then… – we’re doing SWT here.
And fwiw, there *so* many layout managers out there (that work like a charm) that it’s basically more of a giving up statement from you, because you didn’t bother looking into stuff. FWIW, Java layout is sooo much better than what I worked (limited though!) with in C#
This is the best idea. I like Java and I want to see Gnome based in 100% in Java.
Very cool article. I think that gcj+gtk is the way to go for GNOME apps. High level language + native binaries + free/libre license = end of discussion.
Also interesting: http://www.valdyas.org/fading/index.cgi/hacking/gcj.html?seemore=y
Well this is nothing new, but nice tutorials though! =)
I like the idea of developing GNOME applications in Java though! Go for it! Screw Novell and Mono…
”
Why does Novell require a copyright assignment?
When a developer contributes code to the C# compiler or the Mono runtime engine, we require that the author grants Novell the right to relicense his/her contribution under other licensing terms.
This allows Novell to re-distribute the Mono source code to parties that might not want to use the GPL or LGPL versions of the code.
Particularly embedded system vendors obtain grants to the Mono runtime engine and modify it for their own purposes without having to release those changes back.
”
( http://www.mono-project.com/FAQ:_Licensing#Why_does_Novell_require_… )
Uh, oh, please don’t do that. Especially since kdevelop3 is getting so freaking great that I barely can convince myself to use anything else these days. Ok, ok, do it in java if you like, just don’t try to turn kde into what gnome is heading: without a usable unified and good rad environment they just keep crapping with mono, java, whatever and spreading the prophecy that gnome’s future is in one of those. Ok, if you think so… no problem, I just wouldn’t join the party.
It is the other best idea. I like this idea too.
Plus: gcj is where RMS `puts his money’. The man knows something.
I think 2005 is going to be the year of desktop java.
In case people are wondering about the Mono problem, it’s this: Microsoft can, at apparently any point in the future patent aspects of C#, CLR or any implementation details of the library. This could make it possible to ship a legal C# compiler.
As an example, last year they tried to patent an obscure aspect of the FAT32 filesystem, almost 10 years after they introduced it. Had they succeeded, not only could they charge every media (floppy, USB key etc.) manufacturer a fee per product, but they could have entirely locked out F/OSS products. It would have become impossible to use the same USB-key for Linux and Windows. You would have to re-format it to Ext2 or something and only use it with Linux boxes. This would have put F/OSS users at a major disadvantage.
Should the Linux desktop every begin to seriously encroach on Microsoft’s market (e.g. 15% share), they may try to “leverage their IP”, i.e. patent an obscure aspect of C# and make F/OSS C# compilers illegal. If the majority of Gnome is written in C# at this point, the majority of Gnome will have to be dropped.
Sun could do the same, but are less likely to do so. For one thing, they have not been found guilty of several counts of anti-competitive behaviour. Secondly, they are far too reliant on the enterprise (in which IBM and JBoss play a dominant role) to muck about with IP like this, it would do as much damage to them. Indeed, they have waived a lot of IP rights in order to create a community around the product. For their part Microsoft has created a cross-platform development system that only works on one platform.
Things like qtjava and these impressive Gnome bindings, alongside GCJ and GIJ, show that one can build powerful, natively compiled GUIs on Linux using a language whose maker is far less likely to abuse their IP. Java 1.5 has most of the good features of C# (and a few more besides) and the GCJ folk are working on porting those Java 1.5 features. Further, it has a huge class library, and other class libraries on the net, that drastically cut down development time.
In short, the technical differences between Java and C# are minor, but the legal benefits of Java are clear. It is the most secure modern language in which to build a modern desktop.
http://www.kdedevelopers.org/node/view/1104
😀
>>without a usable unified and good rad environment they just keep crapping with mono, java, whatever and spreading the prophecy that gnome’s future is in one of those.<<
Oh come on now! A programming language dose not equal a RAD, there was always Glade and Anjuta 2 is finally out! So there you have your RAD and best of all, you can use it with C, C++, Java and any other language somebody cares enough to make a module for (I found the beginning of an O’Caml module in their wiki).
The reason so many Gnome people are obsessing over mono is that Gnome was always supposed to allow developing apps with any language you feel like. That still is a goal of Gnome but it never really was with KDE. Just about everything there is developed with C++.
This was never about the next generation language for Gnome but about the next generation infrastructure for multi language development. You like/know C#, fine use that. You like/know python, fine use that. You like/know Java fine use that.
Native compiled Java with Gnome bindings is a really nice alternative to programming with C, C++ or C#.
“Sun could do the same, but are less likely to do so.”
I don’t think this is the important point – any company could change or be bought up. What is important is that Sun has made a full free patent grant of the Java technology. Any future management at Sun would have extreme legal difficulties in trying to reverse this.
This is why from the point of legal safety the future of Gnome should be with Java/GCJ rather than C#/Mono.
This is other idea for future. I think that operating systems can be created in Java too in future (including Unix too).
Be careful building the bindings from source if you’re a slack user like me and can’t find a package or whathaveyou, as it’s a PITA. I ran into some missing CFLAGS and a couple of other things that shouldn’t happen in a source package like this.
Aside from building difficulty, the bindings are fantastic, though. The java-gnome documentation seems to be rather nice and helpful, and the API stuff is all in javadoc form so it’s what java devs are used to pawing through. If you’re a fan of GNOME like I am, and are most comfortable develping in java, they’re the way to go.
He is right, you know? .NET is an ECMA standard, yes. It is not encumbered by patents, at this point. It is, however, perfectly legal to add patented pieces of technology to the .NET standard. This way, the F/OSS community will be left alone with either an obsolete platfom or will have to pay a huge amount of money.
Why that urge to base Gnome on java? Seriously, there must be other languages/compilers that are better suited for the task.
Java? Mono? (like in Microsoft .Net based Mono)? What is going on?!?! These technologies are controlled by single companies be they good or evil.
Why not perl/tk, or python, or ruby, or C-interpreted, or TCL, or (the list goes on)…?
Well, the only “problem” whith java that I know is that gcj is behind sun’s proprietary Java SDK. But they’re catching up I think.
why is the great debate just between mono and java????
hmmm i smell money and power…master yoda
gcj is the way to go for GNOME
each day, people join to kde, about 65% linux people use it…
if gnome sleep during a long time, gnome will die
yea my 350mhz 128mb machne will just love gnome if everything is done in java, i can go get a cup of JAVA and have plenty of time to enjoy waiting on everything, while my processor is maxed out…
oh thats right, better hardware requires that we use all that performance up, just like faster internet connections mean we cram more junk on the net and eat it up as well.. I guess I am just left out
What gcj(and java) needs for mindshare in the gnome comunity is someone developing full apps with the java-gnome bindings, like Mono is doing with C# and GTK#. Once people see good sample apps written in native java for gnome, they will start trying it as well. They want to see real stuff working. I used C# first and then tried java, and I can say I personaly liked the later better (like simplicity myself). I give C# and Mono its merits, but would like better the gcj/gnome solution for gnome. I would like as well to have a plugin some day for native eclipse to emulate glade, rather than the external glade app. I mean, something ala visual editor for eclipse but with gtk/gnome controls in the palettes. Sharp develop is good but can compare to native eclipse, so I think there java/gcj has the winning hand.
I used to like Java. 1.0b4 was my first programming environment that I learned on when I was a youngen, but I have to say that after working now with C# it feels much more elegant and not so quirky as Java. Which I guess is expected since they were peeking at Java when they wrote it, took all the good stuff, and retained the good stuff from C++ that Java was too “pure” for. Anyway, I like it, and I can’t wait for mono to mature some more.
>All those Adapter classes are so freaking ugly and inelegant
>compared to events and delegates in C#.
Funny, I dont see any adapters in the Java Gnome example.
Events and delegates are a syntactic hack and hardly worh shackling yourself to the Microsoft platform for.
pascal is the language that everyone has skipped over and should back up and take another look…. nuff said
>but I have to say that after working now with C# it feels
>much more elegant and not so quirky as Java.
Yes having to sprinkle virtual and override keywords everywhere in your code is very elegant.
And don’t get me started on [STAThread].
Funny how all these people are saying that “Java is the future for GNOME” when I can’t think of one, just one, major app written in Java-GNOME. The fact is that useful, innovative applications are being written in Mono where Java apps are totally off the map. I think the developers have already decided which direction GNOME will follow…
Like I said before, Gtk+/Gnome is nice for multi language development. Forget about future stuff and just use what you want now. If you want to use Pascal, do so, Freepascal has Gtk+ bindings with its base install, they also have some tutorials and there are a few apps written with it already. Hell, you can even write Gtk+ apps with Freebasic. Knock your self out.
P.S.: As a note to Windows developers, Java-Gnome has prebuild packages for Java 1.5 on their website. So its not just for Linux.
> The fact is that useful, innovative applications are being written in Mono
> where Java apps are totally off the map
Are you sure about that? Maybe some highly publized apps are being written in Mono, but I doubt most commercial developers are going to touch Mono and its Gnome bindings for quite a while. Why?
1. Because it’s still pretty young. Devels want to know that their tools are going to be successful and around for a long time to come…
2. It’s not cross-platform: Why use a toolkit like .NET or Java if it’s not cross-platform. The days of trying your commercial apps to one platform are mostly over. You’d be better off writing your GUIs in PYthon than Mono/GTK.
3. It’s not standards based – the real standard for GUIs in .NET is windows.forms. If your going to be using .NET, why would you choose anything else? (Why would you want to run .NET on anything other than Windows anyway – the .NET framework was never designed to be cross-platform, and trying to make it one is going to be less than ideal. Plus, the major backer of .NET – Microsoft – doesn’t want .NET apps running on anything other than MS operating systems).
4. It has the makings of a legel time bomb. With the stakes as high as they are for Mono/.NET having major legal troubles, why would a commercial developer pick such a platform on which to build their livelyhood? For all its faults, Java has much less legal concerns, considering Sun’s patent grants.
5. High end developers need a solid, stable platform that has long release cycles and is very backwards compatible. Why choose a technology that changes dramatically very frequently and leaves your old code out to dry? MS has a long history of short support cycles and breaking compatibility between releases.
On a final note, this post is about commercial devels adopting Mono. I would suggest that Open Source devels, while maybe their livelyhood isn’t being supported through their contributions, should still way these issues seriously. Even though you may not be getting paid for your development time, it is still worth just as much as someone’s time who is. Open source developers should pick technologies that will allow their projects to be the most flexibile and reusable and standards compliant (when there are standards that fit) – the technology should let their code stand the test of time.
All those Adapter classes are so freaking ugly and inelegant compared to events and delegates in C#.
You’re probably refering to Swing, as Java-Gnome doesn’t use adapter classes. However, there’s a possibility that JG will in the near future move to a better/different aproach than the current; there has been some discussion about this, and Owen Taylor has quickly proposed a solution which i particularly liked. Wait for the next chapters
Victor.
“Sun could do the same, but are less likely to do so.”
I don’t think this is the important point – any company could change or be bought up. What is important is that Sun has made a full free patent grant of the Java technology. Any future management at Sun would have extreme legal difficulties in trying to reverse this.
This particular falsehood is brought up every time the mono vs java debate happens. Sun has not made a full free patent grant of the Java technology. You are only granted the usage of the patents if you pass the TCK. No TCK, no patents for you. Which means that unless/until GCJ passes the TCK it has the same potential patent problems as mono.
And as much as it pains me to say this, but given that Microsoft has never used patents offensively versus the state of Sun’s financials and their erratic behavior towards open source (especially GPL/GNU stuff), I’d be more worried about Sun then Microsoft.
This is why from the point of legal safety the future of Gnome should be with Java/GCJ rather than C#/Mono.
From the point of legal safety, the are both exactly the same. It’s up to you to decide if that means they’re safe or not.
If you used GCJ to compile, there is no VM, right? Does that also mean no major memory hog? If its compiled into native code instead of byte code, what is the problem with using it as the gnome backend? how much overhead is using Java compared to C# or even C++ if the source is natively compiled (no VM)?
I thought SYNTH was just a look and feel language for AWT/Swing….sorta like a CSS. Not a full blown XML-UI (like say XUL,or Thinlet)
Are you sure about that? Maybe some highly publized apps are being written in Mono, but I doubt most commercial developers are going to touch Mono and its Gnome bindings for quite a while. Why?
1. Because it’s still pretty young. Devels want to know that their tools are going to be successful and around for a long time to come…
I would hardly call GCJ and Classpath mature, at least, no more mature then Mono. And GCJ/Classpath is what would be part of the GNOME platform, not the proprietary Sun JVM.
2. It’s not cross-platform: Why use a toolkit like .NET or Java if it’s not cross-platform. The days of trying your commercial apps to one platform are mostly over. You’d be better off writing your GUIs in PYthon than Mono/GTK.
What’s not cross-platform? And the reason to use a toolkit like .NET or Java even for programs that aren’t meant to be cross platform is they provide faster development times then the same program written in C. We are talking about GNOME apps so that is the platform they have to support.
3. It’s not standards based – the real standard for GUIs in .NET is windows.forms. If your going to be using .NET, why would you choose anything else? (Why would you want to run .NET on anything other than Windows anyway – the .NET framework was never designed to be cross-platform, and trying to make it one is going to be less than ideal. Plus, the major backer of .NET – Microsoft – doesn’t want .NET apps running on anything other than MS operating systems).
We’re talking about the GNOME standards here. Who cares about Windows Forms when you’re building a GNOME app. If you want to write a Windows Forms app, the Mono managed windows forms seems to be coming along nicely. Go look at http://go-mono.com/monologue, they have some screenshots of unmodified Windows Forms apps running on their implementation. Also, you do know that Microsoft released .NET runtimes for both Windows and FreeBSD, right? The FreeBSD one isn’t complete, but it’s not obvious to me at all that Microsoft doesn’t want .NET running on anything other than Windows.
4. It has the makings of a legel time bomb. With the stakes as high as they are for Mono/.NET having major legal troubles, why would a commercial developer pick such a platform on which to build their livelyhood? For all its faults, Java has much less legal concerns, considering Sun’s patent grants.
As I already posted, the Sun patent grant means nothing for free Java implementations until they pass the TCK.
5. High end developers need a solid, stable platform that has long release cycles and is very backwards compatible. Why choose a technology that changes dramatically very frequently and leaves your old code out to dry? MS has a long history of short support cycles and breaking compatibility between releases.
Would you care to provide some examples of this? I hate defending Microsoft but they bend over backwards trying to maintain backwards compatibility with all of the bugs and old APIs they’ve released over the years. And, anyways, how is that different from Java? In the past 2 major releases Sun has introduced several non-backwards compatible keyword changes which causes problems for all sorts of code (assert in 1.4 and enum in 1.5 for those of you watching at home).
On a final note, this post is about commercial devels adopting Mono. I would suggest that Open Source devels, while maybe their livelyhood isn’t being supported through their contributions, should still way these issues seriously. Even though you may not be getting paid for your development time, it is still worth just as much as someone’s time who is. Open source developers should pick technologies that will allow their projects to be the most flexibile and reusable and standards compliant (when there are standards that fit) – the technology should let their code stand the test of time.
Novell and MainSoft have contributed to Mono, they’re commercial developers. And even Microsoft has had Miguel out to Redmond to talk with them and released articles about Mono on MSDN. I’m sorry, but none of the issues which you bring up seem to be a problem unless you’re looking at them through tinted glass.
Why use Java-GTK when you can use SWT and have native look on the platform ?
Plus there are two major apps using SWT :
Eclipse itself and Azureus.
> 4. It has the makings of a legel time bomb. [snip]
As I already posted, the Sun patent grant means nothing for free Java implementations until they pass the TCK.
Look, regardless of which language/libs you choose, as free software becomes more and more viable for desktop use, it’s going to cost some big players (well, mostly MS) money, and thus will become more and more an impetus for litigation. Besides that, the whole notion of “software patents” in general is so ridiculous that it’s going to eventually need to be tested in court (possibly multiple times) anyhow.
If the community goes with Mono, Novell may end up in court.
If the community goes with Java, the FSF, Stallman, and Eben end up in court.
Who do you want in your corner when the shit hits the fan?
> If you used GCJ to compile, there is no VM, right?
Right. GCJ makes a binary for you, and you just run it like any other binary. There’s no VM involved, unless your natively compiled code starts using .jar files (i.e. .class files). Then the runtime built into libgcj kicks in and starts interpreting Java bytecode on-the-fly as-needed (I think that’s how it works anyhow).
> Does that also mean no major memory hog?
Well, the shared lib that implements the whole class lib is pretty big, but besides that, it’s just like any other shared library.
> If its compiled into native code instead of byte code,
> what is the problem with using it as the gnome backend?
You mean for the whole desktop itself? As in, re-writing Gnome in Java? I don’t think you mean that, but if you do, the only problem with the idea is all the work it would take to rewrite all that code.
> how much overhead is using Java compared to C# or even
> C++ if the source is natively compiled (no VM)?
I think the overhead folks are worried about is this: If you all of a sudden have a bunch of pieces of Gnome being written in Java, then you need that sorta big libgcj loaded into memory. This isn’t so bad in itself, except that it’s in addition to all the other libs already loaded into memory that Gnome already needs. There’s a lot of functionality built into the Java libs/classes/API, and the same with everything else Gnome currently uses — so there’s gonna be a lot of duplication there.
Then again, Mac OS X does it 4 times over: they’ve got Cocoa (obj-C API/libs), Carbon (older C API/libs), Java, *and* X11 .
> Does that also mean no major memory hog?
Well, the shared lib that implements the whole class lib is pretty big, but besides that, it’s just like any other shared library.
I should add that, your Java code is still garbage-collected like before. The gc runs in a low-priority thread, and with GCJ it’s all implemented in that shared lib. So, I’m guessing that your Java programs themselves (at runtime) take up about the same memory as when only compiled to bytecode and run in a JVM.
The difference here (JVM vs. GCJ-natively-compiled), is that instead of running a JVM (which takes up memory), you’re loading and running the runtime built into the shared lib (which takes up memory).
Of course, multiple programs using the GCJ shared lib all share it (naturally
), so you’re not starting up multiple VM’s to run multiple Java programs. So, I believe a big performance win with GCJ is program startup time. With Java bytecode and a JVM, you start up the program but have to wait for the JVM to start up first. With GCJ-natively-compiled apps, the first time you start one, libgcj loads. Thereafter, other apps don’t have to reload it, so starting them should be very fast.
That’s my understanding anyway.
So, I’m guessing that your Java programs themselves (at runtime) take up about the same memory as when only compiled to bytecode and run in a JVM.
Yep, nothing changes about the memory model. Badly written Java programs will still allocate too many objects and keep unnecessary references to them, thus stopping the garbage collector from hoovering them up.
The difference here (JVM vs. GCJ-natively-compiled), is that instead of running a JVM (which takes up memory), you’re loading and running the runtime built into the shared lib (which takes up memory).
Note that with Sun’s JVM performance-critical code gets compiled too. Which means you get a hold-up first-time round, but then it’s as fast as native code.
gcj might be a bit better at optimising because it can spend more time on it, but then again the just-in-time-compiler might be able to take advantage of information only available at runtime.
Of course, multiple programs using the GCJ shared lib all share it (naturally
), so you’re not starting up multiple VM’s to run multiple Java programs.
A sensible operating system like Linux ensures that executable binaries are shared too, so the ‘java’ vm is only loaded once, even if you run multiple instances of it.
Also, from version 1.5, Sun’s JVM implements “class data sharing” to avoid loading and compiling the basic class libraries every time you start ‘java’. See here:
http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.htm…
I am sure that Sun’s 1.5 implementation has one or two interesting features, but unfortunately, it’s not available for most of the platforms that GNOME runs on, so those features are nothing that can be relied on. Chances are those features of Sun’s implementation may never see the light in form of a port of 1.5 on the majority of GNOME platforms.
Otoh, gcj is available for most platforms that GNOME runs on, and its features are there right now.
Sounds like gcj has a pretty clear advantage, purely technically speaking. In particular for desktop use, where all your different desktop applications can share the same set of object code, the gcj approach sounds much more efficient, than the alternatives.
cheers,
dalibor topic
There are also good bindings for Qt and KDE.
Btw… there is one advantage if you develop in java, you can do it from Eclipse, that way you can get one of the best IDEs and good bindings for native apps, and Refactoring out of the box.
Can anyone confirm that all of the following are intended for 2.12? If so, it will be a superb release!
1. Cairo-based GTK;
2. Beagle incorporated into the system;
3. Fruits of the memory optimization projects;
4. The long-awaited menu editor;
5. Improved Yelp (held over from 2.10);
6. System/disk tools;
7. Cron front-end (held over from 2.10).
Is there anything else of major significance that I have missed?