OSNews

Perhaps Qt Jambi (as QT on java) will make java more tempting for me.

But Gtk# with C# on linux is truly a nice option.

> Python/Gtk seems like a pretty strong choice

I wouldn't consider Python to be a strong choice for a full blown desktop application due to its lack of strong typing and such.

> Mac issues with dual monitors

What issues? I run Swing apps on my PowerMac G5 with dual monitors, and I have no issues at all.

> it seems unlikely to take advantage of gpu
> drawing anytime soon

Java has been using the GPU for 3D since Java 5, and in Java 6, which has been out for awhile now, it also uses it for 2D drawing.

(http://weblogs.java.net/blog/chet/archive/2005/05/graphics_accele.h...)

> My feeling is that today, on Linux, Mono may be
> the strongest choice. Especially given the
> Gnome bindings for it (I've heard they're quite
> complete?).

I see several problems with Mono on Linux, which are pointed out in the article. Compared to Java, it is very immature, it does not have nearly the amount of open source library support that Java does, and it is doomed to always lag behind the official .NET implementation. That and because of the fact that Mono's class libraries use the MIT license, there are potential software patent traps. (http://www.newsforge.com/article.pl?sid=02/02/19/1651244)

Since Java is GPL, and Sun has made clear that Java will adopt GPLv3 once it becomes finalized, there are no patent traps for Java.

Edited 2007-03-08 00:00

That and because of the fact that Mono's class libraries use the MIT license, there are potential software patent traps.

Not entirely true; the core classes along with GTK#, Cairo# and friends are ok - the problem with occur with the .NET compatibility like Winforms.

Then again, its no more troubling than Wine, which probably treads on a number of patents and yet, there isn't a single bit of protest.

Microsoft know that ultimately Mono will always be playing catch up; the VM of mono alone is immature and no where near the capabilities of Microsofts own .NET or Sun's Java VM - and given that the development is done by only one company, Novell, and a cheapskate organisation at that (unwilling to spend money when required) Microsoft know that its always going to nothing more than a novelty.

> Then again, its no more troubling than Wine, which
> probably treads on a number of patents and yet, there
> isn't a single bit of protest.

Actually not quite correct. Everyone recognizes that WINE and Winelib are temporary (imperfect) solutions, not permanent ones, so the effect of a patent trap is less because few people rely too heavily on WINE. If worse comes to worse and the trap is sprung, you can always use VMWare/Xen/KVM/QEMU.

When Corel ported Wordperfect to Winelib, people balked, so I wouldn't say there isn't a single bit of protest for WINE.

The key difference between WINE/Winelib and Winforms/ASP.NET/ADO.NET is that the later is billed as a permanent solution to writing portable apps that can be developed on Windows first while the former is not.

Edited 2007-03-08 20:57

Although I'd like to see Wine as a temporary solution, the reality is anything but that.

When you have lazy software companies like Adobe not getting off their ass porting their software to Linux, knowing full well that that there is a massive demand, both by Windows and MacOS X users looking at migrating, Wine unfortunately by the nature of laziness of software companies, will become a perminant fixture on the Linux desktop.

Now, I'm not trying to scare people, but it does open up a big can of worms, and worse still, due to the crap portable nature of Wine - the fact that its severly broken on any platform outside Linux - try running it on FreeBSD or Solaris for example, you'll always end up getting locked into a single operating system - hence my preference for an opensource replacement; atleast then I can move and take the application with me, if I move from Linux to FreeBSD, as long as the application as been ported, I can continue on running the same one - with wine, its the roll of the dice as to whether something that might have run under wine on Linux runs under wine on FreeBSD or Solaris.

Python is strongly typed, it's not statically typed. And I agree, I also believe it poses a problem when developing complex software. However, a lot of desktop software doesn't appear to be entirely complex in the way that static typing helps but in other ways where rapid changes help (user interactions are complicated because of users, not the nature of the calculations or data so an easily modified code base is more helpful than a statically typed one).

Obviously mileage will vary from programmer to programmer and problem to problem.

It is good to hear that Swing will be moving forward and making use of that extra hardware for drawing where possible, that's encouraging news. As I tried to communicate before, I didn't have the feeling that Swing was moving forward (other than trying to act more native). Maybe my feeling is wrong.

Start an app with only one display connected. Connect the display. Move the app to the second display. Try to use a combo box. The combo box should fail to display a menu (it does here).
Also, menu's don't do the proper animation after selecting (really minor).
I'm sure I'll find more as time goes on though, I'm new to Mac.


If you've watched Microsoft's take over of application software you should note one thing: It's not about what you can do, it's about what you can promise to do and if you can make people believe you'll get there. In a sense, it's about momentum (or at least perceived momentum) and not about assets.
Java is more mature, that's for sure and that's a great asset. Mono is new and shiny and partially due to its newness and partially due to its openness (not just the source, but the developers talking openly) it appears to have a lot of momentum.


Patent traps are probably going to hurt Mono as well. But I believe that's actually a much smaller group of developers than the group who doesn't think a lot about it; and I'm only talking about Linux application developers (the ones we're concerned with).

