Slashdot Mirror

Like many in here have said, I would simply argue that VB6 is on it's death bed and that is a good enough reason 90% of the time.
If I were starting a new desktop application I would seriously lean towards SWT and Eclipse Rich Client Platform. Hell, there are a number of visual editors for it.

Like many in here have said, I would simply argue that VB6 is on it's death bed and that is a good enough reason 90% of the time.
If I were starting a new desktop application I would seriously lean towards SWT and Eclipse Rich Client Platform. Hell, there are a number of visual editors for it.

Like many in here have said, I would simply argue that VB6 is on it's death bed and that is a good enough reason 90% of the time.
If I were starting a new desktop application I would seriously lean towards SWT and Eclipse Rich Client Platform. Hell, there are a number of visual editors for it.

The very first experiance everyone has with code here is simple text-editor/command line, coding, compliling, and running. After about a week-ish of writing simple "hello world" programs, they are introducted to a relatively bare bones compilor JCreator (basically it has syntax highlighting, auto-indentation, and project building, but you still have to compile the code and wade through the error results yourself.)

After students passed that semester of basic coding, the next semester introduced IDE's with more features, like eclipse, which does fix simple errors for you and basically make the coding go faster so the students get a more general view on whatever is being taught.

It seemed to me this philosophy worked the best, when students were just learning, they had to figure out what was wrong and catch it on their own, but as they got more proficient, they were given tools that did the basic stuff for them.

I would use an IDE, for the very simple reason, they wont be typing code in a text editor if they get a job coding. If you pick one pick Eclipse, http://www.eclipse.org/ as it is the one that is most likely to be used in the real world. Also as there is so many APIs in java with their imports that most students will forget about what to do and will not enjoy the experiences so they are less likely to do their best work. Just my 5c worth

I wonder how difficult it will be to write degradable applications with this toolkit. The demo applications I played with do nothing at all with javascript disabled... they're just a script tag in a body tag, so they make no attempt to render the application using plain HTML. I know they're just demos, but it won't save any time if you have to develop the non-js version separately... which is a problem particularly for those of us who have to develop to accessibility standards.

Also, this is coming right on the heels of the buzz about Oracle's AJAX Framework... and of course there's the Eclipse AJAX Toolkit Framework, which uses Dojo, Zimbra, and OpenRico (which in turn uses prototype)... others have mentioned Yahoo!'s toolkit and Atlas, as well, not to mention Rails... My point is that there are suddenly a ton of frameworks that all have slightly different approaches to the whole AJAX idea. Some are higher-level, some lower; some target a specific server backend; some offer UI libraries... Any or all of these might merge or die off or be made irrelevant at any time. It's almost harder to develop AJAXy applications now than back when you had to write your own HTTP request code... sure, you can knock one out in ten minutes now, but you spend the time you saved choosing the toolset beforehand.

I think I'll wait a bit... we've put the scorpions in the box and shaken it, so let's see who survives.

That means that every Java app out there, and there are a lot, should be able to run much faster

Compiling has trade-offs. You must target the end environment (CPU, OS), and also try to optimize code (for the target CPU). But you can only do static optimization.

Modern JVMs optimize on the fly. So the more you use a particular path through the code, the more it will be optimized (obviously only so far...). See this article: "The dynamic nature of the Java language provides opportunities for better optimization based on runtime profile information, and this is a significant advantage of a Java dynamic compiler over a traditional static compiler."

So having a compiled executable may not yield faster run times. It may have faster load times, which is where most of the perception of slowness comes from.

I use a rather large Java IDE (Eclipse) for development. It takes 10-15 seconds to load up the IDE from a cold start (2.1 GHz laptop). After that it is just as fast as I can type, which includes on-the-fly error/syntax checking, code assist, and so on.

Two things. First, the SWT proved it can be done right. The shortcomings of the AWT aren't really caused by inherent flaws in crossplatform GUI toolkits.

Secondly, even then the SWT is fatally flawed. You should be coding a new interface for every single operating system you port to. If you don't, you're application will never fit in correctly with the local operating system and will always feel out of place. (For example, GNOME specifies that the most commonly used dialog button should be on the right. Eclipse places it on the left under GNOME, because Windows places it on the left.)

Firefox fits in with Windows nicely, but that's about it. Under GNOME, it doesn't look quite right for a GTK+ application (damned close, but it still screws the theme up). Under Windows, there are several things Firefox doesn't do that the Windows GUI does. We'll ignore how badly it works under Mac OS X. If you're going to try and use a crossplatform GUI toolkit, you'll always have to write once, test everywhere. Firefox has different versions of their XUL UI files for GNOME and Windows. One has "Tools\Options", the other has "Edit\Preferences" based on the standards for the two OSes.

There's no such thing as a "crossplatform UI toolkit" that won't run into problems fitting in with some OS. It's not worth trying, because it will always fail.

SWT is inferior to Swing in that it's inflexible and only supports a small set of widgets. Swing is inferior to SWT in that applications using it don't feel like native applications (still, even Swing in 1.6 has flaws). It's simply not possible to create a cross-platform UI without it being out of place on some OS.

And speaking of Sun's dedication to client side apps, lets look at the change log just for 1.5.0_06:

• 6257260 java classes_2d Memory leak on closing JFrame
• 6182812 java classes_io FileOutputStream constructor throws FileNotFoundException with long file names
• 5092063 java classes_net Extremely slow socket creation using new Socket("ip-address", port)
• 4263904 java classes_swing JTextPane: Paragraphs with Justified Attributes Appear Centered
• 6256473 java_plugin iexplorer To download an applet does not finish for 10 minutes with proxy server and IIS

And ad nauseum.

• Loading a progressive JPEG causes OutOfMemoryError
• TreeViewer with input set throws AssertionFailedException
• Eclipse unusable over X with slow network connection
• TreeItem doesn't have setToolTipText
• KeyReleased not working correctly.
• Allow better Integration with existing java2d
• Address platform-specific UI performance problems

Somebody! Please over there at Sun!!! Do not give that grass to Gosling "The Father of Java" anymore!!!! Or my heart would definitely break.

"Java is already open source for 10 years" and "Eclipse destroyed interoperability" is... *NO* *COMMENTS*.

Sun for last ten years - and 6 versions of Java - jumped from one application field to another. Sun's lack of the focus - and Gosling sayings confirm that lack - is sole reason for the problems of Java. Companies just can't trust Sun at that point. (*)

Eclipse claims are just plainly laughable. And in fact one of the most spoken problems of Java and Sun's control over Java. Since Java slowly moved to server side of computing, Sun payed less and less attention to the one simple thing - GUI. There is no standard Java GUI API. Period. People tried what is shipped with Java SDK - AWT & Swing - shivered and moved on. Plainly unusable. In fact, I do not know single successful Java GUI application which uses Java's native GUI toolkits. Eclipse foundation just did what it had to - filled the gap. Now we have GUI toolkit. Which is quite performant, usable on Windows/Linux/BSD/Mac. And people are pretty happy about it. Even me. And many applications already use it (Azureus as an example pops up in my head). Check the http://www.eclipse.org/swt/community.php for more.

P.S. Original article includes the pointer that Sun's planing to try assault on embedded space again. Good Luck Gosling. You freaking need it.

(*) My company wanted to standartize of Java, but backed off the plans. Middle management wanted Java for its stable and rich development environment. R&D manager flat out refused since Java is in fact closed source and there is no sence in adding another dependency to the already huge software package we have. And nobody can assure us what Sun will do tommorow - what if they drop support for M$ Windows?? There is *no* competing Java implementations. And there is no standard for Java.

It wasn't with actual GUI development either, or he wouldn't have called it a spinner. A spinner (Already defined by IBM) is something entirely different.

SWT calls what he was doing an ExpandBox and I've also seen them called Accordions.

It wasn't with actual GUI development either, or he wouldn't have called it a spinner. A spinner (Already defined by IBM) is something entirely different.

SWT calls what he was doing an ExpandBox and I've also seen them called Accordions.

