Was J2EE obviously awful at the time? I'm honestly not sure.
I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when!
I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips.
But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.
The problem is that many that suffered from J2EE v1.0, didn't had the "pleasure" to have worked either with CORBA or DCOM.
So they criticise J2EE, but don't get it was actually a pleasure when compared to these technologies, specially when adding the C++ portability issues across OSes and compiler vendors.
At the time, CORBA definitely seemed more sophisticated. CosTrading, IORs, lots of cool stuff. It was just a colossal pain to use in practice, because of the tooling and interoperability.
If, right off the bat, you had to come up with some complicated patterns to work around EJB's.... to me that says, yes, it was obvious at the time that J2EE/EJB was awful.
There might have been nothing at the time _in mainstream languages/platforms_ (important distinction) that did something similar, but that doesn't mean they coudln't have done better if they had spent more time on it. I mean, even if there's nothing better to use as a model (debatable), is it acceptable to release something that requires complicated workarounds? (I guess that's debatable too; but we know what side Eckel comes down on!).
(Does anyone still want remote object invocation these days? I ask for real, I don't know. In my circles, it seems generally to have been found to be a mistaken thing to try. Based on experiences like yours in fact. So the other question is whether 'something similar' is even what was needed -- again, I think, a design question that takes time. Figuring out the right features of the right solution to actual problems is design.).
In its defence, that was one thing that was really ugly. One obvious but fairly trivial thing. And yes, it was something that they obviously could have fixed if they'd had a competent person working on it for a bit longer. But that didn't qualify it as 'awful'.
As for remote invocation, i think it became clear quite a while ago that there's no point trying to pretend that remote objects are local. So, indeed, the original motivation behind EJB and CORBA has fallen away. The current version of EJB does still have remote invocation, and it appears people use it; i think it's used in much the same way as protobuf+HTTP/Thrift/Avro are, as an efficient coarse-grained intramural RPC mechanism.
A fairly trivial thing that you spent non-trivial time developing a non-trivial in-house workaround for?
I dunno, it is indeed just one example (and it's yours not mine, I don't have enough experience with this stuff to use my own, I've succesfully avoided it in my career) and it alone isn't enough to make the case, but it seems to me to be an example of Eckel's point. For something you're going to put in a stdlib and is going to be used by possibly millions of developers, you have a responsibility to design it right.
Eckel writes "collective losses of billions due to bad design" -- this is not an exageration. How many aggregate developer-hours spent fighting with this stuff, that could have been prevented by many many fewer developer-hours up front doing it right in the first place?
How many aggregate developer-hours spent fighting with this stuff, that could have been prevented by many many fewer developer-hours up front doing it right in the first place?
How many aggregate developer-hours would have been lost waiting for it to be perfect rather than just better than whatever else was available at the time? Especially since perfection is a target that keeps moving as we learn more about what works and doesn't.
> here might have been nothing at the time _in mainstream languages/platforms_ (important distinction)
Going off mainstream, I read somewhere that Objective-C WebObjects framework was the inspiration to J2EE, given the Objective-C work going at Sun back then.
Then there was also Taligent, but it was short lived as well.
> Does anyone still want remote object invocation these days?
Apparently yes, now they call it REST and microservices.
It was probably a pioneer effect with dominant position and far too much resources. They were doing complicated stuff (compared to <?perl for @range { say date(); } ?>), so it lead to premature abstraction over still-cooking paradigm.
But I'm sensing some historical farce coming, the isomorphic web starts to feel a lot like remote objects in javascript/protobuf clothings.
I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when!
I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips.
But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.
reply