BEA has chosen to join the Eclipse foundation. BEA will participate as a top-level "Strategic Developer" member, paying as much as $250,000 per year in dues, and ship a commercial product based on Eclipse within one year, according to the Eclipse Foundation. BEA is proposing to lead a language development tools project based on the company's Javelin compiler framework for Java, according to Eclipse.

This is a big deal for Eclipse. There has always been "issues" with BEA joining, due to the IBM-ness of Eclipse. BEA joining follows on from them participating with Eclipse with AspectJ 5.

Read more: BEA to join Eclipse open source tools foundation

I saw this on JavaWorld but ignored it because the date was February 2004, so I assumed that something happened in the last year that make BEA move away from eclipse.

I guess that date is wrong.

It is indeed a great move. Workshop can retain its features such as portlets, weblogic integrator business processes, solutions as well and leverage from wide range of eclipse plugins.

This is hopefully good news. What does it mean for WebLogic Workshop?

BEA’s decision to join the Eclipse board and move WebLogic Workshop to be an Eclipse plug-in is good news for WebLogic Server users. Eclipse as an IDE provides many features not previously available in WebLogic Workshop, including a good CVS client, a professional-level code editor, and unit testing support.

BEA’s decision ends the battle between Eclipse and NetBeans. Even with IBM’s head-to-head WebSphere competition, BEA still chose to support only Eclipse.

The move does not do much for the open-source world since BEA’s deliverable is a commercial and proprietary plug-in module that runs in the Eclipse framework. So there will be no open peer-review of the WebLogic Workshop code. Users will still need to go back to BEA for improvements and maintenance.

The move means significant changes for existing WebLogic Workshop supporters who build extensions to Workshop. Extensions that make GUI level changes to Workshop have no migration path. These will need to be rewritten to use Eclipse SWT Plug-in APIs. BEA in a briefing today said they intend to provide migration tools focused at upgrading source artifacts.

A theme appears to be emerging from BEA with this announcement: They see ease-of-use and ease-of-integration as the benefits that they will sell the WebLogic platform on against hand integrated solutions from the open-source world. That makes sense to me. For instance, they were an early supporter of annotations (JSR 175 and 181) and WebLogic Workshop makes it very easy in a visual manner to build J2EE and Web Service applications.

BEA has been making a lot individual announcements lately: Beehive 1.0 release coming up, WebLogic Server 9.0 (codename Diablo) now in Beta, improvements in WebLogic Integration and Portal Servers, and additional support for Java Server Faces (JSF.) I wish I had a master timetable for all of this. It appears to me that BEA will have a major release in Summer 2005 that will incorporate a lot of these but it would be great to hear that from BEA itself.

The news should also precipitate a reaction from Oracle and Borland. Oracle will likely have to support Eclipse to keep its own tools efforts from appearing to be fragmented.

-Frank Cohen
http://www.pushtotest.com
See my blog at: http://www.pushtotest.com/thecohenblog/simpleblog_view

BEA’s decision ends the battle between Eclipse and NetBeans

yeah, it seems Eclipse will win the battle...
- Eclipse: SAP, BEA, IBM, HP, Intel, etc...
- NetBeans: Sun.

Is Swing soo bad to compare with SWT (which I don't feel so)? What was the reason why BEA has chosen Eclipse?

Cheers,
Lofi.

I don't think Swing is the bad per se when compared with SWT, especially for most normal business applications. But I personally feel that there is no Swing app out there that can yet compare to the responsiveness of a native application. Eclipse gives you that responsiveness. Again, for some apps, the small difference isn't that noticeable or important. But for coding, it makes a big difference. You're doing so much so quickly that any delay becomes agonizingly apparent. I use eclipse for my main development and several swing-based apps for other things, like UML (MagicDraw) or DB work (DBVisualizer). I can see the difference every day, and would love to have eclipse versions of those other tools.

Note that the responsiveness I'm talking about I've seen on both Windows and OSX.

<drew>
I use eclipse for my main development and several swing-based apps for other things, like UML (MagicDraw) or DB work (DBVisualizer). I can see the difference every day, and would love to have eclipse versions of those other tools.
</drew>

Yes I agree with you... Eclipse, Firefox, Thunderbird look very neat and work very fast (responsive)...

So, the best way is to re-write all Java Swing apps in SWT, right? :-) If NetBeans uses SWT, maybe more devs will use it?