>
>Python is strongly typed, it's not statically typed.
>And I agree, I also believe it poses a problem when
>developing complex software.
>

How do we define complex software? How does static typing make developing complex software easier?

http://pygtk.org/applications.html

On that page you'll find a list of applications ranging for UML editors, auditor editors, video editors, audio streamers, to full blown games all written in Python. Python is excellent for written any kind of software regardless of complexity. The whole "dynamically typed languages is not good for writing 'complex' software" is a silly myth.

Static type checking makes developing complex software easier because it establishes statically (compiler) checked contracts at all of your interfaces.

On a local level it makes software a bit more clear by defining what types of inputs and what type of output a function has. With dynamic type checking you can receive any type of object into your function and pass it down the line until it gets to a point where the duck typing (this is runtime now, and it's usually duck typing as it is in python) causes an error (it can't find some attribute on that object that it expected).

Static type checking forces you to think these things through before you can even compile your program. Some people can do entirely without it and many people substitute extensive unit tests (which do a lot more than check type issues, which is why they're used in static type checked languages as well). But the errors still leak through and you end up doing a lot of work to figure out at what point you're really sending an invalid object into the mix.

To state that static type checking doesn't aid in writing software is to call dozens of prominent language designers wrong... I doubt even Guido would argue that static type checking isn't helpful.
In fact, I do believe Guido agrees with me .
http://www.artima.com/weblogs/viewpost.jsp?thread=86641

There's actually a tool for doing some static type checking in Python: http://pychecker.sourceforge.net/

Static type checking is much more difficult in a language like Python, which is why so many modern statically typed languages add syntax to aid in the enforcing. The difficulty of the check, coupled with Python's "run from source code" workflow, is likely why it's not in the compiler itself.

As Ma_d already pointed out python is strongly typed. One point I would make is that a combination of unit testing and pyDoc gets rid of many of the "risks" that a non statically typed language may introduce.

Also python now has the option of using Windows Forms or Swing Via IronPython or Jython respectively

Java is heavy and uses much RAM.

for small apps it might be a bit heavy but larger apps its about the same as its native counter parts.

Edited 2007-03-08 00:03

I share the sentiment about the GTK bindings. Sadly, even though there used to be decent ones at http://java-gnome.sourceforge.net/, lately the new maintainers have started a rewrite which seems very closely coupled to GNOME. Might be worth informing them that really a lot of people would like to use Java and GTK but not GNOME...

"I share the sentiment about the GTK bindings. [...] lately the new maintainers have started a rewrite which seems very closely coupled to GNOME. Might be worth informing them that really a lot of people would like to use Java and GTK but not GNOME..."

Yes, Gtk is fine, especially with C. Java offers a lot of higher level functionalities than C does, and Gtk is a viable and fast toolkit. So I hope there will be an improvement that does not rely strictly on Gnome, but will be more generic.

That's probably true. A lot of people do choose Gtk because of how nicely it can be integrated into a non-Gnome desktop.

Python/Gtk seems like a pretty strong choice given that there are quite a few applications using it (Gajim for example).

The problem is that Python is a bit slow compared to java and C#. As for java and Gtk bindings I would prefer if the Gtk swing look&feel was improved so that java apps didn't stick out like a sore thumb rather than focus on Gtk bindings.

The java swing class libraries are very well designed, and there are probably a lot more developers that know how to use swing than ones that know Gtk, as java is used as first programming language in many universities round the world.

Why not make a swing Gnome and KDE look&feel as well, that way we could have apps that looked resonably good on both Gnome and KDE.

The only downside I see with Java is that it currently is a bit hungry for RAM.

There should be a way to dynamically communicate amount of free system memory to VM so that swapping heap out can be completely avoided.
VMM should be able to ask VM for garbage collection before resorting to swapping.
Besides, VM should be able to "borrow" free memory for caches implemented using weak references. When in need VMM would ask VM to give it back.
More dynamic interaction could be implemented like kernel asking VM to temporarily pin down references to data in some pages before swapping them out so that GC can work without making them dirty.
This would make -Xmx redundant.
These interactions are not really specific to java VM. Any garbage collected system could benefit from such user space interface to VMM.

You do realize that 90+% of the software written for the desktop takes place in businesses and not in the consumer realm, right? And in almost all of those cases, desktop software is written using a MS provided framework/language.

> You do realize that 90+% of the software written
> for the desktop takes place in businesses and not
> in the consumer realm, right?

Yes I do.

> And in almost all of those cases, desktop software
> is written using a MS provided framework/language.

That is where you are wrong. A survey conducted by Evans Data Corporation found that Java + Swing is actually the most popular toolkit at least in North America. (http://www.psynixis.com/blog/2005/10/19/java-swing-is-dominant-gui-...)

The reason people don't see this is exactly the reason you give. Because most of the applications that make Java and Swing the most popular GUI platform are internal business applications, so the general public never sees these Swing applications.

That is complete bunk..where did you get this??? I have been working in Enterprise IT for 12 years and just about everything is written in Java. I would say you are backwards.. most consumer applications I see are written in C++, VB, or .NET, but most business applications are written in C++ or Java. I can't think of a single application I have used at work since the inception of .NET that is actually written in a .NET language.

C# is a nice language, get over it. I'm not saying "better" or "worse" than java, it's just a great language, and people is going to use it. And not just because Microsoft forces them, but because -again- C# is a great language. And mono is open source, just like java (not GPL, but open source)

> C# is a nice language, get over it.

I'm not saying it's not a nice language. It is. But that doesn't change the fact that mono has serious problems which it is unlikely to ever overcome.

> And mono is open source, just like java (not GPL,
> but open source)

Yeah, it is open source. But like I said, because the class libraries use the MIT license, there is a software patent trap, since any company that makes improvements to the class libraries, or modifications, can patent their changes. With Java, and the GPL, you can't do that--especially not with version 3 of the GPL which Java will adopt once it becomes finalized. So in the end, for open source, Java is a safer choice. Again, there are no software patent traps with Java like there are with mono.

Potential MIT software patent trap? Then the same happens in X and in BSD-licensed libraries, of which there are many (isn't TCP/IP?), and the BSD kernels ...

What do you mean "especially not with version 3"? Is there, or is there not a risk with GPL2? Because if there is one -- because there IS one -- all GPL2 code, which includes the Linux kernel, GTK+, Gnome, Qt, KDE and most open source is also in danger. Java, to start with.

The problem of potential software patent trap in MIT-licensed Mono is pure bullshit: software patents are as much of a liability for everything else. You cannot stop using code for fear of software patents, unless you revert to pen and paper (and even then ...)

It's an USA-only problem. The rest of the world (especially Asia) will just keep on enhancing software, leaving USA in the dust when it comes to IT.

Claiming there are or will be no patent traps in Java is silly, since it is entirely possible for Sun to unknowningly implement functionality patented by somebody else. There will always - no matter the license - be a patent trap, if patents are a possibility.

We all know what he meant by "patent trap". The problem is not accidentally implementing a patented functionality -- that can happen with anyone. The problem is that Mono follows .NET, so MS can use its .NET-related patent portfolio anytime.

It's different with java, as it will use GPLv3.

Edit: and software patents are not be a USA-only problem while there is a constant threat of them being introduced to Europe.

Edited 2007-03-08 16:52

The war has never started because MS and Slave Companies are forced to use C#. They will also use D#,E#,F#,G# and H# if MS orders it. But open source developers is the battlefield, and freshmeat/sourceforge give an indication.

There are no such thing as "slave companies." Java had it's chance for it's place in desktop apps and Sun blew that it. All those years of encountering Java applets them made the average user dislike Java. And reinforce the notion that Java is slow as molasse. Don't go blaming another for Sun's grotesque incompetence.

And about MS and what people program in... Visual BASIC caught on like wildfire because it was/is the best out there. It still is unmatched. MS took an unknown product and turned it into a tour de force. Most VB's competitors (CA-Realize, IBM Visual Age for BASIC) gave up. Delphi is MIA. For languages/compilers, no one outdoes MS. They're still the best.

> They keep pushing swing knowing full well the
> suckage factor that goes with using an interpreted
> GUI - the speed at which Swing applications are at,
> you might as well use GTK + Perl for all its worth.

You haven't used Swing lately have you? And you are dragging up and old argument that has not been true for several years now. Java does something called JIT, which compiles byte code down to native code based on intelligent runtime analysis. Swing is no slower these days that any other toolkit.

> phone manufacturer's are now swooning around GTK
> and Linux for their future phones

They are? Last time I checked, I can count on one hand the number of phones that run Linux. And I can't even think of one that uses GTK.

> Sure, you don't have perfect 'write once,
> run everywhere' but better to have something
> that actually has a decent level of integration
> with the operating system in regards to the GUI
> than trying to emulate all the operating systems
> in a half assed manner.

First of all, GTK is not even close to perfect write once run anywhere. In fact, it is basically a unix only toolkit. The Windows port of GTK is a joke that is for the most part, unmaintained. Serious bugs don't even get looked at for over a year, etc. And when it comes to Mac, GTK is non-existent unless you want to run X.

> As for the 'example' with the calculator,
> the difference was pretty obvious - massive
> gaps between the border and widgets, lacking
> of inherieting the font settings etc

All of which could be fixed with a little bit of tweaking. The reason the font was different is not because Swing didn't inherit the system font, but because the GNOME calculator does not use the system font. The GNOME calculator is using a custom font and custom font style, something Swing is fully capable of doing as well.

> it would be like me claiming that because there
> are more VB developers than Java ones

Except there aren't more VB developers than Java developers. Java is the most popular language in the world. And VB is actually experiencing a sharp decline in popularity--both of these statistics from an Evans Data survey. (http://cld.blog-city.com/evans_survey__visual_basic_and_vbnet_in_st...)

> then they need to stop pushing the dogma of
> 'write once, piss everyone off in the process"
> and instead realise that when something sucks,
> drop it, and god forbid, if IBM does actually
> make a damn good framework like Eclipse, then
> embrace it!

Swing actually does a better job of looking native than SWT does these days. Even an IBM DeveloperWorks article admits that. And besides, SWT is not the ideal answer either. Because when bugs show up in SWT, you have to fix them on every platform that SWT runs on. And no, SWT is not any faster than Swing.

> Heck, why doesn't Sun drop Netbeans

Because in many ways, Netbeans has surpassed Eclipse. And again, even an article on IBM Developerworks admits this.

> Its about being pragmatic which unfortunately
> Sun doesn't have a very good habit of doing

That's been true in the past. But ever since Jonathan Schwartz took the helm at Sun, he has been turning it on it's head. Jonathan Schwartz is a strong believer in open source. OpenSolaris will be relicensed under GPLv3 as well. And they revived Solaris x86 because A: Customers wanted it big time. And B: They recognized that Sparc is dead, just like Alpha is dead, and PowerPC is basically dead now as well (with the exception of embedded systems and gaming consoles).

You might want to give Sun another change now that Jonathan Schwartz is at the helm. Even Richard Stallman did. In fact, I quote directly from Richard Stallman: "Richard Stallman: "I think Sun has, well with this contribution, have contributed more than any other company to the free software community, in the form of software. And it shows leadership - it's an example I hope others will follow."

Here's the link the video where he says this, in case you want to watch it for yourself: http://sun.feedroom.com/?skin=oneclip&fr_story=FEEDROOM166554&a...

Edited 2007-03-08 01:54

You haven't used Swing lately have you? And you are dragging up and old argument that has not been true for several years now. Java does something called JIT, which compiles byte code down to native code based on intelligent runtime analysis. Swing is no slower these days that any other toolkit.

Yes, I know about JIT, its nothing new - but Swing is still slow, still lacking snappiness and still overly complex to create applications with.

Try assigning some widgets to a form, double clicking, assigning code and compiling - you can't do that with Java; thats how bloody painful Java is in its current form. Little or none have been to make Java a RAD tool, its still overly complex and slow.

They are? Last time I checked, I can count on one hand the number of phones that run Linux. And I can't even think of one that uses GTK.

Obviously you *DIDN'T* read what I posted - what is it with OSNEWS.COM people not actualy *READING* what people write? I said *FUTURE PHONES!* you know, phones that *MIGHT* be released in the future *SINCE* the development of a Linux industry development group for phones.

First of all, GTK is not even close to perfect write once run anywhere. In fact, it is basically a unix only toolkit. The Windows port of GTK is a joke that is for the most part, unmaintained. Serious bugs don't even get looked at for over a year, etc. And when it comes to Mac, GTK is non-existent unless you want to run X.

Then what is wrong with having GTK-SWT, Win32-SWT and Carbon-SWT - better that than the ugly mess that is swing and the crap performance that comes with it.

As for 'not any faster' - I've used Azeurus and Limewire; use them yourself and come back and claim which one is more 'teh snappy'.

You might want to give Sun another change now that Jonathan Schwartz is at the helm.

I'll give them 2 years; like I said last year, I'll give them to the end of 2008 to turn Solaris around; if it is still the same ugly mess along with Java, then I'll be better off hoping for mono to improve along with FreeBSD.

Like I said previously, when you have software developed by part time coders with better hardware support than Solaris, and development tools developed by enthusiasts which is easier to code with and perform better than Java, one really has to ask what the hell are they doing at Sun.

I'll give them 2 years; like I said last year, I'll give them to the end of 2008 to turn Solaris around; if it is still the same ugly mess along with Java, then I'll be better off hoping for mono to improve along with FreeBSD.

As usual, you persist in making unprovable claims about Solaris such as "ugly mess." If you were willing to list specific, valid, verifiable, and undeniable issues that can prove that Solaris is an "ugly mess" that are based on fact and not on anecdotal evidence (such as why your wireless or specific laptop doesn't work), I might believe you.

As usual, you persist in making unprovable claims about Solaris such as "ugly mess." If you were willing to list specific, valid, verifiable, and undeniable issues that can prove that Solaris is an "ugly mess" that are based on fact and not on anecdotal evidence (such as why your wireless or specific laptop doesn't work), I might believe you.

Latest stable version of Solaris (Solaris 10 11/06) and my complaints so far - numbered so you can answer to each one of them:

1) Intel 3945 a/b/g support - NDIS does not support it as there is a known issue with it; promises are of plenty in regards to when its going to arrive.

The alternative is waiting for the OpenBSD driver to be ported - it has alread been/currently ported to NetBSD and FreeBSD, with a couple of revisions so far to address WPA support and so forth.

Where is Sun on this? This is one of the biggest selling wireless chipsets on the market - and yes, there are IT people out there who do want to run Solaris on their x86 laptop, and you know, these people might also wish to show off the capabilities of Solaris to their clients.

2) Audio card is not supported; OpenSound is a drama of pain and missery; I can't hear sound from audio files as they keep skipping around when playing them, no audio comes from cds being played.

3) Ancient version of GNOME is included; not just "oh, its one release behind", hell, I could put up with that, I don't expect the bleeding edge, but when a user wants to download CODEC support for mp3 play back, one shouldn't need to have to download the whole damn toolchain and muddle through only to find that none of it compiles - which goes onto my forth point.

4) How come I can go ./configure on my Fedora box, and I don't have constant conflicts between the GNU version and one included with Solaris - sorry, there is no way to specify that I want the GNU version rather than the Sun one to be used when compiling.

Paths not being setup correctly right from the beginning, I shouldn't need to setup weird and obscure paths; if I have installed my development tools in the standard location, I expect to be able to drop down to bash and go 'make' or 'cc' or 'c++' and find that everything just works - I can do that on Linux or FreeBSD, why can't I do it on Solaris?

Want me to expand more? Maybe I should put up an elaborate 'whinge and bitch' section on my blog to point out all the failings of Solaris? this is actually an honest question, would you like that, so then you can address those deficiences.

"Try assigning some widgets to a form, double clicking, assigning code and compiling - you can't do that with Java; thats how bloody painful Java is in its current form. Little or none have been to make Java a RAD tool, its still overly complex and slow. "

what the hell does this have to do with Java as a language or platform?
However all of this is possible in matisse.

what the hell does this have to do with Java as a language or platform?
However all of this is possible in matisse.

Again, you seem to suffer from osnews-a-litus - the affliction of replying to posts with out actually reading the bloody thing.

I said that Java as a language was complex and over engineered - and gave an example of how its gotten to the point that you can't do something as basic as assigning code to widgets.

Yes, I know about JIT, its nothing new - but Swing is still slow, still lacking snappiness and still overly complex to create applications with.

It sounds like kaiwai needs to upgrade his 486!

I have had no problems running swing on any recent hardware. It you are finding it slow then you either have an old machine without much RAM, an old JDK, or very inefficient display drivers.

If you "know" about JIT why do you still keep talking about "interpreted GUI"?

Try assigning some widgets to a form, double clicking, assigning code and compiling - you can't do that with Java; thats how bloody painful Java is in its current form. Little or none have been to make Java a RAD tool, its still overly complex and slow.

We've had that feature in Netbeans since version 5.0 (over a year ago). Perhaps if you weren't so obsessed with Eclipse...

And like a large number of people on osnews.com, you never read the post or the follow up posts relating to what I write.

Here is a tip; read, think, think, think, and think again THEN think about what you're to write, write it, read it, then think think think, then post.

JIT still results in the delay between excution and the result - the result is a sluggish gui no matter how the problems are coded around.

As for "Netbeans since version 5.0" I doubt it, I've used 5.0 and its just as bad as previous versions; I can't stand Eclipse but atleast there is something being yielded out of it in the way of a decent collaboration tool vs. the out of date rubbish bundled with Solaris.

*shakes head* Sun just doesn't get it - they keep pushing swing knowing full well the suckage factor that goes with using an interpreted GUI - the speed at which Swing applications are at, you might as well use GTK + Perl for all its worth.

Just because Swing doesn't meet your purposes does not mean that it doesn't meet Sun or other people's purposes.

I think Sun "gets it" just fine.

As far as SWT? That has its own fair share of criticisms which I won't bother covering since many other people have already more than adequately stated what its problems are.

Heck, why doesn't Sun drop Netbeans, port the good stuff to Eclipse and work out an arrangement with IBM to bring Notes 8.0 to OpenSolaris?

Maybe because there are a lot of people using NetBeans that really like it, like *their* customers? You do realise that the usage of NetBeans has *grown* significantly the past few years, right?

Why would they drop a product that is very popular, has a growing community, and that their customers want? That makes no sense.

...recent example of that is their final caving in to reviving Solaris x86 in face of the reality that SPARC royally sucks on anything less than an 8 way machine.

"caving in" ? I fail to see how a decision that made *years* ago now can be defined as a "recent example", nor do I see how you qualify it as caving in.

You also seem to be severly outdated in your performance analysis of Solaris and Sparc if you believe that Solaris "SPARC royally sucks on anything less than an 8 way machine."

The right tools for the right job.

I think Sun's significant turn around not only in image, but in hardware and otherwise proves that they're doing better than you claim.

You also seem to be severly outdated in your performance analysis of Solaris and Sparc if you believe that Solaris "SPARC royally sucks on anything less than an 8 way machine."

Look at the Specint and specfp benchmarks of SPARC vs. AMD64/Intel Core 2, and compare prices; x86 still give the best bang for the buck, especially when it comes to workstations.

http://shop.sun.com/is-bin/INTERSHOP.enfinity/WFS/Sun_NorthAmerica-...

$2895 for a low end, single core UltraSPARC IIIi workstation that gets its ass handed to it on a platter by a lower priced Opteron machine being sold by Sun? please. Price performance wise, UltraSPARC always come out worse.

Maybe if they shaved $1500 off the price, it would be in the realms of being realistic in regards to price/performance, but the amount demanded is simply unrealistic - wake up Sun, the days of expensive UNIX stations are long gone.

Compare the servers, an Opteron 4 way dual core machine to a similarly configured UltraSPARC machine - the x86 like the workstation will always outperform - the only saving grace for UltraSPARC is the fact can scale, but when you performance sucks that badly, you need all the scaling you can get your hands onto.

"*shakes head* Sun just doesn't get it - they keep pushing swing knowing full well the suckage factor that goes with using an interpreted GUI - the speed at which Swing applications are at, you might as well use GTK + Perl for all its worth. "

Interpreted GUI??? Java has used a JIT compiler since the late 90's. It beats Microsoft's CLR 2 (used by .NET 3.0). Mono has the worst JIT compiler around.
Look at the benchmarks. Java smokes Mono into the ground:

http://www.shudo.net/jit/perf/

For the record Swing painting has had hardware acceleration since JDK 1.4 released in early 2002. Swing on JDK 6 for Linux has a very efficient OpenGL drawing pipeline.

Please refrain from making comments about something you clearly know very little about.

Edited 2007-03-08 09:05

These benchmars are at least 1.5 year old. As all VMs are doing a constant optimization overhauls, they are meaningless today.

Heck, why doesn't Sun drop Netbeans, port the good stuff to Eclipse

Are you high??

*Groan*. Eclipse is a pain, it doesn't provide half the features of Netbeans, unless you go shopping for endless commercial, proprietary plugins.

Eclipse is surviving on its reputation from 2001, when Netbeans used to suck. Since the release of Eclipse, Netbeans has improved dramatically, it has now surpassed Eclipse in terms of features and usability. The dramatic rise of Netbeans (triple digit annual growth in user numbers) should give you a hint about its popularity! I don't want to use Eclipse, I don't like Eclipse, and in 2007 it's primitive compared to Netbeans.

He didn't say that. He said that it was solved and that licensing was the last barrier to entry, they're independent of each other.

Mono is going to lag behind MS .Net. I'll be surprised if they ever get to the point where they've implemented 99% of what MS has and the 1% they're missing isn't something crucial to a huge number of people.
Assuming Microsoft stays with .Net at the pace they have for the last 6 years.

He didn't say that. He said that it was solved and that licensing was the last barrier to entry, they're independent of each other.

Thanks for clearing that.

Though I wonder if the performance issues are really invalid. Imagine a window manager, session manager, and all other components of the desktop written in Java. :-)

