Link Details

Bileblog is annoying. There is almost a message there, but I get tired of wading though the language to decipher it.

"Anyone interested in funding a foundation dedicated to researching this afflication and trying to get these people some treatment?"

Priceless :)

Wow, what a horrible choice of language... (and I don't mean Java).

There is something to be said for a clever, sarcastic pillory of a group that shows real insight into a given situation.

Unfortunately, not much can be said for this post. The mighty Bile Blog stumbles.

among one of his worst posts, no point here, he's just venting against the language of the week.

Java is marketed as a swizz army knife, which of course get's the job done. But when I have to cut my tenderloin or sirloin roast, I opt for a Global knife, with a 22cm Japanese blade and a 100% stainless steel body. I still continue to use my swizz army knife, but not religiously as (sadly) some people.

i like the article.

This rant was based on a good idea -- addressing folks who hate Java based on irrational, ridiculous beliefs -- but delivered by the mind and mouth of an 8 year old idiot. The author simply acts out the same irrational diatribe he's talking against. This blog is a waste of time and energy.

"Ruby’s genius is in being just about hard enough for its developers to feel clever when they manage to get things done, thus continuing the by now familiar desperation that our industry has to feel self-important and worthwhile."

Hahaha :)

My response is far too long for this message board, sorry for the blog spam. Ignore if you wish.

http://www.clintonbegin.com/2008/05/re-java-haters-gtfo.html

I don't necessarily agree with your blog posting. To start with, we all know that EJB2 was a stinking pile of doo-doo. The community knew it. Sun knew it. And we have something better now. PLEASE GET OVER IT! (sorry for the capitals ;))

>"Servlets and JSP were severely lacking in the framework department"

That's not entirely correct by itself. Servlets and JSP have themselves nothing to do with being being a framework and in fact never pretended to be. Servlet is an abstraction for basically the raw HTTP request/response headers, while JSP is a templating language.

I do agree with your analysis that Sun was absolutely very late with a real web framework and that Microsoft has indeed done a lot of things right.

Sorry, I didn't mean to imply that Servelts/JSP is a framework, nor did I want to imply that Sun SHOULD make a web framework In fact, I'd prefer if they stayed out of the business of building frameworks and ESPECIALLY not specs for frameworks. For example, there was nothing wrong with Hibernate before JPA. But now if you try to use Hibernate on a project someone will undoubtedly ask: "Should we stick to the JPA compliant API?" It didn't help anything. To be fair, I wish Microsoft would get out of the framework building business too... I could live without most of ASP.NET and the EntLib stuff.

I'll update the post to clarify this point

Cheers,
Clinton

@cbegin
>"But now if you try to use Hibernate on a project someone will undoubtedly ask: "Should we stick to the JPA compliant API?" It didn't help anything."

But is that really related to Sun building (supposedly) bad software? To me that seems more like you have something against the concept 'specification'. Of course, a specification has its disadvantages, but also surely its advantages. Take for example MFC. It's not a spec, but a proprietary API from Microsoft. I used to have a lot of software build against that API, when Microsoft suddenly decided to dish it for .NET (yeah, I know it has been given some revival lately in VS 2008, but for >6 years I was left in the dark). Now, had MFC been a spec then I could have just compiled my code against another vendor's implementation when Microsoft decided not continuing with MFC was more beneficial for them.

More related to this blog; in 2003 I had a rather large amount of code deployed to Orion AS. Even though an Orion AS 3 was rumored to be released, as we all know it never came. Had the API's I then coded to be proprietary to Ironflare (the makers of Orion) instead of the J2EE specification, I would have been in a lot of trouble. Luckily J2EE was a spec. So, when it became clear there really wasn't any Orion AS 3 coming, I ported my code with immense ease to run on Jboss.

I know there's sometimes the critique that a spec is designed by a committee who hasn't any link to real world software development. With JPA it was quite the other way around. This was a time tested approach that obviously worked very well and was embraced by thousands of developers around the world. JPA specified the core of that. I don't see anythin wrong that. Retrofitting something as a spec gives one both the advantages a spec gives you, plus it guarantees the stuff being specified is connected to the real world. Seems a win-win to me.

>> But is that really related to Sun building (supposedly) bad software?

I never said Sun built bad software. :-)

>> To me that seems more like you have something against the concept 'specification'.

Bingo. More specifically, Sun's apparent fetish with building bad specifications that offer little value.

There are 3 major problems with Specifications

1) To the customer, they are an intersection of features, that is: the lowest common set of features of any given framework. Thus, you are immediately less functional, unless you break the spec. If you don't break the spec, then you probably aren't getting the full value of the software you've chosen. There may be implementation benefits, such as better performance or greater security. But outside of the spec may also lie a number of beneficial APIs or features that you could leverage and benefit from as well.

2) To the vendor, the spec is a constraint. It keeps them from building what they want, the best way they can for the benefit they want to provide. Furthermore, it stops them from being competitive. How can a vendor innovate and compete with other vendors if they're all compliant with the spec? Again, perhaps they compete on nonfunctional characteristics like performance and security, but that's a really hard sell, especially because both of those topics are so nebulous. Essentially, specs are anti-competitive.

3) They provide a false sense of security. As I pointed out in my post, the specs don't work. Anyone who has ever implemented a EJB spec or JDO, or CMP, or JSF, has basically built non-portable software. The EJB specification is not portable by design. The inclusion of a vendor specific deployment descriptor is a testament to that. But if you build using independent framework software, your apps will have survived the test of time.

