Skip to main content

Give Me The Cure

Posted by editor on January 24, 2008 at 6:26 AM PST

How do we reconcile small ME developers and big mobile carriers?

Day one of the
Mobile & Embedded Developer Days conference has come and gone in a flurry of presentations, poster talks, conversations and tacos, the latter being from a well-attended offsite social event that concluded the long day. The nature of the conference has been an interesting mix: it's still mostly based on eyes-forward presentations from acknowledged experts, but it has a loose, informal, and even personal feel. It's a nice mix, avoiding the stuffiness that you sometimes get at JavaOne, and the mob rule that an unconference can devolve into. The size helps too: enough people to stay interesting, but not so many that everyone else becomes anonymous. Roger and Terrance might be on to something really good here.

Don't feel like you're missing out, though. The conference's live broadcast is available on With a Flash-capable browser, you can watch today's sessions live.


Sean O'Sullivan presenting "Past, Present, and Future of JSR 82 (Java Bluetooth APIs)" on Wednesday at ME Developer Days

You can also participate in a real-time chat with other on-site and off-site attendees, and many of the sessions are taking questions from off-site participants during their Q&A time. You can follow along with the talks by downloading their slides from the sessions list.

One of the major themes that has come up in sessions and Q&A is the long-acknowledged but little discussed disconnect between the developer's view of the mobile world and the carriers'. You may be able to develop a nifty application with the various APIs available to mobile Java developers, but then what? There are somewhere between 800 and 1,000 phones you may want to run it on, and getting your app signed to use some of those APIs may be limited by the handset manufacturer and/or the carrier, and how they manage access to their platform.

A panel at the end of the day yesterday addressed this conflict, positing a hypothetical developer of a "cool app" in front of a panel, whom he asked how he could get his application out to the public. If this were just a developer conference, the only point of view might well be grousing about carrier policies, but with marketing people from some of the carriers there, we got the full picture. And while as a developer you might not want to hear the answer, it's important to understand the real story: mobile and desktop are two different things, and the romanticized notion of the indie developer with the great app that everyone wants may just not be realistic in today's mobile world. Testing on hundreds of devices and joining carrier programs (to get your app signed or even pre-installed) takes serious money, and the "cold, hard truth" feedback from some of the panelists was to ask: "do you want to go big time, or are you just playing around?" If you want to make it big, then maybe you need to think about finding a publisher, someone who will open doors with carriers. Or maybe you need to develop your app in the context of a company that can provide the resources to pay for testing your app on hundreds of phones.

Having said all that, the mobile world is being profoundly challenged by disruptive new entrants, such as the iPhone and the Open Handset Alliance, so things may change. And if developers want change, the panel said that they need to organize around a simple message: many developers vaguely grumbling about similar issues won't accomplish as much as a small, highly-motivated group with very specific desires and a plan to get them.

So, there's your controversy and devil's advocacy for day one. Today, the sessions include Java FX Mobile development, gaming, mapping, databases and more. Tune in to the broadcast and join us for Day Two.

In Java Today, we focus on some of the projects spotlighted at Mobile & Embedded Developer Days.
Open-sourced yesterday, Squawk is the JVM that powers Sun SPOTs, which use Java "on the metal" (rather than atop an operating system). "Squawk is an open source virtual machine for the Java language that examines better ways of building virtual machines. Most commercial virtual machines are written in low level languages such as C and assembler. We believe that virtual machines can be simplified by writing them in a higher level language, and further simplified by implementing the VM in the language that the VM is implementing."

The Marge project is a framework to simplify development of Bluetooth applications for Java ME or SE. "The main idea of this project is to facilitate the use of JSR 82 (Java APIs for Bluetooth), because this API is quite complex to people that does not know a lot about Bluetooth. So, the framework will abstract things related to the Bluetooth communication: connections, protocols, messages exchages, inquirying for devices and searching for services."

In today's Weblogs, Sean Sheedy blogs from MEDD about SunSPOTs and ham radio.
"This week I drove from San Diego to get to the MEDD conference and used ham radio's APRS to track my position - SunSPOTs could be a really cool addition to this space."

Bruce Boyes reports from the conference in
MEDD Exceeding My Expectations.
"End of one day of the Mobile & Embedded Developer Days, and still one to go, and my expectations are more than met."

Finally, in
Disabling Swing Containers, the final solution, Alexander Potochkin offers
"the elegant and effective solution for disabling Swing containers, the correct implementation of the locking GlassPane included."

In today's Forums,
whartung asks
Why are Remote method calls so expensive?
"I have a Remote EJB, and a WAR callig it. The WAR and EJB are in the same container, but the WAR is not in the EJBs EAR, so it needs to be a remote call. The result of the call is large -- a List of 2000+ items. Thankfully, this is cached in the client WAR, but we need to do this one time load. But when the method returns the resulting list, my heap SURGES over 200M for this single call. I added a little blurb of code that simply writes the List out to a file via an ObjectOutputStream, and the final file is ~1.6M in size. Now, all of that 200M in the surge is garbage, but it's some big garbage. If I reduce my heap size, this call will give me an Out of Memory exception, so whatever it is doing with that memory, it's doing it all at once."

wmeissner points to a video player component as an example of speedy Swing in Re: Swing performance on Linux.
"If you want a (admittedly somewhat convoluted) example of displaying video into a lightweight component at decent speed on a 1.4+ jvm, have a look at gstreamer-java project's As Dmitri suggested, it paints the RGB data directly into a BufferedImage (so saving a copy), but it also then draws that BufferedImage into a VolatileImage, so scaling can be accelerated by e.g. the OpenGL pipeline. Without this step, rendering with the opengl pipeline enabled drops to around 0.5fps. It also keeps a pool of BufferedImages for the rendering stage, so the garbage collector doesn't get hammered - which can also be a huge CPU hog when rendering video."

Finally, vralev discusses how to use JSLEE in
Re: Mobicents Sip-Servlets 0.1 Released.
The way I see it is that you will want to use the features easily done in sip servlets like authentication and web context sharing as a front end and then proxy requests to the JSLEE app to play media or other JSLEE service. For example - configure your SIP client to use a sip servlet as a proxy. This sip servlet can require authentication. If the auth succeeds, you can register it in the servlet context or the session context so that the status of this call can be displayed in a web page. After that you can proxy the request to the JSLEE stack where a voicemail/conference JSLEE app will establish the call.

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

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 it will be
archived along with other past issues in the href=""> Archive.

How do we reconcile small ME developers and big mobile carriers?


You asked: "How do we reconcile small ME developers and big mobile carriers?" Answer: The RIM BlackBerry certificate model. A 1 time fee A tool that signs the jar by checking with a master server (additionally) Master Server records your app, and applies a MD5Sum for user download authentication. Then Operators need to provide JSR implementations that match the spec. (No more excuses "we interpreted the spec differently") We have the API JavaDoc, we have the JSR Spec, and we know what it is to do. "Interpreting" it differently is just an excuse for device lock-in. If operators/phone Manufacturers want to be "different" make it easy for software developers to deploy to your device. That would surely be different. PC's didn't become mainstream until FreeWare, ShareWare and small developers started focusing on a easy to program device. The Web didn't pick up until it was easy to setup a webserver and tools to create systems easily (like PHP, Python, Java) came along.

Hello! Thanks for spotlighting Marge! We are working in a new version that will be available soon. Cheers, Bruno Ghisi