Microsoft could win in mobile...

Question

If Sun doesn't deal with some major issues in J2ME.
Given the current situation with J2ME, I think Microsoft may be able to pull off a repeat of what happened in the browser wars ... but this time it's the J2ME vendors that are making it happen.
Here are the problems with Java handsets (J2ME) we are seeing.
1. The handset emulators are almost useless for testing mobile apps. As a developer you have no choice but to build and test on every handset you intend to sell for. It's not only that stuff that works on the Emulator doesn't work on a handset, sometimes it's stuff that doesn't work on the Emulator but DOES work on a handset.
2. The extensions (for example, Camera functions) are not always standardized and are often kept secret by the handset manufactuers.
3. Some handset companies simply refuse to support developers.
EXAMPLE: An inquiry into the camera functions on a LG Handset (for a camera based game) produced this response.
Thank you for inquiring of LG Electronics. Unfortunately, LG cannot supply you with this information as it is proprietary information. Furthermore, LG does not support nor provide SDKs for our phones. For further assistance with your request, you may want to contact the service providers that carry LG phones. Please feel free to contact us with any additional questions or concerns. Thank you again for contacting LG Electronics.
4. SUN is NOT verifying compliance of the handsets and their associated J2ME implimentatioms with the standards.
5. Even within the standard, the VM's are broken:
I've been involved as a producer and designer of games for A VERY LONG TIME (TRS-80 anyone?) and have been working in mobile since 2000.
J2ME Portability? This must be a definition of portability I was previously unaware of. If you don't test on every specific handset, even within a family ... your code may not work. We have seen commerical products for specific handsets that failed, in many cases because the publisher assumed that testing on one handset in a family of handsets was sufficent. I can assure you that it is not.
What have programmers seen? Here's some examples:
a. Character array out of bounds exceptions behave differently on different phones. That's right, something as simple as when an exception is thrown showing different behavior on different phones. According to the J2ME standard, the String.substring(int beginIndex,int endIndex) method throws an IndexOutOfBoundsException "if the begin index is negative, or end index is larger than the length of this String object, or beginIndex is larger than endIndex."
This works in practice on the Nokia 3650. However, on the Motorola i95cl the IndexOutOfBoundsException is thrown when beginIndex is EQUAL TO OR LARGER than endIndex. This does not conform the standard and causes code to run differently on the two phones.
b. Nested loops failing. We fixed a problem on a relatively new phone (the Nokia 6600) by removing a nested loop in a Java game. Problem did NOT occur on the Nokia 3650. The J2ME was actually skipping the execution of the inner loop at times. The problem did not occur on other series 60 handsets.
c. Broken memory managers. Failure of GC to regain space from discarded objects.
d. HTTP I/O functionality is unreliable. Standard tricks such as closing an http connection to force a timeout don't work on most devices. You have to monitor I/O processes to kill threads when they freeze.
... and there's so much more.
Then there's the issue of the specification itself. Would the folks who designed MIDP 1.0 had talked to someone, anyone in the game business. If you need to detect button press you're going to be device specific. The key-codes for the cursor pad, number pad, vary from handset to handset. Yes, MIDP 1.0 has "game actions" that are supposed to abstract the phones so that you don't rely on all phones having arrow keys and fire buttons but this actually causes more problems than it solves. Example: on the Nokia 3650 a call to getGameAction(keyCode) may identify the key as UP. However the keyCode parameter may also be the ID for the 2 key. Now you have to inject complicated logic to distinguish whether one should interpret it as a "2" or as UP. Then there's stuff like trying to draw individual pixels
MIDP 2.0 looks promising, but the MIDP 2.0 handsets we have are showing the same "write once, test everywhere" characteristics we have become familiar with in MIDP 1.0
So what about Microsoft? Microsoft is all about "developers, developers, developers" ... unless someone from SUN et. al. gets serious about this, they could lose their market advantage. Programmers tell me that the mobile development suite from Microsoft works well, and that most of the I/O issues they have with J2ME don't occur in the Microsoft suite.
Here's a thought ... how about a compatibility suite and certification. That is a series of programs that test a large range of the functions .. with user interactions to insure the proper graphics and UI interfaces.
I've seen this situation before (broken implimentations) ... back in 1989 with CD-ROM on PC's and the MSCDEX drivers. We (Activision at that time) created a test suite, contacted every CD-ROM company and provided the results so th drivers could be fixed.
Now what I have been told, in regards to the KVM's, is that it's pretty much a hands off deal by Sun. Handset companies just buy off the shelf VM's that kinda work.
If you wonder why there aren't a slew of multiplayer games or network apps .. this is the main reason. I'd estimate that over half the expense in building "The Dozens"tm (Mobile Multiplayer Game) has been in working out how to deal with the "lock ups" in HTTP I/O and other issues.
I think there's time to fix this for MIDP 2.0. Sun or someone needs to create a set of rigorious test suites that really determine if the VM meets the spec, and in particular exercises the I/O and memory management aspects of the J2ME VM. You can't blame Microsoft for these problems, it is entirely self-inflicted.
William Volk CEO, Bonus Mobile Entertainment

Answer 1

do you think anybody really interrests your opinion
about OSS java?
OOS-Java means to give control out of SUNs hands, if
a jvm is not standard it may not be called "java", so
no problem in means of compatibility there.
HAVE YOU EVER READ SUN's LICENSE? ITS DISGUSTING,
ANOYING, JUST CRAP.
That what OSS means, not incompatibilities and
100.000 forks.
But you are just telling everybody what you think -
nobody is interrested in. I am sure you have NEVER
read the license under which java stands, haven't
you??i don't need to read license, i know it's fine for me .. we were not talking about that anyways