Cheers,
Lofi.

I thought eclipse was working on bridging swing and swt. I remember seeing a screen shot last year and it looked like their work was progressing nicely. By working together I mean having swt use swing widgets to make it easier for existing swing apps to plug into eclipse.

peter

Yes I also saw this, but then I won't see the responsiveness of pure Eclipse apps... If my apps should be fast and responsive I would do a 100% Eclipse/SWT development...

Lofi.

I've been using J as a text editor for the past year. It is 100% Swing and it is fast. When I compare it against Eclipse for editing Java code I don't see SWT's advantages. -Frank

it is fast, u can see that in intellij idea, it is swing based and is fast,it is netbeans that is really bad and lack several important features

I've been using J as a text editor for the past year. It is 100% Swing and it is fast. When I compare it against Eclipse for editing Java code I don't see SWT's advantages. -Frank

Seems like you and several other posters here have overlooked the most probable reason as to why BEA is choosing Eclipse over Netbeans - and it has absolutely nothing to do with either SWT nor Swing, nor the speed of any of those for that sake:

 - Eclipse is simply at better foundation to build an application development framework on top of than Netbeans.

Eclipse makes it easier to build appserver integration, debugging support, CVS integration.

Eclipse also has a more mature and better designed plug-in architecture, which makes it faster and easier for BEA to switch to Eclipse than to Netbeans. It is for example very easy to build plugins for eclipse to do modelling or other applications that needs to have 'semantic/structural' knowledge of the code, as opposed to just being plugins that does some job on the text in a text file.

it might be slow at first, but it may ease the transition. especially in the case where there's an existing app that is large. having used both swing and swt, I like swt api better. plus, swt looks much nicer, but that's a personal preference.

peter

There is an SWT-AWT bridge.

But its mainly for being able to integrate AWT widgets (like charting and such).
Anything more than that would be a mess - you would never get things like colours/l&f/fonts to match...

-Nick

I still use Net Beans alongside IntelliJ. When I need a visual editor for Java the Net Beans is easily the best I've found. I've used Eclipse a bit but to be honest I don’t get on with it but that's just a personal thing – I fell in love with IntellIJ the first time I used it and have stuck with it ever since. The best thing about the Java world though is that you have a choice – both free/OS and proprietary. If you are developing in .NET and don’t like, Can't afford Visual Studio you’re pretty much screwed. I certainly hope Net Beans and Sun's Visual Studio Creator survive alongside Eclipse, IntelliJ and the others.

The SWT/Swing debate is quite interesting to me. Swing has always hot lots of advantages over AWT and SWT as a cross platform library but it had two big problems when it first came out: it was horribly, horribly slow, and it looked awful in a kind of "Fisher Price my first User Interface" kind of a way.

Sun put a lot of work into making it faster and it has got pretty good, for this reason and also because machines just got quicker and developers gradually worked out what made it fast and what it made slow. Apps like IntelliJ and more recently Net Beans and Sun's Java Studio Creator have shown that you can have large Swing based apps that run at a decent speed. More and more of the tools I use in my daily life are Swing based (IntelliJ, Ming’s DB Visulizer and Oracle's DB tools, monitoring tools like Omegamon and Tivoli, and JEDIT to name a few). Where SWT still scored over Swing until very recently was that SWT apps look like Windows apps which doesn’t matter much for developer tools but matters a lot for end user applications. The good news is that Sun picked that up and made big improvements for J2SE 5. Its quite easy now to have good, fast Seeing apps on Windows that look like Native Windows apps but run just as well on Linux, Mac OS X whatever. And I love being able to skin them so the user gets the look that matches the environment they are running on.

