i've seen quite a few posts on how cool it is that j2me is available for BREW via the esmertec JVM. in addition, the first response i've gotten when talking to developers about doing BREW apps is "can't you do that with j2me on top of BREW?". indeed, there are tons more j2me developers than BREW developers, and very few java developers would want to "regress" to the world of using C and C++, even if it's the right tool for the job.
operators that have chosen BREW hate this. they don't like the idea at all of j2me on top of BREW. why? one reason is they've already made the choice of BREW over j2me, mostly for the revenue system that is in place, but also because of the testing and verification system that is in place as well. the apps they get generally perform and run without fault.
however, the bigger reason is they see a huge loss of revenue. why? because to load a JVM on your brew device is 500K, which means you can load a lot fewer apps on your device, which means the potential subscription revenue is lowered by 25% in some cases. they will discourage you as a developer from even thinking about using j2me on top of BREW, at least until this overhead of th JVM is standard packaging on the device, and does not eat into the subscribers app memory.
there are two ways to look at it. one is the argument above. the other is that opening the catalog of apps up to j2me will provide scores more of potential apps they can sell, and even if it's only 75% of what they could have gotten, perhaps more sub's phones would be closer to capacity.
what do i think? honestly, the right tool for the job right now on BREW devices is native BREW, and learning the SDK even with C is not that hard, as it's pretty limited anyway. when some of the bigger BREW smartphones come out that have the JVM embedded in the firmware, then i think this will be palatable for operators. the bigger thing i worry about is consistency and testing. because j2me has no verification process, well, there are a lot of unverified j2me apps i've run across with memory leaks and some obvious bugs. this is a headache for me, and a bigger headache for operators. there are some companies such as tira wireless that are trying to introduce verification for j2me to operators, but i'm not sure how successful they've been. it's probably time for SUN to learn from the good things inherent in the BREW model and propose something here. hopefully, their acquistion of PIXO is what they are framing in this light.
i really don't like that qualcomm requires BREW developers to gain a verisign certificate, get their phone unlocked, etc before being able to develop on the device. that's a huge barrier to entry for many developers - so i think they need to do something in this area. making j2me part of the standard BREW SDK instead of a bolt on would go a long way.
Posted by Steve at November 16, 2003 02:32 PM | TrackBack
Excellent post, Stephen. The Carrier perspective is not often presented amidst all the discussion of BREW and J2ME.
Posted by: Craig Lauer at November 17, 2003 12:25 PM
to correct you unlike c, j2me does have a verification process as doe sregular java..ie its part of the java stae machine definitions..just like C sharp..
what you are confusing is verification against the implementation within the handset..which alos Brew has fro j2me :)
Posted by: Fred Grott at November 27, 2003 05:59 AM
fred - i'm not talking about bytecode verification, i'm talking not only about verification against the handset but also verification that the app does not have any memory leaks or other bugs like inefficient use of network resources, etc. there's nothing built into the language or implementation that guarantees this!
i've seen too many java programmers (and smalltalk programmers) over the years rely on the JVM garbage collector which is risky business even in java. very few j2me apps are tested in low memory handset situations causing tons of runtime errors. in essence, i'm talking about a lack of testing, of which the operator has to bear the burden to ensure the apps do not cause problems.
Posted by: steve at November 28, 2003 01:25 PM
I could not agree with Steve more on the need for developers to understand that the code that they write on J2ME over the KVM executes the same way as any other C code only the way it is done is hidden from them!
Even though as a part of the carrier running J2ME in India we face this problems many a times for apps with problems but we have managed with stringent processes as well as better testing.
Posted by: Anindya Chakravorty at December 24, 2003 12:23 PM
buy tramadol online! tramadol buy tramadol
Posted by: tramadol at April 24, 2004 02:58 PM
Maybe I just didn't understand what was written above... Java can not have memory leaks. The JVM manages the memory. Maybe the JVM you were using is buggy? Maybe the Java programmer wasn't watching the memory space very closely. I think the real reason BREW people hate J2ME is the time to market is 12% of what BREW takes. Also, BREW has failed to catch on in the industry and will soon my QualComm phone will find it's place with my C64. I just got a Nokia 6600 that has 80% of the Java byte code built in it's ARM processor. When you get to that point, not much separates BREW from J2ME, except maybe that nasty C memory management thing...
Posted by: JB at June 6, 2004 11:21 PM
5919 check out the hot blackjack at http://www.blackjack-p.com here you can play blackjack online all you want! So everyone ~SMURKLE~
Posted by: play blackjack at August 23, 2004 12:37 AM
As a J2ME developer and a Brew Starter, Heres my take...
As we move forward, the battle between Brew and J2me is going to heat-up.
J2me being easy to learn and develop, will attract more developers ( Many college going students will be learning it for there Projects, and who knows j2me may also come into curriculum of Graduation course).
As more and more j2me developers are born, the technology will be leavereged to max.
Brew at the other hand is comparatively difficult to start with and will attract geeks and "close to" geeks kind of people to work.
The selling point of Brew, is its Rigorous Testing process (NSTL). But at the same time, the money they charge for porting (250$ per build) is bit too high. We live in Dynamic world and Apps we develop are prone to change ( to have NSTL certification for every single modification in the app, does not go well with publishers).
Finally, whoever(Sun/qualcomm or anyone else) Innovates "fastly and smartly" is going to win in a huge way).
Posted by: Mito at August 26, 2004 06:44 AM
soon NSTL will be required for all "Java Verified" apps as well. it's a really, really, bad thing in my opinion.
Posted by: steve at August 26, 2004 07:50 AM