Mittwoch, 20. Februar 2008

IDEA 7 vs NetBeans 6

NetBeans - Just visiting (or: NetBeans 6.0 vs. IDEA 7.0 and why I think IDEA is better)

Let me begin by saying I'm an IntelliJ IDEA user and I like IDEA as IDE, I think you'll be able to find a lot about why IDEA is a nice IDE on the net. Further, I don't like Eclipse that much, which is another story, so I'm looking at NetBeans every now and then - especially when new releases are out - and let me say, I found the NetBeans 6 feature list quite impressive - its an (mostly) up to date Java IDE with good JEE capabilities, integrated profiler, UML editor with code generation and reverse engineering, support for other (scripting) languages and so on - of course I had to take a look - and I liked all the features, yet I have to stress that the most important thing is still - you guessed it - reading/navigating and writing code plus basic IDE capabilities and that's where NetBeans is somehwat lacking.

  • My diappointment began with not having code completion in JavaDoc "{@link ...}" elements
  • JavaDoc is not taken from source code but from "real" JavaDoc - thus I always had to generate the JavaDoc for all classes I just changed
  • I couldn't find a "toggle comment" action - there's just "Comment" and "Uncomment" and if that weren't enough, it only works with Java files, not with e.g. XML - it's been quite some time since I _manually_ (un)commented anything in IDEA
  • Syntax highlighting has finally gained some more options (with the new editor implementation we've so long waited for), so methods can be colored differently from attributes or local variables, yet NetBeans doesn't offer the kind of highlighting IDEA has, like e.g. coloring reassigned local variables differently or coloring static fields differently
  • JavaDoc errors are only shown when building, not "on the fly" - together with the missing code-completion in JavaDoc (see below) this is really cumbersome
  • Unnecessary to mention that NetBeans' "inspections" are no match to IDEA's, both regarding quantity and quality (this seems to be IDEA's strongest point, regarding Eclipse too)
  • NetBeans really lacks when multiple projects are concerned. Needing to select all projects manually to be able to build them all is just the beginning and would be bearable, if it just worked! Sometimes the "Build (... projects)" action is simply grayed out for no apparent reason, and it is unselectable if anything else than a project node is selected - which forces you to collapse all project nodes in the project navigator before selecting all and building - same for generating JavaDoc, of course. Even worse, you need to check "Generate JavaDoc" for each project separately; and this is, of course, also true for other options - very nice!
  • The same problem (as outlined above regarding build-cpabilities) applies to VCS integrations
  • Not to mention that NetBeans' VCS-capabilities are not even remotely comparable to IDEA's ChangeSet oriented, whole-project, sortable, tree-based changes view.

As said in the beginning, I'm still impressed by the broadness of features NetBeans 6 offers integrated into the IDE together with the little amount of configuration needed to get a 'usable' IDE (the disadvantage is of course a loss of flexibility), but I still prefer IDEA for its great code navigation and editing capabilities.

Mittwoch, 17. Oktober 2007

The Java EE 5 disaster

Before I start ranting about the "JEE5 disaster", i.e. about the drawbacks of the platform, let me say that I think it is a major leap forward from J2EE 1.4, it is even the platform I'd use if I were to start an "enterprise" application now, simply because its stable and "useable" at least, i.e. I can accomplish the things I want, even if it could much easier and there's lots of infrastructure ready to use. And NO, I don't want to hear how Ruby on Rails will help me out and save the world.

In medias res: I don't mind too much that JCA programming could be easier or that clustering is quite complex with JEE - this is, as Scrum says, "inherently complex" - its the day-to-day work that I do with the "core" of JEE, i.e. EJB/JPA that bothers me so much. With JEE5 we (the Java community) had a good chance of revolutionizing things and making it easier to work with them, but we failed. Why? Honestly, I don't know, but in-process I saw lots of things that went wrong and now, well, they are wrong.
Take the JPA annotations, for example: Not only do I need _lots_ of them to define an entity, they're also difficult to use - why do I need to point out an @JoinColumn? I simply want to specify an attribute on the "target" entity - and I don't like how they're applied - why the heck is @Table separate (instead of an attribute of @Entity)? What sense does it make to annotate a class just with "@Table"? In J2EE 1.4 we had lots of interfaces, too many, even, sure, but why didn't we keep the golden mean and, although we now have annotations, use interfaces for what they're there for? Noooo, suddenly we also specify interfaces via annotations - see @PostLoad, @PreUpdate and so on.
Second, I thought we learnt, via many painful lessons, that we should keep things not directly related to the code separated from the source. Sure, J2EE 1.4 went overboard with its myriad of ridiculously large XML-descriptors, but again, JEE 5 swing the pendulum to the complete other extreme - now our code (JPA entities) is closely tied to the concrete datastore, our RDBMS, which is entirely unnecessary! I don't see how JPA is so much easier to use than e.g. JDO, although JDO is datastore neutral.
Let's look at the "detachment" mechanism for further problems: writing a "small" web-app, I don't need it, as the web container runs on the same JVM as the EJB-container, yet, as soon as I need it, it doesn't solve the problems that arise, as I still need code on the server that explicitly loads everything before detachment and I still need code on the client that re-assembles the entity-graph - we should have learnt by now where the simplicity of environments like Oracle Forms, Delphi and VB comes from: direct access to the entities (just DB-records there, so it doesn't scale), no entity-assembling code etc.
It seems we're just too stupid to learn from the past. As soon as a new fashion arises we ignore each and every lesson learned in the past in striving for this new goal - simplicity, in this case.

Ok, enough for now, I was just randomly ranting on things in JEE5 that bother me and which I think could be done more easily.

kind regards,

Messi