Mono is going to lag behind MS .Net. I'll be surprised if they ever get to the point where they've implemented 99% of what MS has and the 1% they're missing isn't something crucial to a huge number of people.
Assuming Microsoft stays with .Net at the pace they have for the last 6 years.

Mono is always going to lag behind .NET but thats not going to be a problem. Lets look at the situation now. Write code for .NET 1.1 and theres no need to care that MS .NET is at 3.0 and Mono is at 2.0.

> Though I wonder if the performance issues are
> really invalid. Imagine a window manager,

There actually are a few window managers written in Java. And really, there are no performance issues with them at all. Again, keep in mind Java does intelligent runtime analysis and looks for areas of code that are too slow, and then compiles those down to native code.

Remember that a typical computer program spends 95% of its time running 5% of its code. So the deal is optimize that 5%, and don't worry much about the rest of it.

Like project looking glass?

Here are a couple more traditional window managers written in Java than project looking glass. They aren't full blown desktop environments, and most of them are in early stages. But they are examples:

JD4X: http://jdx.sourceforge.net/
Jesktop: http://www.jesktop.org/

Hello,

As it turns out, you do not need to implement 100% of Microsoft.NET to port a lot of applications. We found out with Moma (google our web site) we will be able in the next three months to bring 700 applications to Linux that have been reported to us through Moma (this is without making any changes to the apps).

From the remaining half of the applications (based on the sample of 1,700 or so results that have been submitted), its roughly 1/3rd split over less than 10 changes, between 10 and 40 changes, and more than 20 changes (by changes I mean, P/Invokes that will have to be redone).

So one sixth of the .NET applications today wont ever be ported, another sixth will require a strong commitment to port, another sixth trivial changes and the other half would port with trivial changes to Mono.

The numbers are estimates from memory from the results that I collected for my FOSDEM presentation.

Miguel.

> So one sixth of the .NET applications today wont
> ever be ported, another sixth will require a
> strong commitment to port, another sixth
> trivial changes and the other half would port
> with trivial changes to Mono.

The only problem with this, is a lot of those applications that will require "trivial" changes, will be closed source. Expect a lot of the software written for .NET to be closed source. So you won't be able to port it even it would only require trivial changes. Don't count on MS Office.NET running on mono any time soon.

I wouldn't count on MS Office.Net anytime soon.

Yea that's great and I'm not arguing against it. I'm just pointing out that Microsoft has a head start on features anytime they want to have one and they've got a lot more resources than Novell.
And right now Mono is finishing up 2.0 compatibility while Microsoft is rolling out 3.0, correct?

It does seem that Mono will forever be a step behind. Which is fine.