New Desktop Features Of Next Java

bonch writes "Sun has posted the new desktop features of the next Java, codename Mustang. Improvements to Swing look and feel, OpenGL 2D renderer performance, AWT features such as the ability to add a tray/panel icon, and improved deployment capabilities."

Comments

Additional items

[BWJones]

Here are my items that I would like to see in the next Java:

1) The ability to allocate more memory space to Java apps.
2) 64 bit support.
3) Ability to/Easier implementation of hardware specific calls to speed calculations. (e.g. Altivec acceleration).

Re:Additional items

[Anonymous Coward]

2) 64 bit support.

Hard to see how to improve that without destroying run-anywhere. You'd have to stick with 32-bit integers, or you wouldn't get the same behaviour on two different platforms. I guess the VM could use 64-bit pointers internally, but as you can't access memory directly in Java I don't know how the programmer would ever be able to tell.

3) Ability to/Easier implementation of hardware specific calls to speed calculations. (e.g. Altivec acceleration).

This should be implemented at the VM level. Exposing this kind of hardware detail to the programmer would completely miss the point of using a VM in the first place. If you really want to limit yourself to a single platform, use JNI to call C code that uses your hardware-specific instructions. But if you're going to do that, why not just use C++ in the first place?

Re:Additional items

[lawpoop]

I don't get it. If sun was responsible for 64-bit computers being commonplace, how come Java doesn't support 64 bits?

Re:Additional items

[Anonymous Coward]

For those of you who want a better alternative to slashdot which isn't full of errors, redundancy, and trolls: http://news.google.com/nwshp?topic=t

I couldn't find the discussion section on Google News. Can you show me where it is, please? I want to discuss news stories, not just read them.

Re:Additional items

[MindStalker]

I believe there already is an implementation of java for running on 32-bit code on 16-bit hardware. So its not very different.

Re:Additional items

[SnprBoB86]

You can allocate as much memory as you like using the right java command line flags:

http://developer.apple.com/documentation/Java/Re fe rence/Java14VMOptions/VM_Options/chapter_1_section _4.html

Re:Additional items

[nganju]

Java already has support for 64-bit Athlon on Linux.

They also have a release candidate for Windows 64 here:
http://java.sun.com/j2se/1.5.0/download.jsp

Both of these versions allow the allocation of much more memory to Java apps. The old roughly 2 gig limit was a limitation of 32-bit operating systems, not of the java vm. Give it a shot on the 64-bit VMs with
java -Xmx3000m MyApplication
it should run fine (assuming you have >=3 gig of memory).

Re:Additional items

[Anonymous Coward]

Er, no. The most memory Java can address is 4 GB, if memory serves me correctly. Your link doesn't refute that.

Re:Additional items

[catch23]

Says the max memory allocatable is 2048M? 2 gigs is a lot of memory, but I'm not sure this is as much memory as I want though.

Re:Additional items

[CynicTheHedgehog]

All three items are possible, but entirely dependent on the virtual machine implementation.

1) In the current Sun JVM you can allocate more memory space with the -Xms and -Xmx switches (min and max heap size, respectively)

2) I believe that the Solaris VM has 64-bit support. 64-bit support for AMD/G5 could be forthcoming, but they are still relatively new. Than, and you can't really expect Sun develop optimized JVMs for competitors.

3) As for hardware specific calls and optimizations, I'm sure that if AMD, Apple, IBM, and/or Intel wanted to invest in developing their own custom JVMs with those optimizations they would be welcome. Again, it's not really in Sun's best interest to develop VMs optimized for their competitors' hardware. Apple has their on JVM, but I'm not sure what kind of effort they have put into hardware optimization.

3) Java is not C or assembly language. If your performance requirements are critical to the point necessitating direct hardware calls then I can pretty much guarantee that Java is not the appropriate platform for you application.

- Jesse

Re:Additional items

[iwadasn]

It does, on linux and Solaris, I believe. No 64 bits on windows, perhaps because windows doesn't support it?

Re:Additional items

[AKAImBatman]

I don't get it. If sun was responsible for 64-bit computers being commonplace, how come Java doesn't support 64 bits?

It does. 64 bit support already exists on Sparc. My guess is that this is for full 64 bit memory support on newer platforms.

Re:Additional items

[cmburns69]

The java language can already support 64 bits. It's got the long and double data types (which are both 64 bits).

A more pertinent question would be "Why aren't there any 64 bit JVM implementations?".

I don't know if any are available yet, but several are in the works.

Re:Additional items

[jkroll]

Says the max memory allocatable is 2048M? 2 gigs is a lot of memory, but I'm not sure this is as much memory as I want though.

This is a JVM issue, not a language issue. There is nothing in the language spec limiting memory support to 2GB anymore than Windows C language programs are limited to 2GB of memory.

There is no real reason why Sun (or any other JVM provider) couldn't and doesn't provide a 64 bit JVM that can access more than 4GB of memory.

Having said that, it would be nice if there was a command line option on startup that could set the JVM memory limit to some percentage of the physical RAM available on the system (i.e. something like java -Xmxp 50 -- would start the JVM up with a memory limit of 50% of the physical ram on the machine). Today you would need to write an OS specific script/wrapper program to determine the available memory and then launch the JVM.

Re:Additional items

[AKAImBatman]

I don't know if any are available yet, but several are in the works.

I run 64 bit Java on my UltraSparc. I think that's the only 64 bit system that currently has 64 bit memory support. Mustang probably introduces 64 bit memory for the Opertron and the Itanic.

Re:Additional items

[Decaff]

I don't get it. If sun was responsible for 64-bit computers being commonplace, how come Java doesn't support 64 bits?

Who says it doesn't?

Go to javasoft.com, and check the downloads. You can get Java for 64-bit Linux on AMD and 64-bit Solaris on Sparc and AMD.

Re:Additional items

[tim256]

Java does have 64-bit support for Linux AMD-64 and the 1.5 jvm for Windows AMD-64 is available as a release canidate. Sun has also had support for Intel's old 64-bit processor a while now. If you do a google search, I'm sure you can find benchmarks to see the performance improvements this support offers.

Re:Additional items

[null etc.]

Here are my items that I would like to see in the next Java:

Here's what I would like to see:

1) More obfuscated product naming conventions. Java2 1.6 6.0 Mustang?? C'Mon, that must have been agnominated by first-graders. I propose something like Java(2)1:6.0/Desktop-Revision 19.2 Supplement 12 Equus caballus

Re:Additional items

[Jonboy X]

Wow, if only there were a moderation "Doesn't know what the hell he's talking about"...

1) The ability to allocate more memory space to Java apps.

From the command line, run "java -X". Note the -Xmx and -Xms options to allow you to control initial and maximum heap space. These options have been around for years.

2) 64 bit support.

Ever heard of the SPARC processor? You know, the one Sun produces, one of the first mass-market 64-bit platforms available?

Assuming you're talking about AMD64, there's already a JVM that supports it. Linux-only at the moment, but if you insist on using platforms that suck, there're already AMD64 Windows JRE release candidates up too.

3) Ability to/Easier implementation of hardware specific calls to speed calculations.

Now you're just missing the point entirely. One of the major goals of Java is that the same compiled binary can run on any machine with a compliant JVM written for it. When you start making calls to specific hardware, you lose that. Besides, if you *do* want to sacrifice the platform portability of your program, you can always just write a JNI module for it, but then I suppose you don't have a clue about that one either...

Re:Additional items

[albrecht]

bea now has a 64-bit windows itanium jrockit 1.5.0 now as well. HP has recently added 64-bit hpux pa-risc and itanium too.

Re:Additional items

[Anonymous Coward]

1) Allocating more memory space. Can already do that.

-Xms set initial Java heap size
-Xmx set maximum Java heap size

Granted, they are listed as non-standard command line flags, but Sun implements them (don't know about other implementations).

2) 64 bit. There are JVM implementations for 64-bit platforms (both AMD64 and Sparc). If you need to deal with big numbers in your own programs, check out java.math.BigInteger and java.math.BigDecimal.

3) JVM implementations are already free to use platform specific optimizations (like Altivec, MMX, etc.) to speed things up. If you need the speed of Altivec for your own program code, that's what JNI is for.

Re:Additional items

[Glock27]

Hard to see how to improve that without destroying run-anywhere.

Not true. Why would you think that?

You'd have to stick with 32-bit integers, or you wouldn't get the same behaviour on two different platforms.

You don't know about "long"?

I guess the VM could use 64-bit pointers internally, but as you can't access memory directly in Java I don't know how the programmer would ever be able to tell.

The programmer would be able to tell when the allocation of more than 4 GB worth of objects happened without incident. :-)

If you really want to limit yourself to a single platform, use JNI to call C code that uses your hardware-specific instructions. But if you're going to do that, why not just use C++ in the first place?

Because C++ is rather broken, and people would rather use a saner language? For instance, gcj and CNI provide a lightweight approach that seems superior to JNI in many situations.

C++ really needs to be replaced, and Java seems the logical candidate to do it. Java needs further improvements and extensibility, but C++ was around a *long* time before it began to approach actual usability.

By the way, 64-bit VMs do already exist...

Re:Additional items

[ShamanDave]

The feature I'd most like to see? Availability of the real Sun JRE through Microsoft Windows Update. OK. So it's not realistic, but it would make me happy.

Re:Additional items

[Anonymous Coward]

Well, when there's a replacement for C++ that 1. has RAII, 2. allows allocation of objects on the stack (probably required for 1), 3. has operator overloading, and 4. doesn't force user code to distinguish between user-defined and "primitive" types, I'll consider it as an upgrade. As it is, Java is a step backwards in all of the above areas.

Re:Additional items

[Anonymous Coward]

"Hard to see how to improve that without destroying run-anywhere."

Something has to exist before it can be destroyed.

Re:Additional items

[ClosedSource]

Like it or not, the goals of C++ are not achievable with Java.

One of the most important of these goals was to retain a high degree of compatibility with C. This was done not only for purposes of code reuse, but to retain C's ability to handle system programming tasks.

Java is a useful language, but can't replace C++ for everything.

Re:Additional items

[iksrazal_br]

"You can allocate as much memory as you like using the right java command line flags"

Try this on a 16 gigs of memory Solaris 10K:

byte[] b = new byte[3000L * 1000L * 1000L];

Seen this question today:

http://groups.google.com.br/groups?hl=pt-BR&lr=&th readm=pan.2005.04.21.09.43.29.859952%40fffffffffff fff.com&rnum=11&prev=/groups%3Fq%3Dmemory%2B2005%2 6hl%3Dpt-BR%26lr%3D%26group%3Dcomp.lang.java.progr ammer%26start%3D10%26sa%3DN

People doing biometrics apparently are trying to.

iksrazal

Re:Additional items

[Anonymous Coward]

Remove from the runtime anything that was depricated in 1.0.2 (of course on the condition that not having to support the crappy class/method will make the jvm more stable, or simpler, or faster. Like Thread.stop() )

Re:Additional items

[Juergen Kreileder]

Says the max memory allocatable is 2048M? 2 gigs is a lot of memory, but I'm not sure this is as much memory as I want though.

This is a JVM issue, not a language issue. There is nothing in the language spec limiting memory support to 2GB anymore than Windows C language programs are limited to 2GB of memory.

It's no VM issue, it's a OS issue. Java can only use as much memory as the OS gives to processes. On 32-bit Linux/x86 you can get pretty close to 4G with a customized kernel.

There is no real reason why Sun (or any other JVM provider) couldn't and doesn't provide a 64 bit JVM that can access more than 4GB of memory.

Sun and other VM providers (e.g. Blackdown :-) already provide 64-bit VMs!

Re:Additional items

[Juergen Kreileder]

"You can allocate as much memory as you like using the right java command line flags" Try this on a 16 gigs of memory Solaris 10K: byte[] b = new byte[3000L * 1000L * 1000L];

That's a limitation of the current spec: Arrays can only have up 2^31 elements. But that limits the mem you can use for a single array, it's not overall limit.

Re:Additional items

[Anonymous Coward]

Ability to/Easier implementation of hardware specific calls to speed calculations.

If you're after speed, why do you care about Java?

Re:Additional items