Luckily, you there are workarounds, such as using Eclipse instead of swing and a different language to avoid checked exceptions.

IBM and a passel of other organizations who have based their application strategies on Java would put together an open source consortium that would support and guide Java. Something along the lines of the Eclipse or Apache foundations.

Thats where GMF comes in.

Eclipse differs from NetBeans in one significant way, which is that Eclipse is not specifically a Java IDE. I'm doing development with J2EE right now, and am aware of two tools that make this pretty easy:
MyEclipse which costs money, and Eclipse's own WST. So yeah, trying to get plain old Eclipse and Java to work well with J2EE stuff is difficult, but the tools I just mentioned are very well supported.

I can just as easily start working in C++ with Eclipse, because it's not designed for any one language. That's very powerful.

NetBeans makes it easier to work with J2EE right out of the chute, but Eclipse is more flexible.
I've used both NetBeans and Eclipse, and most of my team uses Eclipse, I use it mostly, and a lot of that is because I like Eclipse's interface to VCS better than NB. I also don't like how NetBeans puts jars in my Tomcat directory, and alters its configuration. I don't know if it does that with other servlet containers, but it does with Tomcat.

I'm not talking IDE use, I'm talking open source tools platform. While I personally prefer the Eclipse IDE to the NetBeans IDE, having actually coded for each as a platform, I can offer an opinion from experience: the Eclipse programming model makes just makes it easier to get things done. Most vendors seem to agree, which is why, with the exception of Sun, all the major Java vendors are Eclipse Foundation members (including my employer--naturally my opinions are my own).

Compare NetBeans on this footing and you'll see the difference.

given the title, i am pretty sure the gp was referring to UML2 http://www.eclipse.org/uml2/

Eclipse + Web Tools Platform. It contains a graphical XML Schema editor which is similar to XMLSpy's.

Eclipse + Web Tools Platform. It contains a graphical XML Schema editor which is similar to XMLSpy's.

Let's not forget the Visual Editor!

http://www.eclipse.org/vep

Way better than NetBeans Editor

