Tech Talk: Bob Lee on Google Guice

Discussions

News: Tech Talk: Bob Lee on Google Guice

  1. Tech Talk: Bob Lee on Google Guice (94 messages)

    In this Tech Talk, Bob Lee discusses the reasoning used in writing Guice, his dependency injection library for Java based on annotations.
    Guice is what is called a Dependency Injection framework, and for those of you who do not know what Dependency Injection is, the way I like to describe it and the way I describe in the Guice User's Guide is... I start up explaining that we used to all write factories and our classes whenever they had a dependency, which depend directly on the factory, but then once I discovered this thing called Dependency Injection, and basically the idea of Dependency Injection is that instead of my class depending directly on a factory I just depend on somebody passing that to me either via the constructor or via a method. Dependency Injection does not necessarily require a framework. I actually go into this in the user's guide and show how you could do Dependency Injection by hand. So we move the dependency out of the class, so you are no longer calling into the factory directly but you have to move that dependency somewhere and what you end up doing is you move that dependency into the factory layer. So, basically all the factories know about the other factories but your classes do not know about the factories. What Guice does for you is make it so you do not have to write all those factories, and it basically cuts out a lot of boilerplate code, it gives more flexibility, it handles stuff like circular references and what not. It enables you to do method interception, a lot of other services like that. It also lets you do, one of the big features is, declarative scopes. So, in the past when I wrote factories like say for example, my factory was returning an object from the HTTP session, you would have to write this same code over and over again that says, "Okay, check for an object on this session, if it is not there create one and then store it on this session and then return the object." Well with Guice, you can just say, "Okay, I have this object, it is this type, and store it on the session" and Guice takes care of everything else, and that is actually completely customizable.

    Threaded Messages (94)

  2. Why Guice?[ Go to top ]

    I followed up this tech talk with a blog post that's a little easier to read than the transcription. Can you tell I was nervous? ;)
    TheServerSide just posted a video interview they recorded in May shortly after the Guice 1.0 release. Since then, I've had ample time to chew over what I like so much about Guice and hone my thoughts on dependency injection in general. Being a fan of plain old Java, before I wrote Guice, existing dependency injection frameworks were non-starters for me. I'd sooner write factories by hand than keep XML in sync with my classes or embed method names in strings. I mean, if you don't have type safety, all of that extra typing really is for naught, and you might as well switch to Ruby. Furthermore, a programmer shouldn't have to fire up a debugger or even think too hard in order to figure out what her code is doing. I felt the same way about mocking frameworks until EasyMock pioneered their extraordinarily typesafe approach. Before Guice, I had to make the same up-front decision over and over: do I call a constructor directly, or do I write a factory and call it instead? If you start out calling a constructor and later decide that you need a factory, you have to go back and change all the callers. On the other hand, factories come at a cost: they clutter your API and result in a bunch of boilerplate code which you have to both write and maintain. In practice, if the only reason you need a factory is to enable testing, most programmers will forgo the factory, testing be damned. Guice provides the best of both worlds and finally enables agile programming in Java. Injecting an object requires roughly the same amount of effort as calling a constructor. If you decide later on that you need more abstraction, write a factory and change your code in one place; there's no need to change all the callers. If you're providing code to someone else, give them a bunch of interfaces and a Guice module. They can test their code, you can change how you create objects to your heart's content without impacting your users, and your API will be smaller to boot. As you can probably tell from Guice, I love small, interface-heavy APIs.
  3. Re: Why Guice?[ Go to top ]

    I'd sooner write factories by hand than keep XML in sync with my classes or embed method names in strings.
    I can not agree more! Cheers, Paul Casal Sr Developer jbilling.com The Enterprise Open Source Billing System
  4. Re: Why Guice?[ Go to top ]

    I'd sooner write factories by hand than keep XML in sync with my classes or embed method names in strings.


    I can not agree more!
    Cheers,

    Paul Casal
    Sr Developer
    jbilling.com
    The Enterprise Open Source Billing System
    Yeah, I think this annotation/meta-annotation approach to binding is going to have a real positive effect on AOP. I talk a little about this here So, go Bob go! Keep the Guices flowing. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  5. Re: Why Guice?[ Go to top ]

    So, go Bob go! Keep the Guices flowing.
    Thanks, Bill! :D
  6. isn't it simple enough[ Go to top ]

    most of the people forget to use the phrase "creation context" while explaining Dependency Injection. In very simple words, Dependency Injection is a concept/technique which keeps the user of an object separate/away from the creator of the object. Thats it! Now you may add all your mumbo-jumbo terminologies on the top!
  7. 100% Correct[ Go to top ]

    There is always a chance for religious oriented through out in human civilization OOAD, AOP, IOC, SOA in technology took the same path. When Google guy tell me his IOC is better than Spring, all I can feel about the way a crazy Christian preacher talk about way to heaven just cuz I have to believe in Christianity. All I can ask him what his point about people is lived in earth 2007 year ago, did they go to heaven or hell, cuz there were no Christianity in thin world before Jesus. Any way I do believe in Jesus but not the crazy priest. Same comparison, AOP, IOC, OOAD, SOA are good concepts, there are 100 way to explore it, it do not mean one approach is better than other one until and unless it is compared in all offerings and credibility. SO what is your point Google guy??. You are another developer just like a preacher never gets happy until and unless people get ur way. As I have mentioned in Google post. Please do not get into comparison with Spring CUZ read below When BEA, IBM, SUN, Oracle and all bullies of JAVA were behind stupid EJBs, spring guys came up and told it is not the right way to build an enterprise container to support enterprise application. They lived upto the expectation of the computing world, Never sold their company just like Cameron Purdy and JBOSS guys did and I personally know more than 10 CTOS of Fortune Company only give badge to a consultant, if they know Spring. So what is your point and what are u trying to prove us "HeloWorld.java" benchmarking?? Go to FEDEX, DHL, New York Stock Exchange, etc try to put ur framework for bench mark, come up with the data, then I can think about it, otherwise you are another preacher.
  8. Re: isn't it simple enough[ Go to top ]

    In very simple words, Dependency Injection is a concept/technique which keeps the user of an object separate/away from the creator of the object. Thats it!

    Now you may add all your mumbo-jumbo terminologies on the top!
    Your definition of "Dependency Injection" is too general. You can simply replace "Dependency Injection" in your sentence, and it still works: "[Factories are] a concept/technique which keeps the user of an object separate/away from the creator of the object." "[Service Locator is] a concept/technique which keeps the user of an object separate/away from the creator of the object."
  9. Re: Why Guice?[ Go to top ]

    I mean, if you don't have type safety, all of that extra typing really is for naught, and you might as well switch to Ruby.
    This to me is a key point. I don't think changing to Ruby or Python, etc. is necessarily such a bad thing but paying lip-service to static typing and then going around is a big waste of time, in my opinion. I guess I'll have to check out Guice given my agreement with the rationale.
  10. Video[ Go to top ]

    For those of you new to Guice, you might start with this introductory video.
  11. guice is big..[ Go to top ]

    well, i am a little obsessed with minimalism. so one thing i dislike about guice is that library is a little large for just doing dependency injection (around 500k. ouch). i understand they embed the cglib(for proxying) + asm libraries(for line numbers) into the jar file. those stuff could be substituted by jdk classes with a little work..
  12. Re: guice is big..[ Go to top ]

    well, i am a little obsessed with minimalism. so one thing i dislike about guice is that library is a little large for just doing dependency injection (around 500k. ouch). i understand they embed the cglib(for proxying) + asm libraries(for line numbers) into the jar file. those stuff could be substituted by jdk classes with a little work..
    Chris Nokleberg already extended our build to strip out the parts of cglib we don't use making the jar smaller.
  13. thanks.[ Go to top ]

    good to hear, thanks for the reply.
  14. Yet another framework :), but looks good Bob, nice work.... I've been using Spring for a few years now, and very happy with it, just like thousands of others...Spring(lighter j2ee!) was needed because of the mess EJB was in back then...butin 2007, is a new Dependency Injection framework really needed now? why not just improve on an already reliable framework.. it's like someone coming up with a another MVC framework that has a few more eureka moments....
  15. Re: Tech Talk: Bob Lee on Google Guice[ Go to top ]

    Yet another framework :), but looks good Bob, nice work....

    I've been using Spring for a few years now, and very happy with it, just like thousands of others...Spring(lighter j2ee!) was needed because of the mess EJB was in back then...butin 2007, is a new Dependency Injection framework really needed now? why not just improve on an already reliable framework..

    it's like someone coming up with a another MVC framework that has a few more eureka moments....
    Just like there are a few application servers, a few operating systems in the market. The advantage ending up is the quality of the products keep improved and new ideas (even different way of solving problems) would pop up when existing ones can't solve problems nicely -- like String to EJB application servers.
  16. I still don't see the point ...[ Go to top ]

    Annotations near source code are certainly suitable and better than XML deployment if used to configure AOP and component local properties, such as transaction, security, OR mapping, etc. Or, if the DI framework is only used as a low level platform to factor out factory for instance for a monolithic application developed in house with less concern of third party component and third part containers, then the annotation based solution could have less code religious conflicts to OO developers. However, for general applications, I fail to see the advantage of having application wiring logic that involving multiple components been spread in source code of individual components, let alone the invasiveness and tight coupling to particular container that defeat the POJO premise and largely prohibit components reuseability accross different containers. I saw two arguments that blame the non-invasive XML data based (rather than annotation metadata based) configuration: 1. lack of static type safety. 2. refactoring adverse. The argument 1 hardly stands. The point of static safty is to ensure type safety before runtime. For XML configuration, such a requirement can easily be met by a simple utility that reads a XML configuration and check literal signatures against reflection signatures. I fail to see any practical effect difference of this kind of pre-runtime type check against java source code compile time type check. The argument 2 sounds to be a red harring. The point of refactoring is to fix poorly designed implementations, enable code reuse, improve implementation via reorganizing, software evolution, etc.. Certainly, XML configuration without addtional tools (in fact, such tools should be that tough to be created) seems to be adverse to certain very primitive source code refactoring (such as member rename, package rename, etc.). However this kind of primitive refactorings are likely to be useful in fixing pooly designed implementations. The point of XML configuration, on the other hand, is precisely to avoid such kind of poorly made non-professional implementations at first place and to reduce the needs of such a low level refactoring. It is just like that C++ name mangling invalidated some stone age solutions that helped to fix poorly implemented C/assembly code. Could we claim that C++ was "code-improvement-adverse" and should be avoid in general? On other aspects of refactoring, comparing to annotiation based DI configuratin, XML configuration enables more flexible and convenient code reuse (reuse without source code), higher level component based application structure reorganization and evolutions..... etc.. In summary, contrary to the two arguments, what I can see is that declarative "data" based configurations could be much more expressive, flexible, refactoring friendly, and less error-prone than a metadata based configurations, let alone they (XML based DIs) are non-invasive and container agnostic. Just my 2 cents. Ke
  17. Re: I still don't see the point ...[ Go to top ]

    (XML based DIs) are non-invasive and container agnostic.
    This really depends on your perspective. One could easily say that Spring is as invasive as other solutions merely by the fact that nothing really works (gets created correctly) without the Spring container (yes it is a container). The invasive part is just pushed to the runtime and not the compile time. From my experience of looking at OSS software that has used Spring it become practically impossible to understand the runtime dependencies without looking at the XML and then the code and then the XML...... This is invasive from this perspective. I now have context switching between one language to another. What is even worse is that you simply cannot use the extensions within these OSS software without first learning Spring and the 20 or so context.xml files they have scattered around their libraries. This is invasive and it gets worse. Trying instantiating a repository object within one particular OSS solution and you will suddenly realize that the have baked Spring all the way in without any though for actually layer Spring on top of a solution that can work outside of the Spring container. Guice and Spring and another other magic someone dreams are invasive once you have made the choice to use them at compile time or runtime. Like many other decisions you will make. The real question is should you be making a choice at the the product level. What about a standard? Neither currently offer an alternative runtime environment that offers the same magic at runtime. regards, William
  18. Re: I still don't see the point ...[ Go to top ]


    (XML based DIs) are non-invasive and container agnostic.


    This really depends on your perspective. One could easily say that Spring is as invasive as other solutions merely by the fact that nothing really works (gets created correctly) without the Spring container (yes it is a container). The invasive part is just pushed to the runtime and not the compile time.

    From my experience of looking at OSS software that has used Spring it become practically impossible to understand the runtime dependencies without looking at the XML and then the code and then the XML...... This is invasive from this perspective. I now have context switching between one language to another.

    What is even worse is that you simply cannot use the extensions within these OSS software without first learning Spring and the 20 or so context.xml files they have scattered around their libraries. This is invasive and it gets worse. Trying instantiating a repository object within one particular OSS solution and you will suddenly realize that the have baked Spring all the way in without any though for actually layer Spring on top of a solution that can work outside of the Spring container.

    Guice and Spring and another other magic someone dreams are invasive once you have made the choice to use them at compile time or runtime. Like many other decisions you will make. The real question is should you be making a choice at the the product level. What about a standard? Neither currently offer an alternative runtime environment that offers the same magic at runtime.

    regards,

    William
    When talking about IoC framework, the common understanding of "non-invasiveness" is to "component implementations", rather than about portability of XML configurations. A XML configuration written for one non-invasive IoC container would certainly not work by default in another IoC container. However, an non-invasive container allows itself to use components that were developed totally unawared of this container. Unlike invasive containers, Spring can perform dependency injection on beans that were written without Spring in mind. Personally, I believe the term "neutral to component programming model" should be used here instead.
  19. Re: I still don't see the point ...[ Go to top ]

    Again you are looking at this from the point of view of a Spring container user and not a non-Spring container user. In most of the large applications I have seen the knowledge of the (complex) bean construction has been taken out the of the code and worse JavaDoc and placed into numerous XML files making it practically impossible to use the Spring "non-invasive" bean in a normal environment. I do not think it and other similar frameworks are neutral to the programming model. The programming model is now less explicit and within another language but again there is nothing non-invasive at least in the real world examples which I have seen. By the way I not think knowledge of a container is such a big problem. We have JVM containers today which hide the underlying hardware and execution environment. The issue to me is whether the container is standardized. To do anything really meaningful you always need to interact with a container. regards, William
  20. agreed[ Go to top ]

    I agree with williams comments. In particular the distribution of logic between XML and Java is something that makes me really wonder every time I see it.. Another thing I like about Bob's Guice presentations - he does not present DI frameworks (or Guice) as an indispensible and all-encompassing solution, but rather points out that DI is a technique that serves a very specific purpose (isolating the object creation and assembly aspects) and should be used after careful consideration of the needs and benefits. I have seen too many cases where Spring was used just because it was "the thing to do". Christian
  21. Re: agreed[ Go to top ]

    I agree with williams comments. In particular the distribution of logic between XML and Java is something that makes me really wonder every time I see it
    I hope you've been wondering this for several years then, as Spring certainly didn't invent the idea of XML configuration. I seem to remember some popular things called Struts and J2EE that placed an awful lot of logic in XML files. When Spring came out in 2003, XML configuration was still very prevalent. Annotations are certainly gaining in popularity as an alternative and improvement over XML configuration, and it's good that a framework like Guice exists not only as an alternative to Spring, but also to challenge Spring to further innovate. After all, if annotations were around in 2002, who's to say Spring wouldn't be an annotation-driven framework today? I agree with everything Bob says about DI, but I find his claim that he'd rather write factories by hand than keep XML in sync to be overly dramatic. Did he feel this way about J2EE as well, where he'd rather write his own app server than keep web.xml and ejb-jar.xml files in sync? So let's drop the hysterical arm-flapping about how awful XML configuration is and how a framework or product based on it is a "non-starter". Thousands of successful, maintainable systems have been built on such "non-starters" over the past several years. Let's try to keep that in mind when discussing the latest silver bullets.
  22. Re: agreed[ Go to top ]

    Hi Rob, I was actually there at the very beginning of J2EE/EJB. I did not have problems with XML then and not now but then again I did not have xml files that included the configuration of every single pojo object which some frameworks encourage (but not deliberately). In fact the registry database image used to define the views within JXInsight are all generated from a very large registry.xml file. I think the difference here is when the XML is used as a replacement for code execution paths than mere meta-data and configuration definitions. I cannot clearly define in one blog entry when XML is abused (replaces the programming language) but I know it when I see it - when the code itself becomes barren and understanding diminishes. It all about trade-off but some people always want to abuse a good thing. regards, William
  23. Re: agreed[ Go to top ]

    I agree with everything Bob says about DI, but I find his claim that he'd rather write factories by hand than keep XML in sync to be overly dramatic. Did he feel this way about J2EE as well, where he'd rather write his own app server than keep web.xml and ejb-jar.xml files in sync?
    My problem isn't with XML per se. Guice may even support XML configuration in the future (it'll be quite different from what you see in Spring). My problem is with having to write and change external configuration every time I add or change my dependencies. While using XML to map servlet paths makes good sense, using XML instead of Java to call Java methods doesn't. Also, I don't like EJB at all. That's why I wrote Bitter EJB. ;)
    So let's drop the hysterical arm-flapping about how awful XML configuration is and how a framework or product based on it is a "non-starter". Thousands of successful, maintainable systems have been built on such "non-starters" over the past several years. Let's try to keep that in mind when discussing the latest silver bullets.
    You can same the same for J2EE, EJB, and even COBOL. We must think critically about our tools and not allow our egos or the status quo to get tied up in our decisions and stifle forward movement.
  24. Re: agreed[ Go to top ]

    I hope you've been wondering this for several years then, as Spring certainly didn't invent the idea of XML configuration. I seem to remember some popular things called Struts and J2EE that placed an awful lot of logic in XML files
    you are right. In particular I could never get along with Struts's notion of putting page navigation into XML. Unfortunately this very "feature" was passed on to JSF. I do agree with those who said that its ok to put metadata (e.g. database mapping) into XML, but not application logic.
    So let's drop the hysterical arm-flapping about how awful XML configuration is and how a framework or product based on it is a "non-starter". Thousands of successful, maintainable systems have been built on such "non-starters" over the past several years. Let's try to keep that in mind when discussing the latest silver bullets
    I dont see anyone hysterical or arm-flapping. I also dont question that successful systems have been built using XML (or even assembly language or C or whatever). I just dont think its introduction for purposes beyond pure metadata was any real progress in the software engineering trade. Chris
  25. Re: I still don't see the point ...[ Go to top ]

    Again you are looking at this from the point of view of a Spring container user and not a non-Spring container user.

    In most of the large applications I have seen the knowledge of the (complex) bean construction has been taken out the of the code and worse JavaDoc and placed into numerous XML files making it practically impossible to use the Spring "non-invasive" bean in a normal environment.

    I do not think it and other similar frameworks are neutral to the programming model. The programming model is now less explicit and within another language but again there is nothing non-invasive at least in the real world examples which I have seen.

    By the way I not think knowledge of a container is such a big problem. We have JVM containers today which hide the underlying hardware and execution environment.

    The issue to me is whether the container is standardized. To do anything really meaningful you always need to interact with a container.

    regards,

    William
    Then at the very least blame the software writers, not the tool. If someone cannot drive and wreck their car, you most likely don't conclude that cars bad. Clearly, Spring is not magic. Dependencies have to go somewhere. The question is where does it go? In XML where the code can be rendered more reusable and the XML changed without rebuilding quite so much or in the code where the most minor change can be an issue. I prefer the XML. I've had to change transaction functionality and AOP in testing, demo, and production environments in ways that annotations would not allow. If you don't need to do so, don't use it, but for those who want to take advantage of that ability, it is invaluble. Before Spring, I'm sure we've all seen code that *still* had bad docs and bad comments. Spring doesn't change that. Spring doesn't give people the ability to structure code in such a way to be more readable or allow developers to comment their work better. I have 100% confidence that the code I've written is more maintainable with Spring than without. I also understand that some documentation is needed to explain that certain facilities are implmented in Spring AOP(caching, security,transactions). Should I not use such constructs because they require some ramp-up time? Didn't we here similar arguments about C++? I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring. Spring's claims were to: - remove the dependencies of a calling module from a callee module, which it has done and to - allow one declaratively define those dependencies. - build on the first two to integrate with a variety of services - Give users the option of using POJOs with the first 3 and with unit testing. I've read nothing that said "Keep users from having to understand the system to maintain the system."
  26. Re: I still don't see the point ...[ Go to top ]

    Then at the very least blame the software writers, not the tool. If someone cannot drive and wreck their car, you most likely don't conclude that cars bad.
    This is a specious argument. Talk to a car insurance agent about why sports cars are more costly to insure.
    I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring.
    It was claimed by Kim Je in this thread and I don't see why he should not be able to respond to that statement.
  27. Re: I still don't see the point ...[ Go to top ]

    Then at the very least blame the software writers, not the tool. If someone cannot drive and wreck their car, you most likely don't conclude that cars bad.


    This is a specious argument. Talk to a car insurance agent about why sports cars are more costly to insure.

    I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring.


    It was claimed by Kim Je in this thread and I don't see why he should not be able to respond to that statement.
    Dear Mr Jams Waston, Would you kindly point out in which statement I claimed this? Namely, where I ever claimed Spring is non-invasive according to the new definition of "non-invasive" from William? Thanks! Ke
  28. Re: I still don't see the point ...[ Go to top ]

    Would you kindly point out in which statement I claimed this?
    Message #241570 "let alone they (XML based DIs) are non-invasive and container agnostic."
  29. Re: I still don't see the point ...[ Go to top ]

    Would you kindly point out in which statement I claimed this?


    Message #241570

    "let alone they (XML based DIs) are non-invasive and container agnostic."
    This was assumed the common meaning of "non-invasive", (namely the POJO support) rather than by the new definition from William. Could you point out where I claimed Spring was non-invasive by William's new definition? Thanks! Ke
  30. Re: I still don't see the point ...[ Go to top ]

    Could you point out where I claimed Spring was non-invasive by William's new definition?
    Can you tell me the "old" definition?
  31. Re: I still don't see the point ...[ Go to top ]

    Could you point out where I claimed Spring was non-invasive by William's new definition?


    Can you tell me the "old" definition?
    Sorry, not anymore, not when you refuse to read. I have repeatly given this "old" definition in this thread at least 3 times. Go to read and count youself. Besides, this "old" definition was neither rare used nor debated among DI folks/documents, but has largely been accepted for years.
  32. Re: I still don't see the point ...[ Go to top ]

    Could you point out where I claimed Spring was non-invasive by William's new definition?


    Can you tell me the "old" definition?


    Sorry, not anymore, not when you refuse to read. I have repeatly given this "old" definition in this thread at least 3 times. Go to read and count youself. Besides, this "old" definition was neither rare used nor debated among DI folks/documents, but has largely been accepted for years.
    Your argument rests upon the assumption that your definition of 'non-invasive' is the true definition and that William has redefined it. It's also plain to see that you never made any qualifications of what you meant by 'non-invasive' before William responded to the comment.
  33. Re: I still don't see the point ...[ Go to top ]

    Could you point out where I claimed Spring was non-invasive by William's new definition?


    Can you tell me the "old" definition?


    Sorry, not anymore, not when you refuse to read. I have repeatly given this "old" definition in this thread at least 3 times. Go to read and count youself. Besides, this "old" definition was neither rare used nor debated among DI folks/documents, but has largely been accepted for years.


    Your argument rests upon the assumption that your definition of 'non-invasive' is the true definition and that William has redefined it. It's also plain to see that you never made any qualifications of what you meant by 'non-invasive' before William responded to the comment.
    Yes, true, in my very first post in this thread, I wasn't bother to define what is "non-invasive". Because, firstly, that post was not really about non-invasiveness but mainly questioning the validness of the following two arguments, namely: "XML configurations lack static type safety, and XML configurations were refactoring adverse". My arguments in these questions have nothing rests on the defintion of "non-invasiveness". Second, I thought that the meaning of "non-invasive" was well understood and agreed among DI folks. After William's respons, I have been repeatly clarifying what I meant "non-invasive". Regardless which definition is correct, it is a plain fact that I and William have totally different definitions. However, you just keep spreading the lie that I had claimed "Spring was non-invasive by William's defintion". How could I claim this without even agreeing his definition of "non-invasiveness"? Secondly, I even not mention Spring in my first post. I only start to refer Spring in clarifying what non-invasiveness meant in my mind under the context of Spring (because William already mention it), namely POJOs. Also, you are doing this in a very ugly manner, by quoting part of a sentance and delibrately cutting out what has been clarified in rest part of the sentance.
  34. Re: I still don't see the point ...[ Go to top ]

    However, you just keep spreading the lie that I had claimed "Spring was non-invasive by William's defintion".
    This is merely a misunderstanding. Someone else suggested that William was attacking a strawman because Spring's developers never made any such claim. I merely pointed out the source of that sub-discussion. It was not meant to be an attack in any way. If I had known that you would take offense to that, I would have stated it differently. I believe I understand what you meant but I also think Williams points were pertinent. I think maybe his point was that the term itself as used with respect to DI implies more than it really means. There was no judgement in my pointing out where that part of the discussion started.
  35. Re: I still don't see the point ...[ Go to top ]

    I still don't see the point of using such terms as POJO, non-invasive, containers, ... when there is actual no agreed definition to these. To be honest I find it plain silly to classify code with such terms certainly with the first term. If a POJO stood up in front of my face I probably would not recognize but maybe that is the point - you should not recognize it because it is plain and old. I think I made it pretty clear that anyone claiming "non-invasive" had simplified their domain and/or its definition considerably ignoring all the other concerns that a professional software engineer should factor into any proposed design and eventually supported deployment topologies and integrations. I have read back over your posts and you are critical of invasive containers when you have not even specified what you mean by the container, invasive.... It this a Spring container or a plain old EJB container? No need to answer this was me joking. Can you please refrain from making all this a personal issue. There is no "William definition". I am just a software designer who understands what is meant by non-invasive and invasive and I can attribute aspects of frameworks with either one based on the context - (compile time, runtime, configuration, .....). In any final assessment there is always an intrusion on the solution space by our technology choices. We are just fooling ourselves to think otherwise. We are just shuffling things (invasiveness) from one place (development) to another (maintenance, deployment, operations). A large proportion of engineers must like doing this because it seems so popular in our field at this moment . "Here take our software it is free", "Now, give us money to fix, document, or support the free software you just took". I am not necessarily knocking the OSS model just stating the obvious which is missing from this thread. There is no magic and nothing is free in life. The difference for me is that I have not taken any stance on which technology or approach I prefer. I see problems (in context) with each one but is this not normal for a software architect or developer? At the end of the day choices we make do impact (or limit) future choices and to say otherwise is being stupid or being a fan boy for a particular technology. We can only make "good" choices when we can be honest with ourselves and others. regards, William
  36. Re: I still don't see the point ...[ Go to top ]

    I still don't see the point of using such terms as POJO, non-invasive, containers, ... when there is actual no agreed definition to these. To be honest I find it plain silly to classify code with such terms certainly with the first term. If a POJO stood up in front of my face I probably would not recognize but maybe that is the point - you should not recognize it because it is plain and old.

    I think I made it pretty clear that anyone claiming "non-invasive" had simplified their domain and/or its definition considerably ignoring all the other concerns that a professional software engineer should factor into any proposed design and eventually supported deployment topologies and integrations.

    I have read back over your posts and you are critical of invasive containers when you have not even specified what you mean by the container, invasive.... It this a Spring container or a plain old EJB container? No need to answer this was me joking.

    Can you please refrain from making all this a personal issue. There is no "William definition". I am just a software designer who understands what is meant by non-invasive and invasive and I can attribute aspects of frameworks with either one based on the context - (compile time, runtime, configuration, .....).

    In any final assessment there is always an intrusion on the solution space by our technology choices. We are just fooling ourselves to think otherwise. We are just shuffling things (invasiveness) from one place (development) to another (maintenance, deployment, operations).

    A large proportion of engineers must like doing this because it seems so popular in our field at this moment . "Here take our software it is free", "Now, give us money to fix, document, or support the free software you just took". I am not necessarily knocking the OSS model just stating the obvious which is missing from this thread. There is no magic and nothing is free in life.

    The difference for me is that I have not taken any stance on which technology or approach I prefer. I see problems (in context) with each one but is this not normal for a software architect or developer? At the end of the day choices we make do impact (or limit) future choices and to say otherwise is being stupid or being a fan boy for a particular technology. We can only make "good" choices when we can be honest with ourselves and others.

    regards,

    William
    My understanding on non-invasive was minimal dependence on framework API. And I would argue that in my experience with Spring this is the case. Can I port the app in question from Spring with minimal effort. Yes, with two expections, my use of Spring's Persistence convenience classes and the AOP which uses Spring's interfaces. At least in my stuff, I could wire all the objects by hand and the app would work. I would have to reimplement the persistence tier, perhaps use Hibernate directly, and reimplement how things like security and caching. Another example is how on one project, we ported from Oracle9ias, to JRun, to Tomcat all in once dev cycle. In this, I switched from the connectionpooling provided by Oracle9ias to C3PO's connection pool and made the DS changes need all in XML and never had to touch the code. However, if you looked at the code, you would see very little Spring. As you mentioned, you would need to know about configuration, which I think we handled well, or at least no one ever had any problems and the solution scaled well to smaller and larger apps and across different projects. You would also need to know about AOP. If you didn't some stuff may come as a surprise in a manner simiilar to someone not realizing that a particular method was overriden. However, for me, the XML came with the useful ability to change things without having to change code. This was a feature I used and I think that the annotations tend to spread around certain information as opposed to a single file that gives me the lay of the "lay of the land" of certain architectural details.
  37. Re: I still don't see the point ...[ Go to top ]

    However, for me, the XML came with the useful ability to change things without having to change code.
    XML is code. If you want to reconfigure something without recompiling, you can use a properties file (or an XML file). But, you don't need to put everything, including the stuff that shouldn't change, in XML.
    This was a feature I used and I think that the annotations tend to spread around certain information as opposed to a single file that gives me the lay of the "lay of the land" of certain architectural details.
    You can easily generate this "big picture" graph using the upcoming version of Guice instead of maintaining it by hand.
  38. Re: I still don't see the point ...[ Go to top ]

    XML is code.
    Kind of off-topic but XML isn't always code. Sometimes it's code. Sometimes it's configuration data. Sometimes it's application data. Sometimes it's message data. Sometimes it's a document. Not everyone sees the same thing in XML either. Some people think it's a degenerate LISP and use it that way. Other people think it's a fancy delimited file format. That's my problem with XML. It's used for too many things and it's easy for the unwary to mix data and code in ways that are unstable or even dangerous. I'm not talking about anything in particular here. Just a general observation. With regard to Guice, if the idea it to add another form of code, I'd prefer a DSL or a solid dynamic language over XML. Obviously you are going to do it the way you see is best but that's my 2 cents.
  39. Re: I still don't see the point ...[ Go to top ]

    Then at the very least blame the software writers, not the tool. If someone cannot drive and wreck their car, you most likely don't conclude that cars bad.


    This is a specious argument. Talk to a car insurance agent about why sports cars are more costly to insure.

    I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring.


    It was claimed by Kim Je in this thread and I don't see why he should not be able to respond to that statement.
    Again, I only speak of what William referenced, not what he claimed. William seemed to have an issue with a particular facet of Spring usage and I attempted to address it. Now, I don't agree with you that my arguement was specious and in fact, believe you statement, ironically enough, is. No machine can be better than its operator. Someone can abuse Guice's annotation just like someone can abuse Spring's XML. That misuse doesn't make either tool wrong, yet William, if I'm interpreting him correctly seems to place any perceived missuse at the feet of Spring and not on the developer. I simply don't agree with that sentiment.
  40. Re: I still don't see the point ...[ Go to top ]

    Now, I don't agree with you that my arguement was specious and in fact, believe you statement, ironically enough, is.
    No machine can be better than its operator.
    It is specious and misleading. Take the M-16 automatic rifle and the Kalashnikov family of rifles. The M-16 will work reasonably well as long as it is meticulously cleaned and kept free of dust and moisture. A Kalashnikov will generally operate perfectly even when abused. The Kalashnikov is a superior machine. My car has four wheel anti-lock disc brakes. I used to own a car with normal drum brakes. There have been a number of incidents where the superior stopping power of my current car's braking system has saved me from collisions and possibly death where my old car's brakes would have surely locked up into a skid. My current car is a superior machine. There are any number of machines that allow inferior operators to produce results that are equivalent to or better than superior operators using other equipment. I have a table saw and a hand held circular saw. Both cut wood in basically the same fashion. The table saw, however produces much more precise and accurate results than I can achieve with the hand held saw. The idea that all machines or software are equivalent and that only the operator matters is preposterous.
  41. Re: I still don't see the point ...[ Go to top ]

    Now, I don't agree with you that my arguement was specious and in fact, believe you statement, ironically enough, is.
    No machine can be better than its operator.


    It is specious and misleading. Take the M-16 automatic rifle and the Kalashnikov family of rifles. The M-16 will work reasonably well as long as it is meticulously cleaned and kept free of dust and moisture. A Kalashnikov will generally operate perfectly even when abused.

    The Kalashnikov is a superior machine.

    My car has four wheel anti-lock disc brakes. I used to own a car with normal drum brakes. There have been a number of incidents where the superior stopping power of my current car's braking system has saved me from collisions and possibly death where my old car's brakes would have surely locked up into a skid.

    My current car is a superior machine.

    There are any number of machines that allow inferior operators to produce results that are equivalent to or better than superior operators using other equipment. I have a table saw and a hand held circular saw. Both cut wood in basically the same fashion. The table saw, however produces much more precise and accurate results than I can achieve with the hand held saw.

    The idea that all machines or software are equivalent and that only the operator matters is preposterous.
    No, you just continue to demostrate a large chip on your shoulder and and an impressive ability to misinterpret much of what is going on around you. I am not comparing any two machines. If you want to argue Spring and Guice, that is a different debate. I am only addressing the issue with Spring that William mentioned. Yours in an entirely different debate that you seem rather intent on having. In fact, your last line seems to sum up your style. You seem to make up wild statements and then proceed to debate their merits. That fits in line with someone who states that "Spring is the new religion." all the implying that others think this when NO ONE, but you, has stated this.
  42. Re: I still don't see the point ...[ Go to top ]

    No, you just continue to demostrate a large chip on your shoulder and and an impressive ability to misinterpret much of what is going on around you.
    Responses like this one demonstrate a lack of ability to argue a point coherently.
    I am not comparing any two machines. If you want to argue Spring and Guice, that is a different debate. I am only addressing the issue with Spring that William mentioned. Yours in an entirely different debate that you seem rather intent on having.
    You wrote: "No machine can be better than its operator. Someone can abuse Guice's annotation just like someone can abuse Spring's XML." In English "no machine" doesn't refer to a specific machine. So in fact it does apply to any two machines. Some machines and tools can be abused in ways that others cannot. Some machines can work well even when abused. Machines that prevent errors are superior to those that do not. Whether this is the case for Guice vs. Spring is in question but you have not made your argument specific to Guice. You made a general statements about machines.
    In fact, your last line seems to sum up your style. You seem to make up wild statements and then proceed to debate their merits.

    That fits in line with someone who states that "Spring is the new religion." all the implying that others think this when NO ONE, but you, has stated this.
    It is not my fault that your argument doesn't make sense.
  43. Re: I still don't see the point ...[ Go to top ]

    No, you just continue to demostrate a large chip on your shoulder and and an impressive ability to misinterpret much of what is going on around you.


    Responses like this one demonstrate a lack of ability to argue a point coherently.

    I am not comparing any two machines. If you want to argue Spring and Guice, that is a different debate. I am only addressing the issue with Spring that William mentioned. Yours in an entirely different debate that you seem rather intent on having.


    You wrote:

    "No machine can be better than its operator. Someone can abuse Guice's annotation just like someone can abuse Spring's XML."

    In English "no machine" doesn't refer to a specific machine. So in fact it does apply to any two machines.

    Some machines and tools can be abused in ways that others cannot. Some machines can work well even when abused. Machines that prevent errors are superior to those that do not. Whether this is the case for Guice vs. Spring is in question but you have not made your argument specific to Guice. You made a general statements about machines.

    In fact, your last line seems to sum up your style. You seem to make up wild statements and then proceed to debate their merits.

    That fits in line with someone who states that "Spring is the new religion." all the implying that others think this when NO ONE, but you, has stated this.


    It is not my fault that your argument doesn't make sense.
    Your responses only demostrate that you feel compelled to argue and misinterpret. No matter, I believe that the reasonable people understand what I was saying. As for the unreasonable ones..., hostility is their religion.
  44. Re: I still don't see the point ...[ Go to top ]

    Your responses only demostrate that you feel compelled to argue and misinterpret. No matter, I believe that the reasonable people understand what I was saying.
    I understood it and disagree with it.
    As for the unreasonable ones..., hostility is their religion.
    Passive aggression is a form of hostility. I prefer more open and honest attacks on my person.
  45. Re: I still don't see the point ...[ Go to top ]

    Take the M-16 automatic rifle and the Kalashnikov family of rifles. The M-16 will work reasonably well as long as it is meticulously cleaned and kept free of dust and moisture. A Kalashnikov will generally operate perfectly even when abused.

    The Kalashnikov is a superior machine.
    I love this analogy. It fits perfectly.
  46. Re: I still don't see the point ...[ Go to top ]

    I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring.
    Is is really too much to ask for people to actually read the complete thread or at least the pathway to my command. I never said the Spring team claimed their solution was non-invasive. This was stated first by someone else. Maybe the interface21 team did claim it or not. Maybe they never stated it was not the case when a fan stated it. It does not really matter because it is wrong at least from a not so narrow minded perspective. When someone who has not bought into Spring cannot understand what the actual construction (and dependency) requirements for an object are or is forced to create an Spring application context just to be able to access an object (lets say a JCR repository) then there is definitely something wrong. I cannot imagine a JDBC driver forcing this on someone but amazingly this is the case with one prominent OSS CMS (supposedly a JCR implementation) based largely on Spring. It is practically impossible to unravel this beast and understand how to just get the core runtime to work without creating 500 Spring beans. Today it is pretty simply to use a JDBC driver but maybe that it all about to change. If it is going to be so then can this please be within the runtime and packaged in a way that I do not have to include 80-160 jars because I have not got the courage and patience to wade through 10+ context xml files. regards, William
  47. I think that until the day this is all part of the runtime, authors of products that offer an API should not push their choice of framework in everyones face. There should be at minimum support for plain old Java programming (POJP) and then additional ease of integration offered for those using particular frameworks. You can decided to layer on Spring or Guice support later after the underlying system or component or library works or use these frameworks yourself internally whilst still offering an interface that hides the complexity and/or technology implementation issues. Unfortunately it seems that most projects I come across the developers feel proud of surfacing the internals and shoving it everyones face like some badge of honor of sorts but sadly to me it is more like a security guard badge resembling a police officer badge. Maybe this trend is connected with the open source movement and openness (even when its your internals) is the flavor of month (or year). regards, William
  48. Re: I still don't see the point ...[ Go to top ]

    I think that until the day this is all part of the runtime, authors of products that offer an API should not push their choice of framework in everyones face.
    It seems to me a lot of Java developers have decided that Spring is the ultimate solution and that no application should ever need to be built without it. Of course this is not a new phenomenon. It's just a few years back where every enterprise application was assumed from the outset to be n-tier with EJBs. Suggesting that Entity Beans weren't the bee's knees back then would draw the same kind of ire you see here. That people are offended by the thought of creating a competitor to Spring is to me evidence that this is the case. Spring is the new religion.
  49. Re: I still don't see the point ...[ Go to top ]

    I think that until the day this is all part of the runtime, authors of products that offer an API should not push their choice of framework in everyones face.


    It seems to me a lot of Java developers have decided that Spring is the ultimate solution and that no application should ever need to be built without it.

    Of course this is not a new phenomenon. It's just a few years back where every enterprise application was assumed from the outset to be n-tier with EJBs. Suggesting that Entity Beans weren't the bee's knees back then would draw the same kind of ire you see here.

    That people are offended by the thought of creating a competitor to Spring is to me evidence that this is the case. Spring is the new religion.
    That's *your* interpretation and non necessarily the correct one. My interpretation is that there is always someone who doesn't like whatever is popular because they think that something so popular cannot possibly be good. In fact, I'll offer a less revisionist opinion of entity beans. They were *supposed* to offer certain benefits and didn't. I tried them and it didn't work out so I stopped using them as did lots of people. Spring differs, IMO, because it has made good on its promises time and time again. It may seem to you that "a lot of Java developers have decided that Spring is the ultimate solution", but that is just your flawed interpretation of the environment. I use Spring and it has served me well, but I don't think it is the ultimate anything. I doubt any developer who uses Spring thinks that. In fact, I would say that most developers are mercenaries. As soon as something better emerges, they'll use that. I suspect if that Guice was on top and Spring was the newbie, you'll would say that "Guice is the new religion."
  50. Re: I still don't see the point ...[ Go to top ]

    That's *your* interpretation and non necessarily the correct one. My interpretation is that there is always someone who doesn't like whatever is popular because they think that something so popular cannot possibly be good.

    In fact, I'll offer a less revisionist opinion of entity beans.
    It's not revisionist and I find your implication I am lying to be highly offensive. My statement comes from my own personal experience. I never claimed that you loved entity beans and the idea that your personal history disproves my assertion is just illogical.
    In fact, I would say that most developers are mercenaries. As soon as something better emerges, they'll use that.
    You do understand the difference between 'a lot', 'most', and 'all' right? If that's the case then why would people be so against a new DI framwork being developed instead of 'improving the existing one'?
    I suspect if that Guice was on top and Spring was the newbie, you'll would say that "Guice is the new religion."
    I definitely would if people were acting religiously about it. I don't use Guice. I know almost nothing about it. I don't recommend it nor do I recommend against it.
  51. Re: I still don't see the point ...[ Go to top ]

    That's *your* interpretation and non necessarily the correct one. My interpretation is that there is always someone who doesn't like whatever is popular because they think that something so popular cannot possibly be good.

    In fact, I'll offer a less revisionist opinion of entity beans.


    It's not revisionist and I find your implication I am lying to be highly offensive. My statement comes from my own personal experience. I never claimed that you loved entity beans and the idea that your personal history disproves my assertion is just illogical.

    In fact, I would say that most developers are mercenaries. As soon as something better emerges, they'll use that.


    You do understand the difference between 'a lot', 'most', and 'all' right?

    If that's the case then why would people be so against a new DI framwork being developed instead of 'improving the existing one'?

    I suspect if that Guice was on top and Spring was the newbie, you'll would say that "Guice is the new religion."


    I definitely would if people were acting religiously about it. I don't use Guice. I know almost nothing about it. I don't recommend it nor do I recommend against it.
    I think one person here questioned the existence of Guice. But guess what, when Spring came out, its existence was questioned. It doesn't people zealots for something to question why the other is better. That's the job of the newbie. I use Spring. Why should I use you? Convince me. Spring had to convince me. You seem perceive extremist behavior while exhibiting it. I don't think anyone, certainly in this thread has been acting religously at all. No one prays to it. Don't don't have faith in it, despite never actually used or even seen it. They don't make offerings to it. They don't raise their children to believe in it. No churches or iconagraphy. There are books, but no bibles. Now, to address your offended sensibilities. You say that I am implying that you are lying, but have no problems stating that I am being misleading. Interesting. I guess we just remember different histories about how entity beans worked out nad people's opinion of them. If my difference of opinion, offends you, well...I guess TS.
  52. Re: I still don't see the point ...[ Go to top ]

    I think one person here questioned the existence of Guice.
    I guess you are implying that that makes me wrong. How, I have no idea. There's actually a post that basically calls Bob Lee a 'preacher' but that's irrelevant in your eyes, I suppose.
    But guess what, when Spring came out, its existence was questioned. It doesn't people zealots for something to question why the other is better. That's the job of the newbie.
    I can't really make out what you are trying to say here.
    I use Spring. Why should I use you? Convince me. Spring had to convince me.
    I don't want you to 'use me' whatever you mean by that.
    You seem perceive extremist behavior while exhibiting it.
    Exactly how am I being extremist?
    I don't think anyone, certainly in this thread has been acting religously at all.
    I've read posts on the Java Forums where the poster literally states that all Java applications should use Spring. My comment about religion was general. I don't know where you got the idea that it was about the posters in this thread. The comment I was replying to was about library/framework authors delivering code with dependencies on Spring.
    Now, to address your offended sensibilities. You say that I am implying that you are lying, but have no problems stating that I am being misleading.

    Interesting.
    Not really. Making misleading arguments is just rhetoric. I dislike rhetoric but it's not a character flaw, just counter-productive. To say I am being revisionist is suggesting that I am being dishonest in my characterizing of the past.
    I guess we just remember different histories about how entity beans worked out nad people's opinion of them. If my difference of opinion, offends you, well...I guess TS.
    I distinctly recall people suggesting that Entity beans were not the greatest invention ever (maybe you were one of those people) and being attacked. I wouldn't have guessed that that anyone with experience in the Java world would argue that EJB was not overused and misused. I don't have any particular problem with Spring. What I have a problem with is people shoving it down my throat. You say that you haven't done that? Great, because I never accused you. Just because I post a comment on a thread you are reading doesn't mean it's about you. If you believe that no one is doing that, that's your option but I'm not tell you what has and hasn't happened to you. I'd like to enjoy the same courtesy from you.
  53. Re: I still don't see the point ...[ Go to top ]

    That's *your* interpretation and non necessarily the correct one. My interpretation is that there is always someone who doesn't like whatever is popular because they think that something so popular cannot possibly be good.
    Reminds of EJB. Just go back and read some old posts on this subject on TSS. Some people were shouting "this is wrong! this is wrong!" others responded angrily "but it works for us! yes we have to do this and that but it works! and it's standard!". I was, and still am a huge fan of Spring. But I see some very innovative new technologies on the market these days that are even more promising than legacy Spring, in some aspects. And yes Spring is legacy. It fells old, compared to newer stuff. I would really like to see DI standardized as a part of JDK. I want it everywhere, in JEE, in JSE, everywhere. And I don't see why interface21 doesn't contribute to these JSRs. This is not constructive. Ara.
  54. Re: I still don't see the point ...[ Go to top ]

    I think that until the day this is all part of the runtime, authors of products that offer an API should not push their choice of framework in everyones face.

    There should be at minimum support for plain old Java programming (POJP) and then additional ease of integration offered for those using particular frameworks. You can decided to layer on Spring or Guice support later after the underlying system or component or library works or use these frameworks yourself internally whilst still offering an interface that hides the complexity and/or technology implementation issues.

    Unfortunately it seems that most projects I come across the developers feel proud of surfacing the internals and shoving it everyones face like some badge of honor of sorts but sadly to me it is more like a security guard badge resembling a police officer badge. Maybe this trend is connected with the open source movement and openness (even when its your internals) is the flavor of month (or year).

    regards,

    William
    Well, think that market forces should speak. If it is advantages to offer their software in such a way that one has to buy into Spring, Guice, or whatever else, them I say do it. If it is wrong, the market will correct it soon enough. I've personally enjoyed using software that has configuration that followed Spring configuration. I certainly didn't think the developers were doing it to "shove" anything in my face.
  55. Re: I still don't see the point ...[ Go to top ]


    I submit that perhaps the "non-invasiveness" you reference was never claimed by Spring.


    Is is really too much to ask for people to actually read the complete thread or at least the pathway to my command. I never said the Spring team claimed their solution was non-invasive. This was stated first by someone else. Maybe the interface21 team did claim it or not. Maybe they never stated it was not the case when a fan stated it. It does not really matter because it is wrong at least from a not so narrow minded perspective.

    When someone who has not bought into Spring cannot understand what the actual construction (and dependency) requirements for an object are or is forced to create an Spring application context just to be able to access an object (lets say a JCR repository) then there is definitely something wrong. I cannot imagine a JDBC driver forcing this on someone but amazingly this is the case with one prominent OSS CMS (supposedly a JCR implementation) based largely on Spring. It is practically impossible to unravel this beast and understand how to just get the core runtime to work without creating 500 Spring beans.

    Today it is pretty simply to use a JDBC driver but maybe that it all about to change. If it is going to be so then can this please be within the runtime and packaged in a way that I do not have to include 80-160 jars because I have not got the courage and patience to wade through 10+ context xml files.

    regards,

    William
    I didn't say that you claimed anything. You references at statement about non-invasiveness, quoted it,and and seem to have pretty clear feelings about the matter. In your words, Spring makes it "practically impossible to unravel this beast and understand how to just get the core runtime to work without creating 500 Spring beans." So I posted my thoughts on the matter concerning what Spring was and was not attempting to do. You seemed to knee-jerk react and ironically not read what I wrote. I don't think Spring much to the complexity of any inherently complex piece of software. In fact, in my experience, quite the opposite. I have been able to integrate several software packages, using Spring, in such a way that made the whole easier to digest than each individual piece of software. To be frank, I don't even see how you can compare a jdbc driver and a CMS tool the way you've attempted. Regardless, some ramp-up was still needed on any non-trivial project, whether or not Spring is involved and I think you aim your considerable ire at the wrong target. Spring cannot replace documetation and was never intended to. And my understanding is that the Spring team claimed that your applications will have minimal dependencies on the Spring and in my experience, this is true.
  56. Re: I still don't see the point ...[ Go to top ]

    Again you are looking at this from the point of view of a Spring container user and not a non-Spring container user.

    In most of the large applications I have seen the knowledge of the (complex) bean construction has been taken out the of the code and worse JavaDoc and placed into numerous XML files making it practically impossible to use the Spring "non-invasive" bean in a normal environment.

    I do not think it and other similar frameworks are neutral to the programming model. The programming model is now less explicit and within another language but again there is nothing non-invasive at least in the real world examples which I have seen.

    By the way I not think knowledge of a container is such a big problem. We have JVM containers today which hide the underlying hardware and execution environment.

    The issue to me is whether the container is standardized. To do anything really meaningful you always need to interact with a container.

    regards,

    William
    Again, the term "non-invasive" has its precise meaning among DI framework folks, and largely means POJO support. If you want to change this definition, I don't care. My original post wasn't about non-invasiveness but mainly questioning the validness of the two claims. Namely XML configuration lack of static type safety and are refactoring adverse. Regards, Ke
  57. Re: I still don't see the point ...[ Go to top ]

    Ke Jin,
    However, for general applications, I fail to see the advantage of having application wiring logic that involving multiple components been spread in source code of individual components, let alone the invasiveness and tight coupling to particular container that defeat the POJO premise and largely prohibit components reuseability accross different containers.
    First, annotations don't tightly couple your code to the framework. I already blogged about this here. You can inject Guice objects with Spring if you like. Second, let me see if I can help you visualize the benefits. A common misconception about Guice is that it has an equivalent to Spring's XML. It doesn't. You simply don't have to do that work or maintain that code. For example, if you have a class Foo which depends on Bar and Tee, in Spring, you have to write both Foo itself and XML to configure it: public class Foo { public Foo(Bar bar, Tee tee) { ... } } If you use bar or tee somewhere else, you have to write more XML. You have to write XML every time you use a component! What's worse, if you reorder the constructor arguments in Foo, you have to reorder them in the XML, too. If you have M components which you use N times each, Spring requires O(M*N) code. In contrast, this is all you write in Guice: public class Foo { @Inject public Foo(Bar bar, Tee tee) { ... } } In the common cases, Guice only requires O(M) code. Sure, there are a minority of more complicated cases where you have to manually wire up your components, but that doesn't mean you should make all of your code complicated and verbose.
    The argument 2 sounds to be a red harring. The point of refactoring is to fix poorly designed implementations, enable code reuse, improve implementation via reorganizing, software evolution, etc.. Certainly, XML configuration without addtional tools (in fact, such tools should be that tough to be created) seems to be adverse to certain very primitive source code refactoring (such as member rename, package rename, etc.). However this kind of primitive refactorings are likely to be useful in fixing pooly designed implementations. The point of XML configuration, on the other hand, is precisely to avoid such kind of poorly made non-professional implementations at first place and to reduce the needs of such a low level refactoring.
    You sound just like someone trying to justify the fact that Ruby doesn't have static type checking.
  58. Re: I still don't see the point ...[ Go to top ]

    First, annotations don't tightly couple your code to the framework. I already blogged about this here. You can inject Guice objects with Spring if you like.
    Yes, certainly, and exactly as I pointed out last night. Because Spring treats your guice objects just as POJOs!! You have just provded the advantage of XML based non-invasive DI. Is Guice able to do injections on objects written without Guice in mind?

    The argument 2 sounds to be a red harring. The point of refactoring is to fix poorly designed implementations, enable code reuse, improve implementation via reorganizing, software evolution, etc.. Certainly, XML configuration without addtional tools (in fact, such tools should be that tough to be created) seems to be adverse to certain very primitive source code refactoring (such as member rename, package rename, etc.). However this kind of primitive refactorings are likely to be useful in fixing pooly designed implementations. The point of XML configuration, on the other hand, is precisely to avoid such kind of poorly made non-professional implementations at first place and to reduce the needs of such a low level refactoring.


    You sound just like someone trying to justify the fact that Ruby doesn't have static type checking.
    I was expecting you could convince me with some new sound arguments. thanks anyway!
  59. Re: I still don't see the point ...[ Go to top ]

    Is Guice able to do injections on objects written without Guice in mind?
    Yes, you have to explicitly wire those objects just like you do in Spring, either by extending the class and adding the annotations or by writing a custom provider. The next version of Guice supports this very elegantly with provider methods (much more elegantly than Spring's JavaConfig I might add).
    The argument 2 sounds to be a red harring. The point of refactoring is to fix poorly designed implementations, enable code reuse, improve implementation via reorganizing, software evolution, etc.. Certainly, XML configuration without addtional tools (in fact, such tools should be that tough to be created) seems to be adverse to certain very primitive source code refactoring (such as member rename, package rename, etc.). However this kind of primitive refactorings are likely to be useful in fixing pooly designed implementations. The point of XML configuration, on the other hand, is precisely to avoid such kind of poorly made non-professional implementations at first place and to reduce the needs of such a low level refactoring.


    You sound just like someone trying to justify the fact that Ruby doesn't have static type checking.


    I was expecting you could convince me with some new sound arguments. thanks anyway!
    I thought I made a good analogy. You claimed that the addition of XML alleviates the need for refactoring. I call bullshit. Not only do you still need to refactor your Java code, but now you also need to refactor Spring XML. With Guice, less code == less to refactor. So far, we've focused on annotation-based vs. XML configuration, but my distaste for Spring runs much deeper (nothing personal against Spring obviously). Guice has a much cleaner API and implementation and we pay much more attention to details and keeping things simple and predictable. Frameworks need to be simple (but not simplistic). To me, there's nothing worse than firing up a debugger and stepping into framework code so I can figure out what the heck my code is doing. Spring has a bloated, J2EE-esque feel to me; except, unlike J2EE standards, Spring didn't need to support multiple implementations, so the API and implementation are hopelessly entwined. I suspect users run into Spring's "quirks" pretty frequently. I sure did in the short time that I used it. I suspect those same people, the Spring developers included, don't recognize these quirks for what they are. If they did, Spring wouldn't have them. I think most Spring users were jaded by J2EE and are simply happy enough to identify the problem and get their code working. I have higher expectations for my frameworks. If I run into a problem, I ask, why wasn't the framework designed in such a way that I wouldn't run into this problem in the first place? I want a framework that blows up spectacularly when I make a mistake, a framework which tells me all the mistakes I made, not just the first one, a framework which gives me a hint as to how to fix problems. Programmers shouldn't have to read a 500 page book to maintain my code. They shouldn't have to grep the entire codebase to find out what's actually happening in a given line of code. There's no room for ambiguity and the framework trying to figure out what I'm thinking. That's how subtle errors creep into my application. I'm not saying Guice is completely devoid of these cases, but it definitely has very few of them. The bar for adding new features to Guice is very, very high. We solve real problems; we don't develop solutions in search of problems. We also don't just solve one problem. Like Java SE, we justify every feature with at least three use cases. If a problem can be solved as well or better using existing features, that use case doesn't count. We think there should be one best way of doing something. Having more than one way to do something just increases the learning curve and reduces the power-to-weight ration of your API. Take singletons, for example. I'm not sure how Spring came up with its policy. It doesn't make sense to me. When we designed this part of Guice, we recognized you want different behaviors at different times. In production (and integration testing), you want all your singletons to load eagerly so you detect errors early and the first user action doesn't take 5 minutes. In development, you want to lazy load as much as possible so you can start your application quickly and only load what you actually use. For tools, you don't want to load singletons at all (Guice makes heavy reuse between the runtime API and tool API). Now, before the Spring fanboys jump all over me (assuming you've bothered to read this far), I really don't like to say bad things about Spring, and I hope I haven't offended anyone too badly. I'm simply answering those people who ask incessantly why I don't "just use Spring." I'm also not telling you to use Guice. I've simply told you why I use Guice, and I put it out there and tried to make it easy for you to use, too. Guice is by no means a silver bullet. It just enables me to write code how I want to write it. Unlike the Spring folks, I make end user products, not dependency injection frameworks for a living, so I'm putting myself out here with very little to gain in the hopes that I can make Java just a little bit better. Please don't tell me why I should be using Spring. You'll be wasting your breath. If Spring is up to your standards and you like to use it, then I'm happy for you.
  60. Re: I still don't see the point ...[ Go to top ]

    Is Guice able to do injections on objects written without Guice in mind?
    Yes, you have to explicitly wire those objects just like you do in Spring, either by extending the class and adding the annotations or by writing a custom provider. The next version of Guice supports this very elegantly with provider methods (much more elegantly than Spring's JavaConfig I might add).

    "Just like"? Would you pls show some example code side by side let's see how simple or complex they would "just like" to each other in this case?
    The argument 2 sounds to be a red harring. The point of refactoring is to fix poorly designed implementations, enable code reuse, improve implementation via reorganizing, software evolution, etc.. Certainly, XML configuration without addtional tools (in fact, such tools should be that tough to be created) seems to be adverse to certain very primitive source code refactoring (such as member rename, package rename, etc.). However this kind of primitive refactorings are likely to be useful in fixing pooly designed implementations. The point of XML configuration, on the other hand, is precisely to avoid such kind of poorly made non-professional implementations at first place and to reduce the needs of such a low level refactoring.
    You sound just like someone trying to justify the fact that Ruby doesn't have static type checking.
    I was expecting you could convince me with some new sound arguments. thanks anyway!
    I thought I made a good analogy.

    Your made an analogy, however, without giving any reasons to justify it.
    You claimed that the addition of XML alleviates the need for refactoring. I call bullshit.

    This kind of statement without fact is even worse than appeal to authority fallacy. It seems you thought you had the authority to make such a verdict without presenting facts?
    Not only do you still need to refactor your Java code, but now you also need to refactor Spring XML. With Guice, less code == less to refactor.
    This simple equation proves you have never thought through this issue. The cost of refactoring does not proporation to number of lines of code. It depends on: 1. Type of the refactoring: Is it low level code refactoring, or high level architecture changes and component rewiring and replacement? 2. How you are going to conduct the refactoring? For instance, using refactoring tools or by disciplined developers? For low level refactoring with tools, it really doesn't matter you have 100 lines of code or 120 lines of code. Do you have any concrete number to prove how much cost XML configuration would add to such kind of refactoring in general cases? And reason behind such a refactoring? For instance, original app was poorly implemented, etc.. Also, is that a refactoring tool handle literal signatures in XML configuration files that hard to be implemented than resorting to an annotation based DI? For architecture level refactoring, the crutial thing is to understand the architecture itself and the flexability of the original design. Refactoring cost in this case is more relevant to code quality, style, paradigm, etc. than size (number of lines). The imperative natural of classic OO languages tends to miss the forest for the trees and made it very hard for one to figure out the architecture from the code. One has to rely on separated documents, and even low level code comments, patterns to piece out the whole picture of the system. XML configurations, if designed properly, provides a centralized, declarative, and self-documented description of the system. It would largely help the high level refactoring.
    So far, we've focused on annotation-based vs. XML configuration, but my distaste for Spring runs much deeper (nothing personal against Spring obviously).
    You are very keen on setting up the camp and changing the discussion on my topic a religious war. Pls read my initial post and all my followups. In the initial post where I questioned the two false claims about XML vs annotation, I did not even mention Spring at all. In all of my followup after that, I only mentioned Spring when I was questioned specifically. This is simply because I really don't see my questions are relevant to Spring vs Guice. AFAIK: 1. Many other DI frameworks also support XML configurations, 2. Spring supports annotation based DI, 3. Guice is absoluately not the first one to support annotation based DI. Why on earth my XML vs annotation questions are relevant to Spring vs Guice? Who shamelessly claimed Spring entitles XML configurations and Guice deserves the icon of annotation DI? In your post following up mine, you spent 10 or even 20 times more words on the Spring vs Guice war (which I am not involved and have no interest) than to present facts (if any) to answer my questions about annotation itself. I was half/half guessing I might be wrong last night before my first post and was expecting to be convinced. Your reaction only convince me that my guess is the reality, you made the false claims on XML configurations before even thought through them at all.
    Guice has a much cleaner API and implementation and we pay much more attention to details and keeping things simple and predictable. Frameworks need to be simple (but not simplistic). To me, there's nothing worse than firing up a debugger and stepping into framework code so I can figure out what the heck my code is doing. Spring has a bloated, J2EE-esque feel to me; except, unlike J2EE standards, Spring didn't need to support multiple implementations, so the API and implementation are hopelessly entwined.

    I suspect users run into Spring's "quirks" pretty frequently. I sure did in the short time that I used it. I suspect those same people, the Spring developers included, don't recognize these quirks for what they are. If they did, Spring wouldn't have them. I think most Spring users were jaded by J2EE and are simply happy enough to identify the problem and get their code working.

    I have higher expectations for my frameworks. If I run into a problem, I ask, why wasn't the framework designed in such a way that I wouldn't run into this problem in the first place? I want a framework that blows up spectacularly when I make a mistake, a framework which tells me all the mistakes I made, not just the first one, a framework which gives me a hint as to how to fix problems. Programmers shouldn't have to read a 500 page book to maintain my code. They shouldn't have to grep the entire codebase to find out what's actually happening in a given line of code. There's no room for ambiguity and the framework trying to figure out what I'm thinking. That's how subtle errors creep into my application. I'm not saying Guice is completely devoid of these cases, but it definitely has very few of them.

    The bar for adding new features to Guice is very, very high. We solve real problems; we don't develop solutions in search of problems. We also don't just solve one problem. Like Java SE, we justify every feature with at least three use cases. If a problem can be solved as well or better using existing features, that use case doesn't count. We think there should be one best way of doing something. Having more than one way to do something just increases the learning curve and reduces the power-to-weight ration of your API.

    Take singletons, for example. I'm not sure how Spring came up with its policy. It doesn't make sense to me. When we designed this part of Guice, we recognized you want different behaviors at different times. In production (and integration testing), you want all your singletons to load eagerly so you detect errors early and the first user action doesn't take 5 minutes. In development, you want to lazy load as much as possible so you can start your application quickly and only load what you actually use. For tools, you don't want to load singletons at all (Guice makes heavy reuse between the runtime API and tool API).

    Now, before the Spring fanboys jump all over me (assuming you've bothered to read this far), I really don't like to say bad things about Spring, and I hope I haven't offended anyone too badly. I'm simply answering those people who ask incessantly why I don't "just use Spring."

    I'm also not telling you to use Guice. I've simply told you why I use Guice, and I put it out there and tried to make it easy for you to use, too. Guice is by no means a silver bullet. It just enables me to write code how I want to write it. Unlike the Spring folks, I make end user products, not dependency injection frameworks for a living, so I'm putting myself out here with very little to gain in the hopes that I can make Java just a little bit better.

    Please don't tell me why I should be using Spring. You'll be wasting your breath. If Spring is up to your standards and you like to use it, then I'm happy for you.
  61. Re: I still don't see the point ...[ Go to top ]

    Ke Jin, First, let me say that I really enjoyed your first response (as well as the followups). You have an exceptionally good understanding of dependency injection. I'm sorry that I got off on a tangent and didn't address your original point more directly.
    "Just like"? Would you pls show some example code side by side let's see how simple or complex they would "just like" to each other in this case?
    Let's continue my example from above. Here's the Spring XML which configures Foo: Here's a Guice provider method which does the same: @Provides Foo provideFoo(Bar bar, Tee tee) { return new Foo(bar, tee); } I think the two examples are reasonably comparable. Both have some level of repetition. They require similar effort to write. I prefer the latter because it's plain Java. No need for specialized tools. Back to your original points. Your first point was that you can write tools to type check XML. I agree--that's why I didn't dispute your claim. I don't think I've said otherwise, not at least since Guice came out. In fact, IntelliJ already supports Spring in this way. You may have thought that I didn't address your point in my first response, but I really just jumped ahead a bit. I don't care if you can write a tool to type check your XML at compile time. Whether it's XML or Java, I don't want to write this code at all. O(M*N) vs. O(M). In your last response, you claimed that this XML is still useful for high level refactorings:
    XML configurations, if designed properly, provides a centralized, declarative, and self-documented description of the system. It would largely help the high level refactoring.
    With Guice, you can generate this graph automatically and not have to maintain it by hand.
    3. Guice is absoluately not the first one to support annotation based DI.
    Can you cite an earlier example? I suppose you could count @Resource, but I think Guice was the first to enable users to define their own annotations and not require string identifiers. Anyway, like I said in the interview, it was really Kevin B.'s idea to drop string identifiers altogether and use annotations instead. That was the first I heard of it. Regarding lower level refactoring, I suppose I can provide a couple examples. I like constructor injection. One thing that bothered me about Spring was that if I added a parameter or reordered parameters, I had to keep the external XML in sync. This isn't a problem with Guice; code changes are more localized. With Guice, I can rename just about anything reliably without needing specialized (non Java) tools. With Guice, I can use plain Java IDEs to navigate my application (find usages). Did I cover everything?
  62. Re: I still don't see the point ...[ Go to top ]

    Bob, Thanks for your words, and really happy to see we can forget about the religious war and start to discuss facts. To be honestly, I am not a fan on any Java DI frameworks (neither Spring nor Guice). I am working on a project and came across your statements that conflict to my vision (certainly, I could be very very very wrong). That is why I asked here. Let's start from your example. Firstly, i find it is very hard to do quote in this forum. Therefore, I drop all your code and words in this response. Hope this will not mislead others. Secondly, in my previous post asking for this example, I specifically asked an example to show how Guice could wireup (inject something into) non-guice beans (namely, objects what were written without guice in mind). Instead of showing this, the example I got seems to only show how guice could instantiate such a bean. I guess one would have to write additonal imperative code to do the wiring, am I correct? If that wiring code is simple enough, then my question is, why you define the non-POJO guice bean program model in the first place? Can't Guice simply use POJO? What a non-POJO bean model buys guice? With regarding to refactoring, now I trust you have some facts, however, may be over generalized them. Let temporary live on violent agreement and saying XML and pure java code based configurations both have pros and cons. Besides, I am looking at XML configuration not as what was appeared in Spring. That kind of XML configurations merely express imperative wiring java code logic almost line by line (at least conceptually) in XML, and imperatively. In my current project, I am using high level DSL (also in XML) configurations which are not only declarative but also largely avoid boilerplate code (XML) and low level API signatures. So, when I said XML configurations have certain advantages blabla in my very first post, I really did not mean the very primitive XML configurations from Spring. This is too far out of topic and I better stop here and could discuss it in other opportunity.
  63. Bob, I did some english polish ... Thanks for your words, and really glade to see we can forget about the religious war and start to exchange useful ideas. To be honestly, I am not a fan on any Java DI frameworks (neither Spring nor Guice). I am working on a project and came across your statements that conflict to my vision (certainly, I could be very very very wrong). That is why I asked here. Let's start from your example. Firstly, i find it is very painful to do quote in this forum. Therefore, I drop all your code and words in this response. Hope this would not mislead others to misunderstand your example. Secondly, in my previous post asking for this example, I specifically asked an example to show how Guice could wire up (inject something into) non-guice beans (namely, objects that were written without guice in mind). Instead of showing this, the example I got seems to only show how guice could instantiate such a bean. I guess one would have to write additional imperative code to do the wiring, am I correct? If that wiring code is simple enough, then my question is, why Guice defines the non-POJO guice bean program model in the first place? Couldn't Guice simply use POJO? What a non-POJO bean model buys guice? With regarding to refactoring, now I trust you have some facts, however, I believe you may over generalized them. Let's temporary live on violent agreement and saying XML and pure java code based configurations both have pros and cons. Besides, the XML configurations I am looking at are not the same as what is presented in Spring (that is the first reason I didn't mention Spring in most of my post). The Spring XML configurations merely express imperative wiring java code logic almost line by line (at least conceptually) in XML, and still imperatively. In my current project, I am using high level DSLs (also in XML) configurations which are not only declarative but also largely avoid boilerplate code (XML) and low level API signatures. So, when I said XML configurations had certain advantages blabla in my very first post, I really did not mean the very primitive XML configurations from Spring. This is too far out of topic and I better stop here to save other people time.
  64. I specifically asked an example to show how Guice could wire up (inject something into) non-guice beans (namely, objects that were written without guice in mind). Instead of showing this, the example I got seems to only show how guice could instantiate such a bean.
    Well, I'm not sure what more you want. In this code, Guice passes Bar and Tee to your method which you can use to manually wire up Foo: @Provides Foo provideFoo(Bar bar, Tee tee) { return new Foo(bar, tee); } Guice doesn't do anything magical.
    I guess one would have to write additional imperative code to do the wiring, am I correct? If that wiring code is simple enough, then my question is, why Guice defines the non-POJO guice bean program model in the first place? Couldn't Guice simply use POJO? What a non-POJO bean model buys guice?
    Guice uses POJOs. Do you think that applying @Inject to your class makes it not a POJO? That isn't the case. Guice uses @Inject because it saves you from having to write the provider method above. This means you can change your class and how things get injected without having to change the provider method (because it doesn't exist).
  65. Bob, Thanks! And again, snip the code (painful to quote them).
    Well, I'm not sure what more you want. In this code, Guice passes Bar and Tee to your method which you can use to manually wire up Foo
    What I want to see is how and where you get the bar and tee. Spring has a way to do it (i forgot the name). Instead of writing a XML document, the wirings are write as Java code in a class with each member function corresponds to a element of the original XML configuration. In my opinion, this is a very ugly kludge. I just want see how Guice does it.
    Guice uses POJOs. Do you think that applying @Inject to your class makes it not a POJO? That isn't the case.

    Guice uses @Inject because it saves you from having to write the provider method above. This means you can change your class and how things get injected without having to change the provider method (because it doesn't exist).
    Understood, argument well taken.
  66. What I want to see is how and where you get the bar and tee. Spring has a way to do it (i forgot the name). Instead of writing a XML document, the wirings are write as Java code in a class with each member function corresponds to a element of the original XML configuration. In my opinion, this is a very ugly kludge. I just want see how Guice does it.
    You're referring to Spring's JavaConfig, and I agree with you--it's unnecessarily magical. With Guice, your provider method is just a normal Java method (no proxying like you see in JavaConfig). In your Guice configuration, you tell Guice where your provider methods are. Guice creates "bindings" to the types the provider methods return. When you request an instance of one of those bindings, Guice calls your provider method, it passes in the arguments just as if it were injecting a constructor, and it returns the result. If you look at the provider method in isolation, you might ask, what the heck is the benefit that Guice is providing? The key is that the classes which depend on the object returned by that method don't depend on your provider method. You can replace the provider method with a different type of binding and none of the dependents have to change. Contrast that to plain Java where you start of calling a constructor directly. If you come back and replace that constructor with a factory (equivalent to a provider method) later, you also have to go around and change all the callers. Guice saves from this, and since your code is more flexible, it's also easier to test.
  67. <blockquoteWith Guice, your provider method is just a normal Java method (no proxying like you see in JavaConfig). In your Guice configuration, you tell Guice where your provider methods are. Guice creates "bindings" to the types the provider methods return. When you request an instance of one of those bindings, Guice calls your provider method, it passes in the arguments just as if it were injecting a constructor, and it returns the result. Sorry, I am slow to fully understand this. It seems Guice does not bind by user specified IDs (or symbols) but by matching types of providers to declared types of injection references (input arguments), am I correct? How it is going to handle the case of two factories returning same interface type of different implementations? Which one Guice is going to bind to?
  68. Sorry, I am slow to fully understand this. It seems Guice does not bind by user specified IDs (or symbols) but by matching types of providers to declared types of injection references (input arguments), am I correct? How it is going to handle the case of two factories returning same interface type of different implementations? Which one Guice is going to bind to?
    You can use an annotation to differentiate bindings to the same type. It is an error to bind two things to the same type and annotation. You should check out this video. In it, I explain everything.
  69. You should check out this video. In it, I explain everything.
    Or, check out the user's guide. It obviously doesn't discuss provider methods because those are in the upcoming version. We would have loved to have gotten them into 1.0, but we couldn't wait forever to release something. :)
  70. Sorry, I am slow to fully understand this. It seems Guice does not bind by user specified IDs (or symbols) but by matching types of providers to declared types of injection references (input arguments), am I correct? How it is going to handle the case of two factories returning same interface type of different implementations? Which one Guice is going to bind to?
    That's an excellent question. Guice actually uses annotations to differentiate different instances of the same type, whether they are from the different factories or from diffent provider.bind class... The end result (taken ironically from the Spring 2.5 serverside tutorial which mentions that spring now has "Guice-style resolution by annotation"): public void setOrderServices( @Emea OrderService emea, @Apac OrderService apac) Ke, I would encourage you to look at the Guice homepage and the links therein. They're chocked with all sorts of interesting stuff...
  71. Thanks, Solomon!
  72. taken ironically from the Spring 2.5 serverside tutorial
    In case anyone is interested, here is the working link to the Spring 2.5 article which was (ironically) mistyped in the previous post :) For those interested in Spring's support for annotation-driven dependency injection, the Spring Reference Documentation provides some examples. Mark
  73. Re: I still don't see the point ...[ Go to top ]

    I just don't think the XML component is a thick enough reason. First, I prefer setting injection so, for me, that knocks the O(M*N) argument out. There have been occasions where I've need to change things without access to source and your solution seems to elimnate that option. I've just never found the XML that big of a deal.
  74. Hi All, Reading all these posts is very funny. Contrary to popular belief Spring didn't invent IoC and IoC has been performed in dynamic languages for years without XML or a "container". IoC, DI and "light weight containers" as we have come to know them in the Java world are a reaction to EJBs and their associated heavy weight J2EE containers. The idea is that POJOs become reusable components, but if you stop long enough to inspect the detail as William has pointed out, POJOs aren't reusable at all (as they aren't packaged independently and thus cannot be deployed independently) and aren't invasive (as each POJO demands that a factory exists that will satisfy the dependencies defined by the setters/constructor at construction). The simple truth is that IoC containers are not a component model at all. They are merely a reaction to flaws in the Java language when it comes to constructing objects in an OO fashion: http://gbracha.blogspot.com/2007/06/constructors-considered-harmful.html The old solution to this problem was objects factories (remember them?). IoC is just another more loosely coupled alternative. I like Spring (and Pico-container back in the day), and Guice sounds interesting too. The problem here IMO is that as always a simple idea as been oversold, and the Java IoC crowd haven't been that honest about explaining the problem IoC addresses and why it is needed. Marketing winning out over honest technical explanation I think :^). Paul.
  75. Hi All,


    Reading all these posts is very funny. Contrary to popular belief Spring didn't invent IoC and IoC has been performed in dynamic languages for years without XML or a "container".

    IoC, DI and "light weight containers" as we have come to know them in the Java world are a reaction to EJBs and their associated heavy weight J2EE containers. The idea is that POJOs become reusable components, but if you stop long enough to inspect the detail as William has pointed out, POJOs aren't reusable at all (as they aren't packaged independently and thus cannot be deployed independently) and aren't invasive (as each POJO demands that a factory exists that will satisfy the dependencies defined by the setters/constructor at construction).

    The simple truth is that IoC containers are not a component model at all. They are merely a reaction to flaws in the Java language when it comes to constructing objects in an OO fashion:

    http://gbracha.blogspot.com/2007/06/constructors-considered-harmful.html

    The old solution to this problem was objects factories (remember them?). IoC is just another more loosely coupled alternative.

    I like Spring (and Pico-container back in the day), and Guice sounds interesting too. The problem here IMO is that as always a simple idea as been oversold, and the Java IoC crowd haven't been that honest about explaining the problem IoC addresses and why it is needed.

    Marketing winning out over honest technical explanation I think :^).

    Paul.
    See, I don't agree that the idea is being oversold. To me, this shifts the responsibility from the developers. Read the literature and make an informed decision. If there are 10 articles a day on Spring, Guice, or anything else, I don't have to read it. There are many articles concerning facets of Java tech that I may not have time to read(only so many hours in a day), so I don't read them. If someone uses Spring, Hibernate, or something else inapproprately or poorly, I don't blame Spring or Hibernate and "society" believing that either one was oversold. I blame the person who wrote the code. To use the firey Mr. Watson's example, if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.
  76. Re: Tech Talk: Bob Lee on Google Guice[ Go to top ]

    One more thing...years ago, I had a job where the managment wanted me to use stored procedures where I thought they were inappropriate. But I could "write them in java." I refused. Simple as that. I said that I don't believe this is the right decision. "If you want to do this, you need to find someone else to do it. No hard feelings." I was absolutely prepared to walk. They relented, the app was written, and it was successful. People shouldn't blame the tool, they should have the courage of their convictions.
  77. if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.
    Basically your argument is that people should not say that a given car can't pull a boat and that a truck should be used because that's blaming the car instead of the people who don't know that the car isn't good for pulling boats and that they should use a truck.
  78. if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.


    Basically your argument is that people should not say that a given car can't pull a boat and that a truck should be used because that's blaming the car instead of the people who don't know that the car isn't good for pulling boats and that they should use a truck.
    No. That is not my argument. That's a product of your habitual misinterpretations. You seem bent on argument and I see that it is fruitless to continue trying to discuss what is a baffling hot button with you.
  79. if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.


    Basically your argument is that people should not say that a given car can't pull a boat and that a truck should be used because that's blaming the car instead of the people who don't know that the car isn't good for pulling boats and that they should use a truck.


    No. That is not my argument. That's a product of your habitual misinterpretations.
    It is your argument. A poster stated some fairly specific reasons why he believed that Spring was not up to the task it is designed for and why Guice is better. You told us that we shouldn't blame the tools but the developer for using the tool. If that's not your argument, what is it?
  80. if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.


    Basically your argument is that people should not say that a given car can't pull a boat and that a truck should be used because that's blaming the car instead of the people who don't know that the car isn't good for pulling boats and that they should use a truck.


    No. That is not my argument. That's a product of your habitual misinterpretations.


    It is your argument. A poster stated some fairly specific reasons why he believed that Spring was not up to the task it is designed for and why Guice is better. You told us that we shouldn't blame the tools but the developer for using the tool.

    If that's not your argument, what is it?
    No. It isn't my argument. My entry into this thread was to address the fact that William brings Spring because one or more tools he's used/evaluated/looked at had, issues that I think were independent of Spring and were caused more by how Spring was used. Bear in mind that since I don't know what tools he references, I don't think any of us are in any position to speak to those claims, be they right or wrong. Furthermore, my contention with the car analogy is that if you are foolish enough to use a car that is NOT built for towing to tow, that says more about you than any flaw in the car. You have different cars, different machines for different situations. I want to haul a family, I don't use a two-seater and complain that it is too small. I want to race, I don't use a SUV and act surprised that I lost or flipped over. The burden on on the developer to ensure that he is not only using the right tool, but using it correctly. If you are stuck using Java 1.4 or earlier, for example, no matter how it does what it does, Guice cannot help you(assuming my understanding that it doesn't work on pre-Java5 is correct). If someone picked Guice for that environment, does that make just an inferior tool? No.
  81. No. It isn't my argument. My entry into this thread was to address the fact that William brings Spring because one or more tools he's used/evaluated/looked at had, issues that I think were independent of Spring and were caused more by how Spring was used. Bear in mind that since I don't know what tools he references, I don't think any of us are in any position to speak to those claims, be they right or wrong.

    Furthermore, my contention with the car analogy is that if you are foolish enough to use a car that is NOT built for towing to tow, that says more about you than any flaw in the car.
    I don't really see this as the proper analogy, though. I don't think the argument is that people are using Spring for something that it is not meant for. If I understand William's point correctly, it's that the Spring framework provides a solution path that is attractive but ultimately problematic. A more proper analogy would be if your car came with a tow hitch but attempting to pull anything significant would damage the car. Sure we can say "the owner should know better" but the question remains: why was the hitch there if you shouldn't use it?
  82. No. It isn't my argument. My entry into this thread was to address the fact that William brings Spring because one or more tools he's used/evaluated/looked at had, issues that I think were independent of Spring and were caused more by how Spring was used. Bear in mind that since I don't know what tools he references, I don't think any of us are in any position to speak to those claims, be they right or wrong.

    Furthermore, my contention with the car analogy is that if you are foolish enough to use a car that is NOT built for towing to tow, that says more about you than any flaw in the car.


    I don't really see this as the proper analogy, though. I don't think the argument is that people are using Spring for something that it is not meant for. If I understand William's point correctly, it's that the Spring framework provides a solution path that is attractive but ultimately problematic.

    A more proper analogy would be if your car came with a tow hitch but attempting to pull anything significant would damage the car. Sure we can say "the owner should know better" but the question remains: why was the hitch there if you shouldn't use it?
    A car has a door. It would be improper to drive with the car doors open or close the car on your hand. By your logic, or at least how I perceive it, the car is flawed. After all, it lets me close the door on my hand. It lets me drive with the doors open. I say the owner should know better. My contention that no machine is better than the operator, doesn't preclude the case of flawed machinery. I simply don't think it is the case that Spring is flawed. It isn't perfect, but lack of perfection doesn't imply the fundamental flaws that warrant the belief that using Spring is ultimately problematic, at least IMO. I guess we'll have to agree to disagree, as cliche' a statement as that is. The fact that I don't agree with the assertion that Spring is inherently problematic coupled with our fundamental POV differences, means we've probably gone as far as we can in this thread.
  83. I don't really see this as the proper analogy, though. I don't think the argument is that people are using Spring for something that it is not meant for. If I understand William's point correctly, it's that the Spring framework provides a solution path that is attractive but ultimately problematic.

    A more proper analogy would be if your car came with a tow hitch but attempting to pull anything significant would damage the car. Sure we can say "the owner should know better" but the question remains: why was the hitch there if you shouldn't use it?
    A car has a door. It would be improper to drive with the car doors open or close the car on your hand. By your logic, or at least how I perceive it, the car is flawed. After all, it lets me close the door on my hand. It lets me drive with the doors open.

    I say the owner should know better.
    That's absolutely not the same thing. A car door is there to be used. A car must have doors. It's not a feature that should never be used. Besides that, modern cars will warn you if your car door is open when you are driving and will lock the doors while the car is moving to prevent accidental opening. Those systems are superior because they help to prevent misuse. And there are in fact systems for doors that can prevent them from injuring people. They are required by law on garage doors where I live. If a car had a system to help prevent me from closing it on my hand (assuming it works), it's superior to one that doesn't at least in that aspect of the car's design. I can't see how you would argue otherwise. The other thing here is that you are misrepresenting my statement. I never used the word 'flawed'. I have only referred to comparing two tools and determining which is superior.
    My contention that no machine is better than the operator, doesn't preclude the case of flawed machinery.
    Which is essentially stating that your contention is meaningless in a discussion comparing two tools, regardless of whether it is true or not.
    I simply don't think it is the case that Spring is flawed. It isn't perfect, but lack of perfection doesn't imply the fundamental flaws that warrant the belief that using Spring is ultimately problematic, at least IMO.
    I have no problem with this. I think it's a perfectly valid argument and I'm not disputing it. But when someone challenges you on this, and respond with "no machine is better than it's operator", it's implies that the challenge is invalid. The reality is that if you have two tools that do the same thing and one of them is less easily misused, or mitigates that misuse, that tool has advantages.
  84. issues that I think were independent of Spring and were caused more by how Spring was used
    Well if that is the case can we all go back to using EJBs and all those standard specifications of technologies wrapped by Spring because I never had any problems with using them correctly once I actually read the specification and understand the design goals and expected usage scenarios. Whilst we can all say that it is ** possible ** to construct the complete object graph outside of the container (in this case Spring) practically no ever tries this because they know pretty well that they have shoot themselves in the foot many times in how they have structured their code in another language (XML) and hacked around various issues getting it to look like more the the execution flow and less like the data structure it it. At the end of the day I really would like to see people focus on publishing interfaces to libraries, components, and platforms that are more focused on the standard use cases rather than the bootstrapping of the internals with verbose XML files. If you really want to see how crazy this all gets just take a look at the WebLogic Event Server and its programming model as well as its deployment approaches. Now here is a pretty good product idea and possibly a good implementation practically killed by the exposure of its runtime model. http://edocs.bea.com/wlevs/docs20/get_started/examples.html Now compare that with GridGains programming model which by the way does in fact use Spring internally for some basic service bootstrapping and instrumentation (aop -> tracing). Surely CEP can be made easier. By the way my previous references would be easily recognized by any who has read previous Spring announcements or blog entries. OSS. CMS. Spring. JCR. This is easy. regards, William
  85. Hi All,


    Reading all these posts is very funny. Contrary to popular belief Spring didn't invent IoC and IoC has been performed in dynamic languages for years without XML or a "container".

    IoC, DI and "light weight containers" as we have come to know them in the Java world are a reaction to EJBs and their associated heavy weight J2EE containers. The idea is that POJOs become reusable components, but if you stop long enough to inspect the detail as William has pointed out, POJOs aren't reusable at all (as they aren't packaged independently and thus cannot be deployed independently) and aren't invasive (as each POJO demands that a factory exists that will satisfy the dependencies defined by the setters/constructor at construction).

    The simple truth is that IoC containers are not a component model at all. They are merely a reaction to flaws in the Java language when it comes to constructing objects in an OO fashion:

    http://gbracha.blogspot.com/2007/06/constructors-considered-harmful.html

    The old solution to this problem was objects factories (remember them?). IoC is just another more loosely coupled alternative.

    I like Spring (and Pico-container back in the day), and Guice sounds interesting too. The problem here IMO is that as always a simple idea as been oversold, and the Java IoC crowd haven't been that honest about explaining the problem IoC addresses and why it is needed.

    Marketing winning out over honest technical explanation I think :^).

    Paul.



    See, I don't agree that the idea is being oversold. To me, this shifts the responsibility from the developers. Read the literature and make an informed decision. If there are 10 articles a day on Spring, Guice, or anything else, I don't have to read it. There are many articles concerning facets of Java tech that I may not have time to read(only so many hours in a day), so I don't read them.

    If someone uses Spring, Hibernate, or something else inapproprately or poorly, I don't blame Spring or Hibernate and "society" believing that either one was oversold.

    I blame the person who wrote the code. To use the firey Mr. Watson's example, if you screw up your superior car because you tried towing a boat, don't blame the car for being a poor at towing, blame yourself for using a car when you should have been using a truck.
    hi David, OK I agree. Whether you describe IoC is "oversold" is a subjective point, but I agree with William, that the Spring community in particular (or should I say Interface21 :^)) are misrepresenting IoC. Quoting William:
    I still don't see the point of using such terms as POJO, non-invasive, containers, ... when there is actual no agreed definition to these. To be honest I find it plain silly to classify code with such terms...
    These terms are meaningless. What we are talking about is object construction, message passing and polymorphism. I think it would help greatly if Rod Johnson was more honest and accurate about this. I always think about junior programmers. I remember trying to learn OO by reading Object Orientated Programming with Applications in C++ by Grady Booch. Booch had an "understanding" of OO which was largely inaccurate. Reading that book cost me three years until I stumbled across Smalltalk and realised that his explanation of OO was mostly wrong (it turned out that my initial intuition was nearer the truth). Now a lot of people came to OO through that book and IMO a lot of people still misunderstand OO concepts because of it to this day. Boochs excuse could be that he had a honest misunderstanding himself, in which case he should not have been authoring a book on the subject. With Spring, I'm not sure whether the motives are as simple and honest. Bob Lee is calling "bullshit", and I agree. Gilads explanation is the only "accurate" explanation I've seen on IoC, yet this explanation is not widely known or used. I remember introducing Spring to a project and developers trying to use it as a service locator akin to a JNDI service locator. This was because this was all they knew (J2EE Application Servers) and demonstrated a lack of understanding of the underlying language concepts. There is a lot of misinformation out there and one of the advantages of forums like this is that the more experienced practitioners amongst us get to clarify things for people that may still have open questions. Bobs explanation of Guice sounds honest to me, and has whetted my interest in taking a look. I think a number of us are arguing for more clear and honest explanations all round. Paul.
  86. The problem here IMO is that as always a simple idea as been oversold, and the Java IoC crowd haven't been that honest about explaining the problem IoC addresses and why it is needed.
    In fairness I think that Bob has been very level headed in all of the talks I have seen about Guice. He has a three point bullet list on why you should use Guice. I also like the fact that they are keeping the guice core simple. For example if someone wants to use JPA with guice then they can use a JPA Guice provider like Warp, but it is not part of the Guice core. Just DI.
  87. The problem here IMO is that as always a simple idea as been oversold, and the Java IoC crowd haven't been that honest about explaining the problem IoC addresses and why it is needed.


    In fairness I think that Bob has been very level headed in all of the talks I have seen about Guice. He has a three point bullet list on why you should use Guice. I also like the fact that they are keeping the guice core simple. For example if someone wants to use JPA with guice then they can use a JPA Guice provider like Warp, but it is not part of the Guice core. Just DI.
    Agreed. Perhaps I should have watched Bob's video first. I haven't watched it all, but what I did see was very level headed and explains the issues with "newing up" objects in Java well. The Guice idea of "binding" Classes to alternative implementations using a DSL looks compelling. If I need to choose a Java DI Framework in the future then I will definately take a close look at Guice. Still waiting for a Java IoC advocate to admit that the problem these frameworks address evaporates in other languages like Ruby, Smalltalk and Python... But I guess that would be too much honesty to ask for :^) Nit picking aside, Bob Lee is doing a great job and should be appluaded. Paul.
  88. Re: Tech Talk: Bob Lee on Google Guice[ Go to top ]

    Still waiting for a Java IoC advocate to admit that the problem these frameworks address evaporates in other languages like Ruby, Smalltalk and Python...

    But I guess that would be too much honesty to ask for :^)

    Nit picking aside, Bob Lee is doing a great job and should be appluaded.
    Thanks, Paul. Yes, in many scripting languages you can easily swap out any class and method definition. I prefer a more controlled, maintainable approach though. With dependency injection, it's clear from a testing standpoint which dependencies can be mocked out without looking at the implementation of the class you're testing. If you add a new dependency, the compiler tells you that you need to address this in the test. By contrast, in a scripting language, I could add a dependency which accesses a remote server, but then I need to manually find all the tests which touch this code and mock it out so the tests don't run slowly and unreliably. With dependency injection, you can use different implementations in different contexts, whereas swapping out a class definition would change the implementation for everyone (other concurrently running tests for example), and you would have to be sure to replace the original implementation when you're finished. Dependency injection encourages me to mock out immediate dependencies versus deeply nested dependencies which makes unit tests easier to write and maintain. Am I missing something?
  89. Re: Tech Talk: Bob Lee on Google Guice[ Go to top ]

    Still waiting for a Java IoC advocate to admit that the problem these frameworks address evaporates in other languages like Ruby, Smalltalk and Python...

    But I guess that would be too much honesty to ask for :^)

    Nit picking aside, Bob Lee is doing a great job and should be appluaded.


    Thanks, Paul.

    Yes, in many scripting languages you can easily swap out any class and method definition. I prefer a more controlled, maintainable approach though. With dependency injection, it's clear from a testing standpoint which dependencies can be mocked out without looking at the implementation of the class you're testing. If you add a new dependency, the compiler tells you that you need to address this in the test. By contrast, in a scripting language, I could add a dependency which accesses a remote server, but then I need to manually find all the tests which touch this code and mock it out so the tests don't run slowly and unreliably. With dependency injection, you can use different implementations in different contexts, whereas swapping out a class definition would change the implementation for everyone (other concurrently running tests for example), and you would have to be sure to replace the original implementation when you're finished. Dependency injection encourages me to mock out immediate dependencies versus deeply nested dependencies which makes unit tests easier to write and maintain.

    Am I missing something?
    Hi Bob, No not really if testing is your main goal and you are developing test first. Dynamic languages come into their own when you don't know in advance the classes you may want to "swap out" or "extend" at a later stage. So its is like using an interface for everything, with the ability to change implementation anywhere. So all your code is loosely coupled with no dependencies on concrete implementations, just dependencies on interfaces (protocols). This flexibility comes from message passing which leads to better OO abstraction (like mixins) and code that is easier to extend over time (an example is the third party plug-ins available for Rails). But like you say there is a downside, you don't know which protocols each object supports until you suck it and see by sending a message, and Classes are objects with global scope, so swapping out a Classes implementation causes a global change everywhere. I like your pragmatic tone. I will get around to watching the rest of the video. Cheers, Paul.
  90. Still waiting for a Java IoC advocate to admit that the problem these frameworks address evaporates in other languages like Ruby, Smalltalk and Python...

    But I guess that would be too much honesty to ask for :^)
    That's an interesting statement. My initial reaction is that the need for injection is driven by testing and is independent of the language or framework you are using. Case in point: Ruby on Rails (which shines in many ways in this area) lets you define various databases for production, staging and development. This certainly looks a lot like dependency injection to me, albeit taken to an even higher level (basically hiding the DI framework and just exposing the articulation point so you can configure it). -- Cedric Author "Next Generation Testing in Java"
  91. On a less serious note[ Go to top ]

    Here's an anecdote. It kind of backs up my point that Spring is the new 'it girl'. Mostly though, it's funny. Well, funny if it weren't my personal hell but you should all enjoy it. As I try to de-over-complexify the gnarled mess of Java where I work, I keep getting asked about 'Springs'. "Why aren't we using Springs?" "Shouldn't we be using Springs and Struts". If it was just a one time thing I'd wouldn't think much of it but it's a number of different people over the course of a year.
  92. Spring is good, until people began to think XML is a programming language. Spring makes people believe Ruby is the future, because it is a lot easier to use a real programming language to write your CONFIGURATION files. Then came along Guice. That is called evolution.
  93. Spring is good, until people began to think XML is a programming language. Spring makes people believe Ruby is the future, because it is a lot easier to use a real programming language to write your CONFIGURATION files. Then came along Guice. That is called evolution.
    As a matter of fact, people started to use XML as a programming language (or as base to define other programming languages) long before Spring (2003). For instance: 1. XSL (1998) -- a declarative language. More or less a lousy (but feature enriched) Lisp defmacro in disguise, a proof of Greenspun's Tenth Rule. I guess the predecessor of XSL -- the CSS -- might also be a programming language. 2. BPEL4WS (2002) -- an imperative programming language based on XML. Even XML itself is more or less a dailect of Lisp S-expression. Similarly, AFAIK, annotation based DI configuration started from EJB 3.0 (2004) and then followed by apache tapestry, etc...
  94. Spring is good, until people began to think XML is a programming language. Spring makes people believe Ruby is the future, because it is a lot easier to use a real programming language to write your CONFIGURATION files. Then came along Guice. That is called evolution.
    +1 Yep, Java is catching up with were Smalltalk was 30 years ago!
  95. PICO[ Go to top ]

    So is it better than PICO.. its just the same .. except a few features..