[jkroll]

Sun and other VM providers (e.g. Blackdown :-) already provide 64-bit VMs!

Yes they run in 64 bit mode on a 64 bit OS, but from the Java 5.0 docs:

-Xmxn
Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples:

-Xmx83886080
-Xmx81920k
-Xmx80m

On Solaris 7 and Solaris 8 SPARC platforms, the upper limit for this value is approximately 4000m minus overhead amounts. On Solaris 2.6 and x86 platforms, the upper limit is approximately 2000m minus overhead amounts. On Linux platforms, the upper limit is approximately 2000m minus overhead amounts.

So either there still is a problem with the JVM limiting memory usage to 4GB or the documentation is wrong. Don't have a Sun box with more than 4GB RAM handy to test this out on. But I think it is a JVM issue.

Re:Additional items

[Juergen Kreileder]

So either there still is a problem with the JVM limiting memory usage to 4GB or the documentation is wrong. Don't have a Sun box with more than 4GB RAM handy to test this out on. But I think it is a JVM issue.

No, the documentation is wrong. The limits only apply to the 32-bit versions.

It's worth noting...

[AKAImBatman]

...that mustang is also the first Java version to be developed under an Open Source type model. The CVS is open to guests over on http://www.java.net, thus allowing for immediate feedback and bugfixes. It has been a real boon for the gaming community, as they've been able to direct several key performance features.

Re:It's worth noting...

[AKAImBatman]

Linky

Re:It's worth noting...

[Anonymous Coward]

I've seen phrases similar to "developed under an Open Source type model" before. I don't know what it means.

Open-source itself is a type of licensing, not a development model. I've seen open-source programs written under all sorts of development models, from "secret in a company until the day of release" to "written on a weekend by guys hanging out on an IRC channel".

Is this basically Sun's way of saying "We tried, for once, not ignoring what people were asking for"?

That's great, and I applaud them for listening. (If they had done that back when I was writing Java apps in the 1.2-1.4 era, I wouldn't have switched away from Java. They really were great at thumbing their noses at developers for a while.) But that doesn't make it open-source.

It's kind of amusing to see that all the big companies seem to agree that (a) customers want open-source, and (b) what they've got ain't open-source. So they dance around it:
- Apple: "open at the source" (= the kernel is open-source)
- Microsoft: "shared source" (not open-source at all)

The look and feel of Swing.

[chkorn]

Yeah! This is really something that should be made better.
Always when I use some Swing based applications I'm remembered that the times of ugly GUI's aren't over yet.

Re:The look and feel of Swing.

[TiMac]

They are improving the Windows and GTK Look and Feel...but I'm hoping also that either Sun or Apple tackle the Mac OS X look and feel of Java apps.

Sure, you can code Cocoa apps in Java and use Java in those ways...but pure Java executables programmed in Swing still lack the complete purity of Mac OS X. Apple ships tools in the Developer Tools to improve Java (like Jar Bundler) but the UI still isn't perfect.

Re:The look and feel of Swing.

[MassacrE]

Personally, I'd be happier if they completely dropped swing support on the Mac ,or at least removed aqua L&F.

There is a proliferation of really horrid java applications on the Mac because people don't understand that you cannot WORA and have GUI make sense. Users of different operating systems have different needs and expectations, even when they are equivalent 'types' of users with relatively equal computer experience.

Re:The look and feel of Swing.

[tim256]

It's almost like they tried to make the ugliest GUI of all time. Luckily, they are getting better and the Windows XP and Ocean look and feel for 1.5 look good. If only swing wasn't so bloated and it was little faster...

Re:The look and feel of Swing.

[XMetal2001]

Definately, Whenever I use a Swing app i feel as if im back in the early 90's... actually discourages me to use the application.

Re:The look and feel of Swing.

[SlightlyMadman]

you cannot WORA and have GUI make sense

Care to elucidate? Why does Write Once Run Anywhere mean a GUI doesn't make sense? Are you referring to the major UI differences between MacOS and most others, like having the menus in the bar at the top of the screen? If you write your java apps properly, they completely conform with the MacOS UI conventions when run on a mac. If you don't write them properly or don't care, then they'll be awful on a mac even if they have jellybean buttons.

Have a look at a large and well supported app like jEdit for an example of something that does it mostly right.

Re:The look and feel of Swing.

[green menace]

I think the SWT from the eclipse/ibm peoples is the way to go. Swing will probably always look like ass. I don't know why Sun doesn't get that. My guess is that they don't like that you can compile to native with SWT & gcc while you are bound to the JVM with Swing.

Re:The look and feel of Swing.

[Anonymous Coward]

By "they," of course, you mean Apple. After all, Apple's the one doing the VM for OS X. Not Sun.

