Tor has posted an interesting image:

Just a thought here, but out of all these Web 2.0 sites that have user pages… for instance out of my personal collection:

https://www.last.fm/user/kebernet
https://flickr.com/photos/kebernet
https://allconsuming.net/person/kebernet/
https://del.icio.us/kebernet
https://wiki.java.net/bin/view/People/RobertCooper

Why don’t we go back to the way-back days of using https://host.tld/~username? It worked so well for a long time and while the ~ key might be a mystery to “mom”, at least it was a convention. For all the talk about pretty and intuitive URLs, this seems like an easy one that time has forgotten.

The mobile phone market doesn’t need yet another innovative device design. We’re well-served by RAZRs and Treos and Dash’s (oh my!). But it desperately needs innovation in the smartphone OS area.

[Sorry for parking this in the Java area for now, but technical difficulties leave me no alternative.]

Now that the dust is beginning to settle on Sun’s Decision to open source Java , what does it actually mean for you? That’s you as in a Business user, you as in a Java Developer , and you as a member of the wider IT Community?

• In the short run (i.e. next 6 months), once the buzz dies down , not much. Remember that it took several years after the Netscape code was open source for Firefox to emerge and change the dynamic of the browser market.

• In the medium term (between 6 and 24 months) expect some interesting packagings of Java to emerge, similar to the way the various Linux Distros work today. Consider these ‘green shoots’ or prototypes with interesting ideas. A ’small footprint’ version of Java targeted at Applet developers seems to be one popular opinion of what might emerge. However, unless you are ‘bleeding edge’ or in a niche area the chances are you won’t notice them at this stage.

It is in the longer term (2 years plus) that open source java really makes it’s mark. Some predictions that you can quote back to me later:

- In the same way as JBoss and Geronimo have commoditised the app server market programming languages and runtimes will become a commodity. Expect the .Net platform to be opened (not just standardized) in some limited form.

- Java will become more like .Net with multiple languages running in the standard JVM. We have JRuby and Groovy. It wouldn’t be too hard to add C# to this list. Visual Basic in the JVM (the Sun Semplice Project) is already on it’s way.

- Oracle , IBM , SAP and others already committed to the Java market will become focussed on Java as an even bigger part of the core strategy. Just like the app server market, each will seek to differentiate themselves, perhaps by Service (IBM), by a core database (Oracle) or by leading a niche (SAP). Expect tension between the desire to differentiate (and fragment) and the GPL which seeks to ‘bind them all’.

- Apache Harmony , a clean room implementation of Java will continue to gain momentum. It will get picked up by a major vendor in a similar manner to Apple using BSD code.

- Microsoft .Net will end up in a ‘death march’ with Java trying to gain a lead in a feature set. Open source is very good a mimicing existing products (as it makes an easy spec for dispersed developers to write on - just look at Open Office), so (unless software patents get thrown into the mix), it’s hard to see .Net getting a fundamental and lasting edge over the Java Ecosystem.

More in Technology in Plain English

Update: I’m not saying that .Net is going to go away (nor should it), just that both it and Java are going to be around for a long time to come. Joe and John also have more commentary.

If you read my OJ article on GWT, you saw the first version of the maven plugin. It has been updated since then, but we have been somewhat… negligent in releasing. So there is a new version avialable at our Google Code site.

Details after the bump.

This isn’t much of anything, really. More the beginings of ideas, but I was chatting with Josh Marinacci earlier about databinding in Swing, and frankly, how completely unimpressed I am by what I have seen of JSR-295. Honestly, I implemented all of the functionality I have seen there in about a week on my own. Having a whole spec that does, frankly, that little work for me doesn’t get me all hot and bothered.

I made some notes about what I consider — off the top of my head — the ultimate Swing binding framework. I don’t pretend that all the issues have been worked out, but I think it is a good starting place to think about it.

More after the bump.

A bit off topic here, but I saw this on /. today:

“Microsoft has recently announced a new licensing program for the Office 2007 user interface. This page links to the license and an MSDN Channel9 interview about the program (featuring a lawyer). The program ‘allows virtually anyone to obtain a royalty-free license to use the new Office UI in a software product. There’s only one limitation: if you are building a program which directly competes with Word, Excel, PowerPoint, Outlook, or Access (the Microsoft applications with the new UI), you can’t obtain the royalty-free license.’

Which, was followed up with: “What does this mean for OpenOffice?”

I don’t think that matters much, frankly. OO.o isn’t going to use the Office UI APIs directly anyway, for what I would think are obvious reasons. What I am curious about is what qualifies as “compete”? Does ACT! “compete” with Outlook? Does Quicken compete with Excel? Does Grandma’s Recipe Software compete with Access? Does Dreamweaver compete with Word? The reason for the success of Office is the software included is very generic and in a lot of ways is a representative of the primary functions of a computer in general — Data Storage, Calculations, Communications, Visualization/Presentation.

The other thing, as a bit of an aside, that I find funny is Microsoft spinning wildly in the opposite direction of their arguments during the MSIE antitrust trial: Browsers and Email clients are a “fundamental” part of the operating system, but now UI API’s are part of Office and licensed separately. The FAQ’s business about “protecting their investment” is almost comical, since MIcrosoft’s biggest asset is the fact that everyone else’s software is closely coupled to their APIs anyway. The implication that still more coupling would be bad for their business is interesting.

…in response to Dejan’s previous blog post “Playing with XFire”. Dejan, Xfire is great, it runs Axis out of town from a performance perspective. from my own experience, Apache Axis (both 1 and 2) has a codebase that will make you never want to use it again. Seriously, check for yourself. If you really want a compelling reason to use XFire, google “JSR 181 XFire” and the “Spring Proxy XFire”. XFire is fast as lightning, and, at least, for the work i’ve been doing lately, you can get something exposed as a SOAP service simply by using the JSR 181 Annotations. plus, it has support for different transports like JMS. Couple something like XFire as a messaging library with ActiveMQ as a JMS provider and ServiceMix and you’ve got some really interesting tools.

In short, to anyone looking to produce or consume a web service in Java, Use XFire. Couple it with the Spring Framework and you’ll be disappointed by how easy it is.

Takai has posted a brief howto on running RoR apps in Glassfish, which Charles and half the free world is linking to. Since I seem to have been in a run of profoundly negative discussions around here lately anyway, allow me to get all Jay Sherman on this one too:

Iiiiit stinks!

Yeah, running Rails apps in JEE servers is cool, and it has the possibility to really open up a new world for Rails, but this seems to be sidestepping one of the things I most wanted to see. Let’s look at the instructions.

1. Copy follow files to /lib
…
2. Edit /domains//conf/domain.xml
…
3. create config file to /domains//conf/rails.xml
…
4. generate rails app to /domains//applications/rails

Seems to me #1 should be optional and the rest of it should be:
“ant war”
“ant sun-appserv-deploy”

WAR packaging is one of the things JEE has going for it in a big way. I know Tim has talked about PHP and Ruby vs Java at the language level, but he and everyone else on the planet will generally concede that the tooling for Java is second to none, and this seems like part of that. However, anyone who remembers what deployment of webapps was like back in the day, or people who still juggle tgz’s of their apps around between servers for PHP or RoR absolutely adore the simplicity of WAR based deployment. Having Grizzly simply redirect requests to Rails isn’t even on the list of things I would have worried about at this point in the game, and leaving me with another directory structure/non-remote based deployment doesn’t seem like progress.

This was the impression I got as a target for JRuby from the get go, and while I understand it might be slower — come on, if we cared a whole lot about slow at this point, would we really be talking about Ruby at all? :P — just having a template Servlet that can send off requests to the JRoR environment seems like a much better option here.

This concludes this Andy Rooney moment.

Every once in a while I get some WSDL file and a task to create a Java client (and a service for testing purposes) that will use a defined service. I’ve tried XFire a couple of times before (version was 1.1 in those days). But it never actually managed to create stub client and servers classes from “my” WSDL files. So, without much time left to investigate I usually decided to give it a bit more time and fallback to good old Axis.
But, a few weeks ago everything changed. I got a definition file and decided to try XFire again. This time I found an Eclipse plugin for it, which does exactly what I needed to do. It needs Java 5 and Eclipse 3.2 … checked and checked … I ran the wizard that plugin provides, entered some basic facts (location of the file, package and the location for the generated sources) and that was all. I was up and running in under five minutes. Excellent.
But that is not the end of the story. The real surprise came when I browsed the generated code. It was much more “elegant” (readable) then equivalent Axis stub. With a heavy use of annotations it will be much easier to maintain in the coming years. Also, support for XBeans and Spring definitely makes my life much easier with XFire. I didn’t have time to verify whether it is as efficient as people say, but it doesn’t matter for me at this moment. And with all good coding that has been put into that project, I don’t see how it could be any different.
So with all modern features, elegant stub classes and “probably” good performance, I think that I will stick to the XFire for my future SOAP coding.

The GWT team has released GWT 1.2. Details at the GWT blog. This version includes enhanced performance in hosted mode, the new HTTP module which allows for full function HTTP requests, beyond the simple HTTPRequest object. Most importantly, however, is it support Mac OS X 10.4+, which has made my life a whole lot easier.

is it…. GPL?

Bray gives an interview with Artima and there are at least a couple of WTF moments in there.

Frank Sommers: Why is the GPL a better choice for Java than Apache, Mozilla or some other open-source license?

Tim Bray: You are never going to get a consensus on that. There was a huge amount of argument on that [issue]. I see IBM issued a statement today, wishing that we had done Apache. You can name many reasons for choosing Apache.

I personally think that the GPL is a better choice, simply because Java has been given away for free for so long by us that the world owes Java something back. When people make improvements [to] Java these days, they should very well turn around and give that back to the community. So I’m really comfortable with GPL.

He’s the thing, Tim. That is all well and good, except you maintain the dual licensing model. Unless *Sun* wants to fork Java — an all internal version, and an all GPL version — that is just not going to happen. All those improvements that might float around on the internet can’t just be culled by Sun. The author has to hack through the red tape of your contributor agreement, feel comfortable with Sun selling her code to binary only distributors completely out her control — something which I suspect is going to go over like a fart in church with the exact people you are trying to woo with this — and THEN Sun will put it “in Java.”

Frank Sommers: The new project on java.net is called OpenJDK. It’s not called Java. How does the licensing change impact the use of the Java name?

Tim Bray: That’s a very good question. The source code is open-sourced under the GPL. Anybody can take the code, anybody can change the code, anybody can compile their changed version and ship it, or sell it even.

What they can’t do is call it Java. You can’t call it Java unless it passes the TCK and goes through all the usual TCK and copyright processes you have to go through to call something Java.

That’s how we’re keeping the compatibility promise to the world. We’re not doing it through engineering means, we’re doing it through business and legal means. If something is called Java, and has the Coffee Cup logo on it, that means that it has passed the TCK and it is, in fact, fully compatible Java.

In the past, there have been incidents of people trying to skate around that, to call something Java that really isn’t. In the past, when that happened, we have taken them to court. Let’s be totally clear on that: If somebody’s trying to do that, they’ll find themselves in court right away. We will be very aggressive about that.

For the business user who doesn’t want to be fooling around with experimental open-source, all they need to do is look for the Java name and the brand [image], and they’ll have real Java. Whether it’s called Java in the administration panel, or the command line you type to run it, or however you normally access it, if it appears under the name Java, then it had better be Java, or that distribution is going to end up in court. [ed: emphasis mine]

Seriously, that is (a) not or only marginally enforced right now, and (b) pretty stupid. If Sun wants to get its panties in a wad every time the word “java” is used then the courts should already be awash in suits. Fedora today ships with a “java” command that isn’t Java™. Does GWT need to get sued because they hava a java.lang.String class that isn’t TCK compliant? Why aren’t you suing Classpath from the get go, since they don’t pass the TCK?

I understand having Java™ certification, but this statement implies a level of legal wankery on Sun’s part that is well past what we have been accustomed to and beyond that proverbial pale. Out side of that, is it good for Sun OR Java to have the Iceweasel issue here?

Danese Cooper (no relation) gives a timeline of Open Source Java

It’s finally happened! Sun has released Java under an open source license. Not only that, they did it in the best possible way: using GPL version 2, not some bizarre concoction of their own. Congratulations to Jonathan Schwartz, James Gosling, and everyone else involved with this decision.

What’s surprising, of course, is how long it took. We’ve talked about it for years, written articles and editorials–but after lots of “maybe next year,” some of us never really believed it would happen. And it’s worth noting that a complete JDK hasn’t yet been released; just the compiler (javac) and the Hot Spot VM, with the rest of the JDK coming in the first half of 2007. But what’s available under the GPL today is substantial: as Gosling has said on a number of occasions, the JVM is the crown jewel.

So, now that we have the crown jewels in our hands, and the other bits coming in a few months, we need to ask the hard question. Is it too little, too late? It’s certainly not too little. But too late?

Sun has always been a company that many developers have loved to hate. People have been dancing on Java’s grave ever since Gosling first gave us a look at a USENIX conference back in 1995. I know–I was there. I doubt that this announcement will convince any of the historical Java-bashers. For them, the license is irrelevant.

More to the point: Java has been the birthing ground or proving ground for many important technologies: the first web containers, Jini, JXTA, aspect-oriented programming, Hibernate, and Spring, to name a few. Lucene made it easy for developers to integrate sophisticated search engines into their applications. The JAIN community had a working, web-startable SIP phone long before VoIP became popular. EJB first interested me because I could see a way to write a database application without writing SQL. That idea is still pretty radical. GPL’d Java will do a lot to make the achievements of the Java community more visible: more people will be willing to look at what Java developers are doing, and take advantage of the great wealth of innovation that Java has driven.

But that isn’t the whole story: that street runs in both directions. As you probably know, EJB 2.0 and 2.1 went badly off course. Whatever promise EJB showed early on, EJB 2.0 and 2.1 had massively complex APIs that made them nearly unusable. These APIs weren’t driven by developers and what they wanted, but by corporate partners and what they thought they needed: software platforms that could solve virtually any problem, while generating nice consulting fees. Clarity and simplicity weren’t virtues that counted for anything. On a number of occasions, Gosling said “Simple things should be simple” (or some variant thereof) from the JavaOne podium. That’s a focus Java has lost–and if you hear that slogan in the next year, you’ll probably hear it from David Heinemeier Hansson or someone else working with Ruby on Rails. Rails’ ActiveRecord succeeds where EJB 2.1 fails: ActiveRecord is simple, extremely capable, pleasant to use, and drives you to do better design work.

I don’t know whether greater involvement by the Open Source community could have kept EJB 2 from running off the rails (so to speak). The EJB 3 specification, which had much more input from the Open Source developers, is a huge improvement. Furthermore, EJB is just a start: everything from Swing to generic collection libraries needs to be revisited in this light. So here’s the challenge: now that Java has an open source license, will greater participation by the open source community help Java return to its roots in simplicity? Will more input from the open source community help to define a platform that’s
simpler and more developer-friendly? If so, then Sun’s announcement is not too late.

One final perspective: I develop an open-source application called JL with a userbase that’s small, but larger than I can count on one hand. I’ve gotten lots of emails thanking me, some free CDs (thanks, Normunds!), and very few problem reports. The issues come largely from people trying to run JL on a Linux distro that doesn’t include a JDK, and the story is always the same: the user found some strange out-of-date JVM (an fruity old Blackdown release, Japhar, or something like that) and installed it. And the answer is always the same: download the JDK or JRE from Sun or from IBM. “Write Once, Run Anywhere” is a good thing–and it’s true, it’s really true. I’ve only once had to fix a cross-platform bug, and that was years ago. I don’t understand why anyone would write platform-specific software: I’ve got Macs, Windows, Linux (and even an ancient Solaris box) at home, and I want anything I write to run on all of them. But “Write Once Run Anywhere” only works if Java–and I mean a good Java–is everywhere. Sun’s announcement may be late, but it’s not too late: a truly open Java can be everywhere, in a way that the current JRE is not.

