Coming Attractions

On the user side, the code generation process will be shifting to EJB version 2.0. The Version 1.1 templates will still exist -- they just won't be the default generation option anymore.

The EJBWizard itself doesn't care which version of the EJB standard you want to generate for. Given appropriate template files, it will generate pretty much anything you can think of. However, I personally haven't needed the extra features of EJB 2.0. Blame the economy. Blame business who won't interview - much less hire - people who won't blandly swear that they've got 11 years Java experience using exactly their chosen brand of appserver, DBMS and even IDE that the position advertisement demanded. Blame Ken Lay and the whole corporate mentality where soothing lies are more valuable than the truth.

Blame the HR mindset that mindlessly uses a Boolean "one-strike-you're-out" mentality instead of trying to make an intelligent score of an applicant's abilities and likelihood of actually bringing something above and beyond the "laundry list" that the hiring manager specified. Blame the hiring managers for allowing HR to do that to them. Hey, this is America! Let's SUE!

Seriously, I'd move to Mumbai and apply for one of the 5000 jobs Oracle sent there. Or the 500 that GE did. Or even one of the 30 or so that ALLTEL did. But I'm afraid I like Florida. It's not as cheap as India, but it's still cheaper than a lot of places. It just means that instead of making a living programming, I may end up as a Wal-Mart® greeter, writing the occasional magazine article for a profession that will no longer employ me in the hopes that it will support the costs of running this website.

OK, so I have a bad attitude. But I got into this profession because I liked doing it and allegedly I do it much better than most, for what good that does me. If I was only in it for the money, I would have ditched my corporate loyalty, gone straight for the dot-com that had the best stock-option deal and cashed out long ago. It's just hard to keep plugging away when you feel unloved.

Enough self-pity. Assuming I don't end up standing at the doorway of the local Wal-Mart, here's what's in the works and planned for the future:

1. EJB2.0 support. The GUI adds a checkbox on the main panel to select local-homed EJBs. Presently I'm going with the recommendation that it's not considered to be good design for a bean to be both remotely-homed and locally-homed. If you strongly disagree, let me know!
2. User-defined panels. Since the EJBWizard is open-source, it has always been possible to add your own tab panels to the program, but in V4.0 the process is completely dynamic. This means that specialized products like the Struts development package can not only work with their own templates and macro functions, but that you can even setup GUI input panels and save/load that information as part of an EJBWizard project.
3. IDE interoperability. Version 3.5 added the ability for an external IDE such as Eclipse or Emacs to run the EJBWizard as a plug-in tool. This trend will continue. Expect to see the EJBWizard interacting with UML-based systems such as Argo and Poseidon.
4. Extended Integration. An alternative way of generating EJBs that has been gaining popularity is the XDoclet system. While it might seem that XDoclet might make the EJBWizard obsolete, in fact the two are complementary. The EJBWizard has error-checking GUI input and the ability to sniff database metadata. The new code-generation process will include XDoclet tags, plus you can add additional tags in the "description" box of the Method Editor. You can then create your EJB either completely from the EJBWizard-generated source OR you can run XDoclet against on it OR mix and match at your convenience.
5. The Grand code cleanup. EJBWizard Version 3.4 was about 63 source classes. EJBWizard V4 is now 80+ classes. It was time to rethink source module organization. A general partitioning into major subsystems has been done. If I were designing from scratch, I'd do more and better, but at least things are better than they were.

   In addition, virtually every GUI component has been inspected for proper operation under the generally-accepted conventions. When I doubt I have usually opted for operation similar to Microsoft Windows[TM] - MS-Windows was designed for a world where a mouse was an extra-cost option. I'm a big fan of mice - after working with a number of pointing devices, the only thing I'd rather have is an on-screen touch device. However, too much mousing causes me serious RSI - and both the Mac and X Windows are "mousier" than MS-Windows Occasionally I've gotten into fights with Java Swing over this issue, and I still have my objections to how Swing handles (or frequently doesn't handle) focus.

   Regardless, the original ugly IDE-generated GUI code has been almost completely overhauled, cleaned up and tightened up.

6. Regression Testing. It's been very embarrasing to release new versions of the EJBWizard with something broken in them. Finally, at long last, some regression tests have been created. Things will still break, but at least maybe no longer will they be major.