(PS - there's a proliferation of really horrid Java apps *everywhere*. It's just that Mac users pay attention, while most others don't)

Re:The look and feel of Swing.

[CaptainPinko]

Well mostly because of user expectations based on the OS's gui conventions.

For example Windows uses a File menu that always appears first and contains saive, load, and exit. Settings appear usually in the second menu called "Edit"

Now on MyImaginaryOS I have the convention that the first menu is called "System". It contains program settings and exit the program. The second menu is called "Data". It contains the save, load, export to different format (which is not part of the save dialogue on my imaginary os).

In swing you either code it one way or the other leaving the user using the program on the other system confused since where did their "System" menu go? Or you code two seperate GUI, or you code one gui with a lof of if-OS-then-else-if-os-then statements.

I once saw this article on a Java professional site saying to never use native LnF. Becaues even though the widgets will look the same the program will won't look right. They showed a screenshot of a Java app designed with Windows conventions awith a Mac OS LnF. I only casually used Mac OSso I was like "hmm, looks macky to me." Then next to it they showed an image of the app redesigned to Mac sensibilites. It just felt much more Mac.

To give a Linux analogy: take the old Gnome finder. Give it a KDE theme (keramik or plastiK). It just won't feel right since it lacks that KDE sensibility. That's why the suggestion of the Java professional was to use the Metal LnF. The user might have to get used to the way buttons look, but at least the won't be confused when the menus are layed out differently since they'll *know* they are using a different platform with standards and conventions.

There are endless such examples.

Re:The look and feel of Swing.

[lrucker]

Using the native LnF is not a problem, provided you let the layout manager do its job. The worst thing you can do is hardcode layout values. As for menu items and such, you can specify platform in your resources, and there's a way to make Swing apps put Swing menu items into the real Mac menu - somewhere on Apple there's a tech note that goes into more details on all these things.

You can use the MacMetrics Metal theme I wrote to get an approximation of how things will be laid out under the MacL&F

Re:The look and feel of Swing.

[SlightlyMadman]

Yes, you're absolutely correct. There are certain UI conventions that are completely unique to a particular OS, way beyond widgets. With java, it is the responsibility of the OS author and the VM author to cooperate and make sure developers are given the tools to make their apps aware of this.

To speak specifically of OSX, have a look at this document. A java application author who reads it carefully and follows the guidelines apple has set forth will find that their app fits perfectly in an OSX environment.

I agree with you that the majority of java apps are awful on any platform but the one the author used for development, but that is either due to laziness on the part of the developer, the os developer, and/or the vm developer.

It should be noted that this is not unique to java. A program can be written in just about any language that either ignores or overrides the OS's UI conventions. Heck, even Apple and Microsoft do it all the time.

Re:The look and feel of Swing.

[Anonymous Coward]

There is a proliferation of really horrid java applications on the Mac because people don't understand that you cannot WORA and have GUI make sense. Users of different operating systems have different needs and expectations

So that's why they use those same applications ?

Re:The look and feel of Swing.

[CaptainPinko]

The the problem is that the OSX conventions you linked to are worthless. It's not laziness. The problem is that those conventions are platform specific and thus a Java developer cannot follow all the conventions of all the platforms he is targetting since there are conflicting conventions. So while you can code a perfect OSX in Java, you cannot write a perfectly convention compliant application that is cross-platform )at least not reasonably). You need to do a lot of work any way you slice. Perhaps is Sun created a higher-level API and let the LnF handle it there'd be a chance.

alright....

[HTL2001]

Who spilled the java in my Mustang??!

Re:alright....

[Anonymous Coward]

Woo, now that's a knee-slapper. No, really, I'm laughing on the inside. I vote we remove your feeding tube.

Re:alright....

[HTL2001]

i guess you posted as AC so you could still mod me?

Dear jFirstPostBot

[Letter]

Dear jFirstPostBot,

You would have succeeded, if only you had used the speedy next version of Java, codenamed Mustang.

Letter

Re:Dear jFirstPostBot

[anishm]

Or if you have taken to heart -- If at first you don't succeed, destroy all evidence that you tried. You could have avoided the previous comment and this one!

And as usual

[Anonymous Coward]

Jave was too slow.

Hate to feed the trolls, but

[gotr00t]

YOU FAIL IT. Yes, you had a bot.

Re:Hate to feed the trolls, but

[notherenow]

can you tell me what a troll is? and then can you tell me what a bot is?

how about

[VolciMaster]

Simplifying the ridiculously complicated Java libraries. The (limited) Java development I've done in the past has led me to build a whole bunch of things that probably already existed in the libraries, but I couldn't find.

I'd also like to see a reduction in the 'layouts' available. Maybe I'm old-fashioned, but I like to position the elements where I want them, and not how some layout manager feeld they will will go best.

Re:how about

[rpozz]

I think that there is a Layout for positioning with exact coordinates. Either that or you can use a Java IDE.

However, the more common GridLayout, BorderLayout and FlowLayout can all be used to make perfectly acceptable GUIs, it just takes a bit of practice. The main advantage with it is that it allows your windows to be a range of different sizes without repositioning anything, and is less likely to screw up when you change look and feel.

GTK has very similar layouts to Java as well.

Re:how about

[comwiz56]

You don't have to use a layout manager. You can easily call setLayoutManager(null), and then use coords to place everything in the frame.

Re:how about

[quantum bit]

It would help if GridBagLayout actually worked as advertised...

For example, is there any way to have a double-height cell at the end of a row, and start on the next (single) row, and not have to resort to statically numbering everything?

BoxLayout is good for simple stuff but not when you need to have things line up both horizontally and vertically.

Re:how about

[Anonymous Coward]

maybe if you'd actually looked on the public API that Sun provides you would have found the list of layout managers, one of which being springLayout that allows you to provide exact coordinate placing relative to anything you want (the frame/panel, other components, etc.) sorry if it's so punchy, but I'm consistently amazed at how much people hate Java just because they are lazy.

Re:how about

[Anonymous Coward]

For example, is there any way to have a double-height cell at the end of a row, and start on the next (single) row, and not have to resort to statically numbering everything?

Maybe we could help you if you explained that in a clearer way.

Re:how about

[mark-t]

I remember feeling a bit frustrated at the choice of layout managers in Java, and with much trepedation, thought perhaps I should try to write my own.

To my suprise and delight, it was incredibly easy to do... and I've done many custom layout managers since. They are about the same level of difficulty as some of the one-off scripts unix sysadmins might develop to automate a particular job that needs doing.

Re:how about

[Anonymous Coward]

Good luck maintaining anything other than a toy GUI, or building one that is dynamic (dockable windows, etc.). Sure, you could do it without using the API layout managers, but why the hell would you want to?

Re:how about

[Call Me Black Cloud]

"Dear China,

I am inexperienced with the Chinese language. I am having difficulty learning it because I find it ridiculously complicated. Please simplify it.

Signed,

VolciMaster"

As for the layout managers, you just need practice with them. My suggestion is to stick with BorderLayout, FlowLayout, and BoxLayout (with some widgets from the Box class). You can easily nest panels using those layout managers to get what you want, 99% of the time.

Do you know what frustrates me about Windows development (using C++ Builder)? Absolute positioning. I place things where I want them, run the app, resize the window, and nothing moves! Only the window gets bigger. Once you get the hang of layout managers you'll see how easy they are to use and how much nicer your UIs will be.

Re:how about

[mrtroy]

You don't have to use a layout manager. You can easily call setLayoutManager(null), and then use coords to place everything in the frame

Just what I was going to say.

That guy has obviously less than 1 hour experience with swing, and he is making outrageous claims like you cant position things where you want to.

Re:how about

[Anonymous Coward]

Cause static layouts don't work. If you resize the window the layout doesn't resize. Whats the point of having a 21 inch monitor if you can't use all of it.

Re:how about

[Anonymous Coward]

It's very easy to do in builder you just select the component and change the anchor properties, you can anchor top, bottom, left, right or any combination of that. That is unless you're using a very old version of builder. This is why most borland developers hate the idea of all this layout manager b.s.

Re:how about

[Anonymous Coward]

Moreover this guy obviously does not understand what happens when you use a null layout manager and then translate all of your GUI's text into German or Japanese or your user has longer text than you thought they would and they can't resize your dialog or text entry panel because you were stupid enough to use a null layout manager. [Microsoft Visual Studio is positively *awful* for fixed sized entry panels where I want a nice big text field.]

Re:how about

[Anonymous Coward]

I am inexperienced with the Chinese language. I am having difficulty learning it because I find it ridiculously complicated. Please simplify it.

Done.

Re:how about

[quantum bit]

Ok, I'll bite... Say you want to produce the following layout (diagram sucks because lameness filter is unfairly biased against ASCII art -- it looked much better the first time):

A B C
D D E
F G E
H I J

(where D is double width, and E is double hieght)
According to the GridBagLayout documentation, it sounds like you should set the constraints on cell 'E' to gridheight=2 and gridwidth=REMAINDER. However, when doing this, the "next" cell starts _UNDER_ 'E'. So there's a blank line, everything gets shifted down, and 'F' starts where 'H' should be.

The only workaround I've found is to manually set gridx and gridy coordinates on every cell, which makes changing the layout later a royal pain.

Re:how about

[patio11]

Dear VolciMaster, We already did. Signed, China

Re:how about

[glitch23]

I'd also like to see a reduction in the 'layouts' available. Maybe I'm old-fashioned, but I like to position the elements where I want them, and not how some layout manager feeld they will will go best.

Do you not know about the GridBagLayout or does it just not suffice?

SubPixel Rendering

[aCapitalist]

It looks like they've finally addressed this issue, but I think Sun is a little late.

Personally, I can deal with non-native look-n-feel, but when the fonts look like something circa 1988 on an Amiga, how can anyone take Swing seriously.

I never understood why they couldn't use platform specific code for fonts, and if not possible then go into fallback mode and paint everything themselves.

Swing has been a disaster. I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.

And thank god for .NET/Mono being around to give Sun a little kick in the rear to get moving on things.

Re:SubPixel Rendering

[rpozz]

On the current version of Swing:

label.setFont(new Font("dialog",Font.PLAIN,12));

Obviously doesn't look as pretty as a regular anti-aliased font, but infinitely better than that disgusting bold font that is used by default.

Re:SubPixel Rendering

[Anonymous Coward]

SWT seemed like a good idea at the time but overall it's time has past.

Swing is fast now (and has been since early 1.4.2 releases) and the few areas where it is not quite up-to-snuff are rapidly being fixed.

Overall, SWT seems like a waste of good developers' time -- both those who wrote it and could have been writing something of more lasting use and those who bother learning it and splitting Java GUI mindshare.

Re:SubPixel Rendering

[bnenning]

Swing has been a disaster. I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.

Indeed. The implementation of AWT sucked, but it at least had the right idea: the host OS has facilities for drawing interface elements, so use them rather than reinventing the wheel. Apple's Swing L&F is halfway decent because they use native APIs to draw widgets, and according to the article Sun is now doing the same thing for Windows and Linux. Desktop Java would be in a much better state if they hadn't gotten sidetracked for years trying to make apps on every OS look identically bad.

Re:SubPixel Rendering

[shutdown -p now]

I believe it was the OTI guys (who now work on Eclipse and SWT) that told Sun not to go the route of "give me a handle to a brush and we'll paint everything ourselves", but some other group won that debate.

Strictly speaking, this approach can work very well. That's exactly how Qt handles things - and it's damn hard to tell a Qt app on Windows from a native one (not sure how things are on Mac, but judging by the screenshots, it's fine there as well).

Re:SubPixel Rendering

[Anonymous Coward]

What sucked about AWT is not the implementation but the original design principles. You can't make the toolkit be an interface to native API with native L&F and make it "write once, run everywhere" at the same time. It's just an obvious logical contradiction. Swing is imperfect, it's bloated, but it works aroung this contradiction.

What I'd like to see is

[ImaLamer]

Screenshots!

A story about desktops carry no weight with me unless there is pretty pictures.

Re:What I'd like to see is

[Anonymous Coward]

Yeah, especially considering this is about desktop integration features of a programming environment instead of a desktop.

Re:What I'd like to see is

[catch23]

Unless this is humor, don't think screenshots will be of much help... not sure how you'd post of screenshot of the new double buffering implementation :-P

Re:What I'd like to see is

[Anonymous Coward]

parent has anger problem

Re:What I'd like to see is

[Anonymous Coward]

Parent has no sense of humour

Re:What I'd like to see is

[Anonymous Coward]

How typical to blame your parents...

Re:What I'd like to see is

[Anonymous Coward]

Did you talk to your parent about it?

Re:What I'd like to see is

[nitehawk214]

Just post the screenshot twice.

Disclaimer on the url "we would LIKE to" have in..

[Assmasher]

...the next version.

Not quite the same thing as "this is in the next version."

Re:And as usual ...

[chkorn]

You mean java is slow?
Yes. Sometimes it is.

But hey! With such a codename it MUST be much faster ;)

Re:Java Desktop

[Lysol]

First off, no one said it's what we need. And regardless if you or I feel there might be no need for it (I personally use it daily), there are plenty of shops out there that do.

And second, they're addressing a significant issue with Swing which is its pokyness. This is going head on with SWT , a 'feature' that Eclipse people have enjoyed for sometime. This also signifies Sun throwing in the towel on their whole Swing widget abstraction, abstraction, abstraction mantra in favor of using the native OS rendering widget facilities. This has been a major Java gripe for some time; why can't my Windows Java app look like a Windows app and why does it have to be do damned slow?!

Should be interesting to see how these features/additions play out. Also, looks like Swing apps are finally getting native aa font support. This will please many as the text rendering in Java apps is still in the Windwos 2k/GTK 1.x days..

SWT

[Yag]

Java must embrace SWT and start doing GUIs in a fast, portable, native way. SWING is slow, redundant and ugly. IBM knows the right way, SUN should follow them or surrender to .NET (both windows and mono have NATIVE widgets stuff).

Re:SWT

[mark-t]

If you didn't RTA, you may not have noticed that the *FIRST* thing on their list of improvements was improving the native look and feel for both the windows and gtk platforms.

Also, Swing integrates well into the rest of Java, including Java2D, where SWT does not.

Re:SWT

[arudloff]

Swing is generally slow because developers don't take the time to learn how to use it -- they end up overloading event listeners instead of using SwingUtilities to offload the logic onto the SwingWorker thread..

It's not so much of a speed issue as it is a visual response issue.

Here's an excellent presentation on how to go about coding swing properly...

Re:SWT

[omicronish]

If you didn't RTA, you may not have noticed that the *FIRST* thing on their list of improvements was improving the native look and feel for both the windows and gtk platforms.

But how close is it to the native Windows look? I've found that whenever someone does custom widgets that tries to emulate the native look, there's always something missing or slightly different that produces a disconcerting GUI feeling. Maybe a lot of people don't notice, but I'd rather it look completely different than almost the same but with quirks. Eclipse is good in this manner. It looks very nice and fits right in with other Windows apps.

Re:SWT

[iwadasn]

Wow, interesting? This is a troll. Swing already uses hardware acceleration, and you can't really tell the difference on most apps (in my experience) between swing and SWT.

Yeah, SWT, it's like swing but without all that pesky portability and inherent safety. That's exactly what java needs, I demand more buffer overflows. :-)

Re:SWT

[RzUpAnmsCwrds]

"I've found that whenever someone does custom widgets that tries to emulate the native look, there's always something missing or slightly different that produces a disconcerting GUI feeling."

What about Firefox? With the Qute theme, it's pretty damn hard to tell that it's not a native app.

Re:SWT

[SlightlyMadman]

Um, it looks like you didn't RTFA either. They claim they will actually be using the native API to render the components in Microsoft and GTK.

And if you'd rather it look completely different so that it doesn't bug you, that's what the "Metal" L&F is for.

Re:SWT

[tim256]

That's the reason that I use Swing. However, SWT can help to build some sweet apps. Take a look at the code for bittorent client Azarius at www.sf.net. They really have done a great job at making a java app seem like a native app using SWT.

Re:SWT

[csnydermvpsoft]

What about Firefox? With the Qute theme, it's pretty damn hard to tell that it's not a native app.

Firefox is a native app.

Re:SWT

[noamt]

The problem with SWT is that I must somehow distribute it with my application. Is there an easy way to do it, while keeping my application cross platform (like a regular Java application)?

Re:SWT

[Anonymous Coward]

Very close. In fact, it uses the Windows XP themes. The only drawback is if you turn themes off (stop the service), you still get the playskool buttons in your java app unless you changed the theme before turning the service off.

Re:SWT

[metamatic]

Also, Swing has usable documentation available for free, whereas SWT apparently does not.