I'd love to see some work done on the Swing programming model itself. In particular I’d like someone to look try and figure out am easier way of adding custom widgets to the set of components – both QT and Apple seem to do this rather well in a way that Swing, frankly, doesn't.

I’d also like to see the Eclipse people move Eclipse over to Swing but I don’t suppose that will happen!

The SWT/Swing debate is quite interesting to me. Swing has always hot lots of advantages over AWT and SWT as a cross platform library but it had two big problems when it first came out: it was horribly, horribly slow, and it looked awful in a kind of "Fisher Price my first User Interface" kind of a way.Sun put a lot of work into making it faster and it has got pretty good, for this reason and also because machines just got quicker and developers gradually worked out what made it fast and what it made slow.

Ok, so you point out on two Swing shortcomings:
 * L&F
 * speed
These issues can be remedied by an end user with faster machine and a nice skin. What cannot be fixed, though, is that Swing do not use native controls. This simple fact means that all standard features implemented by OS for standard controls should be reimplemented by SUN, if it decides to do so. And each time a new OS version comes out, SUN would have to keep up. Does SUN keep up? Apparently, no. So many OSes, so many versions, so many desktop managers, plugins, ActiveX controls, etc. How about drag-and-drop from Swing app into native app or vice versa? With Swing developers have to reinvent the wheel, actually the huge set of wheels, connected to each other in mind-boggling pattern.

Thus, SWT is better simply because it uses standard controls, which provide standard features for OS desktop.

On the other hand, SWT semantics represents how GDI/CommDlg/CommCtl looked 15 years ago. With Avalon/XAML release, old WinAPI will get obsolete, and SWT will get obsolete too. Another interesting point is that not all applications use native controls. I was surprised that MSIE or Office apps, for example, do not use standard controls, they draw "control"-like images and mimic behavior of standard controls. How that is different from Swing?





Apps like IntelliJ and more recently Net Beans and Sun's Java Studio Creator have shown that you can have large Swing based apps that run at a decent speed. More and more of the tools I use in my daily life are Swing based (IntelliJ, Ming’s DB Visulizer and Oracle's DB tools, monitoring tools like Omegamon and Tivoli, and JEDIT to name a few). Where SWT still scored over Swing until very recently was that SWT apps look like Windows apps which doesn’t matter much for developer tools but matters a lot for end user applications. The good news is that Sun picked that up and made big improvements for J2SE 5. Its quite easy now to have good, fast Seeing apps on Windows that look like Native Windows apps but run just as well on Linux, Mac OS X whatever. And I love being able to skin them so the user gets the look that matches the environment they are running on. I'd love to see some work done on the Swing programming model itself. In particular I’d like someone to look try and figure out am easier way of adding custom widgets to the set of components – both QT and Apple seem to do this rather well in a way that Swing, frankly, doesn't.I’d also like to see the Eclipse people move Eclipse over to Swing but I don’t suppose that will happen!

I am sorry, the last big chunk of text starting with "Apps like IntelliJ..." is not mine. TSS needs editing feature ;)

This MSDN article describes the reasons for windowless controls:
A [windowless] control can make efficient use of its container's window rather than having a window of its own. This results in using fewer system resources and improves performance through faster activation/deactivation. ... When drawing itself, a control asks the container ... for a device context and returns the device context to the container after drawing into it. Providing windowless support not only provides transparency for interesting visual effects, but also further improves the performance of the control.
Also, [windowless controls] can participate in overlapping 2-D layout, can maintain a specific z-order, and can exhibit transparency as well as irregular shapes.

Despite that windowless controls are windowless, they are still controls. Afaik, this is not the case with Swing controls, which are just pictures.

Is Swing soo bad to compare with SWT (which I don't feel so)? What was the reason why BEA has chosen Eclipse?Cheers,Lofi.

I don't think it was Swing vs. SWT. I think it is clear today that the architecture of Eclipse with its modularity and extensibility is a big reason for its success. Our engineers at BEA obviously weighed a lot of different parameters in choosing this framework.

-- Jesper Joergensen, BEA Systems

<quote>
I don't think it was Swing vs. SWT. I think it is clear today that the architecture of Eclipse with its modularity and extensibility is a big reason for its success.
</quote>

agree, the plug-ins capability of Eclipse is wonderful: "eat your own dog food" and "everything are plug-ins". So, if Sun wants to be successful with NetBeans, they have to "copy" the plug-ins architecture of Eclipse, so that all Eclipse plug-ins can be used within NetBeans as well without any change :-)

