Java Community Process - it’s how additions and changes to the JRE and Java in general are decided.
http://www.jcp.org/
hm, interesting:
http://www.linuxjournal.com/article.php?sid=7413
now I understand why Sun is always pointing at Redhat so bad … 
[quote]hm, interesting:
http://www.linuxjournal.com/article.php?sid=7413
now I understand why Sun is always pointing at Redhat so bad …
[/quote]
I love the way it exposes that really annoying bug in eclipse - SWT - by saying there were only two problems with moving to 64-bit:
which made me chuckle with pleasure - recalling I no longer have to worry about that **** since moving to java :P.
(the other big problem was the truly dismal fact that there was no JVM for AMD 64 
which simultaneously makes java look pretty stupid).
It’s no surprise that SWT was causing most of their problems (slowness, need to maintain JNI bindings w 64 bit pointers). SWT may be what AWT should have been, but it was never worth doing. People still seem to think Swing is slow - it once was, in the days of Java 1.2. Guess what , it got faster! No need to go re-inventing everything.
Actually Swing still is the dog it always was. It should compete with native applications and it just… doesn’t. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.
Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is. The only real reason it feels a bit faster now is that you’re probably on a 2GHz computer…
Cas
The solution: 3d abstract windowing toolkit based on jogl. ;D
LWJGL methinks 
Cas
[quote]Actually Swing still is the dog it always was. It should compete with native applications and it just… doesn’t. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.
[/quote]
That’s not true. If you read Jeff’s Performance Book you’ll see why Swing has improved a lot (like Swpalmer points out) and that if you design your GUI app wrongly, your application will be slow no matter how fast or slow Swing is.
I work a lot with JBuilder and JEdit, both full blown Swing applications: they’re fast, responsive and look nice! (Especially Borlands L&F theme). Aside the Window’s virtual memory swapping with large Java apps they’re as well usable as native apps. On a reasonably fast PC you simply don’t see any difference.
[quote]Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is.
[/quote]
You can’t even use “serious” Windows versions seriously on a 200 MHz computer so why bother talking about them for desktop reasons?
The only real purpose for a 200 MHz is as a Linux (print) server or such. {Even for MAME it’s way too slow…}
Oops, I’m off-topic again! Sorry…
To go back to topic: Bergen (Norway) will go Opensource now, München (Germany; for you English people: Munich) finally does, and several more. Just to name two big ones which decided this route during the last weeks. It’s a good thing. Now where’s the connection to Java…
P.S. Where’s Jeff btw? He used to write a lot of nice articles here…
[quote]Actually Swing still is the dog it always was.
[/quote]
Cas! Are you one of those miscreants who’s still going around spreading these lies?
We’re writing the entire UI for our nextgen product in Swing. Swing performs absolutely great, and is, by far, the most flexible and intuitive windowing kit I have ever used in my life. Our UIs are very complex, yet they are very responsive and intuitive. The flexibility of the API allows us to do all sorts of things that make the interface very ease to use and understand. Now, if you’ve been trying to abuse Swing for gaming purposes, I could see where you might have problems.
[quote]Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is.
[/quote]
“Try running Windows on a VT100 terminal just to see how slow it really is.” That statement is just plain silly.
God bless,
-Toby Reyelts
Agreed ;).
You were with me right up to this point:
…now that’s just wishful thinking (or you must be lucky enough not to work with 70% of swing yourself).
[quote]The flexibility of the API allows us to do all sorts of things that make the interface very ease to use and understand.
[/quote]
It’s just a pity that the most important bits for doing this in swing … are completely FUBAR by Sun, and no-one at Sun has ever got off their backside and fixed them. I’m thinking of:
- layout managers: not just a joke, but enough to cause you to lose the will to live
- JTable, JTree, JList, JTextArea: none of them work. All of them have incompatible architecture; none of them interoperate in the painfully trivially obvious ways that even a 10 year old child could have guessed they ought to, if anyone at Sun had asked.
- Listeners and Events: many are incompatible in stupid ways; many that should extend each other… don’t; the whole thing about needing explicit source because swing’s architecture exposes one of the most dangerous things (recursive infinite loops) by it’s fundamental design; the fact that many Event’s lack basic data that is necessary to handle them properly
OTOH, I entirely agree with you that some parts are excellent, e.g.:
- Actions. (Just a pity Sun hasn’t fully implemented them, and has made it so that you have to create dummy classes all over the place because things like Menus each require an Action )
- Buttons (they got these right, at least)
Maybe. But, it’s a perfectly valid argument that Swing has no excuse NOT to run fast on a 200Mhz machine. Really.
Hey, no lies. I code Swing all day long. It’s crap. 10 years ago I was doing GUIs using Powerbuilder. They were faster on the hardware of the day. They also took about 100th the time to code. 1 step forward, 100 backwards. Enough said about it because obviously your GUIs are much faster than mine
Cas
[quote]Actually Swing still is the dog it always was. It should compete with native applications and it just… doesn’t. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.
Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is. The only real reason it feels a bit faster now is that you’re probably on a 2GHz computer…
Cas
[/quote]
Well, yes I am on a fast computer these days, but for lets say 700 MHz and up Swing has been as fast as anything else as far as human perception.
I’ve been doing a Swing GUI for a couple years now and I have absolutely no complaints about it’s speed. In fact there are areas where it is clearly faster than the native widgets (JSplitter with live resizing works much better in Swing than the equivalent in native windows).
[quote]…now that’s just wishful thinking (or you must be lucky enough not to work with 70% of swing yourself).
[/quote]
It’s been a little while since I’ve done “normal” Swing development - the last “Swing” stuff I wrote was a mapping ui that was primarily Java2D sitting in a JPanel. On the other hand, I’ve probably worked with every Swing control except JSpinner.
[quote] - layout managers: not just a joke, but enough to cause you to lose the will to live
[/quote]
Granted the default layout managers suck - but what other toolkits do you know that come with something great? Swing puts the hooks in there so you can write your own great layout manager (or use someone elses). We wrote our own app to graphically layout components, based on the most venerable JGoodies layout, and, to put it mildly, it kicks ass. We can create very professional layouts in a matter of minutes. Don’t believe me? Download it for free - http://formlayoutmaker.sourceforge.net/
[quote]JTable, JTree, JList, JTextArea: none of them work.
[/quote]
You’re going to have to be more specific here. Of course, there are idiosyncrasities - every toolkit has them. On the other hand, I don’t know of a single toolkit that allows me the same ease in customizing the rendering, editing, and backend data models for these components.
[quote]Listeners and Events:
[/quote]
The only problem I have had with listeners and events, is that they aren’t documented very well. It’s sometimes difficult to know when certain events get published.
[quote]Maybe. But, it’s a perfectly valid argument that Swing has no excuse NOT to run fast on a 200Mhz machine. Really.
[/quote]
I disagree. I bet you wouldn’t see Aqua running fast on a 200Mhz machine - and new MacOS releases generally run faster on older hardware.
Basically, there’s no point for the engineers at Sun to waste their time optimizing to that kind of machine. They should be assuming minimally 16M video memory, 1GHZ processors, and 128M RAM. Most companies are not developing Swing apps for 3rd world countries.
God bless,
-Toby Reyelts
Having only used Windows MFC and Amiga UI stuff, I too find that Swing is the best UI framework I have ever used. I do find it mostly intuitive and reasonable. Though there are a few things that aren’t super wonderful.
I agree that many toolkits have tended to be broken/buggy or look very very ugly and have hard-to-distinguish elements (like the old ones used by a lot of linux/unix apps aimed at being fast-to-draw).
But, as Cas says, there have also been some diamonds. And java arrived as a “modern” language and made great bounds in learning from what went before. I’m still bitter that they didn’t consistently learn when it came to toolkit design; as I’ve said before, I feel sorry for those on the swing team who wrote some parts extremely well, who are let down by the others who wrote some parts extremely badly.
I’m not arguing they should optimize for them; I only think they should remove the MS-quality idiot-code that makes them slow on those machines. I struggle to find a reason (today) for a java app to draw slowly on a 200Mhz machine short of broken video drivers, or the use of DirectX 1.0 or something equally deliberate ;D. Window-painting-accelerating hardware wasn’t exactly new even on 200Mhz PC’s…
Yes, if all you are runing is one swing app on small datasets on your PC then it doesn’t matter so long as it’s fast.
But when you are running 10 or 20 of them (note: I can only run about 5 max at once before the problems of java’s no-shared-memory and swings poor performance slow the machine down to unusably slow) then it DOES matter. Poor performance is a major barrier to attempting to use only java apps for all desktop work - which is a very powerful lure to those of us who HAVE to work on multiple platforms day-to-day. OK, so I have no need to dump ultra-mainstream apps like OO and mozilla, but all the specialist apps (like project-mgmt software) whose authors can’t afford such effort on x-platform ought to be in java - and that places stress on swing.
I can write a better damned toolkit than Swing, on my own Why does it take so many of them to get it wrong?
Cas
[quote]I can write a better damned toolkit than Swing, on my own
[/quote]
I’ll believe it when I see it, Cas. People have been writing alternative ui kits for Java for a long time. Nothing competes with Swing.
God bless,
-Toby Reyelts
NetBeans is a Swing app isn’t it? That runs fine on my P3 1GHz. In fact, it runs as good as Eclipse on my machine. The one thing that gives it away is the noticeable pause when you click on a menu or tab for the first time. After that it seems to run fine.
I always thought that the SwingSet demo in the JDK was a liability in terms of first impressions - it really is dog slow and the menus and tabs are extremely laggy. I know it is demonstrating tons of stuff but still…
There are a lot of crud Swing apps out there. I downloaded a Swing email client (granted it was linked from Sun’s JavaMail page and supposedly it was not meant to be a GUI showcase) but my God, it was butt-ugly. It had buttons with text right up to the edges, no menu (!), weird drag’n’drop behaviour, non-standard toolbar, and an unchangeable brown colour scheme. Technically it worked fine, but it was so ugly that I couldn’t use it. God help any non-techie who stumbled across it.
My previous “toolkit” was raw Win32, so Swing is a huge improvement! I especially like the way you can just chuck a component into a JScrollPane to get scrolling. But then maybe I’m easily impressed. I’ve yet to use any of the heavy hitters like JTree or JTable.
20thCB
Bits of the API design are nice. But by and large it’s slow and unresponsive to the end user. I don’t like to see a big white rectangle sit on the screen before a menu draws itself in its stead about 0.5s later. I don’t like the whole screen to flicker repainting itself when I drag a window over another one. Etc. Bleh.
Cas
[quote]I don’t like to see a big white rectangle sit on the screen before a menu draws itself in its stead about 0.5s later. I don’t like the whole screen to flicker repainting itself when I drag a window over another one.
[/quote]
Umm, Swing doesn’t do that. I’ve got a crappy Intel graphics chipset at work, so it sure doesn’t require any kickass video card. Perhaps you’re using a poorly written Swing app? Perhaps there are problems with your video driver? Perhaps you’re running on a 200Mhz cpu?
God bless,
-Toby Reyelts