(I've never managed to find it.)

Re:SWT

[anti-trojan]

The poster means that it is not using native OS widgets but depends on its own XUL controls.

Re:SWT

[Anonymous Coward]

Technically, IE's controls aren't even "native" either. There were actually some minor visual differences (like single-pixel) that they ironed out later. On XP, it calls the theming API to draw the controls, so they do look exactly the same, but their logic is still all done in IE.

The exception is listboxes, which are native controls. They considered it too hard to deal with controls that changed their size like dropdowns do when expanded, and just punted and used a native control for that. You can even notice this effect in IE when you navigate pages on a loaded-down machine -- the listboxes are either the first or last thing to disappear, but it's not at the same time.

Re:SWT

[omicronish]

Actually, if you take a look at the article they mention using "Microsoft's API for rendering portions of components", which isn't the same as using Win32 widgets directly. Sure, they may look the same as Win32 widgets, but I'm willing to bet I can find behaviorial differences between their implementation and Win32 controls.

new feature request

[geekschmoe]

I was thinking they should add a new feature like not such random sluggish responsiveness in all java GUI apps on *nix machines.

JAVA - the little train that could

[IAmTheDave]

This is downright stupid. How long, exactly, has JAVA been in existance? YEARS. It should never have taken such a mainstream language so many many years to have such basic features in the UI package. We're supposed to ooh and aah over this like it's exciting, breaking, important news. This is JAVA catching up to 10 years of simply horrible UI design (and other features.)

Re:JAVA - the little train that could

[hanshotfirst]

And how long did it take BASIC to get this?
When is it coming out for FORTRAN and COBOL?
10 years is still young as far as languages go.

Re:JAVA - the little train that could

[mattgreen]

I concur, Java pretty much missed the boat for desktop apps. Not that I mind - I hate how they refuse to adopt native widgets, instead pushing their own cheap imitations that lack all the keyboard shortcuts, font anti-aliasing, and solid feel that native widgets have. Most stuff doesn't use SWT, either. Between the horrid UI and a language that loves to hamstring the programmer, I have to say good riddance.

Re:JAVA - the little train that could

[Decaff]

Not that I mind - I hate how they refuse to adopt native widgets, instead pushing their own cheap imitations that lack all the keyboard shortcuts, font anti-aliasing, and solid feel that native widgets have

Swing can have any keyboard shortcuts you like. Also, in Java 5.0, you can globally turn on antialiasing of all fonts in an application.

Swing can have a solid feel, as it can have any feel you like! There are a huge range of looks and feels.

I have to say good riddance.

You can say what you like, but Java use is growing, and has already overtaken C++ use in most job indicators.

Re:JAVA - the little train that could

[mattgreen]

Of course it can have all the keyboard shortcuts you want. The problem is, it doesn't completely conform to the platform it is running on -- it just tries to do a 'good enough' job. For example, focus behavior in a file selector dialog is mostly correct in Java 1.5 - but it isn't completely the same as the native Win32 dialog.

The problem is it inflicts the fact that it is its own 'platform' on us, the users. I want a program that behaves like all my other programs, not does its own thing because marketing idiots have an agenda to push. If I wanted cheap-feeling, half-assed GUIs I'd use KDE.

64-bit pointers

[tepples]

I guess the VM could use 64-bit pointers internally, but as you can't access memory directly in Java I don't know how the programmer would ever be able to tell.

Exactly. So why is Sun dragging its feet on porting its virtual machine for the Java language to the AMD64 platform?

Re:64-bit pointers

[Anonymous Coward]

You're joking?! The JVM has been available for x86-64 for a while now.

Re:64-bit pointers

[AKAImBatman]

Exactly. So why is Sun dragging its feet on porting its virtual machine for the Java language to the AMD64 platform?

What are you talking about?!? Go to http://java.sun.com and click on "J2SE 5.0". Then click on "JDK 5.0 Update 2" and accept the license agreement. Right there are four packages for AMD64. (Two for Linux, two for Solaris.)

Stop spreading FUD.

Re:64-bit pointers

[jjr23]

I had to stop using it because it crashed too often. It is there, but kinda flakey (all crash logs have been reported to sun)

Re:64-bit pointers

[Espectr0]

What are you talking about?!? Go to http://java.sun.com and click on "J2SE 5.0". Then click on "JDK 5.0 Update 2" and accept the license agreement. Right there are four packages for AMD64

Sadly, there is no 1.4 version, which is the one i need/want. Only for the dead IA64 platform

Re:64-bit pointers

[Anonymous Coward]

Whyever would you bother with 1.4 when 1.5 is out?

1.5 is where all the good 64-bit support was added anyway. I don't know of any significant 64-bit gaps with 1.5.

Also for the original poster on this thread, I'd think that if you're looking for easier Altivec access that you're already on a Mac and thus could write code in something else and use its Java-ObjectiveC bridge. On the other hand, JNI is really pretty easy -- considering the low-level bit-twiddling nature of this sort of thing.

Re:64-bit pointers

[AKAImBatman]

What's wrong with 1.5? It should be fully compatible with 1.4. Just make sure you're looking in the 1.4 JavaDocs. Also, you may need to add "-target 1.4 -source 1.4" to the javac parameters.

Re:64-bit pointers

[Espectr0]

Because:
*1.4 works fine.
*Mac version is 1.4
*No java plugin on 1.5 for amd64
*Eclipse's stable version needs 1.4
*Java 1.5 sucks, because of bad implementations of stuff like generics. See here for info.

Re:64-bit pointers

[Juergen Kreileder]

Sadly, there is no 1.4 version, which is the one i need/want.

Blackdown has a J2SE 1.4.2 for AMD64. (Sun's 1.5 for AMD64 is based on that.)

Re:64-bit pointers

[AKAImBatman]

*1.4 works fine.

I thought you just said that 1.4 doesn't work on AMD64?

*Mac version is 1.4

So?

*No java plugin on 1.5 for amd64

But how does not using 1.5 fix that?

*Eclipse's stable version needs 1.4

It should work just fine with 1.5. The 1.4 source level means that the IDE is setup to work with the 1.4 language features and that it won't support stuff like Generics.

*Java 1.5 sucks, because of bad implementations of stuff like generics. See here for info.

So ignore it.

You seem to be under the impression that 1.5 is incompatible with 1.4. Nothing could be farther from the truth.

Re:64-bit pointers

[pivo]

From your link: I haven't used it a lot myself, thankfully, but to me it seems too complicated

Wow, now that's going to be some really valuable criticisim.

Re:64-bit pointers

[Espectr0]

I thought you just said that 1.4 doesn't work on AMD64?

No, i said there was no amd64 port of 1.4. I am using 32 bit 1.4 for development.

I also use mac, and guess what, i want to use the same version on all my boxes

You seem to be under the impression that 1.5 is incompatible with 1.4. Nothing could be farther from the truth.


No i am not. I don't need 1.5 right now, so why upgrade?

Re:64-bit pointers

[Espectr0]

(Sun's 1.5 for AMD64 is based on that.)


Really? That is interesting. On all benchmarks i have seen, blackdown is the slowest of all JVM's. I guess the amd port should be good if Sun used it, or otherwise they just wanted to get any version amd64 compatible. I have always stayed far away from blackdown because of this, but really haven't tested it with servlet development, which is what i currently use.

Re:64-bit pointers

[Juergen Kreileder]

Really?

Yes, I did the 1.4 port and helped Sun integrating it into their 1.5 codebase.

That is interesting. On all benchmarks i have seen, blackdown is the slowest of all JVM's.

There are quite a few old benchmarks on the net which compare Blackdown Java using the Classic VM with Sun Java using the HotSpot VM. That's an unfair comparison (at least performance-wise).

If you have a benchmark that compares the two VMs in a similar setup (e.g. Blackdown 1.4.2 HotSpot Client VM vs. Sun 1.4.2 HotSpot Client VM on the same machine) and Blackdown loses, then please mail me a link.

Our tests say, that our version is always at least as fast as Sun's version. For some things (e.g. Java2D operations) our VM is noticeably faster.

(Note that the AMD64 HotSpot VM has no Client mode. So if you compare it to the x86 version, make sure you enable Server mode for the x86 version too.)

I guess the amd port should be good if Sun used it, or otherwise they just wanted to get any version amd64 compatible.

It's faster than the 32-bit x86 VM on the same machine in almost all benchmarks.

Re:64-bit pointers

[Espectr0]

If you have a benchmark that compares the two VMs in a similar setup (e.g. Blackdown 1.4.2 HotSpot Client VM vs. Sun 1.4.2 HotSpot Client VM on the same machine) and Blackdown loses, then please mail me a link.

You are right, the benchmarks i saw are old. I don't really understand what the blackdown project is about, since other than having ports (the most useful would be the ppc port since java on mac linux is only done otherwise by ibm). The most recent java benchmark i have seen is here yet they don't address blackdown (but it says it was evaluated)

You guys need more marketing :) How about publishing those benchmarks? Or would that break a NDA or something?

Re:64-bit pointers

[Juergen Kreileder]

the most useful would be the ppc port

We're working on HotSpot for ppc and ppc64.

You guys need more marketing :)

Sponsoring would be even better :-)
That would allow me to work fulltime on the ppc port.

How about publishing those benchmarks? Or would that break a NDA or something?

For some, yes. For others I'll put some results on our site after the next release.

Re:64-bit pointers

[DickeyWayne]

OK, I haven't checked lately (right now, I'm on a dial-up machine, so I'm not going to do anything extreme, like check facts before I post), but when I got an AMD-64 computer, and downloaded both the 1.4.? SDK and JRE, *NEITHER* of them had a browser plugin. No documentation, no excuses, it just wasn't there.

The 32-bit plugin (as well as Flash's 32-bit plugin) don't work with 64-bit Mozilla or Firefox, so I have a separate 32-bit Firefox executable, that I use for java and flash sites. It runs noticeably slower than the same app compiled for AMD-64 though.

If v1.4.2 for Linux, on AMD-64 has browser plugins, that would be welcome news to me.

Re:64-bit pointers

[AKAImBatman]

Why the fixation on the browser plugin? It's not a very useful thing to have. Core Java support is far more important for running applications and servers.

If you really need the plugin, then you need to go to the development branch. i.e. Blackdown. :-)

Re:64-bit pointers

[Anonymous Coward]

> I don't need 1.5 right now, so why upgrade?

For 64-bit support?

Localizability

[tepples]

but I like to position the elements where I want them, and not how some layout manager feeld they will will go best.

Thing is that "some layout manager" will know about the different conventions used for different human languages when it comes time to localize your software. Pixel layout is dead because different languages use different numbers of letters to spell the same thing. And in Israel and the Arab world, text in the local languages reads from right to left.

Re:Localizability

[VolciMaster]

different conventions used for different human languages when it comes time to localize

This only matters, though, if you intend to localize. Everything I've written has had no reason to be localized. Also, I spose we might want to remember all of the oriental languages that read right to left, and in columns.

Re:Java Desktop

[REggert]

I'm no Java fanboi, but these are some the classical advantages of Java over other languages:

• The compiled code is completely (well, almost) platform-independent, eliminating the need to port or even recompile code when moving between platforms. This can be especially handy for GUI's, as it gets around the problem of different windowing systems having their own mutually exclusive API's. Write and compile your interface once, and it can be run on any machine that has a JVM installed, whether it be Windows, Mac, XFree86, or whatever.
• It's ALMOST as fast (and in many cases just as fast) as C code. Additionally, it compiles much faster than C, though C binaries make up for it with substantially shorter load times (Java has been improving in this regard recently, however).
• The language is designed to avoid some of the "problems" in C and C++.
• Java provides free (in terms of effort) garbage collection, which (usually) prevents memory leaks.
• Java applets can run in web browser. This allows websites to provide visitors to their sites with custom mini-applications to provide various functionality or visual effects. One of the major benefits to this (especially when combined with the use of application servers) is that a large organization can install all their software in a central place and allow its users to access it from any machine just by using their web browsers.

There are others, but these are the ones that immediately come to mind for me.

I'm a C++ coder myself, but I do appreciate Java's value for certain situations.

Sun actually listening to developers-java.net

[acomj]

I've been on the java.net site.>/a>

Its a good mix of Sun developers and java users. I'm thinking of jumping back into java and been poking around that site to see what is new.

Its not all netbean either, Eclipse is giving good billing to.

The .net suffix is either coincidence or very ironic.

Re:Sun actually listening to developers-java.net

[AKAImBatman]

java.com is the user's site that plays up stupid mobile games and the like.

java.net is the "Network of developers" who are creating useful (and useless) software.

Re:Sun actually listening to developers-java.net

[brandonY]

I think you misunderstand. He was not being critical to Sun or Java when he suggested that java.net is an ironic name.

Re:Sun actually listening to developers-java.net

[AKAImBatman]

No, I understood perfectly. I was just providing a bit of info on the origin of the name. :-)

Security

[tepples]

as soon as I find out something's written in Java I can immediately ignore it

Then which web games do you play? Do you really want to use ActiveX to load web games written in native Win32 code when ActiveX lacks the sandbox capability of the Java platform?

Re:Security

[Kazoo the Clown]

I don't play games on the web-- when I play games I play ones specifically designed to run on the hardware I have-- because the resultant experience is far better.

Years ago I bought an Atari 800. There were games available ONLY for the Atari 800, and some that were available both for the Atari 800 and the Apple II. Guess which ones were better on the Atari 800? The ones specifically designed for the platform, where the authors could take advantage of all the special features that only the Atari had.

Suppose for example, you have a Mac. Why would you buy a Mac, if not to run things that the Mac was uniquely good at doing? How many of those things are going to run at all on a PC? How many are even going to run *as good* on a PC as they do on a Mac?

Re:Security

[Anonymous Coward]

A person that doesn't play Java web games has to use ActiveX games? How about Flash? A great deal of online games now are Flash rather than ActiveX or Java, and since Flash plugins have been developed for multiple platforms, the games are as portable as Java games.

The only instance I can see where someone would have to use Java games would be for some Palm/Cellphone games, but J2ME can't really be compared as far as footprint and other problems that Java causes on desktops.

Is it GPL?

[Anonymous Coward]

Or any kind of OSI approved license?

Re:Java Desktop

[Anonymous Coward]

You have never written a large multi-platform piece of software, have you? Learn to code something a bit more complex than Hello World before you call other people slackers for not going through the hell that is making a piece of software written in C/C++ work on multiple platforms, all from the same source.

Obviously Azureus must be crap by your standards too.

64-bit support is done!

[Wesley Felter]

64-bit Java VMs have been available for SPARC64, PPC64, and AMD64 for ages.

Sounds great...couple more things...

[Anonymous Coward]

Those all sound like very good enhancements. I would get rid of the crappy "Ocean" theme for the default. It's really no better than the much hated Metal. It sounds like they have worked to get the native look and feel much improved, but I would still like to see a *much* nicer default since it seems like that's what so many developers end up using.

