The REST zealotry needs to end.

First, let me establish my bonafides here. I work on the ROME project. I built the first module for Google Base. I have used the Propono project to build an APP service. I use REST. REST is a friend of mine.

Here is the thing:

People need to own up to the fact that SOAP has its place. Yes, “SOAP” is neither “Simple,” nor arguably about “Object Access,” and marginally a “Protocol.” But SOAP and WS-* have their place. Just own up to it.

One of the things I had a chat about at JavaOne last year, over a number of free drinks, is that one of the big advantages of SOAP over REST was the use of nillable. There is a complete semantic difference between and the absence of said tag in SOAP. This is a clean advantage over REST where the presumption is total replacement and preservation of “unsupported” tags. In APP this is generally OK, but lets face it, this is a really HARD requirement to meet. The thing is, I listen to the Google Developer Podcast where the idea of adding a “PATCH” method to HTTP is discussed. I read in the illustrious James Clark’s blog about about complex methods for signing HTTP.

So here is my point, REST people… Yeah, SOAP isn’t simple, but the complexity of the envelope tag gives you a clear point to encrypt or pass transaction information. The soap:nillable namespace has to be there, but it doesn’t require a protocolchange. Can’t we just admit that, on a 60/40 basis REST rules? If you want simple and easy and your data conforms to basic preserved ENTITIES, REST is great. When you need encryption beyond basic SSL, differential updates, two phase commits, reliable messaging — all that “other stuff” — WS-* has a place?

I am getting really tired of religious arguments in my space lately. Sure, dynamically typed languages have a place, but static typing has some real advantages. Yes, environment X gives you A, but environment Y gives you B. I am not going to tell anyone that WS-* is the end all be all, but I wish the REST crowd would own up to the idea that WS-* solves some hard problems, and with basic tooling is not “hard to use.”

So Chris Adamson and I have gone back and forth, and back and forth on the “Leopard Controversy.” (In all fairness, Chris has been in the JavaLobby and #javaposse fray too.)

Frankly, I tend to agree with Chris that Java isn’t likely a make-or-break deal for Apple at all. However, I think there is a compromise.

Steve, join the OpenJDK project.

With the new(ish) found support for Ruby and Python, Apple has demonstrated a willingness to provide basic support for languages/environments that have, lets face it, a marginal impact on the common user, but that developers love. The thing is, with Java moving to a completely open source model, Apple could see even better support with fewer dedicated resources within Apple. The problem is, OpenJDK is missing things like the OSX LAF and AWT Peers. If Apple would contribute their implementations to the OpenJDK project, they might find even better support with less dedicated Apple resources. Then just give it resources similar to what you give Ruby or Python to clean up and QA for distribution.

While it is anecdotal, it seems to me that, much like Ruby, the *majority* of Java developers work on Macs. I have a hard time believing that we, as a community represent a smaller base than the graphic design community. Moreover, over the next few years failing to support the Eclipse-based Flex Builder and other tools from Adobe might serve to alienate one of your larger ISVs.

If Java isn’t a priority for Apple, hey, I understand. But let the community build on the fine work you guys have already done, and keep Apple relevant to the thousands of Java developers who use it, Ruby developers who want to use the new support in NetBeans, and users who use apps like Azureus regularly.

Thanks,

Robert Cooper

From Sun Microsystems: Netbeans out under GPLv2 with the option to use it under CDDL. For those of you who don’t know what that means, I’ll quote from the Sun Microsystem’s FAQ:

2. Why does Sun want to dual license NetBeans software under CDDL and GPLv2 with Classpath Exception?

The GPL v2 license will provide an additional option to vendors that are unable to work with NetBeans software under the CDDL license.

Adding GPLv2 as a license option will make NetBeans software even more Linux friendly.

Adding GPLv2 with Classpath exception to NetBeans software will keep product portfolios and bundles consistent. Sun open sourced its JDK implementation under GPLv2 and the GlassFish project is dual-licensed under CDDL and GPLv2 with Classpath exception.

This is a big deal, the NetBeans codebase is massive, and opening it up with GPLv2 means that the open source “ecosystem” just got that much larger. Most of the programming audience isn’t going to jump at licensing news, but releasing NetBeans under GPLv2 might just have a bigger immediate effect than GPL’ing the JDK. Sun’s moving in the right direction.

If you’re around Dublin on the 7th / 8th / 9th November you’re more than welcome to drop into the Irish Java Technologies Conference (IJTC).This post is preview of some of the people who are speaking. If you can’t make it, it’s an invitation to check out speaker’s websites and see if any of the technologies they are promoting could be of use to your project.

Here are the top 10 projects that I’m looking forward to hearing about out.

10) Java and Microsoft SQL Server : It’s still a brave Microsoft person that comes to a Java conference. Shows MS recognition a substantial amount of Java deployments persist their Data to a SQL- Server database.

