Linked by Thom Holwerda on Thu 29th Sep 2005 16:55 UTC, submitted by BryanFeeney
Java Sun has released a beta edition of the upcoming version 5 of NetBeans. The most notable feature in this new release is the Matisse GUI Builder (demo) which makes it significantly easier to develop Swing GUIs. Other improvements include more refactoring tools, better CVS integration, support for more application servers, better support for web-development, and small tweaks to the editor.
Thread beginning with comment 38019
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: "Lite" version?
by whartung on Thu 29th Sep 2005 19:22 UTC in reply to ""Lite" version?"
whartung
Member since:
2005-07-06

I can't comment on the Desktop apps et al because I've never written one of any significance.

Is it possible to write a J2EE app that isn't endlessly complex, with all the huge, complicated APIs and endless competing frameworks that are supposed to make things more simple but only add to the complexity?

But I can comment on framework complexity.

The complexity comes from, at its base, the complexity of the problem: 3 tier application development with open systems.

I, too, lament the difficulty in creating creating applications of the most base functionality against not just J2EE, but any 3 tier architecture.

Part of it is simply that the plumbing is exposed to you, for good and for ill. Another part is that the nature of the architecture is such that it simply has a lot of bloody plumbing.

Next, you have the common OO patterns and paradigms. Something as simple as Model-View-Controller.

In the most abstract high level view, if you consider a modern OO 3-Tier app, you have: model, view, controller (1st tier), model (2nd tier), data model (3rd tier).

That's 5 seperate components even before you reach the gate. Next you have the parts that manage the communications between the tiers. Say, RMI or SOAP for Java from Tier 1 to Tier 2, and then JDBC from tier 2 to tier 3.

So, that's 2 more components.

Next, they're loosely coupled. Folks don't seem to write code anymore as much as bolt it together (For example, the Spring framework). So, you have to manage the configurations representing that glue. While not actual code components, they are components of the application nevertheless. I argue that today configuration files have almost been elevated to the level of "code" in terms of their use and complexity.

So, lets' toss in 2 more components, again, to configure the interchange between the tiers.

Now we're up to 9 components. 9 steps to get from what you see on your screen to the data stored in the RDBMS.

In the past, with tightly integrated "single tier", and even with client/server computing, most of those components were smashed flat into the runtime of the environment (say, DBase, PowerBuilder, even VB).

Your "view" seemed to have an almost straight path into the heart of the database. In those days you had your "screen" and the database, 2 components, and that was pretty much it.

Today, we have a lot of flexibility because we've taken what appears to be a 2 component process and exposed all 9 aspects of the transaction. Unfortunately, not only have we exposed them, but we seem to have inherited responsibility for them.

This flexibility is what gives us a lot of power. You can change each component at will and reinvent your application much more easily than you could back then.

It was difficult to use DBase code against a SQL database back in the day, vs its native DBF files for example. Or, if you wanted move your PowerBuilder applications from the desktop to the web, say.

So, now we're in the world of not buying pre-assembled toys to help with our work, but rather boxes of ill-fitting Lego(tm) blocks, building out applications from their most base components. Integrating all of the flexibility becomes very complex, and we have to be quite explicit about it (being as we're not only working with the hard nosed and picky computers, but with ill specifying whim powered marketers and managers).

When we had limited computer possibilities, we had more constraints. More contraints is less flexible. Compare creating a screen for a typical Black and Green 80x25 TTY with Reverse Video (w00t! Smart terminals!) and a modern GUI with colors, graphics, buttons, proportional fonts(!!), etc. etc.

The latter is MUCH more difficult to do "right". Hell, it's even hard to make one that looks like crap! But all of the screens look like crap on a TTY.

So, in the past where you could pound out code using screen generators, and what not, you could make screens all day long, work with the limited UIs no more sophisticated than Function Keys. These apps were "easy" simply because they could do so little. When you talked with management, etc, "No" was a perfectly valid answer. "Can I get this in yellow? and bigger letters?" "No. It's a Wyse 50, it only comes in green."

Now, of course, it simply ain't so.

Not only do we have an infinitely flexible/complex architecture, we get to fight incompatible tools (IE vs Firefox, for example) and protocols (SOAP interoperability between Java and .NET anyone?), things not even necessarily PART of our application, and certainly not part of the business problem (Move Orders from Customer Service to Fulfillment).

Before it was fighting termcap entries, or printer escape codes. Getting forms to line up straight in the tractor feeds.

But that's where this is all coming from. We have literaly boundless flexibility and with it comes associated complexity.

The real shame is that most of that flexibility is really only necessary for 15% of the app, particularly internal back office applications (vs some customer facing thing where display and such are really important. You don't put green bar printout from the dot matrix in the annual report, for example, but it's fine for accounting.).

But even though it's only lightly applicable, we pay the price on every component.

You can look at something like Oracle's ADF, which is supposed to make this kind of thing "easy", and see all of the stuff it generates and handles automatically, but while it seems helpful, it's a hard question of it really helping at all.

I don't have a solution, but I can simply say that, particularly when we hit the web, application development speed, progress and productivity made a sharp nose dive, and I don't see it getting any better.

The beauty of something like MS running VB (notably VB 6) is that, since it "eliminated" most of your choices (language, OS, Database, etc. etc.), it speeds up development and productivity. But you end up with an app circa 1992, for good and for ill.

Reply Parent Score: 5

RE[2]: "Lite" version?
by on Fri 30th Sep 2005 09:39 in reply to "RE: "Lite" version?"
Member since:

Wow, great post, J2EE does have a lot of problems with being almost too flexible, and paying for it in terms of development time. Having worked with both J2EE and .Net, I'd say at least .Net gives you a bit less flexibility, but at least it is a bit quicker. I guess that's why so many smaller webapps are using php and now ruby on rails.

Reply Parent Score: 0