The other thing is major Java Web Start improvements. I've tried to use it and it sucks majorly. Basically you end up having two different versions of your application, one that works with WS and one that works as a native application, which stinks from a QA perspective. Furthermore, while I know there are major security considerations when clicking on a program from the web, something has to be done about the dialog boxes. My own parents wouldn't run the application I wrote because it said "it is strongly recommended not to run this program". Then, there are all sorts of other weird dialogs like "would you like to enable desktop integration" that never works, and also sometimes gets put behind the application so you can't see it while it's still modal.

Otherwise, they REALLY REALLY need to get a better browser component. Here's what I suggest:

http://jrex.mozdev.org.

Make this a part of the standard JRE! *It will be the most significant and best single thing that ever could have been done to java*. Imagine having a gecko rendering engine whose DOM is fully controllable from Java on every major platform that the JRE supports! Imagine being able to use a gecko widget inside any GUI com\ponent! That would be how to step up and really innovate.

Finally, provide better desktop integration. Interact with the system tray. Allow "always on top" behavior. Include proper fonts (which it sounds like they're doing).

All in all, though, it sounds like there are some definite improvements, but they need to leap frog, not just catch up. Taking the JREX.MOZDEV.ORG concept and running with it is just how to do it.

Re:Sounds great...couple more things...

[mccalli]

Basically you end up having two different versions of your application, one that works with WS and one that works as a native application, which stinks from a QA perspective

Why? I'm genuinely curious here - I also use WebStart, and I don't need to end up with two versions of the code. Be interested to hear what's restricting you.

Cheers,
Ian

Re:Sounds great...couple more things...

[Anonymous Coward]

Check out JDIC (https://jdic.dev.java.net/)

Whats the point now

[fishlet]

I can count the Java desktop apps I know on one hand. I'm sure theres more but it's pretty much a dead topic for most developers since Swing has sucked for so long. The more I think of it, I see lots of problems with the whole Swing API/programatic approach to building a GUI. Why can't it all be XML based where you just design your GUI elements in document form and load it in.

On a side note, I'm not very happy with JSP these days either. I've been doing dotnet development for a year now and love the idea that each page has an instance of a class behind it. I tried to get back into JSP again lately, but was disgusted to rediscover that all instances of a page are sharing the same object, which is very frustrating and anoying after having done it the other way.

Re:Whats the point now

[nogginthenog]

But I can count the number of .net desktop apps I know on 1 finger!

Re:Whats the point now

[hibiki_r]

Why can't it all be XML based where you just design your GUI elements in document form and load it in.

It can be done, and it is done by those doing Swing work effectively. With tools like JFormDesigner, you can just create resources that are loaded in real time by your swing app. Add a binding framework, and building GUIs in Java becomes as easy as making GUIs in pretty much any other language.

Re:Whats the point now

[thelexx]

JSP sucks. Check out Velocity at the very least.

Re:Whats the point now

[bigmouth_strikes]

> all instances of a page are sharing the same object, which is very frustrating and anoying after having done it the other way.

What are you talking about ? Two instances of a JSP don't share objects. They are both different instances of the jsp servlet class.

Re:Whats the point now

[mrroach]

On Linux, I use muine and tomboy regularly. F-Spot is one of the best rated apps on gnomefiles. I can't think of a single java desktop app for Linux...

-Mark

Re:Whats the point now

[mmusson]

Or Tapestry.

Re:Whats the point now

[fishlet]

Hmnnn, perhaps I'm missing something but that's not the way I understood it. Here is a page that I think backs up my original statement:

http://www.imagescript.com/atg/articles/jsp_j2ee /j sp_declarations.htm

each web server thread calls on the _jspService method but the servlet behind the JSP page is made only once. If you add your own functions and variables outside of the scope of the _jspService method all that stuff seems to get shared between threads running on your web server.

Re:Whats the point now

[FatherOfONe]

Look at JSF. I think it rocks.

Good luck getting .NET apps to run on anything except Windows. Heck good luck getting them to run on anything but the latest version of Windows with all the latest patches. Now if that isn't a concern and you don't mind all the limitations Windows AND not being tied to one vendor, then .NET may be cool. Heck if you don't mind being locked in to one vendor there are a lot of cool tools out there.

Re:Whats the point now

[reverius]

Azureus
Eclipse
JEdit ... and those are just three that I use -daily-.

Re:Whats the point now

[Master Of Ninja]

Why can't it all be XML based where you just design your GUI elements in document form and load it in.

That is one suggestion which needs to be sent to the team working on the new Java. This would make things sensible. It would be even better if they used an XML syntax similar to Mozilla's XUL or even the stuff WxWidgets uses - this would (hopefully) make porting a breeze.

Re:Whats the point now

[ShinmaWa]

If you add your own functions and variables outside of the scope of the _jspService method that is stateful, it sounds like the application architecture is fundementally flawed.

The JSP/Servlet paradigm was always intended to be transitive and stateless, thus forcing (as much as possible) applications into a tiered MVC-like architecture. If you are trying to put stateful information in your JSPs or Servlets, then you need to take a hard look at your architecture and consider redesign/refactoring.

From the article...

[kjeldor]

Where possible, we will add pointers

Wow, the beginning of that sentence sure scared the hell out of me. In my opinion, asterisks should be for multiplication only.

Re:Java Desktop

[Anonymous Coward]

If you don't want OS Abstraction then why not just use AWT?

phew...

[Anonymous Coward]

I dont know why... but when i first read the article i thought it said..

"and improved unemployment capabilities."

Ahh.. the life of a java developer

other languages

[Anonymous Coward]

C and C++ would never have become popular if they had come out without such basic features as a UI library.. ... oh..

emm..

hmm?

Java Gaming

[Anonymous Coward]

Seriously, where are all those Java games which sun keeps talking about? I see a million games written in Flash, but hardly any games written in Java. How come Java isn't better than Flash?

Re:Java Gaming

[Anonymous Coward]

You don't get many games for cellular phones written in Flash.

Re:AWT?

[BridgeBum]

Abstract Windowing Toolkit. Really, is google so hard?

Here's some info.

Apple on their own to make it not suck

[Anonymous Coward]

I love how Apple and Mac OS X are not mentioned anywhere at all.. Java has been welcomed pretty nicely to the platform - although you've probably never heard of WebObjects, among other things - and Sun could really care less about a platform that *wants* good Java.

Re:Java Desktop

[arudloff]

Simple really-- some programmers are lazy. They can't be bothered with optimizing their code for individual platforms.
Or they don't have the time to write something for multiple platforms. Time-to-market is directly tied to your ROI..

Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once? Especially if I'm going to sell just as many copies for the same exact price in either scenerio -- the java route increases my return.

Re:Java Desktop

[Anonymous Coward]

It's ALMOST as fast (and in many cases just as fast) as C code.

On every OS you mean or just on the most used one?

Re:Java Desktop

[Anonymous Coward]

• The compiled code is completely (well, almost) platform-independent... Eliminating many powerful feature possibilities because one has to be concerned that this or that doesn't exist on this or that platform.
• It's ALMOST as fast (and in many cases just as fast) as C code... in someone's dreams maybe. If you honestly believe this, you've totally drunk the Java Kool-aid. Don't worry, the mothership's on its way
• The language is designed to avoid some of the "problems" in C and C++... like giving the programmer too much power - instead, trapping them in a weak little sandbox where nobody's supposed to be able to hurt themselves? wimps.
• Java provides free (in terms of effort) garbage collection... which is fairly inefficient and sucky, and is there because the current generatin of Java Weenies are too lazy to write their own
• Java applets can run in web browser. This allows websites to... upload all sorts of crappy advertising and malicious spyware, costing corporations $millions and causing computer novices around the globe to waste countless hours of their computer geek buddies time to dig them out

[lie]Not that I've got anything against Java [/lie]

Java & Longhorn

[slasho81]

I'm very excited with all the improvments Java is going through, but I'd hate to see it all being completely missed by the general public and web application developers if Microsoft won't include the JRE and Java Plug-in in Longhorn.

Anyone knows what going on with this issue?

Re:Java & Longhorn

[FriedTurkey]

I doesn't matter. Most Java these day is at the middleware level running in application servers. Most desktop Java software will install the JRE you need for it in the installer program. Even internet Java applets can install the JRE you need. The JRE installed with Windows would be outdated in two months.

Re:Java & Longhorn

[slasho81]

I agree about desktop and server software, but I think the most important aspect of Java could have been the applets. These could make the www a true software platform. About the JRE being outdated - it's not a problem with modern JREs. They update themselves.

The problem with the web is the lack of standards makes deploying webapps a nightmare.
The combo of Flash/DHTML/JavaScript/XML with IE/Mozilla/Firebird/Safari/Opera each of different version and platform, of course, is impossible for doing productive development on the web for the wide public.

Re:Java & Longhorn

[Anonymous Coward]

having programs update themselves can be a very bad thing, often times you have a working program, it updates itself, and then it no longer works, this is bad, especially because you could have no idea what caused it.

Re:Java & Longhorn

[WoTG]

MS doesn't package it in XP now, does it? From the machines I've seen, I _think_ Dell/IBM/HP choose to install a JRE for their customers. Smaller whitebox shops are on their own I guess.

Re:Java Desktop

[DarkSkiesAhead]

Simple really-- some programmers are lazy. They can't be bothered with optimizing their code for individual platforms ... as soon as I find out something's written in Java I can immediately ignore it

Sorry, but that's a pretty ignorant attitude. Judging an application soley on being java-based is a poor method. Rather, you should ask if the developing language is appropriate for the task. If someone told me they wrote a graphically intense FPS in java I would be suspicious. But, if the app only needs to be light and portable java may be a good choice. It allows for very easy control of how the application looks on multiple operating systems. A good example of a nice-looking java app with no speed issues is Limewire. It runs quickly, works well and can be updated more efficiently than if they had used a graphical toolkit for python or C. Not that anything is wrong with chosing python or C either. It entirely depends on your application requirements and development resources. Brushing off all apps written for the JVM (or any development kit) will cause you to miss out on a good app sometime.

As someone who develops Java desktop apps...

[ChiralSoftware]

I would like to see three things:

First, it seems like KDE/Qt has more momentum than GTK on the desktop. Qt apps look better and are more integrated with eachother. Suse is the dominant desktop Linux distro and Suse is KDE-oriented. I'm glad that Java is going to be using native GTK for rendering, but what I would really like to see is native Qt. Maybe they could create some kind of interface to make it easier to plug in different rendering systems? Maybe they could open source Java and let the community take care of it? Maybe they don't care because desktop Linux is only about 5% of the market anyway? But still, it's something I would like to see.

The second thing they need is a "SwingLite", or some easier way to do common things. For example, it is very common to need a text field that allows the user to enter a number, but not text. Should be easy, right? This is the code I have to use to do it:

formattedTextField.setFormatterFactory(new DefaultFormatterFactory(new NumberFormatter(NumberFormat.getIntegerInstance()) ));

That's just wrong. I should be able to say:

formattedTextField.setFormat("d+");

or maybe:

formattedTextField.setFormat(FormattedTextField.IN TEGER_ONLY);

The above example, involving two different factory classes to just get the field to accept integers only, puts a high burden of knowledge on the programmer, and Swing is full of stuff like that. It's great that the power is there because I can write my own hierarchy of text formatting factories and objects that enforces correctly-entered Sandhi rules, but that doesn't come up very often, and what does come up very often is having to enter a plain old number, date, currency value, that kind of thing. And I'm just using this one example, but this kind of over-design is all over the place in Swing.

The final problem that they have is putting emphasis on plugable look and feel. Application developers shouldn't get to decide the look and feel of their apps. That should be determined by the desktop environment. Pluggable look and feel is not a feature; it is a bug. It should be deprecated and removed.

----------
Educational software

Re:As someone who develops Java desktop apps...

[Anonymous Coward]

The problem with QT. And the reason it's not used it other things that use native widgets (SWT, wxWidgets, etc.) is by using QT you mostly limit your target audience to non-commercial applications because of QT license.

And don't give me that crap about buying QT. I own a software shop and QT is damn expensive even for us commercial shops. A MSDN subscription is a much better value and 1/3 the price.

Re:As someone who develops Java desktop apps...

[RzUpAnmsCwrds]

"Suse is the dominant desktop Linux distro and Suse is KDE-oriented."

No, it's not. Have you heard of "Novell Linux Desktop", the product that is intended to replace SuSE on the desktop? It's GNOME based, which is understandable because Novell also purchased Ximian.

RHEL and Fedora are also GNOME-focused, as is Ubuntu.

"Qt apps look better and are more integrated with eachother."

According to whom? I personally love the look and feel of GTK+, and I don't think that there's any problem with integration.

"The second thing they need is a "SwingLite", or some easier way to do common things. For example, it is very common to need a text field that allows the user to enter a number, but not text. Should be easy, right? This is the code I have to use to do it:"

Welcome to the world of Java. If you don't like the object-oriented Kool-Aid, you're probably using the wrong language. BS like that is why I use Python/PyGTK for programming on Linux.

Re:As someone who develops Java desktop apps...

[aCapitalist]

Despite the technical superiorty of Qt Sun will not use it to draw widgets because (A) Sun uses Gnome for its desktop and (B) the dual-licensing scheme of Qt.

And I don't know where you get this information about KDE/Qt having more momentum. If anything, it's the other way around. Sun, RedHat, and Novell (the 3 biggest Linux shops) are all going with Gnome. Yeah, I know about Suse and KDE, but if you look at the resources being invested it's all Gnome/Mono.

Until Trolltech gets bought out, the license issues surrounding Qt are unlikely to go away.

Re:As someone who develops Java desktop apps...

[Hulfs]

What's wrong with doing:

new JFormattedTextField(NumberFormat.getIntegerInstanc e());

Seems to work fine for me. Uses the default locale's integer formatter. See Sun's Tutorial

Re:As someone who develops Java desktop apps...

[Ars-Fartsica]

First, it seems like KDE/Qt has more momentum than GTK on the desktop.

based on?

Suse is the dominant desktop Linux distro and Suse is KDE-oriented.

Suse no longer exists, it has been acquired by a company focuing on GNOME.

Re:As someone who develops Java desktop apps...

[Anonymous Coward]

You are right. I am thinking in terms of NetBeans which lets the developer set the properties of a JFormattedTextField, and the property that can be set is the formatter factory, rather than putting a formatter into the constructor. NetBeans is indispensable to me for developing Swing apps but this is a quirky way to have to set a format.

Re:As someone who develops Java desktop apps...

[Anonymous Coward]

> formattedTextField.setFormatterFactory(new DefaultFormatterFactory(new NumberFormatter(NumberFormat.getIntegerInstance()) ));

Bloody hell, that's horrible.

I have no problems with Java the environment. Java the language I just don't want to touch with a bargepole.

Re:As someone who develops Java desktop apps...

[Anonymous Coward]

And don't foget about Ubuntu

Re:As someone who develops Java desktop apps...

[Zephiris]

I don't really think that a Qt version would ever really get off the ground. Even if Sun did it, chances are it would be relatively unmaintained, and would lag behind compared to Gtk+ version. Most apps love GTK+ or 'KDE widgets' to death, even in places where nice, clean Qt widgets would be much more appropriate (and would be faster, to boot). The whole GTK+ file selector, now improved without text input, or remembering where you 'were', and without any way to input actual text or select simple things is a prime example of moving in the wrong direction instead of actually paying attention to users! (I can't even do any nominal file operations, like rename, from a GTK+ file selection dialog, can't simply change directories to something Not In The List). It's just...unspeakably horrible. ;_;

It would perhaps be heavy-handed, but Qt should probably basically make a 'GTK+' compatibility library which translates GTK+ widgets/functions/whatnot to Qt equivalents for user-end applications.
That way, we could all use the Happy Qt Beauty/Speed (particularly for how customizable Qt look/feel is), without needing to care if an app was written for the latest GTK+ or not...which tends to be several step backward in usability, design, and aesthetics, IMHO.

Re:As someone who develops Java desktop apps...

[Anonymous Coward]

Actually, can't you just do

new JFormattedTextField(new Double(0.0));

and in 5.0 (with autoboxing)

new JFormattedTextField(0.0);

?

Seems like they are really improving things

[FedeTXF]

I use many java desktop apps in my day to day tasks on my linux desktop. There is no better way to connect to multiple databases than Squirrel , No better way to code in Java than NetBeans and no better editor than JEdit

I think Java 5 already has great desktop features like shared class data, and 2D acceleration for 2D acelerated hardware (which I don't have yet!).

Re:Seems like they are really improving things

[nabil_IQ]

No better way to code in Java than Eclipse

Re:Seems like they are really improving things

[Casca]

Really? Wow. Try using something like CiscoWorks. I used to use their native X application which worked great, was really fast, and I don't remember it ever crashing. Now I have to live with this complete turd of an application that runs like a dog on hardware 5x as fast as what the old X stuff ran better on, worry about which version of the JVM I've got loading the app because half the apps want a specific version, and have to restart the app because it crashes constantly. Maybe its not Java's fault, but the fault of poor programming, but I've pretty much had it with these bullshit apps.

Re:Seems like they are really improving things

[Anonymous Coward]

There is no better way to connect to multiple databases than Squirrel , No better way to code in Java than NetBeans and no better editor than JEdit

Too easy: Toad, Eclipse, and Emacs. There's plenty of room in between your choices and mine for others.

Re:Seems like they are really improving things

[Dan-DAFC]

Personally, I find using Emacs typing only with my nose and having the monitor switched off a better way to code in Java than using Eclipse - but I seem to be in a minority.

IntelliJ IDEA, both hands and a well adjusted LCD display are even better.

Re:Seems like they are really improving things

[Anonymous Coward]

I am more of the described emacs user than anything else. Everytime I have have tried Eclipse I just get the impression that it needs more work. Found it funny too how /. recently had a story about eclipse revolutionizing the idea of editor plugins.

Re:Java Desktop

[Anonymous Coward]

It's ALMOST as fast (and in many cases just as fast) as C code. Additionally, it compiles much faster than C, though C binaries make up for it with substantially shorter load times (Java has been improving in this regard recently, however).

Incredible, does this crap ever end. No, its not even in the same universe as C when it comes to performance. I can't name ONE Java application that doesn't suck utter arse when it comes to responsiveness. The much touted server peformance is also awful but is easier to hide behind mammoth hardware specs. Embedded Java -- slooowww. Seriously, put any Java application next to a C application and see the truth.

Re:Java Desktop

[Anonymous Coward]

"I'm a C++ coder myself, but I do appreciate Java's value for certain situations."
That is perhaps why you would never apprechiate Oberon.

Just checked out the latest build release

[Anonymous Coward]

I just checked out the latest build release of Mustang, Swing at least on Win32 seemed again snappier, the absence of the gray rectangle problem really made a huge difference, the guy now is faster on Windows (tested it on SwingSet2 and JEdit) than Firefoxs is.

But there still were minor annoyances in the Windows look and feel, mainly, the menus still are different to those done by windows (XP does dropshadows and transparency while being opened, Swing is flat) The file open dialog still has layouting differences, but besides that things start to look very good and fast. Cannot speak for Linux however and the Mac has yet to get a 1.5 release.

Re:Java Desktop

[MemoryDragon]

Actually Sun is not throwing in the towel, Swing has done an interesting approach no other Widget set has done so far. They basically went the way, of rendering the widgets still in software, but the underlying graphics layer is hardware accelerated if possible and the rendering data for the skins is directly parsed from the underlying OS skinning engine if present.

And Swing has gotten much faster that way. Swing has been already more than usable in 1.4 and I recently checked the latest 1.6/6.0 builds, and all I can say is wohaaa... The guy in 1.6 at least on Windows is very snappy. I have had running Firefox and SwingSet2 running side by side and SwingSet2 blew firefox away rendering speedwise.

What about XUL type layout?

[Anonymous Coward]

I wonder why they aren't having an XUL/XAML implementation?

Re:Java Desktop

[$1uck]

I don't want my java apps looking like windows apps. I want them as responsive. I like the ability to change look and feel. I just wish laying out the gui was easier and classes like swingworker (or the foxtrot stuff) was built in and more transparent.

Re:Java Desktop

[Anonymous Coward]

The language is designed to avoid some of the "problems" in C and C++... like giving the programmer too much power - instead, trapping them in a weak little sandbox where nobody's supposed to be able to hurt themselves? wimps.

You're picking your programming language because you think it makes you manly!?

**BARKING LAUGHTER**

Do we have news for you!!

I'd grind up netbeans

[FerretFrottage]

and suggest Eclipse or IntelliJ as a better java IDE.

Re:I'd grind up netbeans

[FedeTXF]

Eclipse on Linux is slow and bare bones Eclipse has way less features. I work with Eclipse on Windows at work since 2002 and it is great for teamwork (cvs support and all) but for my personal projects on Linux, NB gives a way better deal. I tested NB 4.1 and it is way better than 4.0. I drool for the profiler working on J2SE 5.0 soon. Besides at home I use java 5.0's new features which Eclipse only supports partially in the 3.1 milestones.

Re:I'd grind up netbeans

[the eric conspiracy]

I was hot to try some of the Java 5 features so I installed netbeans 4.1. You have got to be kidding me. It's like Eclipse was three years ago plus unstable. It stays up about an hour on my R40 before croaking, and by croaking I mean blue screen, not some wimpy Java error.

Re:I'd grind up netbeans

[Anonymous Coward]

Wow, and I have the reverse experience between work and home: NB at work on Windows = slow, Eclipse at home on Linux = snappy. Plus, I use SVN integration at home. I'm in the process of moving to Eclipse at work.

Well, hardware may be to blame at work. I have a craptop there; a P4 3.0GHz adorns my desk at home. Think I enjoy developing at home more? :)

Re:java? what's java?

[whoisshe]

is that the language i used to care about before i discovered free and open source python?

yes, yes it is! you know, the language you used before python, which made programming free and fun again!

Re:Java Desktop

[dbretton]

Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once?

Because you'll end up coding 10 times anyway, at least according to John Carmack.

But then again, what the hell does he know, right?

What I want

[ToasterofDOOM]

Is stability, security, and more speed. OOo 2 beta is SLOW and most issues i have with it are Java related in some way.

Re:Java Desktop

[Anonymous Coward]

Wow Princess, make a polite post expressing your personal opinion of Java (which is less than glowing) and win TROLL mod points.

You know, as much as I dislike the Java language, what really kills me is the religious evangelism of the Java Bigots and Java Weenies out there.

Java is bloated, slow, and while people throw around lotsa nice terms like "scalability" and "enterprise", it's been my personal experience that anything written in java takes twice as much time to write, runs half as fast and uses 90% of the available memory and processor of the box hosting the JVM.

Re:Java Desktop

[Anonymous Coward]

I'm a girl, you insensitive clod!

Native Swing rendering - oxymoron?

[AttilaSz]

From the TFA:

Use Microsoft's API for rendering portions of components (5106661).

and

Use GTK API for rendering portions of components (6185456). After fixing 6185456 Swing components will use GTK's rendering engine...

ROTFL. After years of Swing fanboys bashing IBM for daring using native OS rendering for UI widgets in their SWT toolkit (in contrast with Swings alleged the-only-right-and-holy-way of drawing everything in Java in name of "Java purity"), they seem to have finally gave up the futile attempts to imitate native OS and Swing will now delegate part of its rendering to the *gasp* _native_ rendering engines. I really wonder how can it be noone in the Swing camp cries desecration... :-)

Re:Native Swing rendering - oxymoron?

[mmusson]

Swing lost the SWT war years ago.

Re:Native Swing rendering - oxymoron?

[lrucker]

Apple Swing L&F has always been using native widget rendering for the Swing L&F. Originally it used the AppearanceManager. I don't know what it uses now I've left.

Re:Native Swing rendering - oxymoron?

[Anonymous Coward]

Rather I think Swing was hurting, SWT came along, and now Swing is faster and better (except for perfect native emulation which I could care less about) than SWT. SWT was an idea whose time had come before it was available and gone shortly after it was.

Re:Native Swing rendering - oxymoron?

[Anonymous Coward]

It never was impossible to use the native APIs to draw swing component. Urban legend.

It was more a difference in the way to design. The swing guys decided to write an API, then get it to draw native like widgets - and, yes, they preferred to do the drawing in Java rather than go native, until now, it seems. Call it to-down.
The SWT guys looked at the native APIs and tried to come up with something that would fit them all - plus they seem to have decided up front that they didn't like swing, and so instead of putting their native code under it to try to replace it. Call it bottom-up.

Now for the difference in actual design. SWT seems to translate the app data into native format, whereas Swing keeps it in Java. So redrawing would be faster with former, but updates faster with the latter. I'm 1000 rows tables now. Of course you won't see a difference on a button.

Problems with Swing:
- it IS a complicated API. It may look java-easy. It is not. If you don't get it, and instead try to bend it to your ways, that's where problems begin...
- it is "slow": programs usually put loads of processing where it doesn't belong: the event thread. So the app is unresponsive because its retrieving data from the DB whereas it should be responding to clicks, whatever, while another thread does the heavy lifting.
- because so much stuff is done in Java, the emulation is imperfect, and there's a lag between when an environment evolves and when Sun or whoever updates the java components to match.

Problems with SWT:
- while it is faster in simple tests - let's create a big table and see how fast it scrolls - it is not intrinsically faster. On a real project you'll hit a wall at some stage. And then you'll have less leeway to fix it.
- because of the bottom up approach, there's a mismatch with the functionality of the native widgets sets.

And now for the myth-busting:
- Swing done right is not slow. But no company doing GUI intensive apps do them in Java. What you get is processing intensive apps with a GUI. And not enough effot is spent on the GUI.
- SWT doesn't look more native. Right now I have eclipse 3.1M6 running on my mac (and I'm a big fan); there's weird looking tabs; an empty line at the bottom sometime used for a progress bar; icons in the menus; there's an exit item in the file menu; the buttons labels are windowsy... Thing is looking native is much, much more than widgets. Widgets has not been the problem for ages.
- SWT is not magically fast. It takes half a sec for the eclipse menubar to show up, for instance.

