We corp-rat developers typically do most real work in some big honkin’ desktop IDE, yet dream of popping into a browser or lightweight shell to get things done. For example, with much of my PHP and Ruby code, I can ssh and vim from anywhere, but my Java work is hopelessly tied to a single laptop. If only we could combine the rich features of an IDE with the shareability and convenience of a cloud environment.

That’s what projects like OrionHub and Codenvy seek to accomplish. Orion seems to have stalled a bit, but since Codenvy is quickly moving forward (and ambitiously taking on Java EE development), I gave it a try.

Codenvy supports a variety of languages, frameworks and cloud platforms, but I only needed Java: for a standalone JAR, and some web code with Spring and Tomcat.

Codenvy works hard to re-create an IDE-style environment in the browser, and does a good job of it. It has an Eclipse-like layout and features, and even many of the same keyboard shortcuts. There were plenty of gaps and differences to remind me that I wasn’t in Kansas anymore, yet I could adjust to those. Even required periodic browser refreshes were OK; they always took me back to some reasonable point.

But it was just too sluggish and buggy for anything but small projects. Granted, Eclipse desktop itself is infamous for stalls, crashes, and sudden disappearances, but this is another level. I suspect some of that can be addressed with faster servers and networks. Indeed, to use this for real work, I’d need the on-premise version where I could control that along with back-end interfaces.

I’ll keep an eye on Codenvy and use it where it fits. It’s great for sharing and collaborating on small bits of code, like a jsFiddle for Java. And maybe soon it’ll be the envy of every developer tied to a desktop IDE.

“If there are enterprise beans in the application, the EJB deployment process can take several minutes. Please do not abandon all hope while the process completes.”

WebSphere deployment message (paraphrased)

Of all the many ills of EJBs, slow deployments are among the most chronic.  New products like JRebel attempt to reduce this time impact, but with inconsistent results.  And hot-swapping code while debugging often fails for all but the most trivial changes.  So if each significant code change requires a long wait for redeployment, it at least better work.

That’s why today’s deployment failures were so annoying.  I could see from console logs that RMIC was running and there were no errors, but the EJB stub classes were missing from the resulting JARs.  This was a new MyEclipse workspace (Blue edition, version 9.1), but I had never had this problem before.  I re-checked my configuration and verified that I had enabled EJBDeploy for my WebSphere 6.1 target server (Properties – MyEclipse – EJB Deploy).  Yet in the process of poking around and checking things, I stumbled on the problem.  While there, I kicked off a manual run by clicking “Apply and run EJB Deploy” and finally got an error message: it could not create the files because it needed the .ejbDeploy sub-folder under my workspace path.  I manually created that folder and it worked.

I don’t know why MyEclipse or ejbdeploy couldn’t just create the folder, nor why it wouldn’t report the error to the console during normal deployments.  But since this manual work-around resolved the problem, I’ll know what to do next time it happens.

Problem solved, and back to waiting on deployments again.  Thanks… I think.

Recent turns of events have moved me onto a new application to be written atop an old platform.  The stack consists of WebSphere AD 5, J2EE 1.4 (with EJB), Struts 1.2, and some Rube Goldberg approaches.  It’s outdated and bloated, but since there’s no time to shift to anything modern, we’ll add more new code atop it.

It’s a very common problem these days.

Over a decade ago, many said that J2EE would become the “COBOL of the 21st Century.”  That prediction has come true, but not in a good way.  By saying that, proponents meant “ubiquitous,” but what we got instead was “entrenched” and “obsolete.”

This is largely due to the size of the ship and the number of course corrections.  J2EE is a huge designed-by-committee camel that dramatically shifted with each major release as it crushed under its own weight.  And with each successive round, the champions of lighter enterprise Java (Rod Johnson, Bruce Tate, Anil Hemrajani, etc.) have either seen their solutions become bloatware themselves, or have abandoned enterprise Java altogether.  No wonder J2EE is now called the dead man walking.

J2EE’s size and needless complexity have worked against each other.  Newer, better, lighter solutions eventually came around, but bloated, entrenched projects found it difficult or impossible to move to them.

While it doesn’t hold a candle to dynamic languages, I actually like Java and parts of J2EE (cleanly-designed servlets, JSPs, and services are good things).  It’s just the bloat and do-overs which accompany it that drive me nuts.  I’ve often wondered why Java and C++ fall victim to this far more than other languages.  Perhaps it’s the culture and personality that comes with static typing: the classic security vs. freedom trade-off.  Folks who are attracted to J2EE’s everything in triplicate and research project mindset often don’t understand the costs of technical debt or the benefits of clean and simple design.

Maybe I’m just too accustomed to quickly building apps that have maximum function with minimum code.  I’ll code in whatever language is required, but I will not abandon my push for agility, simplicity, and elegance.