The reason for this, and the reason he demonstrates a lack of understanding of real enterprise computing is his comment "Java is what it is and you cannot now start taking things out of it. If you do so, you will break existing applications.". You see here is the issue, people like myself who are advocating removing stuff and creating a minimal core for Java (see this presentation) isn't that we are saying "delete all the libraries from existence". What we are saying is that in an enterprise computing environment where there are billions (tens of billions) of dollars spent on people, education, software and planning that we really can decide what we need and what we don't.
What I want is a minimal core and the ability to add only those libraries and features that I want because I know what I'm doing. Sure if someone wants the full bloat, or as the consumer platform, it makes sense to have the full kitchen sink edition (Java KS?). In the former case because the person can't be arsed to work it out and in the later it gives an assured platform for execution.
This is the problem. People of this mindset seem to see the consumer platform as being the ultimate Java environment the one that really matters and the ones whose problems should always been addressed to the detriment of all others.
Quite frankly it was ridiculous in Java SE 6 the justifications that were trotted out to explain why having things like JAX-WS 2.0 in Java SE 6 and a lightweight webserver made sense. The systems I work on have teams of professionals on them who are better able to decide for that problem whether they need a basic Java SE environment with a web service implementation or whether they are going to use an application server. Forcing these people to undertake hideous class loader workarounds just sums up how divorced from enterprise reality the Java SE 6 decisions were.
The problem is that like many vendor employees Chet doesn't have to cope with the myriad of issues that "everything in the box" creates for organisations. The "just don't use it" line doesn't work when you fall victim to Meyfroidt's Law or to the issues of wanting to use something different to that which comes in the box and suffering the pain of ripping it out (no vendor worries about that). The reality of enterprise computing is that the minimal set of functionality that gets the job done is what you want and you want to restrict people to that as it makes support (where the cost is) easier.
If Mark Baker wants to use REST then let him, if Paul Fremantle wants to use Axis 2 or Synapse then so be it, if someone wants to use JAX WS 2.0 on Java SE 6 their funeral (if they want to upgrade to JAX WS 2.1 then that should be easier than using the older version), if Dan Creswell wants to use Jini then so be it and if lots and lots of people want to use a J2EE application server then fair play to them. The point is that all these people (baring the Java SE 6 muppet) have made an informed choice about what works for them and that doesn't mean we want to see all the stuff that other people are using, if we did we'd download the stuff and use it. This is how professionals work, they make informed choices about what they want to do and then select the right approach for the long term. This is good architecture and good engineering, picking the core of the solution, making it architecturally consistent and then enforcing that consistency. Hey its Mythical Man Month territory again, yes Java SE is that wrong.
For the consumer market Chet has a point, for the enterprise market he does not. One of these is worth several billion dollars, the other is not. Its about time that Java Enterprise users got the standard platform that they need rather than the one designed for Joe Sixpack.
Technorati Tags: Java
6 comments:
Interesting thoughts, I agree with your comments. However what do you term as an Enterprise developer? Whenever I see Enterprise I think of developers using application servers or drag and drop tools and not understanding a thing about real development.
"Java is what it is and you cannot now start taking things out of it. If you do so, you will break existing applications."
Ah yes so we'd like to repeat the mistakes of Intel, Microsoft and others supporting a continued huge legacy that makes rapid forward progress challenging.
Give me strength......
+1 on packaging - for a system that started with the whole idea of downloadable code it's utter muppetry to not have this sorted by now.....
I'd like to put forward a hypothesis: that the vast majority of features put forward for inclusion in v6 and v7 are a "competitive" response to feature availability in .NET.
You know the details better than I do, Steve, so what do you think? My strong suspicion, though, is that the agenda here is *still* (unfortunately) driven by a community more interested in being equally/more feature rich than MS, than being focused on what customers actually want.
This is an age old problem in the IT industry - focusing too much on your competitors and on industry hype, and not tempering that with real customer focus.
Anon - Yes there are developers like that in the enterprise but there are architects working in Enterprises (as opposed to Enterprise Architects) who need to construct, and limit, solutions so they can be done by those developers. Java SE doesn't help those people.
Dan, I couldn't agree more.
Neil,
Again I agree, this was explicitly stated during Java SE 6 as a driver (hence the insistance on lobbing scripting aka multi-language support into the core). One bit I disagree on is the idea that it is the community driving this, its a certain vendor mindset and a limited (diggesque) and vocal group who are more care in the community than community.
It might be easier for a software vendor to provide an integrated stack, which can't be decomposed. Just imagine that in your approach it must be possible to replace Axis with CXF. This is an obvious requirement from the user/developer perspective, but a hell for the vendor. From my own experience, running Tomcat 6 with a 1.5 JDK is not really working, so I don't want to imagine what it means to have a plugable JDK. But ok, you are free to put up such a requirement and we will see if SUN has enough resources to fulfil your request.
Sebastian,
It isn't a question of resources its a question of focus. The complexity of things like JDK 5 with Tomcat 6 is exactly the sort of thing I mean. What would make sense would be that Tomcat would ship with a list of dependent library references (ala ivy/maven) which would then be downloaded and create the tailored solution that will work out of the box. The current approach requires (especially with 6) hideous class loader work arounds.
The point of plugable is on having modularisation and some way of defining and downloading the modules you need.
There is (IMO) very little point asking Sun as their focus is on creating a piece of bloatware that has more ticks in the boxes than other people's bloatware and not to create an enterprise grade base for a multi-billion dollar industry.
Post a Comment