Open Source Java was inevitable, but it took a long time to come about. It’s finally here. Thanks again to all the people at Sun, and elsewhere, who made it happen.

I have no idea how they managed to get an interview lined up in the frantic hours before Sun’s announcement of its GPL Java plans, but the Java Posse got a podcast up within minutes of the announcement.

Well, Tim waited a whole 10 minutes to get his post up.

The rest of the story today is HotSpot and JavaC are getting released now. Early next year Sun expects to have a fully buildable JDK available. The response to everyone’s question: Why? Because Sun hopes the GPL will drive adoption, and I think that is a pretty safe bet. It will be nice to see a real JDK and Glassfish show up in the more purist Linux distros. The thing I can’t help but think, though, is this is the biggest boon to RedHat, who now gets to put all of their top-shelf products into Fedora again — lets face it, the LDAP server is nice, but JBoss is better.

It will be offered under multiple licenses, which means the contributor agreement hell is still there. It also means that Sun can’t scrape (L)GPL code of the interwebs and bundle it with the JRE, which is still kind of a shame. I do agree with Tim, though. I expect forks, but not “serious” forks. As I mentioned in the previous post, I think there is a serious opportunity here for aftermarket JRE’s with things like jSDL and libLAME/Tritonous, possibly even things like GCJ — which will surely get a huge boost from this as they can now start cannibalizing the core code — and SWT built it.

One thing I think Sun is going to find with the GPL — like QT before it — is it is never going to get the “stink” off of Java with large swaths of the Linux community. Much like *cough* certain political pundits, they have spent so many years talking about Java in particular tones, they are never going to bring themselves to admit that their issues have been addressed. On the other side of the fence, the “viral” FUD on the GPL is going to get dialed up a notch. In short, I don’t expect Sun to win too many friends with this move in the short term. I do think it is a good move for the long term health of the platform though.

Well, honestly, when I posted this a few months ago, I didn’t actually think the GPL was seriously on the table, but CRN/CMP is reporting (via /.) that Java is set to be released under the FSF’s license, with other products from Sun to move that way:

The company is very close to announcing that it will put the mobile (ME) and standard (SE) editions of the Java platform into the GNU General Public License (GPL), with the Java Enterprise Edition and GlassFish reference implementation (currently open-sourced under Sun’s Common Development and Distribution License, or CDDL) to follow, several industry sources said.

The OpenSolaris operating system will continue to be offered under the CDDL, according to several sources. The news could come as early as next week, they said.

The GPL is an intriguing and controversial choice. By requiring derivative works to also be released as open source, the GPL discourages commercial forking — a consequence that fits well with Sun’s stated goal of preserving Java’s cross-platform compatibility. However, a GPL license would require those making changes to the core Java platform to freely release their code.

Again, I think the GPL is likely a better fit for their goals and concerns as a business than CDDL. Still, I wonder what licensees will think about this move.

Back in the dark days when World War III threatened us with imminent nuclear oblivion, we were told that cockroaches and other insects were the highest form of life that would survive. I’ve recently come to the conclusion that SQL programs, like cockroaches, will surive anything that the IT world can throw at them.

SQL is a way of getting useful information from databases ,like ‘get me all Bank Customers with an account balances greater than 10,000 Euro’. It’s been around since the stone age and it is strongly suspected that the ancient Egyptians were familar with it’s earlier forms. Given that at least part of most systems talk to a database, it is probably the most widely used programming language in the world. It’s the most widely used because it’s the most useful : do one thing and do one thing well.

