Sorry, Rod, Keith, Rick et al. I'll even go so far as to say that I no longer believe Spring does more harm than good.
Spring's Java API and implementation may leave a lot to be desired (
Effective Java should be required reading for Spring committers), but in reality most users rarely see either. Spring users see two things:
- XML configuration
- Their own clean, injected, testable classes
As much as I like to avoid XML, pure Java has its drawbacks, too. I'd say it's six and one half dozen of the other, but I could do without the type conversion necessitated by XML binding. I might explore using BeanShell as a third alternative, but IDE support for Spring XML is already pretty good, and it can only get better.
Spring IDE support also happens to address many of my type checking concerns. If IntelliJ can automatically complete and rename property names and flag errors at development time, do I really care if I'm maintaining Java or XML? Nope.
This pretty much kills any aspirations for implementing a lighter weight framework that focuses solely on DI unless you plan on sticking to pure Java or implementing IDE plugins, too. Unfortunately, the pure Java approach limits what an IDE can do.
Aside from cleaning up the API and optimizing the implementation, I do have one request for Spring 2.0: simpler custom scopes, i.e. not the currently recommended AOP hack. I want something like this in my Spring XML:
<bean name="conversation" class="ConversationScope" />
<bean name="foo" scope="conversation" ... />
In the long term, we need something closer to my ideal factory API in the J2SE so we can strongly type JNDI, the Servlet API, etc. Spring is not that API, but it certainly will do for application development in the mean time.
7 Comments:
Holy crap. Thanks for pointing that out, Sam.
Hi Bob,
While I enjoyed your initial post on raising good questions before jumping to a framework, I found this statement: [quote]Spring's Java API and implementation may leave a lot to be desired (Effective Java should be required reading for Spring committers)[/quote] quite rude. It looks like a God coder looked at all code and decided: There shall be used Effective Java. I am not gonna ask you if you are that "God coder", nor if your code is always perfect, because I really think that everybody has things to learn every day. Do the Spring guys state that their code is best code (what is that?)? I haven't read this anywhere. Do they want to be "God coders"? Probably :-), but at least they are not stating it.
cheers,
./alex
--
.w( the_mindstorm )p.
You got all that from one sentence? I guess that makes you the God of tact and Open Source sensitivity. ;)
I'm not saying it has to be perfect, but it does have to be good enough. Coding a framework as widely adopted as Spring brings with it certain responsibilities to the users now and in the future. If you don't want that, don't put your code out there for everyone to use.
You can cry about it, but applying the lessons from _Effective Java_ (and other books in that vein) makes the difference between a maintainable, evolvable API and an API that's drowning in legacy cruft by version 3.0.
Bob, how do we know that you don't have royalty from an "Effective Java" sales, especially when we know that you are working in the same company with its author. ;-)
By the way, Bob, what do you think about scoping bean conversations using generic bean metadata defined in Spring context? Something like this - http://www.jroller.com/page/eu?entry=adding_metadata_to_spring_beans
Nah. I just want a very simple way to control whether a new object is created or an existing object is reused. No need for proxies, bean post processors, etc.
Bob, tht would be transparent and you won't have to define any proxies, just metadata.
Post a Comment
<< Home