Another Java Disaster: Jobs
I‘ve blogged before about my low opinion of Quartz. Ok, for everyone who loves to make the argument that we live in the land of choice, and the ‘boy, I‘m not going to end up trapped in a walled garden, I‘m going to have choices.‘ 15 years on, we have one job engine that if you showed it to someone serious (and they didn‘t know what it was) they would guess it was in the pupal stage. It‘s anemic feature set is a complete joke. And yet, it‘s been adopted by Spring and Seam. Why? Welcome to the choicest monoculture around: Java.
Now here‘s the surprise in today‘s post: starting from this scabbed puss pocket, Seam somehow found a way to make it even worse.
First off, I defy anyone to read the documentation to the Quartz wrapper in Seam and not develop a stage 4 migraine. It‘s like ‘wait, how do I get something to run at a given time?‘ You‘d think there would be a simple answer. Instead, a clown car of insanity seeps out that makes that old Belushi skit on SNL about the watch that‘s so complex you have to flag someone down in the street to help you get the time from it look kind of staid. Why is it so confusing? Because you can use annotations. But you still have to configure it in components.xml, then the method itself has a return value of the QuartzTriggerHandle, but forget that, it can be null. (In other words: senselessness is the dominant quality.)
People used to mock C++ as the wrapper language. At least their wrappers did stuff!! Java is so full of wrappers that actually decrease functionality it‘s whacked. That‘s what happens here: promise: augmentation, reality: diminishment (some musical theory humor).
So after the API/approach has rolled off you like a spattering of mercury, and you start to use the thing, that‘s when it gets really dark. So I wanted to add some retry logic. How hard could that be in a job engine that‘s been around for 15 years? Apparently no one ever thought of that on the team, because there is no support. So I found an example, that was kind of nice: terse, clear, on Github. Saw that the dude extended SimpleTrigger and just overloaded executionComplete. Perfect. This is going to take no time at all. [Extra credit: guess which design pattern came to mind?... A: the same one that the layout managers in Swing use.]
So then, I go back to the QuartzTriggerHandle, thinking ‘this must extend or Decorate the trigger.‘ Nope. Then it must let me inject it. Nope. Drilled around a bit and found, to my horror, it makes the trigger, by violating the first commandment of DI: thou shalt not new!! Seriously, Guys? I mean, really?
Some people would say this platform has bred mediocrity. Um, I‘m dying to find something mediocre. For all the shortcomings of the C++ community (and there were plenty) it makes Java look like a goat rodeo.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)