9) Eclipse STP (and SOA) - Service Orientated Architecture is the buzzword of the year. If anybody can put substance behind the hype , it’s the guys From Iona.

8) Eclipse JPA and Dali. Hibernate pushed Object Relational Mapping (ORM) to be the standard approach to database access. The manager of the ‘other’ ORM Project (Oracle Toplink) should give a interesting coverage of the tooling developments.

7) Apache Geronimo - by Jeff Genender from Apache Foundation. So long the ‘other’ Open source application server, this is now becoming credible in commercial deployments.

6) Java Update - Simon has been working as a lead Java consultant for Sun Microsystems. He’ll be talking about Java Standard Edition 6 and Java Mobile Edition. But what I’m really interested in is Java Enterprise Edition 5, Scripting, Java Realtime and Java FX.

5) If scripting is your thing fellow Onjava Blogger Dejan Bosanac is also speaking on this subject. He’s talking about Scripting within the JVM, which will be one of the hot topics for 2008.

4) iPhone v JMME - I don’t get the buzz around Mobile (give it another 18 months , we’ll all be running Java Application Servers on the mobile). But many people are interested in it - this talk is how to make you Mobile Java apps as slick as those in the iPhone.

3) JBoss Drools - I’ve blogged (a little bit) about Drools before. I’ve also been fortunate enough to hear Mark Proctor speak and you will come out an convinced that the natural home for Business Logic is in the Rule engine.

2) JPA and Hibernate - There is a very strong possibility that Emmanuel Bernard will be returning to Dublin to talk about the Hibernate project that he leads. Having seen his recent talk, and given the level of interest in Hibernate, I expect a strong turnout for this one.

1) Spring 2.5 - Spring has been around for more than 5 years and is making serious inroads in the the Enterprise Java community. Sam Brannen (from Interface21) will give details on the latest on the major update to Spring (2.5) as well as what is planned for the future.

Disclaimer: I’ll be talking about Java Workflow (based on on JBoss jBPM). But compared to these guys, I’m way down on the Z-List of presenters. Must run that presentation past Robert Cooper and see if he still hates BPM products.

OpenJDK community has a new project, Multi-Language VM (or just mlvm). It is announced by John Rose, from Sun, on the announcement list. The focus of the project will be to prototype JVM features beneficial for dynamic languages and remove “pain points” that current dynamic language developers have with standard JVM.

Here’s the snippet from the announcement:

This project will be open for prototyping
JVM features aimed at efficiently supporting
languages other than Java.

The emphasis will be on completing the existing
bytecode and execution architecture with general
purpose extensions, as opposed to a new feature
for just one language, or adjoining an unrelated
new execution model.

The emphasis will also be on work which removes
“pain points” already observed by implementors
of successful or influential languages, as opposed
to more speculative work on unproven features or
niche languages.

It is definitely a step in the right direction for making Java a true multi-language development platform.

Ben Collins-Sussman has an interesting blog entry about Distributed Version Control titled “Version Control and “the 80%”. Here’s an excerpt:

…In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work; in a decentralized system, the default behavior is for each developer to privately fork the project. They have to put in some extra effort to share code and organize themselves into some sort of collaborative structure. Yes, I’m aware that a DVCS is able to emulate a centralized system; but defaults matter. The default action is to fork, not to collaborate! This encourages people to crawl into caves and write huge new features, then “dump” these code-bombs on their peers, at which point the code is unreviewable. Yes, best practices are possible with DVCS, but they’re not encouraged. It makes me nervous about the future of open source development. (Maybe the great liberation is worth it; time will tell.)

