Comments on: Is this really JBuilder?

By: kokkoonleong

kokkoonleong — Tue, 04 Dec 2007 04:14:13 +0000

The only reason I went into java was JBuilder. It was (not the past tense) an excellent tool. However, with Turbo JBuilder, Borland has just about abandoned it forte in GUI IDE. Previous versions of JBuilder had excellent GUI designer. VB and Delphi programmers will definitely not be attracted to JBuilder 2007. It might be strong in other areas but GUI-programmers should look elsewhere – maybe Netbeans which has improved its GUI designing capabilities in leaps and bounds.

By: John Hetherington

John Hetherington — Fri, 30 Mar 2007 07:57:10 +0000

I have JBuilder for about 2 years as a teaching tool at Diploma and Degree level programming.
We have just obtained JBuilder 2007, I had grave difficulty producing a Gui front end with it.
Nothing is intuitive with it, the palette is non-existent, the menus are confusing. All the database components are gone, no JFileChooser or JColorChooser, no dbswing, more dbswing. Yes some of the the beans are there.
JBuilder is no longer a RAD tool, its hard to imagine a bigger mess of what was a very promising tool although with Microsoft influence it is all very understandable. Sun Systems Netbeans is now on its own in the Java RAD arena.
I also use C++ Builder 6 which is a fantastic RAD tool especially with the STL and Boost Libraries.
Regards to all from a programming Tutor in a New Zealand Polytechnic

By: Matthew Dovey

Matthew Dovey — Thu, 28 Dec 2006 13:25:47 +0000

I can’t help feeling a sense of deja vu.

Not that long ago Borland made the move from a Windows based JBuilder to a Java based JBuilder – whilst ultimately a good move, this was not a painless transition:

i) the initial release despite being Java based ran on Windows only. I think it took a further major release before it became platform independent – likewise the initial JBuilder 2007 release seems to be Windows only, with other platforms to be supported with a maintenance update.

ii) quite a lot of functionality was lost in the initial java based version and it took a numer of releases before they reappeared (integrated Javadoc support springs to mind but I can’t remember what the others were – just that they existed).

iii) ironically, the move to a java based JBuilder coincided with the last rebranding attempt by Borland – the infamous “Inprise” fiasco where Borland forgot that the it was the name “Borland” that was so associated with IDEs and Development tools from programmers which had grown up and learnt their skills on the old Borland Turbo tools. I can’t help thinking that the “Codegear” branding may be as shortlived a mistake as the “Inprise” branding was.

By: Ian Hayes

Ian Hayes — Thu, 23 Nov 2006 21:43:43 +0000

If the new Eclipse based JBuilder product had been a single low price ($299?) all features offering then it might have had a chance.

Otherwise the words “flogging” and “dead horse” come to mind.

By: Mikey

Mikey — Thu, 23 Nov 2006 13:30:46 +0000

Make it 3 for David’s comments – bad move Borland! The new lower pricing model is what you guys should have done when you launched JBuilder 2006 or JBuilder X. I believe this is the one the big reasons you have lost users to Eclipse.

By: Larry

Larry — Thu, 23 Nov 2006 11:52:49 +0000

I’ll second David’s comments. With regard to GUI design in Eclipse, it is just not there yet… and I also misread the original Register article as David did, since that’s the obvious fly in the Eclipse ointment.

We were required to use Eclipse for one of our projects (for compatibility with an existing project) and our developer’s perception is that although touted as a general purpose application development environment, Eclipse’s origins as a framework for an IDE are all too apparent and make for some unexpected difficulties developing GUIs.

By: David Morris

David Morris — Thu, 23 Nov 2006 10:39:32 +0000

Hmmm. Interesting article, Tim. I original misread the article on The Register. I thought BOrland had kept their GUI designer. Having read your article and re-read The Register, I see I had mis-read it. This is a bad move as I see it. My only experiences with the Eclipse GUI designer have been bad. I've found it slow which is why I could never entertain a move from JBuilder to Eclipse. As we predominantly develop Swing-based applications for our corporate intranet, it looks like I'll be sticking with JBuilder2006 for a while longer.

By: Tim

Tim — Wed, 22 Nov 2006 00:55:07 +0000

Thanks for the comments Joe and for providing more details. I’m looking forward to taking a closer look in due course.

Tim

By: Joe McGlynn

Joe McGlynn — Wed, 22 Nov 2006 00:32:57 +0000

Hi Tim,

One of my colleagues forwarded me a link to your blog entry. As part of the JBuilder team I’d like to make a few comments.

First, this is not the primetime JBuilder. You’re absolutely right. We could have “ported” JBuilder 2006 to run on Eclipse, but that doesn’t really serve the needs of Eclipse users or JBuilder users ultimately.

By moving JBuilder to Eclipse we’re brought our JBuilder customers to the de-facto IDE standard platform. They can take advantage of the community, ecosystem and ability to extend and customize their tools.

We’ve been very careful not to violate the Eclipse usability model or build slightly improved replacements for Eclipse features. We’re looked to extend the IDE in both familiar and new ways instead.

As one example, using the LiveSource engine we’ve built new EJB LiveSource and WS LiveSource tools. Both embrace the Eclipse WTP management model and provide great visualizations of complex applications.

OptimizeIT is completely new, this is the first release of Opti that is built for Eclipse (previous releases were just “touchpoint” integration), and JBuilder is the only place to get it. It’s built on top of the latest version of TPTP and already supports Java 6.

Everything we have built sits directly on pure Eclipse 3.2.1. We package Eclipse Callisto and a number of other plug-ins that we’ve tested for convenience, but our value is in the new productivity tools we’ve developed.

The ProjectAssist and TeamInsight features are a completely new offering for *team* productivity. Project Assist lets you define a developer tool stack for SCM, bug tracking, project planning, requirements and continuous integration builds. It installs all of the components, configures them, and makes it easy to provision projects and users onto the system. A team can be up and running in about 30 minutes, including continuous integration builds and a project portal.

Each member of the team gets an XML file that we use to pre-configure Eclipse for your projects. This allows you to immediately pull/check-in source; and provides live lists of assigned bugs, tasks and features on a project. The team can open and close bugs, create requirements and complete tasks even while offline. Every check-in produces an automatic build, powered by Maven2. Every build collects quality metrics, and these metrics are trended over time.

We worked with several open source teams to make this happen, because the core tools are the ones developers have already gravitated to. In fact, if you’re already using Bugzilla, Subversion or any of the other tools we’ll let you just plug them into your TeamInsight deployment. We provide inter-operability, configurability and productivity on top of them.

We’ll be updating and extending the product with regular releases throughout the year. We’d love to get you a copy of the product to review if you’re interested.