>> I ported my code with immense ease to run on Jboss.

If you hadn't coded it to J2EE at all, there would have been no porting activity at all. You would have simply redeployed it to the new servlet container. Generally speaking, it's not a problem with the actual server, the problem is that each server (and verison of the server) is tied to one J2EE spec version, which brings with it a whole pile of other specs and versions. It's an all-or-nothing scenario that you can get around with tweaking and hacks (and likely voiding any service contracts), but it's certain not pretty.

>> With JPA it was quite the other way around.

How did JPA improve Hibernate? How did it improve TopLink? Has it made you more interested in TopLink?

So you might ask, where do I think specifications are important. In my opinion, a specification is important:

A) For anything that already has a related industry specification. For example, HTTP is an industry wide specification. Thus I'm very happy that Java has a corresponding Servlet specification. I'm not so happy that they chose to abstract it from HTTP itself, but whatever. :-)

B) For anything where there's a high level architectural boundary or an external dependency. For example, databases and message queues are often external to the application and have both logical tiers as well as physical boundaries between them and the application. So I think it's important that we have the JDBC and JMS specifications (although I wish JDBC wasn't part of the JDK).

C) The language and SDK. There's nothing wrong with Sun having a spec for their language and SDK. That's just good practice. In a way this falls into the "B" above, because the Java platform (VM) itself is an architectural boundary.

Just because something is working well, doesn't mean it should have a specification. It's a superfluous activity that wastes a lot of effort and creates a false sense of security in the minds of people who put too much value in the word "standard". It's also the root of all evil, as you pointed out, it's design by committee. And JPA indeed does suffer from that like all other specifications.

The worst part of something like JPA is that it will eventually be upgraded, and Hibernate/TopLink will follow it. But when you attempt to use the new Hibernate/TopLink (that implement the new spec) on your old-assed application server that you can't upgrade for whatever political reasons there may be, you will find a great number of headaches and solutions that involve overriding the default classloader order etc.... it's not good man. Meanwhile if you just coded to plain vanilla Hibernate or TopLink, you'd be fine.

I'm seeing that right now on an application that uses Apache CXF but must be deployed to WebLogic 9.2. Good times. (google it)

Cheers,
Clinton

>Bingo. More specifically, Sun's apparent fetish with building bad specifications that offer little value.

I'm not sure about that, but you probably already guessed I was going to say something like that ;) For starters, please realize it's not Sun itself that solely builds the JSR specifications. In fact, building these specifications is an effort undertaken by a whole group of experts, hence the name expert group. This includes companies that have an interest in eventually making use of a specification, as well as companies who plan on becoming a vendor of said specification. It also includes individuals (Doug Lea any one?), and of course numerous open source parties, either represented by a company or not.

>If you don't break the spec, then you probably aren't getting the full value of the software you've chosen.

Sometimes this is true, but as an individual I have the option for choosing whether I want to stay within the bounds of the spec or explore the outside waters, right? It's really something we are seeing at a lot of places in the IT industry. Take for example the SQL specification. I can choose to use strictly SQL-[some year] compliant syntax, or I can take advantage of some specific features my DBMS offers. The choice is really up to me. Sometimes it's of the uttermost importance that I operate within a spec, for instance if I build a product that a customer needs to connect to his own DBMS. At other times it's my choice; leave a path open to migrate to another DB later, or take advantage of some neat features my current DB offers today?

Whatever my choice I often found that staying within a spec as much as possible and only use some vendor specific features when needed works really good. If the time comes to switch an implementation, I -only- have to port the vendor specific things I used, not the whole thing.

>"If you hadn't coded it to J2EE at all, there would have been no porting activity at all. You would have simply redeployed it to the new servlet container."

I'm not sure I follow. Either I simply don't understand what you mean or you *completely* missed my point.

If I hadn't been coding to J2EE, i.e. if there hadn't been a J2EE to begin with, I would have coded my app to some specific Orion API. How can I 'simply' redeploy to another servlet container if there wasn't a servlet spec to begin with, and thus no alternative implementation of it? In that case there only would have been "The Orion API", and I would have had to recode my application completely from scratch. An effort not unlike porting an application from say PHP to ASP.NET.

The fact that Servlet was a spec allowed this entire "simply redeploy to another servlet container".

(btw, you do know that the Servlet API is part of J2EE right?)

>How did JPA improve Hibernate? How did it improve TopLink? Has it made you more interested in TopLink?

It standardized a very large part of it. Other stuff was left out, like the advanced caching stuff and the criteria API. Never the less, I'm now able to easily switch vendors again if necessary and only having to adjust a few parts instead of it all. (I use Hibernate on Jboss via JPA currently and make use of Hibernate specific annotations and configuration for caching). Lately I've been quite unhappy with the progress Jboss is making on Jboss 5, while Glassfish is already on its way with implementing experimental Java EE 6 support, Jboss still hasn't released on official Java EE 5 AS. Through JPA switching to Glassfish/Toplink may actually be an option. And yes, JPA has made me more curious about Toplink indeed.

You obviously see more value in specs and standards than I do. That's totally cool. We can disagree. The only point I want to address is this one:

>> building these specifications is an effort undertaken by a whole group of experts

That is a HUGE part of the problem. That is not leadership. It's chaos. And it has produced every dog's dinner spec for annotations to JSR 308.

The individual people are great, any ONE of them could probably do a better job than the collective organization of the JCP.

Cheers,
Clinton