I don’t see decentralized version control working for a smaller set of projects like Jakarta Commons. For smaller projects, I don’t think the overhead of a DVCS is worth the effort, but for larger projects like Wicket or Maven, I think DVCS would encourage more external contribution. I also don’t think that forking is the opposite of collaborating - forks are part of the creative (read messy) process of evolving a code base. I can think of a few situations where a fork would have been helpful in the past few years (Struts during the Shale debacle and I’m convinced that someone needs to fork Maven documentation into an external project). An ideal fork competes with the original and inspires change.

…and, if you don’t believe me…

Jason Van Zyl wrote the following email to the Maven developer’s list on September 29th:

…for anyone who has patches or wants to try and work with me to
get changes in I am going to try this method of publishing Maven as a
GIT repository which will allow anyone to clone the repository and
work on any changes you like in a controlled way. Once you clone you
can commit changes to your own copy of Maven and do whatever you
like. Then in order for me to see your changes I can simply pull from
your originally cloned repository to a branch on my side and merge.
Merging is sooooooo easy with GIT. So easy in fact that it makes you
wonder how SVN got it so wrong and makes it so painful compared to GIT.

He continues later in his post:

In the short term I really only want to try with a few people but if
you’re keen, want to learn about GIT (which I highly, highly
recommend) then I will take your patches. I think any developer here
and anyone who has ever tried to contribute changes sees that the JIRA
+patch model is highly unworkable and bordering on completely
useless. JIRA might be fine to raise the issue but with a reference
to a GIT repository to pull from it will make life infinitely easier.
People who are not committers can work with people that are in a way
that resembles everyon being part of the team. Dealing with patches
just sucks ass and as a result we don’t look at them nearly as often
as we should so I hope this can become a model that enables people to
contribute in a more effective way. I’m going to try this with Oleg
but I am highly hopeful. I will help anyone who wants to try this as
I see this as a way to truly collaborate with the community. Down
with JIRA+patches! All hail JIRA+GIT! :-)

Oh, and about Sussman’s 80%. I think we can replace them with some Ruby scripts.

John Reynolds has a post at Java.net entitled Why do Java developers hate BPM? where I think he completely misses the problem with “BPM” products:

Java developers hate BPM.

The preceding sentence is (of course) intentionally tailored to be controversial. People tend to read controversial blogs, and I’d like you to read this one. Now that I have hopefully grabbed your attention I’ll tone it down a bit…

A lot of Java developers hate having to use BPM tools instead of the object oriented tools that they are comfortable with.
I work on a lot of BPM projects, and I work with a lot of other folks who work on a lot of BPM projects, and we have all encountered resistance from traditional Java developers. Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite.

Java frameworks like Struts and Spring are in the background… they provide just enough support to “set your creativity free” so that you can be a real programmer. You can build almost anything with Spring or Struts (if you’ve already mastered the intricacies of Java). They are light-weight, they’re agile, and they look sexy on your resume.

BPM suites are in-your-face. They rob you of your creativity. They dictate to you how you will develop your application.

Let me be clear from the outset here. I *love* the idea of BPM tools. I like the idea of a standard process set and ruleset that is clear and standardized. I am not even opposed to something “dictating” how I will build my application. First, constraints encourage creativity more than they limit it. Second, this gets to the “Software Engineering” goal we have talked about for three decades of standardizing parts and interactions into systems that sidestep common errors. From design patterns to frameworks this is the goal.

Here is the problem:

XML is not a programming language.

Let me say it again.

XML is NOT a programming language.

Now I worked for a company what seems like eons ago now, and we made this mistake. We spent a ton of time working on an interpreted XML-based language for our system, and it worked, but it was never usable. XML is great for data. It is good for basic programming that is simply declarative in nature. It is horrible as a format for writing process or algorithms. All these idiotic drag-and-drop program with graphics BPEL tools are impossible to use for anything of significant complexity. BPEL itself is so verbose as to obfuscate any logic you need.

Now, I am not saying that BPM tools should have a general purpose programming language, but even using a *subset* of Groovy, Ruby or Java would be much easier to work with… For programmers…