Altogether, the real problem is that, for SWT or Swing, if an GUI is done right (okay, on windows and mac) nobody's gonna notice it's Java. If it's crap, somebody is bound to have a look around, sometimes notice it's Java. And then the belief engine is at work.

Re:Native Swing rendering - oxymoron?

[astro-g]

Does this mean I will be able to get native open and save dialogues?

Re:Native Swing rendering - oxymoron?

[AttilaSz]

I don't think so. Again, from the article one of the features is

Bring Swing's GTK file chooser up to date with recent changes to GTK's file chooser (5090726).

Re:Native Swing rendering - oxymoron?

[astro-g]

Damn, I want my custom places bar.

Re:Native Swing rendering - oxymoron?

[aCapitalist]

The only thing I disagree with you on:

SWT's widgets might not look "native", but it's fonts sure as hell do (because they are), and that's why I can't stand Swing

I don't care what "api functionality" Sun uses to get the native look-n-feel (or even care about it that much), but just get the fonts done right.

Re:Java Desktop

[FidelCatsro]

If i could pay a programer 1 USD an hour , i would be a very rich man , either that or in jail for slave labour.

Re:Java Desktop

[Kazoo the Clown]

You have never written a large multi-platform piece of software, have you? Learn to code something a bit more complex than Hello World before you call other people slackers for not going through the hell that is making a piece of software written in C/C++ work on multiple platforms, all from the same source.

