OSNews

Not on OS X. Eclipse's VE doesn't even run on OS X and Jigloo is stuck with only designing SWT apps (don't ask me why). As it is, Netbeans is the only IDE with a decent GUI Builder for Java on OS X.

Not on OS X. Eclipse's VE doesn't even run on OS X
and Jigloo is stuck with only designing SWT apps (don't ask me why). As it is, Netbeans is the only IDE with a decent GUI Builder for Java on OS X.

There's an object in SWT called SWT_AWT. It's the bridge between the two frameworks. Unfortunately, on OSX (carbon - which they both use), the event loop has to be on thread 0, and so, there is no practical way to run two event loops on one thread (yet). Look up the bug on the SWT bugzilla. There's a huge list of people waiting for this to get fixed - every GUI builder, and a bunch of others.

You're right, you are stuck with Netbeans for Swing GUIs, but you could also use XCode if you didn't need a cross-platform tool. :-)

If you feel slighted that SWT claims to be cross-platform but this one bug is holding up gobs of projects, feel free to head over to the Apple camp and gripe at them. The SWT guys were nice enough to tell me to contact the Apple folks and see if I could help out. The Apple folks never bothered to write me back when I offered help. :-(

Hopefully one day it will get fixed, but in the mean time, it really broadcasts the concept that Eclipse fails miserably at being cross-platform (when in reality it's actually a pretty good framework).

You're right, you are stuck with Netbeans for Swing GUIs, but you could also use XCode if you didn't need a cross-platform tool. :-)

If I didn't want cross-platform, I'd be using Cocoa and Objective-C. But it's a real shame that SWT doesn't work as intended on Apple. Whoever is to blame, they better fix it soon as Eclipse is a nice IDE.

>The gui builder in Netbeans is pretty powerful, but it is not as fast or as easy to use than the GUI builder in Eclipse.

>I hope that the newer version is also easier.

The last sentece leads me to believe you are actually commenting the quality of the GUI builder without having tried it. I hope I missinterpreted the above. Otherwise please stop spreading opinions of things you know nothing of. The GUI builder in NB5 is a rewrite and should not be compared to the one in 4.1.

Cheers,
Patrik

You should learn to read what people write before you comment. I wrote I hope that Netbeans new version is also easier than former version, I did not say that it was not.

I wrote about my experience with NB 4.1, and Eclipse 3.10. If you think otherwise then tell us why.

This thread is about the 5.0 beta. Why would you choose this place to tell the rest of the world what you think of a specific module of an earlier version that has few similarities with the current? Context dear, context.

/Patrik

Eclipse's gui builder?! What are you smoking?

There is the biggest problem for me; if the damn Eclipse GUI tool worked, I'd be using it straight away, but that isn't the case.

What would be nice is something that is easy like how VS.NET do it, place a widget, double click on it, and add code; sure, it isn't pretty, and probably gives programming purists bad nightmares, but at the same time, the fact of the matter is, the world runs on quick and dirty solutions, not overly academic designs and techniques that are preached in universities.

The GUI builder is dramatically improved over all previous versions of Netbeans. I gave it a try just a few days ago, and it is EASILY_ the best GUI builder on the market.

The properties panels and event hookups could be a little cleaner, but otherwise even in the beta this thing is amazing!

The GMF (Graphical modelling framework will be here soon. This will provide a graphical UML designer based on the UML2 metamodel. It's based on EMF and GEF, so should be good.

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.

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.

Nice demo. It worked for me although at the beginning, the image seemed to be 5 seconds in advance on the voice.

My experience with the flash demo was similar. A few seconds in it goes blank with only voices (even though it has supposedly loaded fully before this on my fast connection).

After another 15-30 seconds or so it comes back and works fine, though. I just wish it were a little more in depth, as it really doesn't do justice to just how good this thing is.

About swing on Linux, are you doing the export AWT_TOOLKIT=XToolkit thing? It fixed the main problem I had with swing in linux, the fonts.

Actually my problem is that it is impossible to type certain characters on internationalized keyboards. This is a over five year old bug that is finally getting fixed in java 6.0 to be expected next year.