Lambda the Ultimate

Ok, I'll bite. J2EE extensions (i.e. proprietary libraries) don't do anything to stop Java source portability modulo having implementations of the libraries available. But we all know that. What is interesting in the "able to use it without understanding OO" quote. How is that different from current practice :) Maybe they're implementing a proprietary language on top of the JVM. That would interesting and a bit win if it gains acceptance (big if there). Web development in Java is a pig compared to, say, Scheme. It's great for generating billable hours and roping together monkeys (which normally go hand in hand) but not so good for actually getting the job done.

Seems I am so busy I wasn't reading closely. Love that able to use it without understanding OO bit - and I didn't even see it before.

Guys, you must help out. Post to the homepage!

On the other hand, with the price of products like JBoss (i.e. pretty much zero) the days of BEA/IBM being able to charge many tens of thousands of dollars for their servers if all they do is implement the standard are rapidly coming to an end. As to monkeys, it's sort of like "if all you have is a hammer every problem looks like a nail", "if all you have is monkeys then everything looks like a design pattern implemented with J2EE or .NET".

My other thought is that in attempting to provide flexibility to solve all problems these frameworks introduce too much complexity into the solutions to simple problems. It may also be that the underlying languages don't provide the tools needed to support the sort of meta programming that might make managing this complexity easier. I've resorted to code generation to produce java from xml "specifications" using xslt as coding similar stuff hundreds of times is just too much.

If things are as you say than there's little hope for the language as platform approach to survive: companies will do whatever it takes to achive developer lock in. But the same logic seems to apply to programming languages in general, when in fact languages did manage to be fairly standardized.

It looks to me like it is more a matter of proportions, than anything else. Some platform specific code will always remain; minimizing it is a worthy goal.

Indeed languages are fairly standardized, and J2EE is also standardized. In fact I think it has done better than other attempts to produce a standard with multiple implementations.

Some of the possibility for lockin comes from the "low" level of the J2EE spec, at least in terms of getting business function implemented. Here's where the design patterns prove useful, they make it easy to rewrite the same code as everyone else to implement the same features. Of course, a vendor could provide an implementation of these patterns, and that's what many of these frameworks are, but the temptation to use this as a way to try to lock developers into their platform is possibly too great to resist.

It is possible to write cross app server code, at work we develop for WebSphere and WebLogic, but it's much more painful that sticking to one. We only do it because we have to sell our software on both platforms. If we were an inhouse effort them we'd go with whoever provided the most productive set of development tools, and probably pay lip service, but not much more, to portability.

These days open source probably has some impact of code standardization. If you release code, or download code, you want it to run on multiple platforms, so you put some effort into portability. On the other hand you probably reinvent the wheel many times in an attempt to remove dependence on other libraries. That's where efforts like jakarta in the java area have impact. By bringing together many java projects they can promote code reuse.