No, in fact, I have been doing multi-platform development for around 20 years now, including client server, three tier, networked database and web applications. How much hell the programmers go through is not the issue-- it's a programmer's job to program, and if that's hell for you perhaps you should look for another job.

Re:Java Desktop

[LWATCDR]

1. You have obviously never written a line of code.
2. The Java programmers of this planet would like to thank you for becoming one of their users.

Re:Java Desktop

[Kazoo the Clown]

Why would I pay a programmer $1 an hour to code something for 10 hours on three different platforms, when I can pay him $1 an hour to code something once? Especially if I'm going to sell just as many copies for the same exact price in either scenerio -- the java route increases my return.

Exactly. But now think like a customer. Why would you buy a Mac and not a PC if you just wanted to run generic programs? Aren't you interested in looking for those programs out there that take specific advantage of your hardware investment? What is it about the best Mac programs that make you buy a Mac in the first place? As a customer, what do you care how hard it is to write code? Sure, you care how much it costs, but you may very well be willing to pay more for software that's better integrated with your platform. When I'm a customer and not a developer, that's the sort of customer I am. Consequently, if it's written in Java, I look elsewhere...

Re:Java Desktop

[Kazoo the Clown]

Brushing off all apps written for the JVM (or any development kit) will cause you to miss out on a good app sometime.

Ok, sure maybe I'll encounter something worthwhile one of these days. So far, everything I've tried was a nightmare to deploy though-- "JVM version hell" for the most part. Flash animations do a lot better in that regard at least-- they run on various platforms and I've never seen them complain about needing a specific version of a player (maybe they do, I've just never seen it), and EVERY time I've tried to deploy a java app I had to reinstall java with the "right" version for the app. Except for web-based Java that is, which has been mostly quirky and/or slow.

But alright, I admit it. I've been doing fine without Java for 20 years and am now a crotchety old curmudgeon. Maybe I just should have programmed everything in MIX...

Re:Java Desktop

[OiBoy]

If i could pay a programer 1 USD an hour , i would be a very rich man , either that or in jail for slave labour. That or you would be a major US corporation outsourcing to India or Russia.

Re:Java Desktop

[Anonymous Coward]

Carmack may know a shit-ton about 3d games, and low level programming. However, that doesn't necessarily mean he knows squat about anything else.

Re:Java Desktop

[Surt]

The compiled code is completely (well, almost) platform-independent, eliminating the need to port or even recompile code when moving between platforms. This can be especially handy for GUI's, as it gets around the problem of different windowing systems having their own mutually exclusive API's. Write and compile your interface once, and it can be run on any machine that has a JVM installed, whether it be Windows, Mac, XFree86, or whatever.

On the other hand, while text mode apps can run on many platforms, there are c compilers on even more platforms. Well written C will port much more easily to those platforms. And GUIs just look wierd when you try to run them on a different platform than you wrote them on.

It's ALMOST as fast (and in many cases just as fast) as C code. Additionally, it compiles much faster than C, though C binaries make up for it with substantially shorter load times (Java has been improving in this regard recently, however).

On the other hand, for many practical applications, java will turn out to be much slower than C. Particularly if your work relies on the performance of two key areas: 1) you write code that does a lot of interesting array access, in which case the lifters and such in the optimizer will fail you and you'll do 3 ops in java to every one in C when you access your array. 2) you copy application data from/to disk or over a network, an extra copy is required to move the data into an object's memory, and this cannot be done in bulk either.

On compilation, I don't know what planet you're working on, none of the java compilers hold a candle to the C compilers, but really, who cares about compile time, run time is what matters, and there indeed you get the joy of slow java startup.

Also, the java compiler has no support for conditional compilation, which hampers debugging support (and lots of other nice bonuses you get with a precompiler).

Java provides free (in terms of effort) garbage collection, which (usually) prevents memory leaks.

On the other hand, most large scale apps still wind up having to track down this sort of problem, and auto_ptr can solve this for you on C if you want.

Java applets can run in web browser. This allows websites to provide visitors to their sites with custom mini-applications to provide various functionality or visual effects. One of the major benefits to this (especially when combined with the use of application servers) is that a large organization can install all their software in a central place and allow its users to access it from any machine just by using their web browsers.

On the other hand, C apps can run in a web browser too, but granted, support is not as widely deployed by default.

Re:Java Desktop

[Anonymous Coward]

How much hell the programmers go through is not the issue

You're quite obviously bullshitting, because anyone who's programmed professionally will tell you that IS the issue. Making a project take much longer to implement and take literally twice as long to test really isn't a sensible option when you are paying people by the hour. If a piece of software doesn't require to be particularly fast, nor does it perform any low-level operations, yet needs to run on multiple platforms, then Java is the sensible option.

If you are writing database and web applications like you claim you are, then you of all people should know that Java is in many cases the sensible option.

Re:Java Desktop

[Retric]

Check out dbvis or Azureus before you talk down to java apps. Java makes networking and database code a lot easer to write which realy shines though on these apps.

From what I hear Azureus is about as fast as any C++ BT client but it adds a good UI and a lot more features than the av BT client.

As to dbvis I have been using it for a while at work and the free vertion works great. Now you want to show me a free / cheep C++ app that does the same things on OS X I will look into it untill then I am going to stick with dbvis.

Re:Java Desktop

[Anonymous Coward]

Nice mis-quote. He's talking about J2ME, which is not what the article is about.

Write a VM that doesn't suck...

[spywhere]

Demographically, it's clear that most Java VM's run on Windows. Why don't they write a version that works even half as well as Microsoft's VM did?
The first thing I do after building a clean XP Service Pack 2 (or 1a) machine is install the no-longer-available Microsoft VM. Then, I go to Sun.com to download and install... nothing.
If I work on a machine that already has the Sun VM, I install the Microsoft VM and set Sun's not to be the default Java engine for IE. I also get rid of the stupid f***ing shortcuts and update managers Sun loves to install.

Why didn't Microsoft just pay those assholes off and keep on making their own VM? It actually worked in Windows.

No plug-in on AMD64

[Anonymous Coward]

The AMD64 editions still does not provide a browser plug-in. Luckily, there is Blackdown.

Re:Java Desktop

[REggert]

Wow... you guys wasted no time bringing out the flamethrowers. ;-)

I'm not advocating Java, but the parent asked what it's good for, so I gave the most commonly cited advantages.

I still prefer C++ myself, unless I don't care about performance or need some specific feature of Java that I don't feel like implementing/obtaining myself.

No GridBag

[Anonymous Coward]

Some of you are complaining about GridBag and other layout managers. You have an excellent point.

To drop components just where you want and still have things resize, look at the UI builder called Foam. They have some videos at http://www.computersinmotion.com/ where you can see some pretty neat demos of Foam building some dialogs.

The dialogs get saved in XML which means one line of Java loads up and creates your layed-out panels!

Re:Java Desktop

[Anonymous Coward]

Why would you buy a Mac and not a PC if you just wanted to run generic programs? Aren't you interested in looking for those programs out there that take specific advantage of your hardware investment?

In that case, you won't even look at Linux/*BSD, because Windows is designed specifically for your x86 architecture, right?

That was a very silly comment you made earlier. I would recommend you stop digging.

Re:Write a browser that doesn't suck...

[0xABADC0DA]

You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM. Maybe it's just me, but highly I recommend learning something new instead of praying "JCobol" will stretch out your IT career until retirement.

Viva Java!

[prophecyslides]

About time they started thinking about the desktop. Java rules the server, why not the client?

Re:Java Desktop

[Kazoo the Clown]

Making a project take much longer to implement and take literally twice as long to test really isn't a sensible option when you are paying people by the hour.

Java is not the panacea your argument here is claiming it is. Testing may take a bit longer, but that's not necessarily a bad thing-- some things get tested better on one platform than another and you find things you might not otherwise. And coding doesn't necessarily take much longer to implement if you are familiar with the variations in the target platforms. Sure, I've seen a lot of *bad* attempts at multi-platform code, look for *platform* specific #ifdefs spread throughout for example, rather than *feature* specific ifdefs that are selectively defined for each platform. That sort of thing can be hell when the programmers don't know what they are doing, or if you've inherited it from some who didn't. But make no mistake, Java has its own unique set of issues that cause their fair share of problems.