After this we can see whether developers like Swing more than SWT or another way around :-)

Cheers,
Lofi.

<quote>
So, if Sun wants to be successful with NetBeans, they have to "copy" the plug-ins architecture of Eclipse, so that all Eclipse plug-ins can be used within NetBeans as well without any change :-)
</quote>

I now believe how good can marketing be.
FYI NetBeans development model is the same as
Eclipse's. NetBeans has a platform and IDE is just
a set of plugins sitting on top of the platform.
Actually Eclipse copied that model from NetBeans
and probably build a better infrastructure for developing
plugins.

I've seen SWT performance on windows but when I installed
Eclipse (GTK2) on my linux box it was really slow. Even NetBeans 3.5.1 was faster.

I think everyone should give a try to NetBeans 4.0 and upcoming
4.1 Beta. I'm more than sure you'll be pleasantly surprised.

Its not about SWT. You would use Eclipse in spite of SWT.

Eclipse is basically a client-side application container. Development is at a much higher level.

The eclipse team have admitted that if they had their choice over again, they would have used Swing. SWT support across all platforms is a major PITA for them - but at the time (a long while ago) they didnt have faith in JVM/Swing perf ever being good enough.

-Nick

BEA has been making a lot individual announcements lately: Beehive 1.0 release coming up, WebLogic Server 9.0 (codename Diablo) now in Beta, improvements in WebLogic Integration and Portal Servers, and additional support for Java Server Faces (JSF.) I wish I had a master timetable for all of this. It appears to me that BEA will have a major release in Summer 2005 that will incorporate a lot of these but it would be great to hear that from BEA itself.

Let me try and give a bit more complete timetable for our roadmap. During 2005, BEA will release most of the components for our next generation platform. Here is a rough breakdown:

Spring 2005
- Liquid Data 8.2

Summer 2005:
- Apache Beehive 1.0
- WebLogic Server 9.0
- "QuickSilver"
- Tuxedo 9.0
- WebLogic Enterprise Security 4.3
- JRockit 5.1

Later in 2005:
- WebLogic Portal 9
- WebLogic Workshop 9 (with support for Eclipse and Beehive)
- Liquid Data 9

There will be other releases than those listed here and everything is as usual subject to change. QuickSilver is the code name for BEA's SOA infrastructure foundation product.

-- Jesper Joergensen, BEA Systems

Hi Jesper,

In the BEA roadmap for 2005, you didn't mention about WLI9.0 release. Is it getting released along with Portal9.0 ?

Thanks.

Bijan

So there will be no open peer-review of the WebLogic Workshop code. Users will still need to go back to BEA for improvements and maintenance

Just as users go back to Jetbrains for improvements and maintenance of IntelliJ. Seems to have worked for them ;-)

IMO, BEA should have done this 2 years ago...

Just as users go back to Jetbrains for improvements and maintenance of IntelliJ. Seems to have worked for them ;-)

Big difference. I can take the Java code that I developed with IntelliJ, and continue to maintain it in any non-IntelliJ environment.

Just as users go back to Jetbrains for improvements and maintenance of IntelliJ. Seems to have worked for them ;-)

Big difference. I can take the Java code that I developed with IntelliJ, and continue to maintain it in any non-IntelliJ environment.

...as you will be able to in WebLogic Workshop.

Any code asset that you develop using WebLogic Workshop 9 will have a standardized format: XML, JSP code, Java code with JSR-175 annotations, etc. You can take this code and work on it in any other IDE/text editor. These are all broadly accepted standards with rich tool support by many different vendors and open source projects.

BEA’s decision ends the battle between Eclipse and NetBeans.

