2006 JavaOne Conference - Fireside Chat - Exploring the Power of Java

Alumni Fireside Chat Participants
Hal Stern, Co-Chief Technology Officer for Software
James Gosling, Vice President and Sun Fellow
Graham Hamilton, Vice President and Sun Fellow in the Java Platform Group
Jeff Jackson, Senior Vice President, Java Enterprise Platforms and Developer Products
Mark Hapner, Distinguished Engineer, Chief Web Services Strategist
Larry Rau, Architect of Mobility

The seventh annual Alumni Fireside Chat, held from 5:30 to 7:00 PM on a breezy San Francisco Monday, May 15, 2006, at the JavaOne Conference, offered a playful, candid, and at times vigorous exchange of ideas between several Sun Microsystems' Java technology luminaries and some spirited and at times confrontational JavaOne Conference Alumni. Hal Stern, the co-chief technology officer for software at Sun, hosted the event, with approximately 400 alumni in attendance. The scene surrounding the panel was strong on atmospherics, with lanterns, cricket sounds, a makeshift campfire, evergreens and slides of mountain sunsets.

After brief introductions, the Chat moved through non-stop questions and answers. The discussion topics meandered from slow applet downloads, to deprecations that never quite disappear, the significance of Jini technology, problems with JAX-B 2.0 (Java API for XML Binding), the problems of formatting source code, the future of AJAX, and more...

Slow Applet Downloads

The first questioner complained that many people find in downloading applets that the Java Runtime Environment (JRE) is too big. He asked if Sun had considered doing a "Java web edition, or browser edition, or some other edition," to address this. Graham Hamilton responded that they have examined a variety of options. "We want a platform where people can use things like Swing and rely on it being there," said Hamilton. "Creating new sub-varieties or subsets of the Java platform seems like a dangerous route to take. We are trying to get more distribution and are working with PC OEM vendors and other channels to get Java software out to people."

James Gosling remarked on the number of times this problem has been considered. One option is to try to take the definition out of the JRE and pare it down -- but it is simply not feasible, according to Gosling. Another option is to have some magic downloading in the background and slowly move things in -- but repeated experiments with this have not been very fruitful. "We've done this evaluation pretty regularly," concluded Gosling, "and it's one of those 'get over it' kind of things."

SOA, ESB and Jini Technology

A questioner remarked about the ubiquity of such buzz words as SOA (Service Oriented Architecture) and ESB (Enterprise Service Bus) and grid technology that seem to be enabled by Jini technology, which appears not to be at the core of Sun's strategy. "Outside of RFID, I can't think of much Sun technology that actually uses Jini," he remarked

Mark Hapner responded that Sun is talking a lot at this year's JavaOne Conference about Microsoft interoperability and Web Services Interoperability Technology (WSIT). Sun is, through WSIT, extending the Java platform through global computing collaborative technologies. "Jini technology," remarked Hapner, "is an interesting technology with some interesting applications, but in the broader interoperability space, we cannot rely on having Java technology on both sides of the wire. Our focus is more on ensuring that we have a good interoperable distributed computing infrastructure in the Java platform, because that is a core building block in SOA and ESB at that level of collaboration between applications."

Superior Cell Phones in Asia and Europe

One questioner initiated a discussion of the superior cell phone technology in Asia and Europe and the challenges of Java Platform, Micro Edition (Java ME) implementation in the North American market. Larry Rau commented on the number of players in the mobile space that must be satisfied. "The bulk of phones do support Java ME -- it's a matter of getting the whole ecosystem set up so that we can enable more of that," said Rau. "I think it's going to go that way. The good thing is we have the base support in all of the phone and a lot of industry momentum around Java ME."

Gosling pointed out that more cooperation is needed in the infrastructure. "We've built a lot of tools that make it easy to build MIDP 1.0 or MIDP 2.0 apps but the whole deployment picture in North America is bad," observed Gosling. "It's rather tragic when you visit Asia and Europe and see how much better their phone systems work, particularly in relation to MIDP applications."

Gosling explained that in Europe and Asia, "They tend not to block ports, they tend to charge sensible amounts for traffic so billing is better. Some places have good bandwidth, some make it a lot easier for you. In Japan, what made things explode for DTT DoCoMo was that they set up a service where two guys and a dog could write something, drop it down on a DoCoMo server and then people could upload it from DoCoMo, and they would not only host it but deal with all the billing and you could actually make money from it. And making a dime a copy for a little game, you could get rich pretty fast. It worked well economically. In a lot of places, it's not so much that one infrastructure is better but that at least it's consistent. The US has some ungodly number of cell phone infrastructures that are kind of similar and kind of not. If you go to Spain, they have a rule that all cell phones must support Java ME, so government services can actually depend on it working everywhere. The networks all are required to support MIDP 2 networking, so it's not so complicated."

