Discussions

News: Opinion: EJB3 red herrings

  1. Opinion: EJB3 red herrings (45 messages)

    Aslak Hellesoy, of PicoContainer/DamageControl/MiddleGen/etc, has written up his thoughts on the EJB 3 announcements. He talks about the role of the lightweight container movement as a push to EJB 3.

    Read the EJB3 red herrings

    Threaded Messages (45)

  2. Opinion: EJB3 red herrings[ Go to top ]

    I just posted the following thoughts on my weblog.

    --
    Cedric


    Aslak is not the first one wondering why the EJB3 Experts Group is not giving credit where credit is due. I have heard this quite a few times since last week, although to be honest, the complaints were only coming from the people who thought they should be credited, so they're probably not the most subjective people either anyway...

    First of all, I'd like to dispel the conspiracy idea (very popular these days). There is absolutely no conscious intent from the group or from its members to avoid giving credit where credit is due.

    Second, there is a difference between inventing a concept and popularizing it, but there is no question that both deserve credit.

    When the first suggestions of dependency injections surfaced on the Experts Group, I didn't immediately make the connection with existing IoC containers because

        * These proposals were natural extensions of the EJB2 model (ejbCreate() is a pretty good example of inversion of control: you are telling the container to invoke you whenever it wants to initialize your bean).
           
        * They were innovative in their own right (as far as I know, EJB3 is the first one to use annotations to enable dependency injection, an approach I like a lot and that I'll blog about in a near future).

    Innovation happens all the time in software and except for a few very rare exceptions, it's usually very hard to tell who invented what, but we certainly know of a few names who are strongly associated to certain ideas (and Aslak is certainly on my list in the IoC category).

    So apologies if a few feelings were hurt, but there is not much we can do about this and we certainly had no intention to offend anyone.
  3. Isnt web service much better :). Do we need to invest into all this ?
  4. Opinion: EJB3 red herrings[ Go to top ]

    Hi all,

    I just want to clarify three major points:

    1) I do not claim that any of the lightweight containers have been particularly innovative from a technical perspective. In fact, the common trait for them all is completely opposed to technical innovation in a sense. What the lightweight container movement/projects have done is to demonstrate (and not least - popularise) how sound OO patterns and vocabulary can take productivity and programmatic power to a next step without the need for bloated component models. -This in a way that it is intuitive most developers (seasoned or inexperienced) to understand the benefits.

    Some good developers will always claim that this is old, this is just common sense, there is nothing new et cetera. That's not the point though. The GoF book didn't presented a single new idea, yet it meant a lot to OO. All it did was to popularise ideas.

    We (popularisers) all in turn owe cred to the inventors such as uncle bob's DIP, Apache Avalon and one of the early pre-J2EE app servers (early setter injection pioneers) whose name I have forgotten. -And I am sure even these have been inspired by prior ideas - as always.

    2) I wasn't moaning for kudos. In particular not for myself personally (although I do appreciate Scott's cred hehe). I just found the balance of references to inspiring projects to be skewed, that's all. Paul Hammant has also been a charismatic proponent of IoC/DI for years. If I were to mention a project that (IMO) has influenced EJB3 the most after Hibernate, it would be Spring. And I can say that now because the Pico and Spring teams have made friends :-)

    3) There is a big crowd pushing the simple yet powerful concept of IoC/DI as core concepts of a non-invasive component model, and seeing what the EJB3 comittee is doing sort of makes me keep the faith in the human race. Now if only the spec committee would have a closer look at Constructor Injection and see how it can make peace on earth... :-)

    I hope that the next chapter of this story is a broader understanding amongst developers what a powerful component model is. There is nothing truly new or magic going on here. What's new is a simple and standardised component model that enjoys widespread container support.

    Aslak
  5. check ego in at the door[ Go to top ]

    Cedric, really liked your blog on "Does this container make me look fat?"

    "I can't wait to be using an IDE that asks me if I want to create a "Lightweight / Mediumweight / Fatass project"." Really cracked me up....
  6. Opinion: EJB3 red herrings[ Go to top ]

    They were innovative in their own right (as far as I know, EJB3 is the first one to use annotations to enable dependency injection, an approach I like a lot and that I'll blog about in a near future).
    No argument here. The EJB3 committee were undoubtedly creative in coming up with an invasive, J2SE 1.5-only, approach to Dependency Injection, thereby missing much of the point.

    No question, this bit was innovation. I think the community will make up their minds about the innovation or otherwise of much of the other Dependency Injection stuff when they see it in more detail. Not of course that it really matters very much where the ideas came from so long as we all agree now that Dependency Injection is an important means towards simplifying the programming model...

    R
  7. Opinion: EJB3 red herrings[ Go to top ]

    No argument here. The EJB3 committee were undoubtedly creative in coming up with an invasive, J2SE 1.5-only, approach to Dependency Injection, thereby missing much of the point.
    I think this is an important point... Not only is this dependent on JDK1.5, but it will also have to be linked at compile time to the j2ee.jar because of the annotations. This brings together 2 of my pet peeves:
    1. Annotations are implemented as class-type objects and linked in at build time. The implementation is basically statically typed macros. Xdoclet (and some other projects) have successfully shown how Javadoc metadata can quite effectively be used without REQUIRING them to be used or linked at build time.
    2. This is still an invasive component model because my objects have to be linked in and run with a J2EE container. I can't move my same components to a Swing app or into a J2ME app (the first person to suggest a lightweight EJB container in a Swing app or on my phone gets the scornful laughter so richly deserved).
  8. Opinion: EJB3 red herrings[ Go to top ]

    I think this is an important point... Not only is this dependent on JDK1.5, but it will also have to be linked at compile time to the j2ee.jar because of the annotations.
    Well, if you write a J2EE application, you need to have j2ee.jar in your classpath. Let us know if you find a better way (renaming "j2ee.jar" to "webworks.jar" does not qualify).
     This brings together 2 of my pet peeves:
    Annotations are implemented as class-type objects and linked in at build time. The implementation is basically statically typed
    Yes.
     macros.
    No.
    Xdoclet (and some other projects) have successfully shown how Javadoc metadata can quite effectively be used without REQUIRING them to be used or linked at build time.
    True. And then the community decided we could do better than inserting typeless semantic annotations in comments, hence came JSR 175.
    This is still an invasive component model because my objects have to be linked in and run with a J2EE container.
    And if you use Pico, your objects will have to be linked and run with pico.jar.

    That's a lot of realizations you are having in one day, Jason, maybe you should go take a nap so they can all sink in :-)

    --
    Cedric
  9. Opinion: EJB3 red herrings[ Go to top ]

    And if you use Pico, your objects will have to be linked and run with pico.jar.
    That is just plain wrong. There is nothing intrusive about PicoContainer's component model. -Except from the Java labguage itself.

    Check your facts.

    Aslak
  10. Opinion: EJB3 red herrings[ Go to top ]

    I think this is an important point... Not only is this dependent on JDK1.5, but it will also have to be linked at compile time to the j2ee.jar because of the annotations.
    Well, if you write a J2EE application, you need to have j2ee.jar in your classpath. Let us know if you find a better way (renaming "j2ee.jar" to "webworks.jar" does not qualify).
    I guess this is why many of us are disappointed in the decision not to use JDO. Maybe some of our code could be reused? Maybe it doesn't always have to be used in a J2EE space? Maybe, just maybe, J2EE could be smart enough to work without me having to spell it all out for it in my statically typed code? Seems some open source projects developed in people's spare time is smart enough...
    This brings together 2 of my pet peeves:Annotations are implemented as class-type objects and linked in at build time. The implementation is basically statically typed
    Yes.
    macros.
    No.
    You should have seen some of the examples they trotted out at JavaOne last year... Stuff like "This can automatically generate your DTO's for you..." Seriously. I asked after about how you'd implement an Annotation, and was told you'd write a class that generates some code using out.println().... This is classic macro stuff masquerading as metadata. Maybe it can be used for good, as well, but it seems like queryable macros to me.
    Xdoclet (and some other projects) have successfully shown how Javadoc metadata can quite effectively be used without REQUIRING them to be used or linked at build time.
    True. And then the community decided we could do better than inserting typeless semantic annotations in comments, hence came JSR 175.
    I've heard more people question why do it this way and why not the XDoclet way than I've heard excited about the prospect of a new type of class... I'm not saying it's all bad, but there's room for both, and they should have realized and included both.
    This is still an invasive component model because my objects have to be linked in and run with a J2EE container.
    And if you use Pico, your objects will have to be linked and run with pico.jar.
    This is just false. Completely and utterly false. Pico and Spring do not require dependencies on their code to use them to wire up your POJOs. That's THE key difference, and what makes them lightweight (yes I know you hate that term) and EJB3 still heavyweight. POJO components don't have dependencies on Spring or Pico unless they need lifecycle callbacks... Even then, Spring can be configured to use ANY method for lifecycle callbacks, and you DON'T have to implement an interface. The only thing you have to do is to set up some infrastructure around your code (such as WebWork / Spring integration) and the framework is automatically called and manages your objects for you.
    That's a lot of realizations you are having in one day, Jason, maybe you should go take a nap so they can all sink in :-)-- Cedric
    Sounds like good advice... Maybe I can recommend it for you, too? Take the Spring docs to bed with you, and take a look. :-)
    <br>
    Jason
  11. Dependency...[ Go to top ]

    <comment>
    ....
    This is still an invasive component model because my objects have to be linked in and run with a J2EE container.
    </comment>

    <jason>
    And if you use Pico, your objects will have to be linked and run with pico.jar.
    This is just false. Completely and utterly false. Pico and Spring do not require dependencies on their code to use them to wire up your POJOs. That's THE key difference, and what makes them lightweight (yes I know you hate that term) and EJB3 still heavyweight. POJO components don't have dependencies on Spring or Pico unless they need lifecycle callbacks...
    </jason>

    What is actually the problem if your application/component depends on the j2ee.jar or jdo.jar or generally Java libraries? J2EE is a specification and it is standardized. I like to have a dependency to interfaces and helper classes which are standardized ;-) Remember that this is not an implementation like (jboss.jar, jonas.jar, ...) I would not like if my component would depend on those implementations...

    C'mon, your application (whether you use Spring, Pico or whatever) will still have a dependency to JDK in whatever version. IMO, it is just non-sense to try to become independent on those standardized interfaces. Just like you say "Hey, I don't want to use AA bateries because it is standardized! Instead I would like to build my own bateries which can be used everywhere".

    IMO, a "real dependency" can be reached if you have a market place where you can choose your own developers. If I search a developer with J2EE 1.4 capability, it is quite clear what this person should have to know about. This is why a standard is quite important for us.

    If you want to reach independency in your application/component, I would go one level higher -> MDA. Reusable models instead of implementation components. IMO, this discussion about POJO (which depends on JDK) or JDO (which depends on jdo.jar + JDK) or EB CMP (which depends on ejb.jar + JDK) is just not productive. It is really ok to depend your application to those *standardized* jar files, because at the end we still depend on Java + JDK ;-) I just have the feeling that some people try to push their products with the argument "Hey, you will be very independent if you use this... ". And as you know by yourself, you always depend on something else (behind those independencies) ;-)

    Cheers,
    Lofi.
  12. Instead of
    "IMO, a "real dependency" can be reached ... " I should have write:
    "IMO, a "real *independency*" can be reached ..."

    One more comment:
    Anyway I don't say that if you use MDA you will be 100% independent. You'll still depend on UML, XMI, OMG... and the tools you use! So, you see that you will never ever 100% independent. If you like so, just go to somewhere, a small island where nobody stays, and build your own hardware, OS, virtual maschine, appserver by yourself :-)

    So, the idea that "lightweight" container makes you independent, is just nonsense.

    Peace,
    Lofi.
  13. Dependency...[ Go to top ]

    What is actually the problem if your application/component depends on the j2ee.jar or jdo.jar or generally Java libraries?
    No problem at all. But don't call it 'POJO', since it ain't. Should the 'POJO' acronym be stricken from the EJB 3 specification?
  14. Dependency...[ Go to top ]

    What is actually the problem if your application/component depends on the j2ee.jar or jdo.jar or generally Java libraries?
    No problem at all. But don't call it 'POJO', since it ain't. Should the 'POJO' acronym be stricken from the EJB 3 specification?
    I am sorry but I have a hard following this discussion. POJO with annotations is what is going on in EJB3. It is a bit of a red-herring (I mean this dicussion).
  15. I think EJB3 is not "Plain Old Java Object" but "Plain Code Java Object".
    Considering as a instance at runtime,EJB3 is not "POJO" at all.
    But the code is plain.
  16. Opinion: EJB3 red herrings[ Go to top ]

    I've heard more people question why do it this way and why not the XDoclet way than I've heard excited about the prospect of a new type of class...
    This hoard of people has been strangely quiet during the JSR175 review. Where were they?

    We've received tons of feedback during these months, and I can tell you that very few of them advocated the use of comments for metadata.
    Take the Spring docs to bed with you, and take a look. :-)<br>Jason
    This may come as a surprise to you, but I actually read about (and use) technologies before I make an opinion on them.

    --
    Cedric
  17. Opinion: EJB3 red herrings[ Go to top ]

    Take the Spring docs to bed with you, and take a look. :-)<br>Jason
    This may come as a surprise to you, but I actually read about (and use) technologies before I make an opinion on them.-- Cedric
    Then what is it you don't understand about the difference in "lightness" between the Spring or Pico model, where there is no dependency on their classes, interfaces, or annotations, and EJB3, where you have to link to the EJB annotations? This makes the components non-POJO (to me at least) and not able to run without a J2EE stack. And for what? What does EJB3 provide above and beyond what I can do with Spring or Pico TODAY? Annotation buzzword compliance doesn't count, 'cause I'm willing to bet you a round of drinks that Spring will have working code configured via annotations before an EJB3 container is available. So I guess not only am I missing the advantage of the annotation, but the advantage of the spec itself.
  18. Opinion: EJB3 red herrings[ Go to top ]

    the first person to suggest a lightweight EJB container in a Swing app or on my phone gets the scornful laughter so richly deserved)
    Interesting point. I will bite.

    Lightweight EJB anyone?


    I read it as being EJB3 really. Since the programming model is mostly J2SE1.5 annotations+DI it is about as lightweight as J2SE + pico is. Aslak does deserve credit for having shown it a viable solution. I will put my money on lightweight EJB3.
  19. Opinion: EJB3 red herrings[ Go to top ]

    ...it will also have to be linked at compile time to the j2ee.jar... This is still an invasive component model because my objects have to be linked in and run with a J2EE container. I can't move my same components to a Swing app or into a J2ME app (the first person to suggest a lightweight EJB container in a Swing app or on my phone gets the scornful laughter so richly deserved).
    I'm shocked. I thought EJB 3 promises POJO automation. A business object isn't a POJO if it needs j2ee.jar to compile.
  20. Opinion: EJB3 red herrings[ Go to top ]

    I'm shocked. I thought EJB 3 promises POJO automation. A business object isn't a POJO if it needs j2ee.jar to compile.
    Very valid point, however it doesn't seem to be the case. POJO and annotations are J2SE1.5 and remove the need for interfaces, that is the whole point of EJB3 it seems, right?

    From what I understand there would still be a dependency on the Entity Manager interface which is the same thing as the Hibernate Session interface. ejb3.jar could then be one interface.
  21. Opinion: EJB3 red herrings[ Go to top ]

    I'm shocked. I thought EJB 3 promises POJO automation. A business object isn't a POJO if it needs j2ee.jar to compile.
    Very valid point, however it doesn't seem to be the case. POJO and annotations are J2SE1.5 and remove the need for interfaces, that is the whole point of EJB3 it seems, right? From what I understand there would still be a dependency on the Entity Manager interface which is the same thing as the Hibernate Session interface. ejb3.jar could then be one interface.
    Perhaps you've missed what Annotations really are... They're another class-type construct and they are statically typed and linked. You have to have the Annotation .class file in the classpath while compiling and running code which uses that annotation. Therefore, annotations defined for EJB3 will have to be in the j2ee.jar and you'll have to have that (or your weblogic.jar, etc) in your classpath to build and run your EJB3 "POJO"s.
  22. Sorry[ Go to top ]

    My apologies for saying that you need pico.jar to run your objects in Pico. I know it's not the case but I fumbled.

    --
    Cedric
  23. Opinion: EJB3 red herrings[ Go to top ]

    I'm shocked. I thought EJB 3 promises POJO automation. A business object isn't a POJO if it needs j2ee.jar to compile.
    What if it requires tools.jar to compile? Where does 'lightweight' begin and end?
  24. Opinion: EJB3 red herrings[ Go to top ]

    They were innovative in their own right (as far as I know, EJB3 is the first one to use annotations to enable dependency injection, an approach I like a lot and that I'll blog about in a near future).
    No argument here. The EJB3 committee were undoubtedly creative in coming up with an invasive, J2SE 1.5-only, approach to Dependency Injection, thereby missing much of the point.
    Why exactly did we miss the point?

    Because it's JDK 1.5? (fail to see your point there)

    Because it's invasive? (so you recommend implementing an interface for DI? Or reflection, which is less invasive and much more error prone). I think annotations strike the right balance between invasion and safety for dependency injection.

    --
    Cedric
  25. Opinion: EJB3 red herrings[ Go to top ]

    Cedric
    Why exactly did we miss the point? Because it's JDK 1.5? (fail to see your point there)
    Because it's unnecessary that that feature requires JDK 1.5, yes, that's an important point.
    Because it's invasive? (so you recommend implementing an interface for DI?
    Or reflection, which is less invasive and much more error prone). I think annotations strike the right balance between invasion and safety for dependency injection
    I think it's well known that I don't recommend using interfaces. See around 10-20 pages of Chapter 4 of this, published in 2002, which describes the motivation for Setter Injection in the framework that later became Spring :-) (That chapter is available free somewhere on this site, as a PDF.) Like annotations, interfaces are also unnecessary and invasive IMO.

    How is using reflection to do IoC error-prone in any meaningful way? Sure I can get an error in my config file during development. It takes me about 30 seconds to detect it and fix it, of which about 0.2 seconds is container startup. My round trips are fast. My application isn't going to break in production due to it. J2EE itself, and all vendors through their proprietary formats, requires a host of XML files that contain class names, among other things. This is sometimes annoying (as some of them are various complex), but actually serves a useful purpose. We can't (and shouldn't) try to put all that stuff in Java classes. Some of it, yes, like transaction attributes, which clearly make sense.

    There is an important tradeoff here. Unless the annotations get incredibly complex, the amount of information that they can carry will be insufficient for anything but trivial IoC. Users in lightweight containers are already doing much more than trivial IoC.

    Furthermore, "autowiring", offered in at least 2 leading IoC containers (although named differently I believe), uses reflection to automatically find dependencies of the correct type. No need for configuration for each property there, although there's some loss of power. Personally I seldom use autowire and feel happy with explicit wiring of my classes outside the class file. This allows reuse in many different ways. Without any special dependencies to compile. Outside any container.

    Basically, there is plenty of evidence that the Spring and Pico annotation-less approach works. Regarding the EJB 3.0 annotation-heavy way, we don't know how well it works: maybe it's even better, but I sincerely doubt it, especially as it sacrifices so much power. Hopefully the spec review period will allow time to see how it does in practice, if previews are released early enough and enough people are able to run serious stuff in 1.5 JVMs: not easy in a typical large organization.

    Rgds
    Rod
  26. Opinion: EJB3 red herrings[ Go to top ]

    How is using reflection to do IoC error-prone in any meaningful way?
    I will pick static checking over reflection any time of the day. For obvious reasons first (the static part) and also because you and I are obviously dealing with different kinds of customers.

    Your round-trips (as in "test fails, fix the code, rerun the test until it passes") are fast, but round-trips in a typical J2EE application are not. They are huge frameworks with millions of code scattered throughout dozens of different systems built on many layers. Sometimes, it will take 24 hours before any meaningful results of a regression test suite comes back and the cascading effect of a failing test can be catastrophic and ripple throughout the entire organization.

    If such a failure is happening because a method signature was changed and it went undetected because of reflection, I'll have a few words with the developer who did that and he'd better have a good reason.

    Interestingly, I have recently replaced some static code with reflection, so I know it is sometimes necessary, but IoC is not a good use case. Use interfaces or annotations for that.

    --
    Cedric
  27. Opinion: EJB3 red herrings[ Go to top ]

    Cedric
    ...also because you and I are obviously dealing with different kinds of customers. Your round-trips (as in "test fails, fix the code, rerun the test until it passes") are fast, but round-trips in a typical J2EE application are not. They are huge frameworks with millions of code scattered throughout dozens of different systems built on many layers. Sometimes, it will take 24 hours before any meaningful results of a regression test suite comes back and the cascading effect of a failing test can be catastrophic and ripple throughout the entire organization.
    I don't understand what you mean by "different kind of customers". I doubt you know where I work :-) I am currently onsite with a large banking organization, working on a project that runs on a high-end container (I won't mention the product, but it shouldn't come as a huge surprise). This is a very high-throughput system, with a huge number of business rules for each object handled within a transaction. It has many layers, and the network of business objects is complex. It's replacing a legacy system that is considered to be unmaintainable because of the volume and complexity of code. In short, it's a proper J2EE application :-)

    Are you saying I don't implement "typical J2EE applications" because my builds during unit testing are quick during development?

    Roundtrips in "typical J2EE applications" are slow. No argument. That's why those projects often exhibit terrible productivity. That is one of the problems with J2EE as often used. It's not an inevitability, unless we give up on productivity. Part of the cure is to lessen dependence on the J2EE server at test time to ensure that less stuff needs to be tested in a sever that takes 2 minutes to start up or 1 minute to deploy a large app (counting interpreting stack trace if it's broken). Sure, you need to deploy to such a server in a high-end app (for JTA etc etc), but your XML or other metadata doesn't need to be predicated on such a container. EJB 3.0 attempts another part of the cure--getting business objects to depend less on server or container APIs.

    Approximately 99% of my XML is the same in the integration test environment (JUnit, lightweight container started up during JUnit tests because it takes hardly any times) as in the deployed environment. I also have true unit tests of course that don't need XML metadata, as the objects being tested are POJOs.

    In general, I don't deploy stuff to the J2EE server unless it will work. It's far too slow to do so and a massive productivity killer. It doesn't take _that_ long to compile Java and run even a (big) unit test suite if it's designed properly.

    Of course stuff needs to be tested in a deployed environment before it gets anywhere near release into production. But that's a different stage of testing from my quick cycles in development, and I've never seen reflection-related breakage at that point, with the approach I've described. The things that most often break here are things like JNDI names, but that doesn't mean that JNDI is a bad idea. Like XML and other external metadata, it has a purpose.

    Rgds
    Rod
  28. It's quite interesting to follow the discussion about static checking vs. reflection, compile time vs. runtime, fat container vs. lightweight container...
    IMO, all these techniques have their own advantages and disadvantages, no technique is superior to other techniques, just like a normal life there is no black and white, there is no "0" and "1" (therefore we have fuzzy logic ;-)).

    I myself prefer to have:
    - Static check, compile time. I like to have everything static check and compiled - everything at the build/compile time - before I run. I hate to have runtime error. Example: uncompiled JSP files are horrible. Therefore I use XML Compiler, so that I can compile HTML, XML files and work with interfaces only.
    - I prefer to work with interfaces. Just write everything towards interfaces.
    - It depends on the "fat" container itself wheter it will start in 2 seconds or 2 minutes. If you use service-oriented "fat" container, you can make it "lightweight" by removing services, which you do not use.
    - I prefer to make a good partition of my application by dividing it into different components. My development cycle (write, compile, run - round trips) is based on each component and not on the whole application, so you'll never have to wait such a long time to start your "already lightweight, fat container" ;-)

    Cheers,
    Lofi.
  29. I forget something..., yes MDA!

    Use techniques you like with the help of MDA:

    - If you like to use static checking and you like working towards interfaces just generate your interfaces directly from your model, no problem and you can save a lot of time.
    - If you like to work with reflections with those XML files you need, just generate them from your model as many files as you can, so you won't make too many mistakes.

    And if your "fat" container which is already getting "light-weighted" - thanks to that service architecture - but still it needs 2 minutes to start, one thing you can do is just to buy a new hardware. "Hey man, I'm working for a huge company with thousands of transactions running each second (I hope those huge transactions can also generate a profit, not only trash ;-)) but I cannot buy a development hardware for only 1000 US$...". This is a bit wyrd for me ;-)

    Cheers,
    Lofi.
  30. Opinion: EJB3 red herrings[ Go to top ]

    How is using reflection to do IoC error-prone in any meaningful way?
    I will pick static checking over reflection any time of the day. For obvious reasons first (the static part) and also because you and I are obviously dealing with different kinds of customers.Your round-trips (as in "test fails, fix the code, rerun the test until it passes") are fast, but round-trips in a typical J2EE application are not. They are huge frameworks with millions of code scattered throughout dozens of different systems built on many layers. Sometimes, it will take 24 hours before any meaningful results of a regression test suite comes back and the cascading effect of a failing test can be catastrophic and ripple throughout the entire organization.If such a failure is happening because a method signature was changed and it went undetected because of reflection, I'll have a few words with the developer who did that and he'd better have a good reason.Interestingly, I have recently replaced some static code with reflection, so I know it is sometimes necessary, but IoC is not a good use case. Use interfaces or annotations for that.-- Cedric
    Here you're using a horrible anti-pattern of J2EE (24 hours before your automated testing catches simple configuration issues?) and using it as the reason you can't make it better? Unit tests should be FAST! You should be able to turn around your whole unit test suite in < 2 minutes... At the very least, you should be able to pretty well cover the usage of the component you're modifying in that time. If you can't, you need to step back and look at how you test... Maybe check out Vincent Massol's stuff on automated builds and tests, I heard it was very good, and I'm going to check out the slides and MP3's ;-)
  31. Opinion: EJB3 red herrings[ Go to top ]

    requires a host of XML files that contain class names, among other things. This is sometimes annoying (as some of them are various complex), but actually serves a useful purpose. We can't (and shouldn't) try to put all that stuff in Java classes. Some of it, yes, like transaction attributes, which clearly make sense.
    I have a different perspective.

    I believe that by default, every metadata that is tied to a Java element should be specifiable in an annotation.

    Then, make these annotations optionally overridable by an external file.

    I bet you will find that the need for outside-source metadata is actually quite small and limited to deployment-time settings.

    But if my metadata has anything to do with the code I write, I want it in my Java source and I want my Java IDE to help me write it, not XMLSpy (which will do a poor job at it anyway since schema-validation comes short when it comes to J2EE applications).

    --
    Cedric
  32. Opinion: EJB3 red herrings[ Go to top ]

    There is an important tradeoff here. Unless the annotations get incredibly complex, the amount of information that they can carry will be insufficient for anything but trivial IoC.
    That's an interesting claim and I would love to see it substantiated.

    I am sure you can find complex examples of metadata that will be easier to express in XML than in annotations (such as an XML file itself), but I contend that these cases are extremely rare.

    Most of the J2EE metadata (and Spring's too) is hardly more complicated than key=value, so I think it will be very accurately and concisely carried over in annotations.

    --
    Cedric
  33. Opinion: EJB3 red herrings[ Go to top ]

    Most of the J2EE metadata (and Spring's too) is hardly more complicated than key=value, so I think it will be very accurately and concisely carried over in annotations.
    Yes, much (not all) of the J2EE metadata should have been trivial. Before it was made into XML hell :-)

    The Spring XML metadata supports way more than key=value. It's all in the Spring reference documentation, so I won't go into detail here.

    Nor is it true that users only use the trivial stuff (even that is way more than key=value, because of the distinction between literal values and references, and the FactoryBean indirection concept). Lists are very popular, for example.

    For example, in my present project I configure via IoC a Map where each entry is a List. It's saved me a lot of time, and works out to be a very clean and simple implementation of what I want. The objects in the Lists come from elsewhere in the same container and of course have their own Dependency Injection.

    R
  34. Opinion: EJB3 red herrings[ Go to top ]

    Regarding the EJB 3.0 annotation-heavy way, we don't know how well it works: maybe it's even better, but I sincerely doubt it, especially as it sacrifices so much power.
    If I recall correctly, "XML hell" was cited prominently in your own slides as one of the many EJB weaknesses, so what are you proposing exactly? We shouldn't use XML and we shouldn't use annotations, what is left?

    Anyway, as you say, time will judge. I am betting that in one year from now, annotations will be such a big part in Java programming that nobody will notice them any more (developers will still be complaining about generics, though :-)).

    --
    Cedric
    http://beust.com/weblog
  35. Opinion: EJB3 red herrings[ Go to top ]

    If I recall correctly, "XML hell" was cited prominently in your own slides as one of the many EJB weaknesses, so what are you proposing exactly?
    You mean my slides from Vegas last week? (Readers will lack a bit of context here.)

    There's a difference in how usable XML formats are based on the particular DTD or schema. EJB 2.1 XML--particularly ejb-jar.xml and its 2-3 proprietary friends in many applications--constitute "XML hell" to me. I do not believe that if you use XML you need to go to hell. Thus I don't hate XML.

    In that presentation I showed some examples of the kind of XML I use. It's a lot simpler, for what it does.
    We shouldn't use XML and we shouldn't use annotations, what is left?
    Where exactly did I say "don't use XML"? There's a lot besides XML and annotations btw: scripting etc. We're going to see some exciting stuff in configuring lightweight containers those ways in the future. I think the Pico guys already have some cool stuff on that and it's coming soon to Spring.
    Anyway, as you say, time will judge. I am betting that in one year from now, annotations will be such a big part in Java programming that nobody will notice them any more (developers will still be complaining about generics, though :-)).
    Annotations will be be big. IMO they will also have been overused by many programmers and people will start seeing problems from abusing them.

    However, no argument that time will tell. Such crystal ball conversations are of limited value... We should reflect on this over a beer in 2 years. Not 1 year, because where I work and in many enterprise software houses, no one will be using Java 1.5 in 1 year, let alone able to draw conclusions about how it worked out. It just takes too long to upgrade such projects, given the bureaucracy and implications for so many things (JDBC drivers, app server etc etc) of upgrading JDK version.

    (Note that I think annotations are valuable. They're proven over the fence at Redmond. It's just that I question their value as the main means of Dependency Injection.)

    Peace
    Rod
  36. Opinion: EJB3 red herrings[ Go to top ]

    Hi Aslak,

    I've already posted a comment to your blog about this, but just in case people didn't see it, I wanted to point everyone to the page I published on Sunday which tries to give credit where it is due:

       http://www.scottcrawford.com/ejb30faq.html

    I really did write this before you wrote your blog entry so I hope everyone feels better. And before anyone else pipes up, I am absolutely sure that others who deserve credit have been forgotten. It's a tough thing to keep track of, but I did try.
  37. Opinion: EJB3 red herrings[ Go to top ]

    It make a lot of difference when a genius make innovation compared to a Sun Certified Java programmer. Unfortunately Sun certified programmer stealing ideas from Genius and making EJB 3. I hope there are millions of programmers already using the EJB 3.0 specs ideas with currently available matured open source such as spring framework, Pico container, Hibernate etc. Do you have anything new for sale?
  38. So rather than evolve and leverage best practices we should just freeze Java specification development and tell everyone to use Spring and Hibernate? I don't think that makes a lot of sense, and I doubt the Spring and Hibernate developers would like to see that either. Innovation stagnates when you are the only game in town.

    This blog entry is about getting credit for ideas, not stopping those ideas from being merged into the mainstream. Anyone involved in these technologies should be thrilled to them reflected in the spec, not angry that their name isn't in flashing lights on the cover. Given that the current EJB spec has a fairly broad set of acknowledgements, I see no reason to believe that won't be the case with this release.
  39. O come on Shaji, don't be so gruffy. After all the time being criticized for bureaucratic committee management, when the JCP at least is listening to the crowd and is coming down from their ivory tower, then they should be bashed again? No no.

    After all "copying is the greatest form of compliment".

    Now we are only waiting for the ultimate showdown, the event of the year, the equivalent of Super Bowl or Word soccer championship in the IT world, the TSS benchmark:

    Weblogic Petshop vs Tomcat/Spring/Hibernate Petshop!

    TSS would love to do such a benchmark; so, if none is forthcoming we all know the reason, BEA will not allow it.

    Regards
    Rolf Tollerud
  40. TSS would love to do such a benchmark; so, if none is forthcoming we all know the reason, BEA will not allow it.
    Not allowing benchmarks that are not supervised by the vendor it fairly common business practice, and it can be seen everywhere. Yes, even at Microsoft.

    --
    Cedric
  41. to deny hungry lions food[ Go to top ]

    Yes I know that. But to deny "us unwashed masses" the anticipation, the thrill and the excitement of such an event.. that could so be useful too..

    It's almost criminal IMO.

    Regards
    Rolf Tollerud
  42. on disallowing benchmarks[ Go to top ]

    You're right, disallowing benchmarks is a fairly common practice among software vendors. But that doesn't make it good. It seems to be a strategy born in paranoia.

    As strange or unlikely as this sounds, Microsoft is trying to change the air of paranoia. Microsoft thinks it a laudable goal to have more high-quality public benchmarks.

    For example, look at the End-User License Agreement (EULA) you must agree to, in order to use the .NET Framework runtime.

    It includes a clause that says
    "You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoft’s prior written approval."

    So the net is, for the .NET Framework
    - people can do their own private benchmarks at any time, of course (as with any product)
    - if people want to publish benchmark results for .NET apps, they are required to get MS approval. There is no clear statement as to what is required for approval. But in general, MS does not and will not require "supervision" of the benchmark effort before granting approval.
  43. Opinion: EJB3 red herrings[ Go to top ]

    I once wrote a hobby project where I had an external object pass a reference to another object. This was very popular with me and my group of friends. I see you have taken this idea in EJB3 and are not giving due credit for it. Aren't you ashamed?
  44. Exactly my point...[ Go to top ]

    ..."dependency injection" is so damn trivial. This is like Erich Gamma claiming you all stole "the singleton" from him. And that said, the singleton is imho about as complicated as "dependency injection" (also called configuration for what it really is). A pattern like "chain of control" is far far more complicated than "dependency injection" and noone makes a fuzz about it!

    Next thing you have those AspectJ guys (nice job btw) hear about how they "invented" aspect oriented programming whereas they actually stole it from CLISP. "That is a well known thing!" (McCall Smith)
  45. trivial patterns[ Go to top ]

    ..."dependency injection" is so damn trivial.
    A wheel a very trivial thing too, yet we keep making "a fuzz about it" :-)
  46. trivial patterns[ Go to top ]

    ..."dependency injection" is so damn trivial.
    A wheel a very trivial thing too, yet we keep making "a fuzz about it" :-)
    Whoawhoawhoa, I imaging the persians/egyptians or whoever invented it crying out to each other "You stole my rollawaything" invention :-)