I have downloaded Spring and AspectJ together, I play with it at home when I'm not playing 'Reading with Pooh' with my kids. It's neat stuff. But if you have a shop with 100 programmers just getting into Struts, this does not even rate...J2EE to many (and the wise, I would suggest), is really about creating a .war file with struts and jsp's, and getting it deployed. App servers can in some fashion be considered tools for sysadmins to cluster, deploy, and monitor all of this stuff so it doesn't go down when a disk crashes. Then you have a full suite of 'stuff' to handle what comes down the pike. I expect MDB's, as well as the 'extraJ2EE' concerns such as workflow and integration will get much greater use where I work. Standards like BPEL and stuff like WS-security are big items of interest, we can all only digest so much...
Add to that a decent POJO persistance layer (we have TopLink right now), and the complexity that's spoken of in J2EE doesn't really touch the developer once you can create a decent .ear. We need a workable EJB3 and JDO, it doesn't have to be model-pretty, just not suck. I could make this a one sentence post by just saying that again...really we'd be gold if we could have that. I'll live with JNDI, call me a trog! I've been happily using JTA/Stateless Session EJB's for some time now, and only after being told at the server side and NFJS that it was 'heavyweight' do I realize I've had problems all of these years! I say that facetiously, because I value and am interested in things in AOP and Spring. I also know I don't know what could happen down the road.
In TopLink, for example, I can either let it wrap my code in transactions, or tie into the underlying JTA if I need to, so what does IoC really do? Is no JTA 'light enough'?
I don't claim to be a pattern junkie, but if I write a bunch of beans, with a bunch of setters for the dependent objects, I'm expecting and externalizing that something is going to set all those up for me. In that sense, am I not actually dependent on, and commiting to IoC containers? How the heck are those dependencies going to be resolved otherwise? If I drop those beans into Tomcat, it doesn't know what to do with them...right? You need the framework and descriptors of your choice. That might be belaboring the point, but once you commit $$$ to a project, you need some assurance that it will be relevant a year ago (I know, IoC and you are all pure POJO and everything is good, I will alow that can be argued).
Too bad there is not a standard for IoC containers you could bank on...maybe that will be J3EE or J4EE. My point here is that I want to have patience with J2EE and Java. I started out soon after the bouncing heads doing Cafe and dbAnywhere, and even as bad as jdk1.0.2 and the awt blew chunks, we wowed a bunch of external consultants, which was gratifying. Java and J2EE has always been waiting for your particular API to be...shall we say 'corrected' in the next release, and I'll do that because I need and believe in Standards. Even if there are parts that don't quite fit the bill, the payoffs have been enormous. In many senses the choice on Server side Java has been a bullseye that we hit here from about 6 years distance. In retrospect it's been fairly incredable how we're still running code that was originally developed for the server in JDK1.1. Part of my problem with IoC is not technical...I don't want the standards fragmented because that's worth Pico, Spring, and HiveMind together!
Anyway, keep IBM and Oracle in line! Just chiming in for your 'run of the mill' developer.
MC |
java.net RSS Feeds
