Taking the second point first, is J2EE really that complex? I've been playing about with the latest BEA, IBM, Sun (Glassfish) and Oracle stuff recently trying to work out the "hard" bit. Now what I'm assuming here is that you don't want to actually code stuff if you can avoid that, so I've been using the JSF builders, playing with the new EJB3 data and invocations stuff and also using some of the process engines out there to string things together. Lobbing in some messaging stuff to try out EDA.
Now I'm a manager type these days, powerpoint jockey and creator of word documents, what I mean is that I don't code on a day to day basis these days, development isn't my job anymore. So surely if I can do it, its not that complex. When I compare it with J2EE 1.1 (which I wouldn't have touched with a barge pole) or J2EE 1.3 (the first one I took vaguely seriously) then JavaEE 5.0 is an absolute dream. The presentation stuff is miles easier in JSF than it was in JSP, the EJB bit is a massive step up, and the Glassfish deployment stuff is sooooo much easier than doing it in app servers in 1.1, 1.2 and 1.3.
So where exactly is J2EE more complex for developers? Sure its got a lot of facilities, but I actually found it easier to understand and use, paticularly with the new tools, than previous editions. Now clearly I've only based the assessment on actually using them to knock up some demo apps, rather than on a project. But have the people saying its very complex even downloaded the thing?
Now the other bit about the death of Java, and J2EE, that confuses me is this idea that lobbing stuff on databases is actually an achievement and that Web Sites represent a massively important part of IT. First off you've got the re-architecting of SAP and Oracle application servers (just a multi billion dollar market but hey, its not "sexy") around the J2EE platform, and the consolidation of the integration market around Java, and J2EE. Oh and of course the human workflow and business process markets, oh and pretty much all the RFiD work being done out there, and the whole mobile phone market.
This to me is the thing about Java, sure you could lob up a web-page on a database with Java, but you can also build all of the bits that live everywhere else in the organisation. When looking at SOA this means you are pretty much 100% guarenteed to have Java, and J2EE within your organisation, if not today then certainly when you do that big applications upgrade. I've always been a fan of standardising around a single language for basic development, just because it helps when looking for people and also it means you don't have increased complexity of management and support, and Java tends to stack up as the only valid language for that sort of approach.
So Java is dead, apart from all of the growth that it will drive in the bits of IT that actually represent a challenge, rather than lobbing web-pages on bloody databases.
Technorati Tags: SOA, Java, J2EE, Service Architecture
6 comments:
You sure do like lobbing things in!
When people say J2EE is overly complex they are not just saying its hard to code. The major problem for me is that is huge in terms of memory foot print and the type of projects i'm on performance is key (so is optimising hardware usage), so for me and most people these days J2EE is a bit of a waste. And with people moving to cheap hardware these days is a waste.
Now that really confuses me, huge in terms of memory footprint? I'm assuming you must work on some pretty special applications, I mean 256Mb is a certainly the minimum, but given even my laptop has two cores and 2Gb I'm really not suffering any memory or CPU pain these days.
The move to cheap hardware is a good thing for J2EE, most of the big J2EE apps I know these days are all running on a set of dual Intel/AMD CPU Linux boxes with 4GB of RAM, or moving towards Blades and virtual environments. The sort of kit that costs around $3-10k a box depending on what you want.
I don't buy memory and CPU as issues for J2EE these days, in 2000 then possibly, but not in 2006.
For some time critical and very high performance apps J2EE has never been the right platform, but the idea that J2EE is more complex today than it was in 2001 is just hockum.
The point is a J2EE application consumes larger amounts of memory and utilises more CPU. I have much experience migrating J2EE applications away from a application servers. These normally result in 20% - 30% increase in hardware improvements.
I'm not saying J2EE is not a good environment, but for most applications its a large waste of hardware.
Given Moore's Law runs at doubling every 18 months (100% gain) then 30% represents less than six months of hardware improvement, combine this with JVM performance improvements and you might only be talking about waiting 3 months and the same price buys you the gain.
Like I say, wasted hardware capacity isn't something I've see as an issue given that software costs and paticularly people development costs massively outstrip the cost of a Linux server.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment