Which changes over time; "Limited" or targeted device?

[scott irwin]

The current J2ME spec is targeted at �Limited� devices such as cell phones, pagers and so forth. Given technology is what it is, do you guys see the definition of �Limited� changing over time or phones running J2SE?
I�ll assume that �Limited� stays defined as is, basically, and that devices migrate up the specification hierarchy (i.e., MIDP -> CLDC -> J2SE). So where my phone is today (MIDP), my coffee cup is tomorrow.
Given that, could we see a �Limited� Container specification, which deals with a more robust lifecycle running on phones? Would we see the ability to route messages to PDAs and the container managing services on the device?
Will we see phones and PDAs running services, managed by a �Limited� Container, capable of staying resident and servicing incoming messages from the wireless network? Or can we do that today? I started thinking about what kind of applications could I develop and the term �Limited� seemed to fit.
Scott

[Mark Herschberg]

Yes, you are right that it is unlikely that Sun/JCP will be willing to change the definition of existing APIs, so devices will change, not the definition of limited.
There is a limited container specification CLDC, Connected Limited Device COnfiguration. Configurations sit above the kVM, but below a profile (profiles are built on configurations). The only other configuration is the CDC, Connected Device Configuration. It is unlikely there will be more anytime soon. Information on both can be found at the JavaSoft website.
In answer to your last question, we can sort of do that today. The issue you raise is not necessarily J2ME specific, but is common to all Java clients. Because Java isn't a true OS, it's programs are applications, and by default, not "always-on." There are tricks to get around this. As for J2ME specifically, I personally tink the JAM needs to be better defined so that application lifecycles can be better understood by developers, who can consequently make more robust applications.
--Mark

[Nizan Horsefield]

From an Enterprise Sys Eng view of things I can see the adoption of the Network Computing framework. All of the major wireless network providers are currently working to implement fast packet tranfer of data similar to what we are used to in networked companies. With this technology in place there will not be a great need for extensive computing on the remote device. The majority of computing will be server-side allowing J2EE to explode to provide the back end services for information propagation. Java is here and will provide us with the tools for shaping the future. It might not be looking in the right places, but I cannot see anything else that can replace what JAVA can do!
------------------
Nizan Horsefield
Sys Eng Internet Services
Citibank

[scott irwin]

Nizan,
Are the networks you speak of G3? If so, I guess we need to really keep our eye on other countries implementing G3 now for those killer wireless apps.
Mark,
So what's the trick? I wanted to develop a web service but I wanted to able to issue asynchronous messaging. Not too good if the app isn't running. Is there a way to route a message to the application?
Thanks,
Scott

[Nizan Horsefield]

Aye lad, 3G they are, or 2.5G in the far-east! With the launch of the new motorola i85 for the iDEN network http://www.techtv.com/superguides/mobilecomputing/mobilephones/story/0,23008,3319795,00.html we can see that it is nearly here, a J2ME app installed and running across a WGAN (Wireless Global Area Network). Nokia are launching Java Phones next year, so we too can create killer apps with J2ME.
Niz

[Mark Herschberg]

I'm not as optimistic as Nizan. I think it will be a few years before even 2.5G becomes widespread; and let's not forget the "legacy" of millions of non 2.5G phones! I suspect we'll still be using J2ME to compensate for lossy networks for a while. Besides, with the power of tosday's devices (e.g. Compaq iPaq: 206Mhz, 32MB), it would be a shame not to make use of them!
The tricks really dpeend on what you're trying to do and on what platform. If you're on the upper end for PersonalJava, you can make JNI calls, so you just need to implement C modules to work with the OS. You can also create callback mechanisms, but this also requires C code.
The problemw ith JMS is that it's too heavyweight, over the wire. JMS wasn't designed for limited bandwidth. I've been told they're working on a new, lightweight, JMS.
--Mark