Skip to main content

Java ME EC topics

8 replies [Last post]
Anonymous

Hi everyone,

On the JCP EC (Executive Committee)'s email reflector, we are talking
about carving out time during January's face-to-face meeting for
topics specific to ME, including fragmentation, governance, platform
direction, etc, with the idea being to turn ideas into action.

I have my own ideas on what's needed, and plan to raise issues that
have been stated previously. But the EC needs to hear what's on the
mind of the general developer community, especially in light of newer
mobile development platforms on the scene. What topics do you think
the EC should be addressing?

Sean Sheedy
JCP EC member

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sfitzjava
Offline
Joined: 2003-06-15
Points: 0

Hi Sean,

Looking at the list of top issues "Fragmentation" is in the top 3. So for the future of ME, I would say that not having more branches of ME would be the right thing to do. Empowering the feature phones to have smartphone type support would be a better solution than splitting off smartphones from feature phones. MIDP has the largest market share of the profiles, while some profiles PBP, PP, have faded into obscurity. Let's focus on the key ME segments, such as TV, SmartCard, and MIDP. These are truly the only segments of ME that have any size and support in the market.

Speaking of market share, I'm not sure where you got your %, in a report earlier this year ABI research was forecasting that it would be 2013 before smartphones made it to 33% of the market. However the iPhone may have skewed that forecast. But with Apple having said "no no" to java on the iPhone there is 25-30% of the US smartphone market that can't be touched. Currently the iPhone in the US is surpassed only by RIM, which supports Java, and MIDP, but I would imagine that RIMs numbers will fall.

My recommendation is to have the JavaME spec require the ability for the user to upgrade the VM on the device, thus allowing for new features to be added on the fly, and not requiring a new phone. Also pushing for a JavaVM to be available on the iPhone would be a major achievement for the advancement of JavaME strength, and not just an app that you download from the itunes store, the VM would need to be in the OS so that it could have more features.

Personally I like MID Profile, and their are a few items it would be nice to have in it, some of which I believe are coming in MIDP 3. However some dynamic app changing, such as classloading, or scripting, would be great. I think also there should be some pressure placed on vendors to move to the latest specs. Also that there should be a central key JSR, such as there was for JTWI. We have MIDP3, MSA, and MSA-Lite, which means operators, and phone manufacturers have to choose. They will base this choice on research of what is going to be the most desired and safe path.... which usually means "don't do anything new", so they stay on MIDP2. SonyEricsson has moved forward with MSA, but few others have opted to move forward or to take on as many JSRs. A JSR is only meaningful if it is used in the market place. JSRs make since for JavaSE since you can load what you need, but in ME land the device is what it is, and thus there is no consistency between 2 devices as to what JSRs are supported or how they are implemented.

So in short, move ME to smartphones, but only if it is consistent with the Feature phones. Don't go to the lowest common denominator, but push feature phones to have more features.
And slim down the choices of profiles that can be on a phone.

-Shawn

sean_sheedy
Offline
Joined: 2005-08-04
Points: 0

Thank you for the replies. I'm putting these together with a number of comments I got from others at a recent developer conference, and these seem to be the top items:

- Permissions, signing, app certification
- Deployment and distribution challenges
- Fragmentation: spec interpretation and buggy implementations, BORA
- Developer tools: supported platforms, on device debug, need for actual handsets
- End user experience/look and feel

This list is far from exhaustive and I'm working on putting this into slides.

Next question: the future of Java ME. Arguably, the ME EC's domain is that of JSRs that are in the pipeline (from pre-submission through maintenance release.) The current set of JSRs place Java ME squarely in the feature phone space. If one considers that the "other space" is the smart phone space - that this was only 5% of the market around 2005, but could be 1/3 of the phone market in 2008 - what role should the ME EC take on in addressing Java's position in the smart phone space? And why or why not? I would like to hear what others in the community have to say about this before throwing in my own two cents.

Sean

pjulien
Offline
Joined: 2007-11-07
Points: 0

I think shipping CDC on smart phones instead of CLDC would go a long way to help on smart phones.

maffeis
Offline
Joined: 2003-10-20
Points: 0

Having rolled out several "live" Java ME projects over the past years, those are some of the most annoying issues we found:

- Code signing: some of our solutions require that, and its a *nightmare*, especially on Motorola devices. If at least all the new devices would support Verisign and Thawte code signing certs. And I don't want to be obliged to go through JavaVerified.

- Lack of decent UI widget set. LWUIT is a step in the right direction, but still not tested/verified on enough phone models, and too heavyweight (not something "light-weight").

- Inability to detect device model information via microedition.platform system property, on many devices.

- Inability to determine phone number of inserted SIM

- Limitations in max. RMS size etc.

- Annoying bugs, some of them very stupid. Makes you wonder whether the device vendor has ever run any MIDP regression test suite

drdth
Offline
Joined: 2003-06-16
Points: 0

Congrats and thanks for giving us a voice, Sean.

From a governance point of view I believe that the specs should be changed to allow software users to install what they consider trusted certificates. I doubt that the revenue made from the JavaVerified program justifies the hurdles JME developers have to take.

In fact, I strongly believe that it is very counter productive in promoting JME to the wide acceptance and distribution that it could reach on a purely technical base. Unless it is possible to write a JME application and deploy it the same way it is possible for JSE, the market share will stay limited unnecessarily.

Developing JME is a walk in the park. Deploying JME is where the hard work sits. Any improvement in standardisation of deployment processes and JVM implementations across manufacturers will be a great achievement.

And yes, if this is in the scope of your committee, support for development tools on all three major platforms would be a very nice to have, too.

Diego

pjulien
Offline
Joined: 2007-11-07
Points: 0

How about finally supporting the java 5 dialect? A lot of 3rd party libraries have no hope of working on Java ME as more and more of them are being updated to use generics and annotations.

sfitzjava
Offline
Joined: 2003-06-15
Points: 0

Congrats on your election Sean!!

What we need:
- Less fragmentation in spec "interpretations". This may mean we need better specs that go to the brass tacks in details, leaving no ambiguity. Followed by Sun failing the JVM implementation on compatibility if they can't run a comprehensive test.

- A simple developer registration and signing certificate process that doesn't cost an arm and leg. Something along the lines of the iPhone or RIM developer programs. Java Verified is not realistic for small developer teams or individuals.

- Operators MUST open up their VMs to only need the signing from the above mentioned programs. NO LOCKOUT!! The supported JSRs should be available with minimal user prompting to developers that have valid certificates, and signed apps.

- The JavaME language needs a scripting engine addon JSR, or some level of dynamic classloading. JavaFX mobile is not an answer. From what I've seen It's a poor excuse of a language syntax that does not follow a clear map, it jumps from one format to another. Something along the lines of the Groovy syntax would be a much better solution.

- Open tools for all development platforms, Linux, Solaris and Mac. The preverifier not being portable it killing development.

I realize some of these items are most likely out of the realm of the EC, but it's important to state the issues that real developers have on a day-to-day basis, and see if there are other ways to promote and progress the support of JavaME in the industry, which seems to be fading.

Thanks,
-Shawn

Adrian Roney

Hi,

What about device identification about device identification and provisioning?
(it seems to becoming an issue that different devices are now using the same useragents, when they connect out).

Better access to on device debugging?

It would also be great to hear what comes out of the meeting, and what you guys decide about the direction of the platform, i.e how we compete with the likes of iPhone and Android.

Thanks

Adrian

> Date: Thu, 18 Dec 2008 20:03:32 -0500> From: sean@THESHEEDYS.COM> Subject: Java ME EC topics> To: KVM-INTEREST@JAVA.SUN.COM> > Hi everyone,> > On the JCP EC (Executive Committee)'s email reflector, we are talking > about carving out time during January's face-to-face meeting for > topics specific to ME, including fragmentation, governance, platform > direction, etc, with the idea being to turn ideas into action.> > I have my own ideas on what's needed, and plan to raise issues that > have been stated previously. But the EC needs to hear what's on the > mind of the general developer community, especially in light of newer > mobile development platforms on the scene. What topics do you think > the EC should be addressing?> > Sean Sheedy> JCP EC member> > ===========================================================================> To unsubscribe, send email to listserv@java.sun.com and include in the body> of the message "signoff KVM-INTEREST". For general help, send email to> listserv@java.sun.com and include in the body of the message "help".
_________________________________________________________________
Live Search presents Big Snap II - win John Lewis vouchers
http://clk.atdmt.com/UKM/go/117442309/direct/01/
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]