Hacker News Reader

Comment by stevoski | Hacker News Reader

I think what Bruce Eckel is arguing here is that the creators of Java and the Java API would have done a much better job if they had applied the lessons in advance that they learnt from years of Java being actively used. Which is, in my opinion, a somewhat unfair and unrealistic point of view.

But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing.

View on HN

> But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing.

I though C# was considered pretty much Java with less warts.

I agree. But, until recently, it had the huge disadvantage of being a Windows-only product.

So Mono being released in 2004, is recent?

There was that recent article about FogBugz vs JIRA, where a former FogBugz guy was participating. He said that the buggy and incomplete standard library for Mono was a large part of their product's failure on UNIX / Linux.

From almost everything I've seen so far Mono wasn't really considered production-ready until recently.

I remember reading, for example, some horror stories from the early days of Fogcreek Fogbugz support on Unix via Mono.

Even today, is any big company using Mono? Are there are any big commercial (or Open Source) applications using it?

Agreed on Mono hardly being production-ready until recently: that said, Unity uses Mono extensively for production purposes.

You don't have the benefit of retrospection in advance, it's true.

But you can take more time before releasing major components/features, and try to get them right. Eckel thinks they could have done better if they hadn't been in such a hurry, and focusing on marketting over quality, and maybe had some more skilled people involved. Especially in a platform so committed to backwards compat, if you release something designed poorly, you're stuck with it.

I guess the 'marketting' rejoinder would be if they had taken more time before releasing an attempted solution, it might have prevented Java's success in the 'market'.

I don't know. But I think it's general consensus at this point that eg J2EE API's and design was/is pretty awful -- and I don't think it actually takes retrospection to see that, it was awful right away and was seen so by many right away too.

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.

See also SOAP. I think the promise of this kind of standard turns out to be false.

Last time I had to deal with it was in 2005, luckily not more.

It had lots of nice ideas, but it was a pain to use in reality.

Typical enterprise stuff.

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.

But noone tries to fake them being the same as local calls

Except almost everyone is providing SDKs that do exactly that. Should I provide links?

Really? Every 10 years the same mistakes roll around again, I guess.

For example, PayPal SDK

https://developer.paypal.com/docs/classic/lifecycle/sdks/

I don't know whether to laugh or cry.

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.

Especially the heavy EJB part - when the heaviness of your designs starts to make it into book titles as something to be avoided, it may be time to reconsider the design :)

"Expert One-on-One J2EE Development without EJB Paperback – July 2, 2004"

http://www.amazon.com/Expert-One-One-Development-without/dp/...

J2EE was awful because it was rushed; the early vision of Java was all applets, and when that didn't pan out, Sun was desperate to find a market, and settled on Java as the new COBOL. Even now I'll wager 95% of what people use EJBs for they could do with POJOs.

That is indeed what Eckel suggests in the OP, that it could have been a heck of a lot better if it hadn't been rushed for market penetration purposes.

I don't know enough about the history of Java to say. But I know from my experience that good design takes time. And I agree with Eckel that a lot of historical Java API's aren't very good design.

I was getting paid to write Java in 1995 so I saw all this first hand, but I got out of the Java game in the early '00s.

EJBs are POJOs now :-)

Source: I am a Java dev and I simply old code a lot by introducing EJBs.

Reply on news.ycombinator.com