JavaOne day 0 - the issues Sun will do nothing about

A lot of interesting questions were asked at alumni-only fireside chat with Sun team today. I am only going to mention the questions Sun did not have a good story for.

• JVM on PDAs - Sun is pushing Java for Mobiles quite hard. Witness the support for SaveJe. This however is a difficult road especially in North America with vendor fragmentation and difficulties of implementing full multimedia/call-handling capabilities. A question was asked whether Sun would consider implementing JVM just a basic app environment for non-phone PDAs running Windows 2003/2005 and for phone PDAs but without full integration of call-capabilities (like IBM's j9, but better). The answer made it very clear that PDAs are not a target device by themselves and that phone integration is a goal, but only with full-functionality . I have a non-phone PDA and was hoping to have a good JVM for it, but it looks like I should just forget about it.
• Multimedia (JMF) API - This one is well and trully dead. Sun is happy for somebody else to develop an alternative reference implementation, but they are not putting any money into it themselves. The basic reason is that they think it will take too much effort to get JMF to really useful state and they are not interested in making it less than perfect. Apparently, there is now a project to do an open-source alternative implementation; let's hope it works out.
• Serial port/USB access - Serial port implementation is semi-dead and there is no USB implementation. Sun's response was that there is a JSR by IBM about USB access, but no further details or enthusiasm were forthcoming.
• Java hosting - the cost of java hosting is 10-15 times higher than hosting PHP apps. I have asked whether they knew why that might be and whether this is something Sun should pay attention to. The reply I got was that this is how capitalist market works and that maybe I should email Jonathan Schwartz about it. I might have mangled the question as the meaning I was aiming for was to see whether it was known what made Java hosting an expensive business - whether it was memory requirements, complicated versioning/classpath issues or something else. If I figure out a good way to phrase it, I will send an email to Jonathan and see what happens.
• JavaOne scheduler application suckage (my question again) - every year scheduler application gets better, but it never seems to be as good as current technologies make it possible. Turns out that Sun people don't use the scheduler themselves (duh!), so they don't actually know it sucks (or pretend that they don't). Well, they got crowd's feedback on that issue loud and clear (very loud). Hopefully (as suggested) the next year's scheduler will be a competition of some sort with the best version becoming an official one. James Gosling sort of volunteered for that one.
  
• Allowing JavaDocs to be published and remixed on 3rd party websites. This was a reference to several websites that a while ago put JavaDocs for official JDK packages together with JavaDocs for various open source software and allowed remixing/commenting/other social manipulations across all those APIs. Sun leaned heavily to have their API removed and I wanted to know whether that negative stance changed and/or whether they thought the legal/copyright issues really were more important than potential benefits of API presentation remix. Graham Hamilton answered that legal issues were quite important, but that JavaDoc will be much better in Java 6 and beyond. An answer, but not quite to the original question. He did add that maybe that issue should be revisited, but - as with other 'to be revisited' issues - I don't really expect them to remember the vague promises with all the other issues and pressures occuring during JavaOne.

There were many other good questions and answers and I am sure somebody will blog about them. These are just the issues that I think are difficult to pin Sun people down on usually and it is worth writing them down for future references, while the memory is strong.

BlogicBlogger Over and Out