7 ms·

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 adva

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.

zokier 11y ago
> 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.
- stevoski 11y ago
  I agree. But, until recently, it had the huge disadvantage of being a Windows-only product.
  - bestusername111 11y ago
    So Mono being released in 2004, is recent?
    - ansible 11y ago
      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.
    - oblio 11y ago
      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?
      - slapresta 11y ago
        Agreed on Mono hardly being production-ready until recently: that said, Unity uses Mono extensively for production purposes.
- deleted 11y ago
  [deleted]
jrochkind1 11y ago
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.
- twic 11y ago
  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++.
  - 11y ago

zokier 11y ago

> 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.

stevoski 11y ago
I agree. But, until recently, it had the huge disadvantage of being a Windows-only product.
- bestusername111 11y ago
  So Mono being released in 2004, is recent?
  - ansible 11y ago
    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.
  - oblio 11y ago
    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?
    - slapresta 11y ago
      Agreed on Mono hardly being production-ready until recently: that said, Unity uses Mono extensively for production purposes.
deleted 11y ago
[deleted]

jrochkind1 11y ago

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.

twic 11y ago
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++.
- 11y ago