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 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."
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
- 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
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
Archives and Subscriptions: This blog is delivered weekdays as
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 href="http://today.java.net/today/archive/">java.net Archive.
A mobile Java pipe-dream might be coming true