However, you get into trouble when you use SQL in ways nature never intended. Once you step beyond the ‘get me this’ or ‘update that’ you’re in trouble. Like a 12m high cockroach from a 1950’s Horror Movie, your code is out of control. Even Oracle are migrating to a Java stack to implement business logic outside of the core database engine.

More in Technology in Plain English

Just a short rant here…

I was looking at This post at j.n about JSR-262 and exposing MBeans as ws-Management SOAP services. All in all, it is a good idea, and seems like a dunk in the water a no-brainer that people would want this functionality, and it follows well with the trend of mapping Java APIs (javax.transaction) to their ws-* equivalents (ws-AtomicTransaction). Bully on!

What stood out in my mind was the URI scheme used:

service:jmx:ws://blah:8888/blah

for SOAP vs

service:jmx:rmi://blah:1099/blah

for RMI.

What am I getting at? “service:jmx:ws:” is stupid. While service:jmx:http: might seem a little non-specific, why not service:jmx:ws:http:? Specifying an on-top-of-something-else application definition in a URI is all well and good, but “ws” is (a) a bad designator, “soap” would be better, and (b) doesn’t offer any alternative protocols. You can run SOAP over any old thing, and people do. While service:jmx:ws:mailto: might seem like overkill for this particular application, what about service:jmx:ws:https? Seems like that is a pretty common thing people might want to do, don’t cha know.

This isn’t the first time I have seen stuff like this. It started with people using feed:// as a schema space for RSS/Atom feed, replacing https:// so they could map URIs out to the browser. Fortunately, later evolutions of this came to use feed:// and feed:https:// interchangeably. Apple gave us the “pcast://” and “.pcast” duopoly for podcasts into iTunes. The interesting thing here, is the .pcast file on Windows is better than what they offer (well supported anyway) with the pcast:// URLs on the Mac, since I can put a .pcast file on an https:// server, and embed a link to an https:// server in the file. There is no pcasts:// protocol definition. Simply using pcast:https:// would have worked just fine, but nobody seemed to want to stop and think about that.

It is not as though people in the Java world are unaccustomed to long URI schemes. I can’t count the number of times I have put jdbc:oracle:thin: into a text file, but hey, unlike jdbc:mysql: oracle has 2 underlying access methods, so they add another layer. Just seems like using ..ws: as the last part of that URI is like restricting jdbc: to one sub-schema. In the best of all possible worlds, shouldn’t it just be specific enough to indicate that “I pass the rest of this to JAX-WS” and move forward, letting JAX-WS take care of the next protocol level with whatever it’s native or available support method is?

The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.

Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’

On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’

So , how do you merge Agile with an upfront design process? It’s easier than you think.

Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.

Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.

Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.

More in Technology in Plain English

Reading this interview with Jean Elliott, director of product marketing for the Java SE platform at Sun Microsystems, got me into thinking about adoption of Java platform editions among developers (and plain users). I think that 1.4 is still very widely deployed runtime environment out there and that it is the main reason why many developers still hesitate to use Java 5 syntax and features in their projects.

There are three kinds of projects that we can differentiate:

• applications developed for the managed environments
• applications developed for unknown (potentially large) customer base
• and libraries developed to be used in other Java applications

In the first case there is no restriction for the development team and their management to make an appropriate case study and upgrade their development and runtime environments. This is well documented in Wall-Mart’s case (mentioned even in Jean’s interview).

In other two cases, this issue becomes even more important because you don’t want to restrict yourself by limiting number of hosts (projects) your code is compatible with.
But existence of Retrotranslator (and Retroweaver) project makes this excuse obsolete.

Retrotranlator is a

Java bytecode transformer that translates Java classes compiled with JDK 5.0 into classes that can be run on JVM 1.4

which basically means that you can very easily make all of your Java 5 code compatible with JVM 1.4. Retrotranslator even offers Ant and Maven tasks that are very easy to use. So there is no reason why you shouldn’t modify your build process to create distributions for both platform editions. Of course, there are some limitations introduced in this process, so additional testing is required.

I think that this is very important topic for wide range of Java projects and that would be great to see Sun back a project like this one.