Fixing the jcp – the server side java symposium

The official title of this session is “The Java Community Process – What’s broken and how to fix it”.  The panel is James Gosling, Patrick Curran (head of the jcp) and Reza Rahman (member of jcp expert groups and author of EJB in action)

What’s wrong

  • Some inherent because so many priorities and agendas. these predated Oracle
  • Apache Harmony TCK issue (Apache Geronomo doesn’t pay for TCK because non profit open source. The problem with Harmony is that it has restrictions). Reza would like to see it free, no strings attached after the lawsuit.
  • Patrick said Oracle is more forceful than Sun in that they make a stand rather than bicker forever
  • Reza said James is too bright but not practical enough :). He views Oracle as being more practical. Reza noted leading is hard and getting people to agree is hard. He views Oracle leading as a necessity because they have the resources to be a JSR lead.   James noted being a spec lead is a full time job even if things go smoothly.
  • In 2007, Oracle tried to create an organization so sun would have less power. Now that they are in charge, they want to retain ownership. Logical position at least.
  • Process issues -greater transparency so don’t have to be a JCP member for read only view
  • Reza views a big problem as lack of individual participation in the JCP. Reas the proceedings, blog, be spec leads, etc. Democracy is participatory [yes, but this isn’t a democracy, right after i wrote this Cameron noted SpringSource and Google are leading by example. Reza said that sounds like Microsoft. and it does.  Except that Sun copied from Spring extensively. James noted that innovation in the String class would be dangerous]

What could be better

  • Reza recognized it is hard to have an independent JCP. It requires resources, a way to move forward without veto bpower, etc
  • Patrick noted that all standards groups have these political obstacles because companies or countries have different interests. The fact that they are trying to work together is a good thing.
  • Patrick noted things are better than they look. Some groups have mailing lists that be read.  Oracle is looking at making things more open and expect to mandate transparency via an open mailing list. Similarly for formally tracking comments. The executive committee has been publishing minutes for several years.
  • Patrick noted they are looking at making it easier to join. In particular, creating a simpler legal agreement for non-spec lead roles
  • Patrick pointed out standards take time. It is more important to get it right than fast. It is avoiding unnecessary waste that matters

audience questions

  • Role of spec evangelist separate from spec lead?  Reza said don’t need formal role. Independents on JCP should blog and do this
  • More people shipping products dependent on platform?  oracle working on balance. Also looking at letting java user groups join so members can contribute
  • What can someone do to help without spending a lot of time?  Follow JSR interested in. Read the spec and comment without joining group. Mny JSRS are open source comments. Reza listed following jee articles on theserverside and javalobby and leave comments for actual jcp members to read and convey. Similarly for the comment period. [this was my question, a lot of the answers sound quite time consuming to me. Reza did list a short one which I appreciate]
  • Developers wait until something is stable to try it because working our own problems. By then it is late in the game to comment. Everyone agreed the proposed final draft and reference implementation IS that

Why JDBC + JSP = Bad

Over years of moderating at The JavaRanch, I’ve seen one type of question spring up on a weekly basis: that asked by people who need help with JDBC code inside of Java Server Pages (JSPs). As much as we may want to help this individual fix their particular problem, the overriding thought of “STOP WHAT YOU’RE DOING” often prevents us from doing so. The purpose of this post is to explain why putting JDBC code inside a JSP file is akin to shooting yourself in the foot. With a shotgun. While not wearing shoes.

Don't use JDBC inside of JSP pages

1. You cannot reuse the code
First and foremost is the issue of code reusability. While importing java classes is quite common, importing code from a JSP is not. While you can write JSP functions, although I never recommend doing so for reasons I won’t get into now, you’re basically writing code that you cannot be used anywhere else, particularly in non-JSP java classes. The most common counter response to this is “Well, I don’t need to use it anywhere else”. Yes, you do. Whether its just reusing code for making the connection to database or the code for performing a query and reading the results, it will be used again at some point in the future in a way you have not thought of yet. Unless you are being paid by the line and prefer this sort of thing, it’s a bad move, and I guarantee your code base will be much larger than someone who put all their JDBC code into normal Java classes. Larger code base means more difficulty to maintain and more headaches for you down the road.

2. You are mixing business logic with the presentation layer
Probably the most overlooked issue for inexperienced developers is the fact that you’re mixing the business/data layers with the presentation layer. I’ll put it another way, if your boss comes in one morning and says we’re throwing out the JSP front end and replacing it with a web service, Java Swing, Flash, or some other interface, there is virtually no way for you to reuse the database code without going through every line of every JSP file by hand. If the database code had been placed in plain java files, then you would have a path for packaging the JDBC code into a single JAR and making it available as a service to a different front-end client such as a web service, Flash, etc.

In enterprise development, the presentation JSP layer and the database are often separated by multiple layers of indirection such as described by the commonly used three-tier architecture pattern. Those who are just starting out programming often do not know why mixing these layers is bad, but I promise you if you stay with software development you’ll understand one day.

3. But it’s just this once!
Often times, JDBC code enters JSPs by developer lying to themselves saying “Well, it’s just this once” or “I just need to test something”. Instead of being removed when the developer is done ‘testing’, the code often persists for a long time afterward. Furthermore, putting your JDBC code inside of reusable Java classes makes testing go faster! Spending 10 minutes setting up a single reusable Java JDBC class will save you hours down the road. Then, if you want to test more than one JSP page with JDBC logic, you already have your Java class file to start with. Proponents of test-driven development tend to understand this better than anyone.

4. It’s really hard to maintain
Code maintenance is another topic that new developers do not fully appreciate since they have not spent years maintaining the same code base. Unless you write the most beautiful JDBC code imaginable, its very difficult to read through huge JSP files looking for bugs and/or making enhancements. It’s a lot easier if all the JDBC access is restricted to a set of files much smaller in size than the JSP code base.

5. It’s a really bad practice
If after reading this article you still do not fully understand why you should not put JDBC code inside of JSPs, let me simplify the issue by saying “Just Don’t Do It”. Whether or not developers understand the reasons against doing so is not as important as stopping them from doing so in the first place. In short, you create code someone else (possibly yourself) will have the misfortune of maintaining down the road.