Sun officials on Wednesday presented a laundry list of technology and promotional efforts planned for the J2EE, including the February release of the final draft of J2EE 1.4. They expressed support for the Oracle let JSR 198 (open API for IDE's) but criticized Eclipse because it is based on the SWT framework, which they claim is not multi-platform.
Read Sun readying J2EE 1.4
Editors update - Jan 17th
Another article covering J2EE 1.4 discusses Sun's push to make the platform simpler:
J2EE 1.4 Moves Down the Enterprise Ladder
Instead of criticizing Eclipse and battling with MS, they (SUN) would better adopt Eclipse architecture and make java GUI look as a GUI and not to be just as a prove of concept. On the other hand Eclipse has very smart and relatively simple approach, which is reusing native widget if one exists and if it doesnt then write your own. This is just my opinion.
This isn't really a J2EE issue but the problem isn't that Java UIs don't look good, that's a symptom of the root causes. It's that Swing/AWT has a non-satisfactory architecture.
There is no concept of the UI inheritence heirarchy. If you have a panel that contains child components, and you set the panel disabled, the children don't also become disabled. If an attribute isn't explicitly set on a component, it should come from the parent component. Same for colors, fonts, etc.
There is no concept of embedded components. There is no standard way for a focused component to post menus and have them integrated into the menubar.
Back to the UI inheritence heirarchy, there's no way for a parent component to intercept mouse/key events destined for a focused child component. Even if you use JComponent.enabledEvents, once a listener has been registered, the events are re-enabled. This makes building a WYSIWYG Visual Development Environment very hard, explaining why there are no high-quality GUI dev tools and we live with IDE's generating ugly code.
And finally, everything is done in code, leading most to just glom their view and controller together. A hell of a lot of in-the-way UI construction code could be removed if there was a rich resource model, like that found in MFC/VB.
SWT using native widgets removes the primary reason to use Java in the first place: WORA. Previous art, mostly ignored, clearly demonstrated that emulation is the way to go.
I used to work for Visix Software and Galaxy solved alot of the problems that Swing currently has. Sun could have picked up Visix for peanuts 6 years ago and based AWT on the existing best solution to the problem. They seem to suffer from Not-Invented-Here syndrome.
I'm working on a layer atop Swing that address each of the problems listed above. It'll be out shortly.
We need a www.theclientside.com already!
I agree. It's so sad that while Java allows to write excellent server side apps, creating presentation layer
isn't so easy as with VB or Delphi.
>rich resource model, like that found in MFC/VB.
BTW JBuilder and JDeveloper (BC4J and uiXML) has some visual, resource-driven SWING components.
I agree that it would be great to have something like a www.theclientside.com. I'd love to have a focused resource for J2EE front-end issues where pros and cons of different architecures/libraries/frameworks/paradigms/etc. would be discussed. So if anyone is doing a head count, well, count me in!
I agree that it would be great to have something like a www.theclientside.com
Well something might happen, as Floyd Marinescu owns the domain name ;-)
FYI, Floyd himself is the owner of the domain name. I guess that with the support of TSS, a TCS Web site could be setup quite easily (https://joker.com/index.joker?t_whois=theclientside.com&tool=whois&Submit=go
INSPIRE IT - www.inspireit.biz
: Your Java bookstore on the Web!
This just great news that 1.4 J2EE app server will soon follow. I cant wait as thsi will give apps in 1.4 a 50% or greater performance boost.
I think swing apps will get a new life in desktop too.
J2EE 1.4 is the final nail to the .Not coffin :)
IMHO, I dont think many companies in the industry follow the suit..Instead, most of the companies will try to make their app servers robust and optimized.....
>>give apps in 1.4 a 50%
>>or greater performance boost.
Where did you get this from? Sounds interesting.
I would like to see J2EE promotional efforts here in eastern Europe (Latvia).
MSFT is doing a lot of free ".NET developers seminars" here.
I visited one. A local guy talked about SQL server and XML (SELECT ... FOR XML).
Mildly interesting, but many geeks were very excited :-)
And one of them asked me "are you doing VB now ???"
Did you download the J2EE Jar?
Do you see that Sun now FINALY sees persistance as a problem?
They included an Non-JDO from Castor in the J2EE.jar.
Download the JAR and look.
Myself, I am just using the Tomcat Jars, and my own DAO with Eclipse, becuase Eclipse is so much faster then Sun's Netbeans.
Eclipse also feels a lot more open, Sun patrols Netbeans.org mail list and deletes non-positive posts, at least it did mine.
Eclipse IDE is best free IDE (other than VIM.org).
Tomcat, Eclipse and PostgreSQL (Cygwin) is all you need to deploy large apps.
There is a serious bug in NetBeans:
Create a project with it and leter delete it from
Then, lo and behold, NetBeans will not work anymore, because
"project manager" will cause NPE every time you use it!
Well, you can reinstall it of course now.
I have written a bug report two times, but it hasn't been fixed. It appears that they dont think it's a bug.
Otherwise it's a nice IDE.
I encountered the same problem some time ago, and found that best solution is actually removing the .Netbeans folder from the user's specific documents folder, its much better than uninstalling the soft.
Netbeans rocks, especially when dealing with Entreprise Beans development, it's the best tool for that work i found, i tried many others including jBuilder and haven't found such an easy way to deal with all the requirements of enterprise java development!
Why do they care about Eclipse not being multi-platform? It's an IDE!!!! You don't have to use SWT in your app! I don't care if the IDE I'm using is built with Java, .Net or C++! Just give me one that is FAST, STABLE, easy to use and FREE! Well, Eclipse is just that...
OK, well we've used eclipse on a few projects now. It's the first IDE that our developers have naturally accepted as productive AND nice to use. Attempts have been made in the past to introduce both forte and jbuilder, but developers kept reverting back to good old editplus. Common complaints revolved around big and clunky, too memory hungry to simply, "client Java apps don't work".
So why has eclipse achieved such a likable persona?
Well, most eclipse users attribute this to the open plugable design creating a feeling of "freedom to code my own way" (sounds like an IDE should be?).
I have spoken to other senior developers who have resisted the move from C++ to Java, citing the main cause as a lack of good IDE (Visual Studio is, dare I say it, very nice to use!).
Still, you can't deny that the fast responsive "native" feeling presented by SWT is far superior to the Swing renderings we have become used to. It's easy to agree that SWT isn't truely platform agnostic, just as it's easy to agree that it's probably the best IDE Java has so far.
So, we can't ignore the virtues of native widgets in improving usability.
Could there be a way for the VM to render Swing through the JNI if available (eg: Windows, Linux). On systems where it is not, then Swing could be rendered in the traditional way?
Our apps would be snappier and more responsive on Windows, GTK and Motif. We wouldn't have to learn a new interface (Swing is fine thanks) and best of all, Java remains open and platform agnostic!
As Eric said, "FAST, STABLE, easy to use", isn't that how all our apps should be?
True that ideaJ is not free but I just find it close to perfection and it's full java/swing !
It's price is small compared to the productivity gain
I guess all the advanced features in eclipse will be found in the IBM WSAD version and probably not in the free edition.
As for SWT, it might be slightly faster than swing (in jdk 1.4 swing is now almost as fast as a native UI) but it's not as OO and flexible and more importly not standard.
I do agree that an IDE is not really important regarding J2EE which are server stuffs. As long as it can integrate with any of the J2EE stack implementations...
Eclipse is the best IDE I´ve used. The look and feel and performance is better than the Netbeans and this is because it uses SWT. Swing is horrible, it´s portable but it´s very ugly and very slow for the user of our applications. However SWT looks like a native application and is portable for Windows and Linux. I dont understand the Sun´s policy. They must give us a better framework for GUI development instead of critizise IBM for giving us a new library that we can use. We must take the decision of using it, not Sun.
NetBeans is slow because of many reasons, none of them being because it's based on Swing. I can point you to many fast Swing based applications. Start by trying IDEA: it uses Swing, it's fast, responsive and looks good (obviously they don't use the default L&F).
If you like Eclipse, good for you. If you don't like NetBeans "tant pis". But saying that NetBeans is slow because it uses Swing it's equivalent as saying that my car is slow because it uses gas instead of kerosene.
I totally second Angel on his thought. I use Together 6.0 for months and it's **not** slow at all, in comparison with native app (Together swing-based, AFAIK). Bad design makes app slower, not because it's built on top of swing.
There are many and many professional apps that use swing out there, and i'm sure speed and fluency of the GUI is no longer a problem with swing... otherwise all those vendors that have swing-based app would have given up using swing ...
Just my 2 cents...
Yes, you can do that Swing go fast but you need a lot of time to get this result and your productivity goes down. One of the reasons of using Java is its high productivity. Of course that Netbeans is slower than Eclipse because it uses Swing!!!. You say that you know many fast applications in Swing but I can say you many slow applications too. And if the enigne of your car is ready for kerosene, i can guarantee you that your car goes faster than if you use a normal enigne with gas. Is your car faster than a plane?
Having used (Forte for a number of projects) I was satisfied UNTIL I tried IDEA (budget contraints does not allow), and then Eclipse. IMHO, Eclipse allows me to develop effectively whether I have maint. of a Large J2EE app or as I am now working on a company J2EE framework. Eclipse is a developer's IDE. Might I add, although Forte or Sun ONE has nice features, at times I reverted back to TextPad ...
This is the problem. Even if you put kerosene in my car that doesn't make it a plane. Same thing goes with NetBeans, even if you used SWT it will still be slow.
Swing is certainly not a speed daemon, but is more than good enough for most uses. But MS and IBM will tell so many times that it's slow that for most people it will become a fact. This reminds me of Java itself. For most people, Java is slow. Why? "Because Java is slow, it's a fact, besides I have seen so many Java program that are slow". Then you point out that the Web Server they use daily is Java based. Then the response, "yes but you have to tune like crazy to make it work fine. This really kills productivity".
Swing and SWT are frameworks for client applications, we are not talking about the server side. The success of Java in the server side is total but Swing is not the perfect framework for client applications.
I'd rather have a faster IDE than a cross-platform IDE. Eclipse is much faster than other Swing based IDE's out there. I think IDE is a different issue. It's not a cross-platform issue.
Before Swing was conceived, there already was a superior GUI toolkit, named IFC. Sun managed to destroy that one very effectively, and then let us wait years for a semi usable new and 'invented here' toolkit. Which totally killed Java on the client side.
IFC was conceptually based on NeXT's AppKit. It was _not native_ but very fast, even on 1997's VMs. Netscape bought it (it was basically built by two ex-nexters as I recall)and subsequently agreed with Sun to build Swing based on it. Sun managed to chase out all the Netscape engineers and started again from scratch. The rest is history.
Now IBM has again given us a proof that Java on the client _is_ feasible if good engineering (from OTI) is applied to the problem. I am sure there has been a lot of teeth gnashing at Sun because of this. If they could find a way to kill it, they surely would. But this time, they can't, SWT and Eclipse are there to stay, the market seems to have decided.
Sun should learn to live with that reality. Better yet: embrace it and see if they can make it part of Java. All these stabs at Eclipse being non standard are just sour grapes IMHO.
If Sun wanted to make SWT a part of the Java standard, there's no reason it couldn't. The key problem with SWT is that it's not available on all platforms that Java is available.
The solution is simple: port SWT to AWT. Native versions of SWT could be written if you want extra speed and you want to have native appearance for your apps. Having both SWT and AWT available may cause developers to become confused as to which they should develop for, but it's easy to sort out. If you want your apps to have native look and feel, use SWT. If you want your apps to look and behave exactly the same on all platforms, use AWT. Documenting you app is easy with AWT (since there's only one look and behaviour), but your users will likely prefer something native (so you need to do more work to support them).
If this is done, there's no reason why Swing couldn't be ported to SWT too. Granted, some parts of AWT leak out into Swing (after all, javax.swing.JComponent is a subclass of java.awt.Container), but seeing that java.awt.Container already depreciates most methods that refer to AWTEvent, so I don't see why this class can't be evolved to support SWT also. I'm sure the SWT team wouldn't mind evolving SWT to make this happen either. The key thing this would buy Swing is the ability to use the native look and feel of the environment if the developer chose to. Currently Swing supports the:
* Java Look and Feel
* MacOS Look and Feel
* Motif Look and Feel
* Windows Look and Feel
artificially. Why can't it also support the native look and feel too? It would get rid of one of Swing's major complains by users. The key thing it would by Eclipse is the ability to integrate with Swing extension more easily.
As for JFace, there's no reason why Sun should add it to the core API. After all, if they support SWT and integrate SWT as an option for Swing, there's little reason to prefer JFace or any other GUI Framework over Swing. It doesn't hurt Eclipse in the slightest since it already includes several other java libraries.
|Why can't it also support the native look and feel too...
I dont know the details - but it seems that Sun are doing just that in JDK1.4.2 (for windows).
Apparently they are releasing a new Windows look and feel, and implementing it using native components ala Apple's OS/X L&F. It will even support WinXP skinning.
It will be *very* interesting to see what the final result is...
If you guys take a minute to look up the dictoionary, you will find Eclipse, the word itself will make Sun uncomfortable.
from Canberra, AU
Yeah you are right Netbeans is not as responsive especially if you are still using a PII when the whole world is already on PIII or PIV with 256ram. If you have peewee pc power i recommend notepad or vi or jcreator. Talking about slow: the slowest ide's i have ever used are Visual Age for Java and Websphere (built on top of eclipse). So you could argue eclipse is fast - because it is merely the skeleton of webshpere. I like va and websphere but i will not run it on a peewee pc.
Netbeans can also be a nightmare if you happen to be a student who needs to stop and start an ide 4x in an hour to run a hello world program in preparation for an exam or the scjp. (But on second thought it will be far more excrucitating to stop and start VA and Webshpere 4x in an hour).
Developers who happen to have work open and close their ide's once! 9am and 7pm. I couldn't care less about stop and start.
Talking about speed again. Go ahead try using Visual age for java or Websphere - let me know how you find the speed.
Have you tried building web components on the eclipse plug-in Lomboz? Jeeez. Come to think of it Lomboz is one of the best plug-ins of Eclipse, but pales in comparison. Netbeans has much much much more to offer (jstl, servlets, listeners, filters, taglibs, and can even have the web.xml done for you). Netbeans is also intuitive. You don't need to memorize a tutorial just to make it work. With Netbeans you can focus on java instead of learning the steps to make it work. I have seen new programers labor with eclipse, pretending to like eclipse, just because they heard somewhere how great eclipse is only to make everything harder..
Personally I think Eclipse is overrated. I think it has tons of paid publicity and advertising backed by an empire that also wants to rule the world. Guys snap out of it. If there is one ide that continues to be eclipsed - it is eclipse.
I assume you mean that VAJ and WebSphere are built on Swing? They certainly existed prior to eclipse or SWT!
Actually VAJ is built on top of a Smalltalk VM (little known fact). If you try real hard you can get a "doesNotUnderstand:" exception!!
Anyway the UI part is based on Swing, but invoked from a Smalltalk code framework.
WebSphere java admin client is perhaps the quintessential example of a BAD swing UI.
Let's return to an earlier point in this dialog and recognize that the important question is not whether you can build a good UI with swing, but whether you can do so easily, or by-default, or out-of-the-box.
The answer is NO, or at least NOT every time.
You can with lesser tools like VB or Delphi and therein lies the failure of swing to gain acceptance, notwithstanding a plethora of objective, academic, or intellectural arguments regarding it's superiority.
My opinion on swing? Wonderfully engineered but inconsistent and schizoprenic when you get to the details. Down deep, it's lipstick on the Abysmal Windowing Toolkit pig.