This is an analysis comparing Java-Gnome and GTK#, in the source code level. Update: Screenshots from “Free Swing”.
A walk in the park with Java-Gnome and GTK#
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
In the context of Gnome, no, there aren’t many differences. However, the differences between .NET and Java are anything but “trivial” in other contexts, such as web application development.
I’ve been on both sides of this and have experienced both of these technologies for web programming and the differences can be that of day and night.
Rather than some clandestine conspiracy designed to pit .NET developers against Java developers, you may want to look at it from the standpoint of one technology being a subtle improvement over another.
Microsoft would have been stupid to ignore the popularity of server-side Java and simply made a “better Java”. Having using both languages, I would agree that C# is “better”. It is more feature-rich than Java and more productive in many ways. Of course we could argue this all day but it is purely subjective and pointless to bicker over.
I think the conclusions the author of this article came to are just goofy.
Why not post an article contrasting J2EE and asp.net? Why not put it in a context that might actually make sense instead of using obscure examples of Gnome-bound code, which is probably on the very-low end of Java and C# usage, I would dare to guess.
The conclusions of the article make a lot of sense when you consider that the author is solely interested in desktop development, particularly with GNOME. Yes, there are plenty of other differences between the languages (or platforms), but they are not directly relevant to this comparison.
Uhh…well yeah, I agree with you…I think I said this already.
Is the author trying to say that Gnome development with Java and C# are so important to Microsoft and Sun, that this is supposidly how they are “colluding to divide and conquer the free software movement”?
Again, I find that conclusion to be just plain strange.
The article is a bit far-fetched and overly-dramatic. How is Microsoft and Sun colluding against Open Source simply by having their own language/API? They couldn’t care less about Open Source in this respect.
Microsoft isn’t holding a gun to your head telling you to implement .NET. You’re implementing it on your own of your own will. Saying Microsoft is holding a gun to your head is just FUD intended to scare people. To what end?
Parrot
Although the whole conspiracy theory seems a little over the top, I think the author made a very valid point. I was expecting to see some rather largish differences between implementations, but I was very surprised. I’m curious about the maturity of the Java-Gnome bindings in comparison to the C# Gnome bindings, and this article leads me to believe that Java-Gnome is a little less complete in places.
Thanks for the great article.
The man needs to take off his tinfoil hat. That’s some crazy conspiracy shit right there.
The code is pretty similar, except for the extra hoops the guy needed to jump through to convert to Java (inner classes vs delegates is most of the bulk). That’s good, that’s very good, so now the open source community can collude against Microsoft and Sun! Drive a wedge between them…!
Although, despite similarities, I don’t like writing Java after having used C# for such a long time. So is life, though.
This guy has some kind of imaginary battle going on (typical of zealots), with Microsoft and Sun teaming up to divide the open source community.
I didn’t look at the examples, because I already know how they would play out. For the most part, they would be very similiar – except for what I consider a somewhat cleaner callback mechanism in C# with delegates/events.
Java can run on top of Mono, but since this is a redhat blog I gather that’s not a viable option for him. In any case, this guy is way too conspiratorial. Take a deep breath man….geez.
I think the point is that C# and Java are pretty much the same.
I think perhaps he’s suggesting that C# and Java API developers cooperate to make these third party APIs compatible. Such that if I port from gtk# to Java Gnome I don’t actually have to change anything other than the standard C# and MS stuff. This way you could potentially have Java and C# compilers targetting either Mono(CLR) or JVM without the need for code changes to use a different API. (Or IKVM could use gtk# as a drop in replacement for Java-Gnome?)
Or I could be around the bend with a few screws loose. I am a Java Developer with a Perl fetish after all.
valid points, I wrote in too conspiratorial a tone. I meant to describe more how I saw Sun and Microsoft standing to benefit from division in free software developers, rather than acting in a particularly premeditated way. I’ve updated the page to reflect that perspective better.
In general, the languages are indeed very similar, and
the article correctly points out the major difference
for GUI development: delegates and events save 6-7 lines of
code per event (not mentioning that declaring them is also
simpler).
But the C# code is C# code written by a Java developer, and
the Java code is still larger than the C# one.
The code could be improved by using: foreach instead of
for loops that have 0, array.lenght boundaries, and using
switch on strings.
The other element is that the code could use static
initializers in C#.
This is without getting into the new C# features like
anonymous methods that would have simplified the code
another chunk.
The on the Gtk# side, the sample failed to use the common
idiom that is used in Gtk# which is to use attributes for
binding widgets to glade files:
[Widget] Entry entry;
Instead it takes the long route (which is closer to Java)
and does the messy: entry = (Entry) gxml [“entry”] code
paths (even if he does auto-connect, and flags the widgets).
Where people got superbly heated up on trashing each other over language trivialities. Sigh.
cheers,
dalibor topic
C# and the CLR have learned from Java’s mistakes. They can’t fight C# and the CLR on the technical side, so they throw out the “immature” bit. Very amusing.
I never programmed in Java, or C#, but read time ago an article describing some specific differences, between the VM’s (or was it a video from channel9.msdn.com ?))
Here is what I remmember:
– .NET for example supports byte-code instructions for tail-calls, which are usefull when you have tail-call recursion (recursion which does not change arguments to the called function, and it’s called when local variables are out of scope, or at least dead).
– Support for unmanaged code, instead of delegation as Java.
– Control over the GC (not sure how exactly).
———————————————————–
My user experience, looking with TOP on my fresh new Solaris 10 installation, there are three-four applications running in separate java machines. Each takes 50mb of commited memory, and about 100mb virtual. Not sure, why they are not running into one full blown machine (I guess security reasons, or logistical ones, or it’s the case where I don’t know details).
How then you would write simple – dockbar, toolbar, GUI apps with JAVA. Don’t get me wrong – Java is great when comes to Eclipse – I have seen the power, but for small utilities, media players, etc. – if the situation is where for each one of them separate java machine is to be started, then … I’m sorry – but it’s good solution.
—
[quote]
Makers of C# and Java technology have a vested interest in making their systems appear more different than they actually are. Differentiation in terms of API draws developers into a private, company-controlled camp, and differentiation in terms of supposed language semantics helps divide any efforts to clone the systems.
I feel that these languages, excepting API, are quite trivially different, and should be considered as minor dialect variations from the perspective of the free software community. We have bridged enormous gaps in the past, from various character sets and natural languages to filesystems, network protocols, multi-language compilers, simulators and runtimes. We can bridge this gap too, if we set our minds to it.[/quote]
I think, he’s making illogical argument, by comparing the two langauges/platforms simply by specific API usage.
It’s like comparing WinSock2 vs. any ix-sockets, given two a bit different language – say C, and D. They may be similiar in that case, but that should not lead to general conclusion.
In fact, the EVENT MAPPING, even that it seems as syntactic sugar in .NET, is something that makes at least sound difference.
couple of missing punctuations got my idea wrongly.
So in short – Java – seems reasanoble for big-applications – Eclipse, Servers, etc. – e.g. the MAIN APPLICATION.
Don’t know about .NET – but most of the tools written in-house do not require much memory (might be that Microsoft optimized it’s system for that), or might be that i’ve measured wrong results.
—-
Even if you port GTK to Scheme, Common Lisp, or any other language carrying big baggage of VM, some kind of specially cooked environment, would make the final GUI tool inefficient, if it was meant just to be simple small program – as Media Player, CD Burner, Text Editor, Clock, etc.
If there is a way to make one virtual machine to run them all, and handle/emulate the OS behaviour (security, groups, priorities, etc.) then it would make sense.
Think about Konfabulator (one VM machine) and it’s java-scripts. As of right now on my Windows XP machine – takes only 8MB with two widgets (duh… well, it’s not like 50mb for nothing on Solaris 10).
.NET for example supports byte-code instructions for tail-calls
Yes, but I don’t think Microsoft’s C# compiler optimizes tail calls, and 99% of .Net libraries are probably written in C#, so it’s not a bonus for .Net at the moment.
I don’t know if Mono performs the optimization, but I hope they do.
If there is a way to make one virtual machine to run them all, and handle/emulate the OS behaviour (security, groups, priorities, etc.) then it would make sense.
Hmm, you should take a look at Eclipse for Java and DrScheme/MrEd for Scheme. They’re both platforms on top of their languages and can manage multiple applications in a single OS process, and DrS/MrEd at least provides security guards and such.
Regarding .Net memory usage. I think most of the current generations of .Net apps use a lot of native (unmanaged) code. That means the memory usage is probably hidden. (Not that windows seems to report very accurate memory usage anyways.)
I think this also obscures measurements of UI performance.
.Net tends to link into lots of native libraries and so forth. Whereas Java is pretty mostly done in java bytecode.
In the future (assuming MS does decide to go this way) .Net shouldn’t use any less memory than Java. Although I’m doubtful they will ever have a fully managed environment. I suspect that since windows is a requirement (as far as MS is concerned), then the tempation to use fast efficient native libraries will be too hard to resist. Mono might do a fully managed implementation, maybe.
While I can’t respond to Miguel’s comments in any way I certianly hope the moral of the story is accepted.
As an outsider looking in on gnome development the whole C# vs Java drama that happened a while ago was very alarming. Having two powerful camps responsible for much of gnome’s development disagree on such major issues looks bad for everyone who likes gnome (like myself).
I use tomboy often and overall have always liked the idea of mono as a gnome application environment (and keep meaning to get past the simple programs that a two year old could do
) but see the need for these two camps to unify to some degree. This article, as I understand, isn’t about saying one language is better than the other but more about how the two camps should be united. I like this idea and hope that this can be achieved to one degree or another since sooner or later I’m sure we’ll see both technologies used in more important roles (such as mono with Beagle).
As it is now it’s interesting that except Novell’s desktop nobody ships either Java or mono out of the box (correct me if I’m wrong) because of legal or licensing issues. I would love to see both included.
Might be really. But who knows.
The last video I watched, the-lead CLI guy over @Microsoft talked about precaching cpu-generated-code to the disk, so when the next time the .net dll loads, and there are no changes, the generated code can be reused (now we are talking about generated-code garbage collecting on operating system level – memory and file caching).
He also mentioned something really cool – Generated code is read-only, or at least write-once, read-many, so it can be shared by other virtual machines – for example mySpecialLibrary.MyFastAudioDecoder can be generated to a code natively to some physical page, and then more than one virtual machine can reuse it. It somehow beats the idea of hot-spotting (my expectations with it would be that the code would morph itself over the time, and that would require writing again to the said page).
Anyway that means that the virtual machine would require extensions from the Operating System (such as sharing code-pages), that might not be avaible as user-level API everywhere, and to be strongly windows specific (I wonder if that would not lead to some security flaws).
So where does the JVM fits into that? Might be interresting to see the JVM source after all
Even if you port GTK to Scheme, Common Lisp, or any other language carrying big baggage of VM, some kind of specially cooked environment, would make the final GUI tool inefficient, if it was meant just to be simple small program – as Media Player, CD Burner, Text Editor, Clock, etc.
Yep, and remember as of now there is only one official language for Gnome – and that’s C.
Now there’s been a lot of talking about making Python “official” into Gnome. Python is a great language, but you have to consider that once you bring in a runtime “officially” you can’t take it away. It’s one thing to force developers to port their apps to a new major number of a toolkit, and another to force them to port their app to another language.
The CLR gives the best chance as of right now for the “universal runtime”. It can run Java, Python, C#, VB.NET, C++(no compiler for open source yet), C (dotgnu has a C compiler to IL), as well as a host of others. The JVM is not going to suited to many of these languages. It doesn’t know about pointers and as you mentioned MSIL does have the tail-call instruction.
Also, with something like the CLR you only maintain one set of bindings. As long as the assembly is CLS (Common Language Specification) compliant then all other languages get the bindings automagically. That is a huge plus even though the API might look foreign to certain language-specific object naming conventions (Pascal, Camel, underscore).
What on earth is “free swing”?
Also, with something like the CLR you only maintain one set of bindings. As long as the assembly is CLS (Common Language Specification) compliant then all other languages get the bindings automagically. That is a huge plus even though the API might look foreign to certain language-specific object naming conventions (Pascal, Camel, underscore).
Yup, that’s another big win. Having looked how Eclipse ties with native code, and how much easier that’s in .NET (the actual foreign declaration goes together with the internal representation). Microsoft really are good at building bridges across old and new.
And I hope some day, there would be good ObjectiveC compiler for Win32 and I can freely enjoy the NextStep API ;(… Anyway
The open source implementation of Swing.
Sun deliberately made native code hard to integrate to discourage usage of native code.
The declaration for native libraries in .NET can be a problem because different platforms might not even use dlls or use different names for the libraries, so “xxx.dll” is nowhere to be found. You can work around this by declaring all possible name for the libraries and wrap them in functions that catch the exceptions and fallback to the alternatives. That’s depending on the fact that the library is loaded when the first function is called.
Java’s way of doing things is more flexible because you can change the name of the library at runtime and it even takes care of the .dll or .so prefixes for you.
I think MS’ approach is better suited if you prefer an easy approach to protability even if it might not always work,
and Sun’s approach is better suited if portability is your main concern.
Someone will no doubt reply to your comment that the CLR could be the “Universal Runtime” with something like “it doesn’t support feature x of language foo”. The huge sticking point for me however is that Microsoft is actively interested in developing the the CLR towards this universality, heck they recognized the talent of the IronPython guy and hired him on the spot, while it will be a cold day in hell before Sun or the JCP commit to supporting alternative languages.
So, while the CLR clearly isn’t reaching its potential as a universal framework today, look at the bigger picture and where it will be, say, 2-5 years from now. Sun will be pushing Java X but the CLR will accommodate all sorts of programming paradigms and languages, of which Python and Ruby are of personal interest to me. This is not a technical difference, it’s a vastly different mindset between the two camps.
“Someone will no doubt reply to your comment that the CLR could be the “Universal Runtime” with something like “it doesn’t support feature x of language foo”
biggest problem is legal concerns not technical. CLR is patented technology owned by MS and ECMA standardisation does not change that
Miguel claims that its royalty free but hasnt got any legal agreements from MS other than a mail which doesnt qualify. so if CLR becomes part of Gnome it can be a liability
The holy grail where everybody is satisfied with a universal runtime is never gonna happen, but the CLR is the closest thing to it that we have.
And you are absolutely correct, in 2-5 years the CLR will be much more advanced and we already know Sun’s track record regarding changing the VM.
Sun and MS have whole different philosophies regarding this. Sun has the philosophy of Java is the language and the JVM just happens to run it, while MS has the philosophy that .NET is the platform, we’ll expose our class libraries to everybody, and run whatever language you want.
This is not surprising considering that the language Java was actually designed before the JVM, while the CLR was designed before C#.
>parrot…
How? Where are the Gnome bindings? Python has some GTK support, but it in no was has complete Gnome support IIRC. Perl doesn’t even touch Gnome, and GTK Perl is seldom used. Seems to me like you’re just throwing out parrot claiming it’s superior to both without having used any of the three.
No code today is safe from an attack on patents from anyone.
Mono is the least of your problems when it comes to
infringing some frivolous patent. And the techniques in
the CLR are wildly used today.
If Microsoft held a patent on technique-A on the CLR,
we can work around it. But the same technique-A would
probably be infringed by some other programs (both
free and proprietary).
The bottom line is: patents suck, but spreading fear wont
get you anywhere, as pretty much everything is tainted.
If you are easily scared by patents, I suggest you move
to a safer business, like mowing lawns.
Miguel.
So what happened to Novell’s patent review on Mono?
Well there is PHP-GTK
maybe the next version of PHP (6) will use parrot vm
parrot is build for these languages:python,php,perl(5,6,..),basic,brain* …
“What about PHP 6?
We are thinking about it. Again, we don’t all agree on what direction that should take. My personal view on what I’d like to try, though I have no idea if it will work, is to go for Parrot. Parrot is the really cool new engine behind Perl 6. But it is not tied that closely to Perl.”
http://phplens.com/phpeverywhere/?q=node/view/84
If Microsoft held a patent on technique-A on the CLR,
we can work around it. But the same technique-A would
probably be infringed by some other programs (both
free and proprietary).
You are assuming of course that MS doesn’t sue for damages, for lost revenue, and whatever else these lawyer types can come up with. While I dislike patents, using the “No code today is safe from an attack on patents from anyone” argument in defense of Mono isn’t very reassuring. It directs attention at some vague entity, completely by passing the question on Mono’s legality.
I agree that a lot of stuff floating around is patented. However, none of them are as widely known as Mono.
Sun deliberately made native code hard to integrate to discourage usage of native code.
No they simply are incopetent, and a lot of the stuff in Java is accumulated crap.
AWT was crap. Then came Swing which was crappy too.
The recent broken generics implementation for java5 comes to mind.
> No code today is safe from an attack on patents from anyone.
Ahh yes, the “you could get hit by lightening today so you might as well play Russian Roulette with this fully loaded 6 shooter” argument.
No thanks.
After Balmer already warned Asia about “someone coming to collect money for all the IP violations in Linux”, you’d think people would wake up.
The results of our study are outlined in our FAQ, there
is nothing else that can be done. All software above 10
lines of code will infringe on a bogus patent.
>The results of our study are outlined in our FAQ, there
>is nothing else that can be done. All software above 10
>lines of code will infringe on a bogus patent.
Of course, all software above 10 lines of code ISN’T an exact copy of the most important piece of IP held by the biggest opponent of OSS.
“Someday, for all countries that are entering the WTO (World Trade Organization, somebody will come and look for money owing to the rights for that intellectual property,”
— Balmer
How much will the .NET IP cost “someday”?
Mono is the least of your problems when it comes to
infringing some frivolous patent. And the techniques in
the CLR are wildly used today.
I’m afraid not. Some software is obviously more at risk than others, and the secret is in how Microsoft has submitted standards to the ECMA but is still in ultimate control of it should it decide to take its work away.
A lot of software is at risk, yes, but some paint large red dots on themselves. Personally, I don’t think a hard legal patent challenge will come from Microsoft, that’s just not their style. However, the opportunity to throw large amounts of FUD about it and scare people away is something they are very, very good at. We are all better off away from that.
The results of our study are outlined in our FAQ, there
is nothing else that can be done. All software above 10
lines of code will infringe on a bogus patent.
No, there was supposedly a comprehensive review of Mono being undertaken by Novell, focusing on what might be at risk – not just the non-ECMA parts, but the ECMA parts as well. The core could actually be the problem, not the non-ECMA parts. The FAQ doesn’t give any hard facts and reasoning that hasn’t already been given.
Did Novell decide not to bother with the patent review?
All software above 10 lines of code will infringe on a bogus patent.
Doesn’t answer anyone’s questions I’m afraid.
There was also supposedly a letter talked about from March of this year written by Microsoft, HP etc. saying that the ECMA standards would always be license under the free and fair terms they are now.
Now, if that letter has to exist then does that mean that if Microsoft leaves the ECMA and develops future versions of .Net, the CLR and core technologies away from the ECMA, those reasonable licensing terms are on shaky ground? This applies to the stuff actually within the ECMA, not outside it.
Does the letter exist, and if so, can the contents be made public?
“Mono is the least of your problems when it comes to
infringing some frivolous patent. And the techniques in
the CLR are wildly used today. ”
you are doing a extremely poor job with name calling others as sissies and wimps because there is a threat of .net patents in mono. your argument that i should ignore it because every software in the world has a potential patent problem is just like IE users saying that I should continue to use IE because firefox might have security issues anyway. both of these answers have a BIG hole (ie) what is the amount of risk?
You were promising everyone that novell would undertake a thorough patent review. We are asking for the results. your faq DOES NOT have the results or you guys didnt do it at all.
You also claim that the patents related to core are RAND and royalty free. I ask you where is the legal agreement from MS. random emails are completely invalid. list out the patents and assert how you are planning to deal with them
you call me a sissy. come on now.be a man
.NET encompasses a great deal more than what was narrowly defined in this article, however, it is obvious that when M$ was snubbed by Sun for MS’ modifications to their Java implementation and subsequent judgement from the resulting lawsuit(s) that MS decided to push on along a similar track. Hence, IMO C# & .NET were born. Speed disadvantages were overcome by an almost immedicate drilling down into natively compiled API’s, leaving a development environment that, while partially, platform independent really isn’t unless MS do the incredibly odd thing of making native(or interpreted/byte compiled) APIs available on other platforms.
Beyond this C# it’s syntax and semantics(excluding APIs) is almost identical to that of Java, which as mentioned by others was probably a purposeful design decision to make Java -> C# conversion and familiarity of the basic underlying language as simple as possible.
All this being said C# & other .NET languages are NOT as fast as pure native languages, and I am leery of MS sitching to this as their primary development environment. Windows is already not quite as speedy as it could be and .NET will make things worse while not even gaining portability. (Unless, of course MS is thinking of pushing for a different PC architectural base…in which case it would make a transition somewhat simpler, possibly…although I am still sceptical if this is the case. Another line of reasoning could be that MS expects significant improvements in processing power in the near future, leaving the inefficiency of byte code interpreted languages a moot point. Franly, I’d rather have more efficiency with a portable native API provided for any alternate platforms/architectures that MS may wish to support, after all NT did used to run on Alpha, PPC, etc. as well as IA32(and now x86-64, sort of…).)
I have to disagree with you. C# and Java, while sharing much, are different in a large number of ways.
C# embraces C++ concepts much more than Java and is quite a bit more complicated.
As I’ve said before on here, C# has learned from Java’s shortcomings while embracing its strengths.