Was there a battle for BEA between Eclipse and NetBeans? or do you mean a general battle for users? If the latter, I doubt this ends anything. NetBeans 4.0 is a huge advance, now (finally) has most of the refactoring capability that Eclipse has always had, and has seamless JSP/Servlet, Swing GUI development, and Java 5.0 support fully integrated as shipped. I also find the Swing UI provided by Java 5.0 to be both attractive and fast. The performance improvement over older versions of NetBeans is significant (and was necessary!).

I used to be an enthusiastic Eclipse user, as it was positioned as the successor to VisualAge for Java - one of my all-time favourite IDEs. However, not having built-in support for GUI development and J2EE put me off, and the slow support for Java 5.0 finally made me switch to NetBeans. I'm not likely to switch back anytime soon.

I think Eclipse is obviously definitely winning the battle of plugin support, but there are a large number of contented NetBeans users out there.

BEA’s decision ends the battle between Eclipse and NetBeans.

...and the slow support for Java 5.0 finally made me switch to NetBeans. .

This is why I think it is so important to have NetBeans thrive as a valid competitor to Eclipse. Otherwise, it will be Eclipse that dictates the adoption rate of new Java versions, not the JDK. (Maybe it already does.). I know I stayed with Intellij for its JDK 5 support (since May last year!).

Bill

BEA’s decision ends the battle between Eclipse and NetBeans.

Baloney.

Sure, eclipse has garnered a lot of support recently. I've even heard that Oracle has moved the next version of their IDE to be based upon Eclipse.

But to say that the battle is over is just flat ass wrong. Sort of like those who have said, continually, that Apple was going out of business any day now for the last 20 years.

Netbeans in it's current incarnation is a fine IDE with many features that Eclipse does not have. If you are running it on the latest JDK (1.5) on a decent machine, it is every bit as fast as eclipse for most things. Speed is really no longer an issue as is was in the early netbeans/forte days.

Netbeans seems to be developing very rapidly (i.e. 1.5 support, etc). Have you seen the new profiler for netbeans? This is one kick ass tool I have played with that is supposed to be final sometime in april:

http://profiler.netbeans.org/

Also, have you tried the built in web and gui capabilities of netbeans? Have you seen the cool ant based project files (so you can do everything completely outside the ide if needed)? Have you seen that the next version will have J2EE support (EJB, webservices, blueprints, etc)?

Netbeans will continue to develop and advance no matter what happens with eclipse. We need choice in the free java IDE world, and netbeans is an excellent one.

Mike

... have you tried the built in web and gui capabilities of netbeans? Have you seen the cool ant based project files (so you can do everything completely outside the ide if needed)? Have you seen that the next version will have J2EE support (EJB, webservices, blueprints, etc)?

I used to use Netbeans!

Then they pilled feature on top of feature and it got to be fat, slow. I left Netbeans not becuase Eclipse (or CodeGuide I used also) was better, but becuase Netbeans was slow.
The people currently in charge of Netbeans don't understand that, and keep piling on features.

So I do JDNC(Swing) in Eclipse and it works great. I fear that somehow Sun will think it good idea to combine JDNC w/ Netbeans.

Less is more.

.V
ps: In 2 weeks there is a Swing deployment online chat coming up, those tend to be good: http://java.sun.com/developer/community/chat

<blackquote>I used to use Netbeans!Then they pilled feature on top of feature and it got to be fat, slow. I left Netbeans not becuase Eclipse (or CodeGuide I used also) was better, but becuase Netbeans was slow.
You won't have this conculsion if you have used the Netbeans 4.0

Exactly, NetBeans 4.0 is superb fast. I myself have used it much. I agree earlier versions of NB was slow but this 4.0 runs like wind. Sun has made major updates and improvements in this version.
On the other hand, Eclipse Version 3.0.1 is too slow. We are working on a project and we are using Eclipse. My personal opinion is to use NetBeans 4.0 or if u want more functionality then use SJSE 7.0.
Sun has come up with new vision. It's SJSE 7.0 is a excellent tool for RAD and for me, being in touch with this IDE since it was called as Forte, it's never been so fast.
I suggest all of u to test SJSE 7.0 trial version for 90 days. All Eclipse guys would find it far-far better then Eclipse.