Ultimately, the customer doesn't really care what it's written in, other than the fact that he's "heard" things good or bad about one language or another. I've never heard someone react to the fact that something was written in C as if it was a bad thing though, usually the contrary (most customers are ignorant of it's propensity for buffer overflows and wayward pointers). I have heard negative reactions from customers for a lot of other languages though.

If you can't afford programmers who know about coding in multi-platform environments, then Java might well be a good bet for you-- but that's not a good argument to relay to the customer as to why they should buy it...

Java's dead . . .

[Anonymous Coward]

Long live C#!

Re:Java Desktop

[Kazoo the Clown]

In many ways, Linux takes better advantage of x86 architecture than Windows does. Linux is written multi-platform in the way I'm arguing makes sense, not by emulating a virtual machine on every platform, but by optionally taking advantage of the specialties of every platform. Otherwise, all Linux installations would be compiled strictly for the 386. And the ways that Linux comes up short on the x86 platform, it's due to either lack of hardware drivers which is a short-term problem (hopefully) OR the overhead "one-size-fits-all platform independent" solutions such as X which is also a short-term problem (see directFB.org for an example). I dual boot Linux/PC at home, Linux anytime I want to surf the web because its more secure, and PC when I want to run games or other graphics intensive programs. I create (boot) the platform I want for the job I'm trying to do. I have little interest in emulations such as Wine to do that, rebooting is not a big problem for me. Eventually I do hope to be able to stick with one environment, but it's just not a big deal in the meantime. I'm not interested in "networked" games though, if I was I'd have to do something else.

It seems to me that product managers have long concluded that programming is hard, or expensive, or otherwise prohibitive and they want to do less of it. We don't have time or money or expertise to do it right, so we have to find some kind of shortcut. And that sells lots of things-- fad methodologies, magic tools, outsourcing, all sorts of software snake-oil. The problem is however, that there's no free lunch. Each of these alternatives have their own set of complications. I choose to pick those that optimize the results, not the process.

I knock my pipes out writing SwingWT...

[bobintetley]

...and nobody bloody cares or remembers.

SwingWT is a FREE implementation of the Swing APIs on top of SWT so you get all the juicy nativeness of SWT and all of the nice APIness of Swing.

Re:I knock my pipes out writing SwingWT...

[DrEasy]

This is sweet, I'd been wondering if such a thing existed.

Re:I knock my pipes out writing SwingWT...

[aCapitalist]

I've never used your library, but I appreciate your work in addressing the issue.

Sun needs to hire you brother.

Still no Plans for BSD

[obender]

I know about the old Slashdot joke about BSD dying but I think Sun should release a distribution of Java for BSD. BSD's can make great servers and Java on that platform could open the way for many enterprise solutions.

Re:Still no Plans for BSD

[Anonymous Coward]

The Linux/x86 version of Java can easily be run using Linux emulation. Additionally there is a native port of Java for FreeBSD, although it's not done by Sun.

Re:Java Desktop

[Anonymous Coward]

Don't forget it makes your skin turn green.

The fact that Java by default only allocates and will use 64 MB per application shows your lack of knowledge. This is a great feature; a runaway program is a runaway program, but using Java it won't use ALL your system memory.

Re:Java Desktop

[Anonymous Coward]

You know that Linux basically emulates its preferred 3-stage (is it 4 now?) page table layout when the architecture doesn't support it?

Ever wonder why your Amiga (or whatever) ran so fast given its processsing power? The OS was designed specifically for the hardware. With Windows there's an interesting conspiracy theory that MS purposefully slow it down to encourage people to upgrade.. but I digress.

Remember when everything was written in assembler? Was it "lazy" to code in C? While it would be nice to optimize the results, you have to remember that if you have more time, you can spend it debugging or adding new features - thus optimizing the process can lead to optimizing the results.

While C/C++ with MFC/GTK is much faster usually with a better UI, it takes an order of magnitude longer to develop software for it, time which could be spent improving the program itself, if it was to be written in Java.

You don't have infinite time to develop software. Not everything can be Duke Nukem Forever.

Re:Java Desktop

[Anonymous Coward]

You hot?

Re:Java Desktop

[Anonymous Coward]

it's been my personal experience that anything written in java takes twice as much time to write, runs half as fast and uses 90% of the available memory and processor of the box hosting the JVM.

I'd be intterested to know what those Java apps were. Obviously not IntelliJ, Jedit, Azureus (on the desktop), or any of the cellphone games written in J2ME.

If I tried, I could write and configure a java program to behave as you described. But I'd have to consciously try to. You are obviously used to running programs written by somebody who's not skilled in writing Java.

Flash is expensive

[tepples]

How about Flash?

Games using Java technology can be made in J2SDK, which costs $0 (royalty-free proprietary software). Games using ActiveX technology can be made in MinGW, which costs $0 (free software). In both cases, the Eclipse IDE is free software. Flash games, on the other hand, are made only in Macromedia Flash, which costs well over what I can afford.

In addition, doesn't using Java technology let nearly the same codebase run on J2SE web browsers and J2ME phones?

Re:Flash is expensive

[Kazoo the Clown]

How well does ActiveX run on Linux? Is an Java+ActiveX game really a "write once run anywhere" deal? Or does only the Java portion of such a program have that characteristic? How much of the code actually being executed has to be written in Java for the result to be considered a "Java" program? If much of what the Java does is interfacing between platform dependent libraries, and the result won't run anywhere these platform dependent libraries haven't been ported, it seems to me significantly nontrivial portions of the code can hardly be said to be "platform independent." As the JVM context gets more and more complex with graphics and other such extention libraries, isn't the concept of moving a Java program to a brand new platform an even bigger barrier to entry for a Java program that is only be using a subset of these capabilties?-- you can't run a Java program until you have a JVM, and if a JVM has become a hugely complex nonportable piece...

Re:Flash is expensive

[tepples]

How much of the code actually being executed has to be written in Java for the result to be considered a "Java" program?

All of it. Applets not signed with a VeriSign certificate can't call unknown native methods. In any case, all of a program has to be Java bytecode in order for the program to qualify for the "100% Pure Java" branding program.

you can't run a Java program until you have a JVM, and if a JVM has become a hugely complex nonportable piece...

you can't run a Flash program until you have a Flash player, and if a Flash player has become a hugely complex nonportable piece...

Still, Java technology is cheaper to learn than Flash for people who have already graduated.

Bit of a boring list

[bungley]

In java 1.5 they added quite a few nifty things to the language, (generics, varargs, etc). I'm surprised they've not thought of anything else worth adding.

Of course, it's still better to not fix stuff that ain't broke.

Be prepared

[tepples]

Everything I've written has had no reason to be localized.

Yet. Are you planning for when some foreign company wants to publish your program in another country and possibly pay you for the i18n work underlying its L10n job?

Re:Java Desktop

[Kazoo the Clown]

Remember when everything was written in assembler? Was it "lazy" to code in C? While it would be nice to optimize the results, you have to remember that if you have more time, you can spend it debugging or adding new features - thus optimizing the process can lead to optimizing the results.

As usual, it's a tradeoff. C was a pretty good tradeoff against assembler in most cases, it is practically a generic assembler itself-- handling data at pretty much the same level, mainly just the "instruction set" is hardware independent, not so much the data. A good C programmer will generally have a pretty good idea what the equivalent machine instructions are for a given line of C code.

C++ however, somewhat less so. Many of those object oriented features move the programmer further away from the sense of what is happening with the hardware. Layers are hidden, encapsulated, etc., but bugs and performance problems can be as well. It may be a reasonable tradeoff, but there is some penalty you are paying.

When on top of that, you further add virtual machine emulation, you've completely removed the programmer from any sense of what is going on at the level of the hardware. If that's good enough for you, fine, but as long as there are available alternatives that aren't carrying around that kind of lets-make-it-playskool-for-the-programmer baggage, the only thing that is going to convince me is a Java "killer app." While Azureus may be a good performer (I wouldn't know, I've had virtually no need to bittorrent at all so far), it's not a "killer app" as there's nothing about it that Java can do better than an alternative. A true Java "killer app" would have to be one where if it wasn't written in Java or an equivalently architectured environment, it would necessarily not perform as well, AND be something that almost noone will want to do without once it's created. Until then, it'll always be second-fiddle to something with fewer layers between the language and unique hardware features.

Java may evolve to where very little of a Java program is actually written in Java-- the Java code becomes merely interface logic that calls "libraries" or "drivers" that handle the platform dependent capabilities. But then in fact, while the interface logic is "run anywhere," who cares as it's pretty trivial, and useless if you don't have the relevant libraries and drivers for a candidate platform...

Footprints in the Sand.

[triso]

What I would like to see is a reduced memory footprint for Java. Using up 40MB for a tiny applet, application or servlet is a pain. CDS, Class Data Sharing, is close but you have to use the old-school garbage collector and the client VM. See http://java.sun.com/j2se/1.5.0/docs/guide/vm/class -data-sharing.html for the poop.

Please show me I am wrong.

Call my a cynic

[Anonymous Coward]

I suspect two reasons for the lukewarm reaction to java: one the complete LACk of apple suport, two: "cooL!" factor.

Making SWT portable

[Latent Heat]

Yeah, like get Sun to adopt it.

Only reason Swing runs without a companion distribution is that the required DLL's for Swing are part of the Java download for Windows, Mac, etc.

OK, so Swing is "lightweight" in that most of it is done in Java, but there still has to be a link to the native OS at some level.

DER DER DER!!!

[TheLittleJetson]

Yuo must be in INdia where programmars work for $1..... AHAHAHAHAHAHAHAHAHAHAHH WTF! LOL1 BBQ!!!!!

Sounds great...NOT less filling.

[Anonymous Coward]

"Make this a part of the standard JRE! *It will be the most significant and best single thing that ever could have been done to java*. Imagine having a gecko rendering engine whose DOM is fully controllable from Java on every major platform that the JRE supports! Imagine being able to use a gecko widget inside any GUI com\ponent! That would be how to step up and really innovate."

Imagine listening to "It's bloated!", and "Why do I need this?"

More Hardware Support

[DudeAbides]

Built in USB and HID support would be nice!

Java had subpixel rendering since 1.2 FUD ALERT

[Anonymous Coward]

Anti-aliased fonts have been around since Java 1.2. They are not enabled by default in Swing but sophisticated applications like netbeans can enable them with a simple switch in the preferences menu.

What is still missing is "ClearType" which is relevant only for LCD monitors! Personally I'm not too crazy about ClearType since it makes the fonts look "colorfull" when they should be black. But some people claim they are essential.
ClearType will be a part of Mustang and it will probably turn on anti-aliasing by default rather than let the programmer decide (it will do so by using the OS/font defaults).

JDNC is what you are looking for

[Anonymous Coward]

Simplified model based on XML for client server applications. With an additionally large layered component libraries. Its FREE SOFTWARE (as in GPL).

FUD! This is completely different from SWT!

[Anonymous Coward]

It only does the rendering natively which gives it the advantages of SWT without the disadvantages. The look of the component will be the same as the native OS but the full behavior and the ability to modify the look will remain in Swing which is exactly what the PLAF was designed to do.
Up until now this was impossible to do under Windows, but XP has made some internal undocumented rendering API's into public API's. So rather than ask the OS to create a button, Swing creates a button and only asks the OS to draw it for a particular state and allows the user to replace the drawing if necessary. No dissadvantage of portability since the PLAF can still be replaced and is still in control.
Unlike SWT who both lacks a PLAF and handles events using an EVENT LOOP (how 1980's is that).

This doesn't work

[Anonymous Coward]

Since Swing is much larger and more complicated than SWT/JFace this cannot technically be accomplished for REAL LIFE Swing applications. The reverse however is possible there is a partial SWT implementation running on Swing....
Features such as full component based renderers/editors with truely decoupled models just can't be accomplished natively.

Re:This doesn't work

[Anonymous Coward]

Nobody actually uses that much of Swing anyway - SwingWT more than covers what people actually want to do with Swing.

Re:Write a browser that doesn't suck...

[aCapitalist]

You just posted to slashdot that you use IE... nevermind that you also prefer a 10-year-old JVM

Yeah, I'm sure he feels the need to fit in with Slashbot groupthink.

Re:Java Desktop

[Anonymous Coward]

If Only I could convince my boss of that fact... maybe he'd replace the skill-less Java Biggot with someone who knows how to code, and my opinion of the language might just change.

I've often wondered if the real issue wasn't just that my company has been hiring the "I got into programming because my mommie said it paid well" crowd who hide behind Java Religion because it's the only thing they've ever coded. I should really try to be more fair to Java, but I guess I've just got a bitter taste in my mouth.

Heh Bitter Java... heh (yes, I've read the book)