The time on my room's alarm clock was an hour ahead, I found out this morning. So, I ended up back at the Mascone this morning around 6:40AM. Nothing too wrong with that: the empty halls are a refreshing calm from the busyness of yesterday.
(As I side note, it's interesting to see the difficult line-walking between IBM and Eclipse in that press release. Notice that it's an IBM keynote all about Eclipse dev practices. Nothing wrong with that on my end, but it's little wonder that people conflate the two so much.)
Press/Analyst
This year, unlike the last time I attended, my badge is red and says in bold white type, "PRESS/ANALYST." The net result of this is spending more time talking with loads of Sun folks on many non-Java topics:
Sun is consistently a fascinating company because they have so much going on. I'm sure orchestrating all that fascination is nightmarish, but it makes for a great pool of content, technologies, and ideas to suck content from.
Java Developers
While Sun has matured itself quite a bit over the past few years, the Java developer community itself has grown up and moved out of the house. Java developers suffered through EJBs and found the cure in simpler, non-Sun or vendor provided methods of development like Spring. Once out from under mom and dad's control, the kids weren't afraid to to work for a new boss either, JBoss.
That is, the Java developer community stands on it's own, apart from the care, feeding, and guidance of Sun and the JCP. Indeed, many of the aspects of JEE are an attempt to get the kids to call home more often.
From what I've seen over the past few years and the conversations I've had with Java developers, my feel is that the driving force behind the evolution of Java has passed from the vendor's hands to the developer's. The difficult part is that the two are only now starting to work together instead of being all Norman Rockwell and cooperating. See Rod Johnson on a BEA panel is still somewhat weird, but is getting less so. There's still the forked energy spent on maintaining two IDEs, but I see less and less of Sun and the other Java vendors trying to dictate what the Java community should do.
Dynamic Languages
The ultimate proof-point of this leadership transition is the conversation around dynamic languages in Java and the official Java party line that will emerge. It's clear to me that what developers want are access to dynamic languages in the Java world sometime around yesterday. Java developers can't stand for the LAMP and Rails people lording over them too long, and the usual counter-arguments aren't working out so well. Instead of dismissing dynamic languages, the real solution is to assimilate them into Java.
People we've talk with so here don't immediately dismiss adding addressing this dynamic language issue in Java, but it's been apparent so far that it hasn't been high on the priority list for sometime. Granted, Sun is a massive company, and massive anythings are slow to react to something as quick and "small" as dynamic languages. Others, of course, given the power and time would ram dynamic languages into the VM as quickly as possible, as well as burn all the WS-* specs they could find ;>
Sure, work is being done to address the dynamic language issue, but at that very slow JCP pace that drives me and other Java developers crazy. We've had JRuby, JPython, and Rhino for a long time. Why do we need to wait for all the JSR implementations to finally ship in Java?
Addressing that slow reaction is the prime example of how mature the Java developer community has become. Instead of whining about how slow innovation in the core Java stack was happening, developers took ownership of the problem and wrote their own libraries and frameworks to address it. Mom and dad could sort out their reaction to it later.
While other developers left all together, the bulk of the Java developers have displayed a deep loyalty to the platform. It's easy to be loyal to something that you feel you own and control, which is a solid lesson for any vendor building an ecosystem.
Never Mind IBM Forking Java...
In my mind, as discussions for open sourcing Java emerge again, this loyalty and ownership offer the real forking danger for Java. People against open sourcing Java freak out about the likes of IBM forking the Java code base, creating two Javas and de-standardizing Java. I don't really buy the idea of a vendor forking Java, but I am beginning to think that the Java developer community itself would very quickly take to forking Java if the pace of Java evolution became too slow.
A developer fork (or forks) of Java would be much more difficult to deal with than a vendor-fork. You can sue a vendor, or, more likely, make them freak out by sending a cease and desist letter about labeling their fork "Java." But developers could give a rats ass about that. They'll change the name from the get go.
What this means is that along with open sourcing Java, Sun needs to speed up the pace at which it pulls features into Java. Indeed, my theory is that this fact is the real fear of open sourcing Java: Sun will have to start accepting features and code from the Java developer community (more work), or face a developer fork because they haven't truly open sourced Java.
Of all the large companies I've gotten cozy with over the last 3-4 months in the RedMonk gig, Sun is the best positioned both culturally and technologically to handle this situation. While Sun has the typical in-fighting and politics of any large, mature companies, the people I talk to in the middle are extremely enthusiastic and hopeful around open source, most recently, the identity folks. The challenge will be moving the relationship between Sun and the Java developer community from parent-child to a partnership, which means letting the developers drive much more often.
Previous Topic