I forget where I heard this, so perhaps someone with knowledge of it can clarify. Netbeans 4.0 on window uses windows native widgets and performs better than netbeans on solaris, which defaults to swing/awt widgets.

back on topic, the thing I like the most about eclipse architecture is the API and Plugin framework. hopefully this will mean weblogic's tools will plug with third party tools nicely. that's my hope anyways.

Then they pilled feature on top of feature and it got to be fat, slow. I left Netbeans not becuase Eclipse (or CodeGuide I used also) was better, but becuase Netbeans was slow.

It certainly was! Years ago I would occasionally try NetBeans, and it was so slow that I could not believe anyone could possibly use it. But, that was years ago, and things are very different now.

Less is more

I'm not sure I agree in the case of an IDE. I want lots of nice tools in my IDE: Refactoring tools, GUI designer, debugger, J2ME support, J2SE support, J2EE support etc. I realise this is just personal preference - I used to be a Smalltalk developer and I am used to having a very rich development environment.

Truly the end of the innocence.

Does it mean the end for WorkShop?


Marina
http://www.servletsuite.com

Does it mean the end for WorkShop?

Absolutely not.

BEA will be releasing the next version of WebLogic Workshop later this year. The new thing is that we will be using the Eclipse framework for that version.

You will get the best of both worlds: The IDE framework with the biggest ecosystem together with the service-oriented and metadata based programming model that Workshop pioneered.

-- Jesper Joergensen, BEA Systems

In my previous company, we evaluated workshop for doing a Struts app. We loved the features it provided but found it near IMPOSSIBLE to generate portable code (even when we were using non BEA stuff). This was the ONLY reason why we did not go with workshop.

I also brought this up at several BEA netinars. Yes, I realise the need for platform specific extensions for many customers, but the IDE should not tie you to the platform unless any specific extension is used.

Hope this will be changed in the next version.

This is not specific to Workshop. Even WSAD generates horribly IBMized code if you try to use JSF (even when you are not using IBM JSF component extensions but using the default components)

We heard the community lound and clear on that one. Your characterization of

"the need for platform specific extensions for many customers, but the IDE should not tie you to the platform unless any specific extension is used."

is exactly the target we need to hit with the next relase, or there isn't much point in doing it, frankly.

Pieter Humphrey – BEA Systems

We heard the community lound and clear on that one. Your characterization of "the need for platform specific extensions for many customers, but the IDE should not tie you to the platform unless any specific extension is used."is exactly the target we need to hit with the next relase, or there isn't much point in doing it, frankly.Pieter Humphrey – BEA Systems

Was the decision to move Weblogic Workshop based
on the RCP and OSGi feature of Eclipse 3.x series?

I am a die hard Eclipse user since 2.x. In 2003 my then
client standardised on JDeveloper 9.0i and my colleague
resigned from his contract. Before he went, he just let
loose trying out various downloads and MP3, and the
euphoria of finally realising a doom project (ages
before I did ; should have left at the same time )

The J2SE 5 support has been slow to through, but then,
I am like most J2EE developers, there is no need for it
when two leading application servers WLS and IBM are
not officially supporting the latest JDK. I think that
will happen when the J2EE 5 spec is finalised in line
with the J2SE 5. Like most things in Eclipse, it is not
release until it is ready, but when it is ready, man
it will blow your head. I know I remember the presentation
at JavaONE 2004 with Erich Gamma and they demoed the
new Eclipse SDK 3.0 then and show off how funky the
OSGi and RCP thing was. I remember everyone in the room
applauded, and then they had the same tremondous acclaim
and respect demonstrating the basic Eclipse 3 features.

I think the main selling thing for me in Eclipse that
is different to another IDE I have seen, is the concept
of Perspective, once I saw that it was just like those
bad-meaning-good Italio-American movies "Get the XXXX
outta here!"

========
Peter Pilgrim
http://www.xenonique.co.uk/

