Since I am a specialist in such matters, you'd do well to believe it ;)

Indeed. I completely trust zoot's judgement in matters of java.

We're stuck coding in java at my college and really, it's working fine. In fact, it was only once I got to school that I really started to appreciate the cross platform aspects of java. It is so nice to be able to write something in windows in the CS lab and then bring it home and finish it one one of my *nix systems without having to change anything. The performance seems fine, although java apps seem to take a bit long to start up for the size of the program.

Zoot, how does java handle the issue of paths between systems. If you wanted to have a program create some directories and then put things in them, what does it do about the / vs \ issue? Is there a way to detect what OS you're running on and have variable directoryDelimeter or something?

In this case it's more of a matter of computing theory and implementation, but thanks :)

Java programs are "JIT compiled" when they're started (JIT meaning "Just In Time"), meaning there's a pre-processing stage when they start up, which is why they take so long to start up. There's ways around this if you'd rather avoid it, but I'd not recommend them in most cases.

Always use / and Java is smart enough to work it out. If you want to know the actual character, though, it's available on File.pathSeparatorChar (File.pathSeparator gives you it as a String for convenience).

999 times out of 1000 when you're attempting to detect a specific OS on Java, there's a better way to do it.

Java gets an undeserved bad reputation, largely due to the fact that it is currently clunky on the desktop, and because of people's misunderstandings of the platform. The next version is apparently concentrating on Desktop API problems, so hopefully it'll be a bit better for curing this problem.

zootm, I understand that you really like Java, and yes, its JIT functionality is very nice, and also there are some very, very nice optimizations in recent JREs, but the problem I have with believing that Java is truly a language with "exemplary performace" is that I have yet to see a lean Java program on the desktop, even when the interface is relatively nice and the application is inherently large enough that the overhead of running a JRE shouldn't matter too much (OpenOffice.org, Azureus). Do you have an explanation?

I think it's partly a stigma issue (Java was slow), partly due to the APIs not being up to scratch (they're still not, but Swing is the current area where work is being focussed so hopefully it'll work acceptably in the next version), and partly because people don't generally think that a couple of seconds to JIT is something they want for a lean app (which is fair enough - I'm not sure if GCJ-style systems or possibly just caching the JIT output would fix this). OOo is slow anyway - most of it is not written in Java if I remember correctly (it uses some Java libraries, but it's not a Java app). Azureus was never trying to be fast.

This is something I have pondered on in the past. I'm not actually sure that Java, as it works from the off, is really suitable for a "lean app". A lot of the overhead in Java apps can be offset or shared between Java processes though, so it can be done, it's just not how it's set up to start with.

Another problem with performance is that a lot of people use SWT, and its performance isn't great, due to the amount of native code it uses.

My personal view is that Java is perfectly capable of implementing desktop apps, but there's a number of factors which prevent people from using it in smaller projects, whereas Java's very structure helps with larger apps.

Fuck Swing, by the way. Fuck all non-native interfaces for non-application-specific uses. Fuck them up their stupid asses.

SWT is "slow"? Why the hell would using native code make a toolkit "slow"? Wouldn't using native code, near by definition, make it *not* slow?

I dunno. Of the Java apps I have seriously considered using, I'm still only using Azureus, and only because everything else lacks a couple of (what I consider to be) critical features — I actually hate the thing for its horrid performance and the tendancy of everything else to run more slowly when it is running (I'm not sure why... a lot of a particular system call maybe? ... Outlook does something similar).

If Swing were implemented well, it'd be a better solution for a truly cross-platform toolkit. The problem isn't so much them being non-native as them being dissimilar to the feel of the original toolkit. Bolting a generic core over the toolkit (like SWT does) does not hugely help this.

False assumption here: Java is not significantly slower than native toolkit code. If fact, there's a considerable amount of the time Java code is faster than native code (by virtue of JIT, and the fact that the language is more easily-optimised). What is slow is calling native code from Java, because of the glue and marshalling levels required.

Also the OSX and *nix implementations of the native parts of SWT are apparently pretty poor.

Possibly memory use? If you're not using Java 5 already, use it - it makes a lot of things "better" in terms of performance. I've not experienced that though (I can run Azureus minimised on this, my older PC, without a noticable performance hit, and on my main Windows box).

Here's a fun article on Java performance, there's many like it. A quick search will find you them. One thing you'll find is that the client JVM is a lot slower than the server JVM, in many tests, which impacts desktop performance because it's what's typically used for desktop apps.

well... i've just recently received my vista disks in the mail, and i must say, i spent a good part of the day configuring and installing it :rolleyes:

HOWEVER, i do like it, a lot, and plan to devote myself to full time testing of this new operating system...
it's quite useable once you get the fucking thing configured the way it should be and looks real nice too.
call me a fanboy but i love vista so far, and it's only going to get better as more and more bugs are reported and fixed/found.
in fact, i like it so much, this computer will henceforth be running vista exclusively.

Fuck XUL?
There is no dana only zuul.

there.is.only.xul :D

XUL is a clever solution, and it's clearly been a strong influence on XAML, which is what WPF uses and part of what makes it such a potentially-powerful system. XUL has been criticised for being slow (its general reliance on scripting often seen as the culprit) though. I'd really like to see some new "open" toolkit with a similar structure to XAML, compiling layout code into real widgets.

XUL is not inherently bad. It could be implemented with native widgets, you see.

I'm still not convinced native widgets are a cross-platform answer. In any sufficiently-powerful cross-platform GUI toolkit, native widgets will give you the look, but not the feel. Self-drawn systems can already emulate the look.

Yes, they can emulate the look — poorly.

How would native widgets not give you most of the feel of a particular OS?

Think syntax vs. semantics. They look the same, but act differently. It's a dishonest interface.

Oh, and I realised I do know an example of a lightweight Java desktop app: Cabos.

Don't know what desktop API it uses, it looks like SWT though.

Like what, for example?

Cabos looks pretty sweet. I'll have to check it out.

An example is creating your own dialog to look like a standard system one. What order do you put the "Ok" and "Cancel" buttons in? It's different in Windows and GTK. Different widget toolkits behave in subtly different ways, and it's hard to carry these things across.

There's pros and cons to both systems. I personally think Swing is a better approach, but it's inherently harder to implement and isn't really "prime time" at present.

So why not have the cross-platform toolkit decide that?

I can think of a lot of examples, but nothing which is not trivial for the cross-platform toolkit to deal with (even if there are so many examples that it's not inherently trivial).

The abstractions add up. My bottom line, though, is that in "safe" systems, calling a native code toolkit can be slow and unstable, and often affords little real benefit, since the only thing you gain is the look, which is essentially the easiest thing to mimic.

You don't gain just the look, you also gain how the widgets work. Buttons, scrollbars, menus — they all have subtle differences between platforms. When using a Swing-based application on Windows, it doesn't feel like I'm using a Windows app.

Everything's a little different, everything requires a little more attention to deal with.

It reminds me of my first time of driving in Canada — yeah, there are still roads, still speed limit signs, still lines on the roads, and everything is pretty damn close to the US (with the major exception of MPH vs KPH), but it was confusing as hell, just because things which took no attention to deal with were now unfamiliar.

It's not quite as extreme with Java toolkits, but perhaps you can see what I mean...

Do you ever wonder why every app written in SWT acts more like Eclipse than any other system? The way the widgets work is usually not well carried across, because they have to act just as the abstractions say they do.

I maintain that Swing's biggest problems are that its rendering is rubbish and it's buggy (there's one bug in particular that annoys the shit out of me). Native toolkits which are reasonably powerful don't get a significant semantic gain.