Raul agreed that Japan's NTT DoCoMo "did a great job setting up the whole ecosystem and Europe has done a great job getting Java technology on phones and pushing for data usage. The US is getting there, but different networks are causing problems."

Not Meaning to Deprecate

The biggest laugh of the evening came when an alumnus asked, "When an API element is marked 'deprecated' will it ever be removed from the Java API or will it just sit there?"

James Gosling quipped that he lies awake fantasizing about deleting deprecated elements of APIs. Graham Hamilton remarked that removing deprecated elements can break existing apps for developers. "In practice," said Hamilton, "we are not going to break even a 1.1 app. So we're sort of stuck with them even though it would be nice to be rid of them."

Gosling chimed in that most deprecations are warts, and not real problems. He plugged the NetBeans tool, Jackpot, available as a plug-in in pre-release. "Jackpot is a rather funky refactoring tool that lets you define your own refactorings," Gosling explained. "...You can get rid of all implications of deprecated methods, and get rid of all the deprecation warnings. One of my deprecation fantasies is to get everyone to use Jackpot, because it will automatically get rid of all of your use of deprecated methods and correctly fix them. Once people do that, it will probably be safe for us to do something a little more dramatic with deprecations."

Anyone for Source Code Reformatting?

Someone griped about whether Sun was ever going to do any source code reformatting for the APIs since most of the classes use a very inconsistent format, with some declaring the variable at the end, some at the top, and some in the middle, leaving no one able to decide from class to class which one to use.

Hamilton clarified that the complaint was not about the public API that shows up in javadocs, but the source code, and then said, "I confess all. If you want to move stuff around in the source code, you will have to code review and queuing will be involved, because when you touch source code we treat it as a very big deal. When people move source code around, accidents occur. People make what they think are completely safe changes and break something and queue it, and we have the massacre of the innocents." Hamilton described the culture he works in as one in which, because of the risks involved, changing source code is not done unless there's a clear payoff. When it comes to source code, he described himself as "on the paranoid side."

Jeff Jackson countered that he is more on the "unparanoid side." "We seesaw back and forth on this all the time, trying to reach a happy medium regarding how fast we can clean up source code while testing it to maintain the level of quality," said Jackson.

Hamilton responded: "We will make a release and a product team will tell us that an area is buggy, and that they would like to write it from scratch to improve it. And they mean it and believe it!" he emphasized. "But the track record is that when you let someone rewrite an area, the new code may be better and clearer, but, somehow old apps don't quite run correctly any more."

Jackson insisted that Hamilton's observation, "has to be balanced with how well the test code runs, how good your coverage is, how well the unit testing is done, and how well you do the actual inspection of the code. So there is balance back and forth; there is no excuse for not engineering it the right way."

Java Developers Around the World

Someone enquired about the size and vibrancy of other developer groups around the world compared to the JavaOne Conference in San Francisco. Gosling, who has gone to four Tech Days he described as "mini JavaOne Conferences", around the world in the last year, remarked that, "There are really great developer communities everywhere. The last one I did was in Johannesburg, South Africa, where they have some really sharp Java developers. An interesting thing about software development is that they are all globally connected on the web. There is one culture around the world. When you meet a really good developer in St. Petersburg or Sao Paolo, they all seem similar in a lot of ways. There's not one place where there are 'the best.' It's pretty uniform around the world." Gosling said that around the world, when developers get into code, any cultural differences appear to evaporate.

The Future of AJAX

An alumnus asked what Sun is doing regarding AJAX. Hamilton observed that there are several different ways people want to use AJAX. Some want to hand code JavaScript that runs in the browsers and make sure that technologies like JavaServer Pages (JSP) can easily generate Ajax content. "Writing JavaScript that runs in the browser is a bit of an adventure at the moment," said Hamilton. "Another approach is to use a higher level component technology like JavaServer Faces (JSF). One way to go with JSF is to make it easy to create AJAX-aware JSF components. So relatively expert people create interesting GUI components and use JavaScript, AJAX internally, and a whole bunch of the rest of us can reuse these high level AJAX-aware components. Then we can use tools like Sun Java Studio Creator to drag and drop our JSF components. That application runs within the Java web tier and projects AJAX components out to the client side."

Hamilton's biggest concern is the ongoing fragmentation of AJAX, with lots of new Ajax toolkits appearing. "I would like for there to be two or three AJAX toolkits in two years' time and not 20 or 30. We are in an early phase of AJAX adoption. I hope it settles down," he concluded.

A developer asked if there are any plans to update the bean API. Hamilton said that there will be an update to Java Beans as part of Dolphin with better support for defining design time attributes for Java Beans. And it will be easier to tie together properties for different beans.

In a comment that summed up the essence of the evening, Gosling gave this call to action: "If you have any great ideas, talk to us please. We'd love suggestions."