The J2SE 5 support has been slow to through, but then,I am like most J2EE developers, there is no need for itwhen two leading application servers WLS and IBM arenot officially supporting the latest JDK. I think thatwill happen when the J2EE 5 spec is finalised in linewith the J2SE 5.

BEA is very serious about J2SE 5. JRockit 5.0 was released in December and BEA has had been one of the drivers behind the JSR-175 metadata spec that is included in J2SE 5. WebLogic Server 9.0 fully supports J2SE 5 and is currently publicly available in beta.

Metadata as a core part of Java is a cornerstone of BEA's vision for simplified, standards-based development models. The programming model pioneered by WebLogic Workshop 8.1 was based on metadata and it is being evolved in the Apache Beehive project that depends on J2SE 5. WebLogic Workshop 9 on Eclipse will support Beehive and make full use of J2SE 5 metadata.

-- Jesper Joergensen, BEA Systems

The idea behind Workshop 8.1 was to simplify the programming model but we got push back on the portability point for obvious reasons. The next release has two very significant differences.

As this thread has mentioned, the IDE will be reimplimented as plug-ins for Eclipse. For WebLogic Server you will get PageFlows (graphical Struts), Controls and Web services development. With Portal you get the Portal designer and with Integration you get the BPM designer. We also announced plug ins for JRockit to do profiling and memeory leak detection and another for AspectJ.

The other big difference is that the framework is now an Apache Incubator project called Beehive, which now runs on Tomcat and other J2EE servers (I hear they have also have it running on Geronimo and Jonas). The plan is for BEA and/or the community to port it to other J2EE servers over time.

Eric
BEA Systems

Seems to me, BEA focused on portable code by open-sourcing XMLBeans, Pageflows, and Controls early on. I think Eclipse had to move farther away from IBM before BEA could move closer to Eclipse.

It was the right product at the right time but times have changed. Workshop, as a loss leader, increased productivity and traction for WebLogic Portal and Integration which, it turn, helped sell more server licenses.

Moving to Eclipse means that IDEs are not BEA's core competency so they don't have to hemorrhage money keeping up with a commodity market. Plugins, enabling technologies like Portal, Integration, XMLBean, Pageflows, and Controls, and GUI builders are the value-add BEA needs to de-commonitize its apps server.

I think Eclipse reached critical mass as a defacto standard a while ago so BEA is late in migrating. But as one move in an overall strategy, BEA seems to be walking the line between commoditization and Websphere pretty well. In a bake-off between Tomcat/JBoss, Websphere and BEA, any company looking to migrate its developers from Microsoft to a J2EE platform would see more similarities and lower learning curve between WebLogic and MS than with the others. Workshop provided that MS-style handholding but with a "free-will" kicker.

This acutally represents the beginning of a new direction for BEA WebLogic Workshop, which will simply be implemented on the 3.1 eclipse IDE framework going forward. Workshop will continute to be the best IDE development tool that unifies our platform (Portal, Integration) and for other BEA products that require a development tool interface.

When Workshop was first released, NetBeans nor Eclipse could really do what BEA needed to bring an innovation like annotation - driven development to the fore. Also, it is clear that the industry is converging on a single framwork, so it makes sense in every way to implement Workshop on Eclipse going forward. Great refactoring, brilliant CVS integration, the list goes on...

Pieter Humphrey, BEA Systems

I gave a presentation about Eclipse WebTools in January 2005 at the Portland Java Users Group:

http://www.pjug.org/pjug-eclipse-webtools-2005-01-25.ppt

WebTools is promising but it has a long way to go before it can compare to the web tools in IBM Rational Application Developer 6.0

I think the next step for Eclipse is be the container for business applications. The Eclipse plataform GUI has the necessary elements for end user interaction and its plugins usually will provide similar user experience if developed according the enterprise GUI guidelines. Plugins are also easy to develop and you don't need to reinveint widgets and gadgets each time you develop a new rich application.

|
|Eclipse plataform GUI has the necessary elements
|

It has ... if only they could make the learning curve less steep...

-Nick