Editor's Daily Blog

All This I've Done For You

A mobile Java pipe-dream might be coming true

Nobody's objective, nobody can be opinion-free, even those of us who are paid to be, and that's a good thing. It's better to have writers and editors who care enough to have opinions, than to have HTML-reformatting PR-bots who don't know awesome from awful, even if that means that I can't possibly agree with every reader every time. I think I generally do a good job of squaring the POV and setting my opinions aside -- has anyone been able to tell that I hate generics and still compile my code with -source 1.4 -target 1.4 ? -- but clearly, there will still be a bias exposed in what does or doesn't make the cut for the front page. Or, for the purposes of this blog, what gets included as a choice in a java.net poll.

Go back a couple months, right after the M&E Developer Days and the discussions that came from it about how hard the carriers and handset makers make life for developers, when our poll asked "Who could do the most to end Java ME fragmentation?" Few noticed and fewer voted for the choice "competitors". But after putting it in the poll, I was one of the nine people who voted for it.

Here's the story behind that option: this was when Apple had announced it would release a "real" SDK for the iPhone, but details were still a month away. I had allowed myself to hope that Apple's offering would be enough of a game-changer to challenge the locked-down mindset of the current mobile software world, in which indie and niche-topic software developers have effectively no chance of getting their software onto ME and other mobile devices. I argue this is one kind of "fragmentation": aside from the technical differences between various ME devices, mobile software developers also have to deal with different levels of resistance (and some outright prohibitions) in signing their apps for different carriers' devices. Many in the poll thought that this was Sun's problem to fix, a point that that Terrence Barr implicitly rejects in a very interesting forum post from last month, in which he writes:

The problem is that what is happening in this space is that some (not all) device manufacturers and operators are using security mechanism to impose business models on developers.

So, like I said, back then, I was secretly hoping that whatever Apple did, it would cause enough pain to the current carriers that they'd have to open up their software platforms, or watch their users defect to an entirely different platform.

Total pipe dream.

Except that it looks like that might be happening.

In an item picked up by the Washington Post and Slashdot, mocoNews.net reports that T-Mobile USA Will Ditch The Traditional Deck To Mirror Apple's App Store.

Starting this fall, T-Mobile USA will take the extraordinary step of ditching its traditional deck on the phone and replacing it with a platform that’s open to almost any developer, multiple sources have told us. Think of Apple’s App store, but for the entire carrier’s handset line-up from smartphone to feature phone. As one developer, who was briefed on the matter, said: “The App store was a big deal, but that’s one phone. This is an entire carrier.” In other words, we are talking about T-Mobile’s 31.5 million subscribers today vs. the 10 million iPhones Apple expects to sell by year-end (granted, the iPhone users tend to be more engaged as early adopters). The impact of this move by T-Mobile could set off a wave of changes in the industry, as other carriers feel pressure to offer new applications on their networks. Clearly, for this to happen, T-Mobile will have to follow through on its promises to encourage developers to participate.

mocoNews' source says developers will submit applications online and get a revenue-sharing agreement with T-Mobile based on network use. All T-Mobile's platforms will reportedly be available to developers, including Java and Android. T-Mobile declined to address the report's specifics, but advised developers to "stay tuned" to its devPartner Community site.

If this report is anywhere close to accurate -- do take it with a grain of salt and notice the sourcing to a handful of developers, though also note T-Mobile's non-contradictory reply -- it could be a revolution if Java ME developers of many sizes and pursuits can actually find a market for their software, one that has previously been closed off by T-Mobile and the other carriers.

Acknowledging again my bias, I personally think this could be the most important Java story this year. We'll obviously be watching to see if this pans out as reported, and if other carriers follow suit.

Of course, there's still the technical fragmentation issue: it's hard to test your ME app on hundreds, or even thousands of handsets. The mocoNews article notes that T-Mobile has partnered with DeviceAnywhere, and in a happy coincidence, the company also has just announced a special deal for NetBeans users, as noted in the Java Today section. To celebrate the success of its integration with NetBeans, DeviceAnywhere is doubling its free trial, from five to 10 hours. "DeviceAnywhere's one-of-a-kind testing, monitoring, porting and deployment solutions provides mobile developers with remote access 1500 real mobile devices worldwide - facilitating faster time-to-market in a cost-effective, pay-as-you-go model." Through this extended free trial, NetBeans users can remotely perform all testing on real devices - from the convenience of their own desktops.

Moving over to the desktop, we note that Josh Marinacci's latest blog on javafx.com: API Documentation: the Overlooked Little Brother of Programming Tools, in which he reveals that the recently released JavaFX Preview SDK includes a next-generation documentation tool, javafxdoc. "So what makes it awesome? It could be all of the new GUI goodness we added like the accordion control and javascript animation, but those are secondary to the really cool thing: we built it to be future proof. Unlike javadoc, javafxdoc doesn't directly produce HTML at all. Instead it generates a large XML file which is fed into a second transformation step. This transformation currently produces the semantic & strict XHTML you see today, but in the future we could generate PDFs instead. Or a mobile phone version. Or push it into a database for searching and annotation. Or something else no one has thought of yet."

Speaking of future-proofing, today's Weblogs begin with a strategy from Tim Boudreau in The Capability Pattern - Future-Proof Your APIs. "Here is a simple pattern which you can use to make your APIs extensible, even by third parties, without sacrificing your ability to keep backward compatibility."

Gary S. Weaver post a warning in java.protocol.handler.pkgs Strikes Back. "Look out for uses of System Property java.protocol.handler.pkgs in the applications you use. It could be trouble in Java 1.4+."

Finally, in Metro SOAP and REST Web Service JavaOne 2008 presentations online, Harold Carr announces, "Metro SOAP and REST Web Service presentation slides, video and audio from JavaOne 2008 are available online in the areas of Java and .NET 3.x interop; other ways to interop between Java and .NET; overviews of Metro and Jersey; using REST. If you missed these sessions or want to see them again, I've provided links, presenters and abstracts. Enjoy!"

In today's Forums, john_t wonders about an apparent upper memory limit to vmem cached images with direct3d pipeline? "I'm working on a touchscreen interactive for an australian museum. the project uses a number of historical and modern panoramic images running across two 30" displays (5120x1600 total pixels). i'm using the scene graph project to load in multiple huge images (max 26,300x1600 pixels (i've spilt these into 1024x1600 tiles)) and to allow the user to scroll and zoom around them. its all working very well. it's very impressive watching images of this size smoothly scroll and zoom with subpixel positioning and virtually no CPU usage. obviously the accelerated pipelines are working very well! I was running this on a nvidia 8800GT 512MB, however as the number of images has increased it gets to a point where some of the images are no longer accelerated (which is painfully obvious). so i recently upgraded to a GTX280 1GB. when the program is running with the direct3d pipeline there still seems to be the same limit (in terms of number of images) as the 512MB card. whereas running with the opengl pipeline allows approximately twice as many images. so it would seem that there is some sort of hard coded limit with the direct3d pipeline. is this a limitation with direct3d itself or with the pipeline?"

With a very different opinion about performance, demonduck is deeply critical of the current state of Java SE 6 Update 10 in the reply Re: 6u10 Post-Beta Survey. "You are considering 6u10_b28 as a release candidate -- to coin a phrase, "...you can't be serious..." There are so many things wrong with 1.6u10 that I'm amazed that you would even consider it a release candidate."

Finally, egon_olsen is trying to figure out the nitty-gritty of Horizontal Sizing of Custom Component. "I am trying to write a custom Component that expands horizontally, i.e. uses as much horizontal space as the Layout Manager is willing to give but only so much that horizontal padding and margins still occur. Overwriting calcPreferredSize and setSize is not enough, though. If I let calcPreferredSize return a width larger than the Display then setSize still does not get called with a smaller value for width. Is there another method I have to overwrite?"

Current and upcoming Java Events :

• August 11-15 - Struts Training Philippines
• August 15-17 - Southern California Software Symposium 2008
• August 15-17 - Southern Ohio Software Symposium 2008
• August 18-22 - J2EE Training Philippines
• August 22-24 - Central Florida Software Symposium 2008
• August 25-28 - Dev Week India 2008
• August 25-28 - Java Power Tools Bootcamp in Wellington
• September 12-14 - New England Software Symposium 2008: Fall Edition
• September 15-19 - Java Training Philippines
• September 19-21 - Pacific Northwest Software Symposium 2008: Fall Edition
• September 23-26 - Java Power Tools Bootcamp in Melbourne
• September 29-October 1 - The Ajax Experience
• September 29-October 2 - Java Power Tools Bootcamp in Sydney
• September 29-October 3 - JavaEE Training Philippines

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Comments

• 
  Well we can hope that the store front t-mobile is (might be) thinking of is for JavaME. However with more companies choosing to move to Android, RIM, and WinMO, one has to wonder if JavaME will exist in a few years. Much like the glaciers, both in it's progress and in it steady disappearance from the landscape, one has to wonder could the change be from a common code base language like java to something more interesting and feature rich.

  We are still on MIDP2.0 (JSR-118) which had a final release on Nov 20, 2002.
  Nokia is supporting Android, and working to integrate Symbian with it, nokia being the notable leader in the promotion of JavaME in the first place, and now supporting a competitive product.

  As I have been saying for a while now, something need to be done to build up the excitement and commitment to JavaME, and it would make since for Sun to lead that. If not Sun then the developer community needs to step up with the Mobile Developer Alliance, however we have seen how that effort has been thrown to the wayside.

  -Shawn

  Posted by: sfitzjava on August 11, 2008 at 04:12 PM

This work is licensed under a Creative Commons License.