And here is where it breaks down. All these unusable drag and drop tools, and “easy” XML programming languages aren’t targeted at programmers. They are targeted to suits who can buy into the idea that some non-techy is going to orchestrate these services and modify business rules. These products are unworkable because they are based on the idea that “You won’t need programmers anymore!” at least at a core level. Once you make that assumption you start building things that get in programmers way, and still include enough abstract programming concepts that no non-programmer is ever going to be able to work with it proficiently.

Just to emphasize this point:

<?xml version="1.0" encoding="UTF-8"?>
<process
	xmlns="https://schemas.xmlsoap.org/ws/2003/03/business-process/"
	xmlns:print="https://www.eclipse.org/tptp/choreography/2004/engine/Print"
	<!--Hello World - my first ever BPEL program -->
	<import importType="https://schemas.xmlsoap.org/wsdl/"
		location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl"
		namespace="https://www.eclipse.org/tptp/choreography/2004/engine/Print" />
	<partnerLinks>
		<partnerLink 	name="printService"
				partnerLinkType="print:printLink"
				partnerRole="printService"/>
	</partnerLinks>
	<variables>
		<variable 	name="hello_world"
				messageType="print:PrintMessage" />
	</variables>
	<assign>
		<copy>
			<from><literal>Hello World</literal></from>
			<to>$hello_world.value</to>
		</copy>
	</assign>
	<invoke partnerLink="printService" operation="print" inputVariable="hello_world" />
</process>

So.PrintMessage hello = new PrintMessage(); hello.value = "Hello Wolrd"; PrintService.print( hello ); is now incredibly long and non obvious. Scale that up to something where you have to do complex data adaptation and handle exceptions across multiple service calls, and you should be able to see how stupid this gets.

Apache Struts is the most popular Java web application framework till date. However, newer developments have rendered it both obsolete and inadequate. There are a few options that are trying to replace it but there is no clear winner yet! Who do you think is leading and worthy of the position? Which framework should you use today if you are a Java web application developer?

Rich application development technologies, AJAX, RIA or whatever other form that they may manifest in, are currently the most popular web UI technologies. However, Java is still the choice at the server side. Because of this some of the server side UI technologies, based on JSP and JavaServlets, are still prevelant. Many times these server side UI technologies work in association with the rich UI technologies. As an example many developers are incorporating AJAX with Java Server Faces (JSF), the new generation server centric web framework specification from Java. Many others are using Java remoting libraries, open source and commercial, to remote JavaScript and ActionScript calls down to the server side.

Does that mean we should adopt one of the frameworks like Apache Shale that work well with JSF? Does it mean we should use a remoting library with Servlets only, as far as the Java part of the web application goes? Or does it mean we should use a framework that does both - i.e. JBoss Seam?

Picture the scene: a self help group meeting, plastic chairs arranged in a circle. Sitting on the chairs are an assortment of (mainly) men in their 20’s or 30’s, some smartly dressed, others with 2 day old beards. They fail to look each other in the eye, until one plucks up the courage and mumbles ‘Hello, I’m Paul , and I’ve been writing bad Java code for 10 years‘.

Taking a deep breath he continues: ‘When I got into Java I was using JSP for everything - HTML, talking to databases, doing workflow - anything I could get my hands on‘. Seeing the shock on his comrades faces he adds ‘I was young and I didn’t know what I was doing‘. ‘Then I found Struts and MVC and things became a little bit better. My days had a bit more structure, but things didn’t seem right. Even after I got treatment based on EJB, Spring and Hibernate, I still feel that there is a void at the centre of my coding life‘.

The rest of the group nodded - This was a classic case. ‘I fell in with a bad crowd. Business types with suits and violin cases. They said they’d pay me good money if I built them something just like they asked. Now they don’t believe that it works - it’s all techie stuff to them. Those boys are going to play rough if I can’t show them the goods and let them review the code. What can I do?‘

There was silence for a while. Then the group leader said

You need to build a system where non-technical people can review the important parts. You’ve used all the major frameworks, and while they’re good in what they do, they’re not helping here. And if you sacrifice maintainability , performance or speed of development, the suits are going to get you.

‘It’s a tough one. Does anybody have any suggestions?’

What would YOU suggest?