• Native widget support: C Check, Java Check (SWT)
• Portable GUI code between platforms or even Window managers on the same platform: C No, Java Check (SWT)
• Native code execution for maximum performance where needed: C Check, Java Check (JIT even allows for profile data guided native code translationon on the fly which no C runtime can do that I'm aware of)
• Deterministic cost of algorithms: C Check, Java No (The promised pluggable GC API still missing)
• Susceptible to buffer overflows: C Check, Java No.

IBM developed their own graphical toolkit SWT which simply wraps native widgets since they were of the same opinion as people in general at that time, that Sun utterly dropped the ball on both their GUI initiatives (Swing and AWT). SWT enables GUIs to act and look like native platform GUIs since ... it relies on the actual underlying widgets of the platform the OS the app is running on. That is Gnome for Linux/Gnome, Microsoft widgets through Win32 API on Windows and whatever Apple is using on OSX.

Currently there is to my knowledge only one area where any sane person would use C, C++ or Assembly over more modern (read higher level) languages namely realtime programs. The reason why Java is no option in this case has to do with the absence of the pluggable GC interface (was hoping it would arrive with 1.5 but I guess we'll have to wait some yet). Another category where Java isn't suitable is for you typical "one-liner" programs (or general small command line programs designed to fit into the typical "unix" pipe chaining design) due to the slow startup time of the JVM (Unpacking of 35 MB zip file and loading of hundreds of classes needed or not during the JVM initialization).

Now unless you are creating a realtime program (such as a game for example), great performance can be obtained by mixing C and Java. Using C or assembler together with Java (or another higher-level language) when you want to optimize the bottleneck algorithm to use every ounce of your latest and greatest "Itanium processor". Minimizing the use of lower level languages decreases the maintenance cost if you're targetting multiple environments (zOS, AS/400, AIX, Solaris, Windows, OSX ..) since you only have to maintain platform specifics for the minimal amount of C/Asm code used instead of hundreds of thousands to millions of lines of code for your typical non-trivial application.

I'd argue that the vast majority of business software are not realtime systems and as such I doubt you'd notice a difference if the program was coded in C, Assembler, C# running on DotNet or Java since they all would appear the same from an interface standpoint and responsiveness which you would observe.

IBM's replacement of Notes code named Hannover is essentially a stripped down eclipse platform (really the Rich Client Platform offering) with a bunch of plugins added to the work bench for whatever features Notes currently implements.

As a current victim working at a company which is a Notes/Domino shop I really look forward to the Hannover release since it will be based on a fully documented and open platform. Being based on Eclipse I really look forward to the massive amount of inhouse plugins which will written shortly after the release. Really can't think of a more integrated base as a platform for my company's (or any company's for that matter) need of inhouse tooling

• Native widget support: C Check, Java Check (SWT)
• Portable GUI code between platforms or even Window managers on the same platform: C No, Java Check (SWT)
• Native code execution for maximum performance where needed: C Check, Java Check (JIT even allows for profile data guided native code translationon on the fly which no C runtime can do that I'm aware of)
• Deterministic cost of algorithms: C Check, Java No (The promised pluggable GC API still missing)
• Susceptible to buffer overflows: C Check, Java No.

IBM developed their own graphical toolkit SWT which simply wraps native widgets since they were of the same opinion as people in general at that time, that Sun utterly dropped the ball on both their GUI initiatives (Swing and AWT). SWT enables GUIs to act and look like native platform GUIs since ... it relies on the actual underlying widgets of the platform the OS the app is running on. That is Gnome for Linux/Gnome, Microsoft widgets through Win32 API on Windows and whatever Apple is using on OSX.

Currently there is to my knowledge only one area where any sane person would use C, C++ or Assembly over more modern (read higher level) languages namely realtime programs. The reason why Java is no option in this case has to do with the absence of the pluggable GC interface (was hoping it would arrive with 1.5 but I guess we'll have to wait some yet). Another category where Java isn't suitable is for you typical "one-liner" programs (or general small command line programs designed to fit into the typical "unix" pipe chaining design) due to the slow startup time of the JVM (Unpacking of 35 MB zip file and loading of hundreds of classes needed or not during the JVM initialization).

Now unless you are creating a realtime program (such as a game for example), great performance can be obtained by mixing C and Java. Using C or assembler together with Java (or another higher-level language) when you want to optimize the bottleneck algorithm to use every ounce of your latest and greatest "Itanium processor". Minimizing the use of lower level languages decreases the maintenance cost if you're targetting multiple environments (zOS, AS/400, AIX, Solaris, Windows, OSX ..) since you only have to maintain platform specifics for the minimal amount of C/Asm code used instead of hundreds of thousands to millions of lines of code for your typical non-trivial application.

I'd argue that the vast majority of business software are not realtime systems and as such I doubt you'd notice a difference if the program was coded in C, Assembler, C# running on DotNet or Java since they all would appear the same from an interface standpoint and responsiveness which you would observe.

IBM's replacement of Notes code named Hannover is essentially a stripped down eclipse platform (really the Rich Client Platform offering) with a bunch of plugins added to the work bench for whatever features Notes currently implements.

As a current victim working at a company which is a Notes/Domino shop I really look forward to the Hannover release since it will be based on a fully documented and open platform. Being based on Eclipse I really look forward to the massive amount of inhouse plugins which will written shortly after the release. Really can't think of a more integrated base as a platform for my company's (or any company's for that matter) need of inhouse tooling

Have you tried Eclipse?

Crystal Reports was designed and developed by some of the most sadistic and shit headed sons of bitches ever. Any developer with any experience using Crystal Reports despises it, loathes it, has fantasies of strangling the ignorant shit headded fucktards that created it.

Ah, someone who shares my opinion of Crystal Reports :)

Fortunately, I convinced my company to switch to JasperReports. But I still have quite a few awful Crystal Reports to maintain until we get a chance to port them over.

BIRT also looks cool.

I think that for Eclipse to be fully embraced by Linux application developers, the CDT plugin will need to mature some more. I'm not seeing Java become more adopted.

Anyway, I tried working with Eclipse + CDT, but for medium-sized applications programmed in C (> 5000 lines) it's not really nice.

• The indexer is very slow (but that's being worked on) and in my experience, gets in the way of other background processes. Turn it off and you lose
• Refactoring is extremely limited, not even 'extract method'.
• Editor is not equal to the Java editor yet.
• "Clicking through" (i.e. CTRL + left-click) takes you to a header file, while often you want to see the implementation. The workaround is to right-click and choose Open Definition, but don't do this immediately. You might end up in a similarly-named function which you didn't include through a header file.
• Hovering over a function will show the start of the function definition, but only if the function body is located in the same file. Otherwise nothing will be shown but the function name.
• Hovering over a constant will show nothing.

On the other hand, these guys are REALLY working on it. I especially applaud Doug Schaefer and the rest of the team too, of course.

Open Source Champion IBM is the single largest patenter in the WORLD

That's right. If you lack the cluefullness to observe the obvious in your own oxymoronic illustration: that IBM is no "Open Source Champion" but merely an opportunistic leach; you have clearly checked out of the reality department long ago. Software and business method patents do not have a "quality problem", they are fundamentally structurally unsound. Even Bill Gates understands this.

If you've spent any time at all with an IBM sales executive, you would realize that IBM's open source strategy is simply a way to bait people into using software which will hopefully segue into proprietary upgrades.

As RMS has so elequently and accurately stated over and over again: the greatest impediment to software development is not innovation - we have had plenty of that with no help from the USPTO. The greatest impedement to software development is the creation of large scale systems. Because of software patents, any software project of any substance must navigate a legal minefield. That is an impedement to progress, much more so than any threat to the pretensions of petulant greedy developers who think their little brain farts should feed their grandchildren.

It'd be nice is Venkman was updated for 1.5. I loved the thing, but left it behind when I upgraded.

On a related note, Eclipse has the Ajax Tools Framework proposal that looks to be very promising for developers. I currently use Eclipse and the WTP for JSP/Struts development, and its excellent, but debugging javascript is still a pain.

There is supposedly going to be an eclipse plugin. http://www.eclipse.org/proposals/atf/

I've been using RoR for a couple of projects (small) the last few months. I've found it capable of running on OSX and M$ well enough. My research has shown the main difficulty for most is in deploying a production install cleanly. However, these problems are likely addressed (search on RoR production deploy for more info) in common deployment scenarios.

As for IDE's.... The "Ruby Development Tool" (RDT) for Eclipse has nice potential! It's home page is: http://rubyeclipse.sourceforge.net/. Naturally, it requires Eclipse.

HTH

Personally, I generally avoid using AWT directly -- but it supports many things that you marked as "N/A". For example:

Display an image -> java.awt.image.BufferedImage
Display text and image -> java.awt.image.BufferedImage
Generic container of other controls with a border and title -> java.awt.Frame
Add items to the system tray -> java.awt.SystemTray
etc etc

Also, while you do comment on the fact that SWT doesn't come with the JDK, you say "If you are developing only for one platform, SWT has an advantage in host compatibility"... that's not quite accurate... IBM has been notoriously behind on JDK implementations (ie: how long until it supports the JDK1.6 features?). The SWT FAQ says that it is built on JDK1.4, so it is already 2 major versions (a few years) out of date. Also, their download page ( http://download.eclipse.org/eclipse/downloads/drop s/R-3.1.2-200601181600/index.php#swt ) doesn't even show my server platform (FreeBSD) on the list...

Personally, if the library requires a native download, I'm not using it -- too much hassle to maintain.

Ever tried to open a print dialog on linux with SWT? After spending a few days learning SWT I stumbled upon this bug which has been known for over three years. https://bugs.eclipse.org/bugs/show_bug.cgi?id=2479 6/
So much for SWT apps being portable even between the platforms that they support!

Actually no, there is a binary component to SWT because it wraps native widgets. When you download the libraries, you have to download the SWT library appropriate for your platform. 64 bit support for windows is (sorta) under development See bug 57151 for the remaining issues

https://bugs.eclipse.org/bugs/show_bug.cgi?id=5715 1

thats interesting, seeing as SWT is written in java, and java code is totally portable... http://www.eclipse.org/articles/Article-SWT-Design -1/SWT-Design-1.html

Also. Who needs all these widgets anyway? I fly with System.out.print();

The model is developed using ArgoUML. The output is a zipped XMI file that I convert to a EMF ecore model using the argo2ecore Eclipse plug-in. From there I generate the model and editor code using EMF. After that, I use the Elver plugin to generate the corresponding hibernate mappings.

So from the UML source, I can generate EMF model and edit code to serve the presentation and hibernate mappings for persistence to an RDBMS -- all using free software.

There are a couple of big challenges, namely distributed object persistence (including transactions). For this we're attempting to use the EMF SDO (Service Data Objects) implementation. Also implementing business behavior is a bit of a challenge since ideally we'd be able to mark certain EMF methods as "biz logic" such that the factory generates a stub for the client, and I could fill in real business logic for the server side.

If you're doing PHP and considering either CVS or SVN I'd recommend :

• Eclipse
• Eclipse Webtools
• PHP Eclipse

CVS integration is built into the Eclipse platform. If you're going to use Subversion integrate in Eclipse with Subclipse.

When I'm working on a project where I have NO IS&T to support me I set up my own Subversion server on an Apache box (usually my own machine) download Eclipse, point it to the update sites for all the above and it's off to the races!

If you're doing PHP and considering either CVS or SVN I'd recommend :

• Eclipse
• Eclipse Webtools
• PHP Eclipse

CVS integration is built into the Eclipse platform. If you're going to use Subversion integrate in Eclipse with Subclipse.

When I'm working on a project where I have NO IS&T to support me I set up my own Subversion server on an Apache box (usually my own machine) download Eclipse, point it to the update sites for all the above and it's off to the races!

But XUL isn't a crossplatform widget set. It's a widget set built explicitly for Mozilla. It's written in this weird mix of CSS and C++ and XBL and JavaScript that ensures that almost no one will understand how it works. XUL is completed tied with the browser portion. You can't just render widgets with XUL, you also get the entire CSS, HTML, XML, XBL, XPCOM, and JavaScript libraries along with it.

What's worse is that even with all this crap XUL does to "blend in" with my OS, it still goofs it up. Under any platform that isn't Windows XP, the form widgets are some weird "default" and not styled appropriately.

You know those webpages that attempt to mimic rich client behaviors through JavaScript? XUL is essentially a very complicated library that does just that. And like most of those libraries, it's very, very fragile.

For what it's worth, GTK+ is also a very crappy cross-platform widget toolkit. The only crossplatform widget toolkit I've ever really liked is the SWT. I think a C++ port of SWT would have been perfect for Mozilla and a far more obvious solution than inventing a weird XML/CSS/XBL/JavaScript/XPCOM ... thing.

Let's not leave jEdit off of that list. ... Yeah, I've tried Eclipse, and not to get into an IDE war, but it just seemed too heavyweight for me.

There is no war: Eclipse is an IDE and jEdit is an editor. Just look at the sites.

jEdit: "jEdit is a mature and well-designed programmer's text editor with 7 years of development behind it."

Eclipse: "Eclipse is an open source community whose projects are focused on providing an extensible development platform and application frameworks for building software."

See? Two completely different beasts. (Disclaimer: I use both on a daily basis :)

I won't go down the NetBeans versus Eclipse, IBM versus Sun, or SWT versus Swing battle. Those are all non-issues to the bigger picture.

Competition makes better systems right? Sun must agree with you since they pay for their NetBeans developers to blog online. Most of its just simple bashing Eclipse to keep the battle roaring. Sure, most of it is very objectionable and often times questionable in accuracy. I have been compiling some great links to some very interesting blog entries by lead Sun developers/managers aimed at the Eclipse foundation (not the Eclipse IDE, but the foundation itself). I've even watched Eclipse members ask Sun to participate in Eclipse, or even become a strategic partner to Eclipse:

http://www.eclipse.org/membership/members/strategi c.php

Stupid Eclipse foundation keeps wanting to work as a team. I mean, you can do much more as an individual than you can ever do as a team.

Let me go ahead and plug a couple projects for the disillusioned masses reading this:
Free Delphi Alternative:
Lazarus
Free C++ IDEs:
Anjuta, Code::Blocks, KDevelop (works with other langs too I believe)
Free Python IDE:
Stani's Python Editor
Free Visual Basic Alternative:
Gambas
Free Java (and others) IDE:
Eclipse

But honestly, that's ok with me. It's only $30 for the personal license, and they license per developer not per seat/cpu... so you are welcome to install it on as many machines as you use (e.g. desktop and laptop).

I do quite a bit of Python coding, and after checking out Eclipse, SPE, and a few others, I'm still a huge fan of Komodo. I've easily gotten $30 of value out of using it.

Plus, if you watch the bargain sites carefully, they occasionally run promotions where you can get Komodo for free. :)

That said, YMMV. I know a lot of people who would disagree with me and would rather use Eclipse with PyDev.

The OSGi framework mentioned is very cool indeed. It's best known usage is the Eclipse IDE. It can also be used in web applications, where especially the Wicket component web framework delivers a very good integration. There are several users working with OSGi compliant frameworks (most notably Oscar, which is in the Apache incubator under the name Felix), and Wicket. I have used Oscar and Wicket in a commercial product and we were very satisfied with the runtime re-deployment of new components.

http://www.eclipse.org/vep/WebContent/main.php

You might want to give eclipse another shot.
Eclpse Webtools just recently went 1.0 and it inlcludes much of the stuff that you would pay mycelcipse for.

• The syntax, which you can adapt to, given a good editor with auto-indent and syntax highlight.
• The fact the standard libraries, despite providing a wealth of datastructures, are lame or non-existant for doing anything actually useful (heavy duty I/O, sockets, GUI, etc). Compare this with C, where nothing is standard per ANSI C, but there are libraries which do everything for free bundled in the OS.
• There is no really good free and multi-platform implementation. For C you have GCC. It works on basically everything you may care about (from ARM PDAs to s390 Mainframes). For Java you have Sun's JDK, which despite not really being open source, is a free (as in beer) download and allows you to develop payware without paying a dime to Sun. The following is a couple years old info, but I am guessing things have not changed much yet: Emacs LISP isn't does not compile into native binaries and is not Common LISP compatible. CLISP does not compile into native binaries and is not 100% Common LISP compatible (almost). CMUCL is buggy, used to have an incredibly lame garbage collector which made you twiddle your thumbs every 5 minutes, and a had poor user interface to boot, GCL is not Common LISP compliant by a longshot. The good tools are payola like Allegro. Contrast this with Sun Java JDK + Eclipse. There is no contest... Even Microsoft is handing out at the moment Visual C# Express for $0 which can be used for commercial use.

Note that the IDE is based on the Eclipse platform! Good work Adobe!

Damien

Many programs do not run (we use BlueJ and Eclipse, neither work on the Intel).

What an amazing surprise, since Eclipse has always worked perfectly on under Mac OS X before.

As someone who spends a lot of time in Eclipse, the fact that it's never quite worked right under OS X is the only reason I'm still typing this on a PC running Windows. While it's unfortunate for early adopters like yourself, I'm kind of glad it's altogether broken because perhaps this will force Apple to pay more attention to the issues that have been there all along.

Many programs do not run (we use BlueJ and Eclipse, neither work on the Intel).

What an amazing surprise, since Eclipse has always worked perfectly on under Mac OS X before.

As someone who spends a lot of time in Eclipse, the fact that it's never quite worked right under OS X is the only reason I'm still typing this on a PC running Windows. While it's unfortunate for early adopters like yourself, I'm kind of glad it's altogether broken because perhaps this will force Apple to pay more attention to the issues that have been there all along.

Depending on the goal of your application, yes. As for GUI toolkits, I recommend SWT.