So first I love Intellij IDEA IDE (not for just Java anymore).  I find it one of the best tools (in the EAP version) to work with Adobe Flex (much better than Adobe’s solutions) as long as you don’t need a visual Flex editor.  It is not a IDE for a wimpy machine though.  It has gotten way slower over the years, but it does a zillion more things than versions ago.

What I love even more, is the new features and UI enhancements they have made in IDEA X (Early Access Program version): Idea X EAP

It’s code complete takes a major step forward in this new build!  Few quirks still, but it is EAP, but it really is setting the stage for a huge upgrade in my book.

With all that IDE gushing over, there has always been something that annoyed me.  For classes that are Serializable, you would think it would have an intention for creating an actual serialVersionUID.  I am not going to get into whether your should create serialVersionUID or not in your Serializable classes since we could have an entire debate over the pro’s and con’s.  What I want to talk about is that IDEA does have this (not limited to the EAP, but at least 9 as well).

So for those who care, this is what I discovered after actually looking in the intentions available this week.

All the following screen snaps are from IDEA X since that is my mainstay these days.  Can’t go back to 9 any longer.

Now for Steps for enabling IDEA to generate serialVersionUIDs via intentions.

1. Click the Code Inspection icon from the lower right portion of IDEA. The one displayed like the little guy with a black hat on.

2.  Click the Configure inspections link to see the Inspections dialog box.

3. You should now see the following window:

4.  Find the Inspections -> Serialization issues -> Serializable class without ‘serialVersionUID’.

5. Check the serialVersionUID options (I highlighted in the above snap).  Your choice to select all four (4) that I did or not.

6. Click OK to close the Inspections dialog box.

Now, when editing a Serializable class without a serialVersionUID, it will display a warning on the class name and an inspection suggestion to generate the unique serialVersionUID for you.

Viola!

And to think I started out thinking I was going to need a plugin or something, it was there all along.  Thank JetBrains!

Well, I finally had to bite the bullet and migrate a large Wicket project from 1.3 to 1.4.  I was really not looking forward to it because of all the generic mess and model changes.

This was nothing against the Apache Wicket team, since they do an incredible job on the BEST Java framework ever (it is more than that.. but that is further down).

I just thought of having to review so much code and updating the ever growing set of Wicket “component” libraries, but that was the actual reason for the surge of change.

Some of the key sub projects I was leveraging were all converted (for sometime now) and were really starting to not go back to their 1.3x branches to update the older code.  I saw the 1.3x branches dying.  NO!!!!

I was trying to keep some of my key sub component / libraries manually synced from their newer bigger brother 1.4 code trees, but that was getting ever increasing painful and foolish.  Not to mention to find bug issues fixed in the 1.4 branches, but not in the 1.3x code base I was using.   So the decision was to maintain old branches for the sub projects (not my code even) or update my project and use all new 1.4 code for everything.

Jump… 1.4            1.4 is a very good great thing.

I know in the Wicket community there has been some huge Generic battles and long, long, long threads on it was the wrong approach, too verbose, too much code for no bang, blah, blah, blah. It was painful to watch since last year (thankfully they took it out of the forum and gave it a wiki home for folks to die over).

I actually find so far that 9 out of 10 times, it has made my code more understandable and actually working with models even more concise.  You get the added benefit of types collisions be detected in your IDE (if you use a real one) / compile time on models in the code that you would not get until you actually put the wrong object in a model for a component… then crash and burn and do a wtf was I thinking!  Nothing beats detecting issues before ever running a line of code.  I have C (not ++ or #, C) flashbacks of trying to figure out what code didn’t work, but would compile.  Boy I am glad I don’t code in that world anymore.

I am glad though, that I did hold out past the 1.4M3 period.  Much of the early on back and forth over how to implement generics was not pretty and I could only think of moving code from M1, M2 to M3, to RC…   Even sweet utility classes (albiet small classes) like ListModel and MapModel really do ease the coding and sets up the enhanced model design even better.   Once again, it makes the code more understandable as to what the Model contains and what you are working on.

Of course with any cleaning, updating has spurred on some good old refactoring of my own to leverage some new efforts in 1.4 branch and even how I plan to continue to leverage Apache Cayenne in some more elegant base Model designs of my own.  Should help with the whole deteaching and seperation level between Cayenne and Detachable models in Wicket so much cleaner.

So the dread, regret and final excitement was all part of my 1.4 migration.  At this point all projects will of course be 1.4x and some day 1.5… (Ajax enhancements could be even more awesome to come.)

Once again, it just goes to show that Wicket never steers me wrong and increases my I love for the whole framework project (99.9% of the time) that much better.  It makes Java Web development fun and exciting.  Come on kids, drink the cool aid, it won’t hurt ya!

SIDENOTE:

Wicket is not just a web framework, but a Java web way of life.   I don’t how many times I have told the story of that I will not / never (never say never right) go back to doing JSP development period.  It is just wrong once you see the light.

Apache Wicket 1.3.5 released.  The only way to do Java web development anymore IMO.

The Apache Wicket team is proud to announce the availability of the fifth
maintenance release: Apache Wicket 1.3.5. A lot of bugs have been squashed and
several improvements implemented. It is recommended you update to Wicket 1.3.5
at your earliest convenience.

Apache Wicket 1.3.3 Release news

The Apache Wicket team announced the availability of the third maintenance release: Apache Wicket 1.3.3.
A lot of bugs have been squashed and several improvements implemented.
NOTE: A bug related to the order of the rendered links in <wicket:head>, which might have influence how stylesheets were loaded.

http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

Another great release from a great team of developers. Each release is like a new gift found under the tree at Christmas.

UPDATE: An autocomplete bug has cropped up in this version (that I personally have run into), but is fixed in the 1.3.4 trunk or 1.4M1 trunk. You can always wait as well for the official 1.3.4 release.

The Apache Wicket team announced the availability of the 2nd maintenance release: Apache Wicket 1.3.2.  Mostly bug fixes and minor improvements.   Paving the way for the next major version of Wicket I believe.

Wicket users update now, I personally have not notice anything broken, but I use self built weekly builds most of the time anyhow.

Apache Wicket

The Apache Wicket team is proud to announce the availability of the first maintenance release: Apache Wicket 1.3.1.

A lot of bugs have been squashed and improvements implemented. The most notable improvement is the addition out-of-the-box, transparent clustering support.

1.3 has personally been extremely stable and a ton of features that if you are still using 1.2 you should bite the bullet and jump.

 Apache Wicket