Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Motorola Seeks Mobile Unity at JavaOne

ScuttleMonkey posted more than 8 years ago | from the shiny-happy-people dept.

87

Mike Barton writes "InfoWorld's Paul Krill reports that Motorola and Eclipse will unveil open source mobile initiatives at the JavaOne conference this week to broaden Java's mobile and software ecosystem. From the article: 'Motorola also will develop under an open process a references implementation and compliance test for Motorola-driven Java Specification Requests, such as the Mobile Information Device Profiles (MIDP) 3.0 specification.' Motorola's goal is "write-once, run everywhere" implementation capabilities."

cancel ×

87 comments

Java Sucks FP! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15336362)

Motorol sucks too!

I think you mean... (3, Funny)

MrNonchalant (767683) | more than 8 years ago | (#15336391)

Write once, debug everywhere.

Zing!

Re:I think you mean... (0)

FatherOfONe (515801) | more than 8 years ago | (#15336698)

I didn't realize that you had an account on Slashdot Bill. You forgot your usual uneducated statement about Java being slow...

By the way how is Microsoft these days?

Seriously, write some Java code for any "modern" JVM and then "if" you can't deploy it to any certified JVM post something. Our company has many Java applications on many different platforms. Most apps are fairly large in size and we have had little to no problems with different platforms. The ONLY JVM we "had" issues with was Microsofts. I wonder why that was????

So Bill in short.
Thanks for dropping support of Java. You made our life easier.

Re:I think you mean... (3, Insightful)

bladesjester (774793) | more than 8 years ago | (#15336761)

I've said it before, and it should be said again. Most of the problems people have with java not being portable are due to stupid mistakes and shortcuts by the programmer.

The two most common problems (which should not happen) are use of non-core packages and hard coding of file seperator characters in pathnames instead of using File.seperator

Sun even takes pains to point these things out, but a lot of people don't listen, so those of use who write useable, portable code get to hear "java is teh suxor" too often.

Re:I think you mean... (1)

RapedByKateMorrow (974920) | more than 8 years ago | (#15337014)

Mod parent up.

If programmers ignore the standard and thereby cripple functionality, it is not the standard's fault.

If phone OS / firmware developers ignore the standard and thereby cripple functionality, it is not the standard's fault.

If, on the one hand, developers are required to uphold standards as a part of a developer/license agreement, much of this lack of interoperability crap would be avoided. The flip side of that is that a certain number of developers will whine about code oppression or simply find shortcuts that are non-standard but operational. The former can be handled somewhat by enforcing standards, by code, within the interpreter. The latter chiefly by meeting their technical / emotion arguments on each point, or ignoring / mocking / fudding their efforts.

Re:I think you mean... (1, Insightful)

molarmass192 (608071) | more than 8 years ago | (#15337244)

As a java programmer myself, I'd say that PART of the problem is that Java is "taught" as both an entry level language and an advanced language. The result is that programmers who shouldn't be programming wind up working in the domain. Let's face it, Java is a VERY forgiving language. You can get away with things in Java that would make a C programmer's head explode. If you've worked in C, you've learned to respect programming techniques. Sadly, Java-only progs who haven't worked in C are "typically" (not all) really sloppy careless programmers. It's the same cruft you see in VB programmers.

Re:I think you mean... (1)

bladesjester (774793) | more than 8 years ago | (#15337418)

I agree. After working with C, C++, Java, and a bit of ASM, prolog, and scheme, it's pretty easy to both know what's going on code-wise and having a whole new appreciation for not having to futz with things like memory.

Re:I think you mean... (0)

angel'o'sphere (80593) | more than 8 years ago | (#15337916)

Deservs +3 mod points.

Exact this is what is "wrong" with java. Java is a superb language + environment, but total noobs 8that in earlyer tiems where restricted to do VB instead) are now allowed to mess with serious programming. OFC they mess it up generally.

Unfortunately Java/Sun gets teh balme.

angel'o'sphere

Re:I think you mean... (1)

Billly Gates (198444) | more than 8 years ago | (#15337287)

Awt as well.

Most people who say ignorant things like debug everywhere tried java out in 98 or 97 with awt that relies on the platform's window manager to draw and use gui's. Because the platforms were so different in the way they did things bugs could show up if a programmer was used to the way windows did things but X did not.

Swing and SWT took care of most of those problems recently in modern java which makes the gui components truly reusable.

Re:I think you mean... (1)

angel'o'sphere (80593) | more than 8 years ago | (#15337890)


The two most common problems (which should not happen) are use of non-core packages and hard coding of file seperator characters in pathnames instead of using File.seperat


In fact you can hardcode file seperators if you use "/" and not "\\" as "/" gets transalted to System.getProperty(File.Seperator) ....

However its not "fully" portable as you might have a system where "." is the path seperator and "/" is a fully legal character in the name of a file.

angel'o'sphere

Re:I think you mean... (1)

00lmz (733976) | more than 8 years ago | (#15339040)

The two most common problems (which should not happen) are use of non-core packages and hard coding of file seperator characters in pathnames instead of using File.seperator

And assuming a case insensitive filesystem.

Re:I think you mean... (2, Informative)

oncebitter (894257) | more than 8 years ago | (#15337435)

The issue is not the JVM/KVM but the MIDP/CLDC implementation layer in mobile phones -- they are always inconsistent and usually buggy. Great strides have been made, but "write once, run anywhere" applied to J2ME is the biggest joke in the industry, as any of the dozen engineers at my company dedicated to porting code to different J2ME devices will agree. Blame Sun's certification tests. Curiously, Motorola is one of the worst offenders.

Ironically, Qualcomm's iron-fisted control of BREW (a C-based competitor to J2ME) has resulted in much higher levels of consistency, approximating "write once run anywhere".

Re:I think you mean... (1)

FatherOfONe (515801) | more than 8 years ago | (#15337649)

Excellent points about J2ME. However, don't blame Sun too much for this one. They where idiots for handing that over to Palm to work with. Then when Palm didn't do jack with it then somewhat took the lead again, but it hasn't had the leadership that SE or EE has had. However, the core code that you would write (business logic) will port fine, it is just the issues with what API's are included and what is not. The other big issues I see is with the GUI, but the orignal poster did not mean J2ME, he meant Java in general.

Now for it being the biggest joke in the industry.... It isn't even close.

Re:I think you mean... (1)

Metaphorically (841874) | more than 8 years ago | (#15351941)

I never got very far with J2ME. Just from reading the introductory materials - while trying to get a development environment together - the ME part really makes a difference. There seem to be some serious discrepencies between the basic classes available in SE and EE vs ME.

I got the impression that ME is Java in name only.

Re:I think you mean... (2, Informative)

BigLinuxGuy (241110) | more than 8 years ago | (#15338598)

Programming for the Java Standard Edition is not the same as programming for the Java Micro Edition. The JME JVM is just about as non-standard across embedded devices as it gets. Best practices in JME are to use as few classes as possible to avoid as much of the overhead inherent in the class loader. Due to these inconsistencies, one has the issue of potentially having to debug everywhere due to a non-standard platform implementation. The wireless carriers are pushing for a "standard" embedded JVM, but are years away from realizing anything from the OEMs. In the meantime, worst practices are still used to create applications (most notably building monolithic applications with no use of MVC).

JME apps are also measurably slower on embedded devices than a natively compiled binary. Not a good thing for the embedded space where the processors are not particulary powerful. The argument that "devices are getting more powerful and have more memory" is at best silly since battery life is not getting any longer (shorter in fact due to the larger screens, more powerful processors, and memory).

Other technologies, like Adobe's FlashLite, are positioned to provide a uniform presentation platform long before the issues with embedded Java will be worked out. That means that business logic layer is next and for the most part I'll take faster with fewer CPU cycles over a non-existent WORA promise. Of course, that makes it harder for developers so perhaps it will ensure that embedded space development doesn't become the same kind of commodity as "mainstream" development.

But your mileage may vary.....

JVM's are UNSTABLE! (1)

ThinkingInBinary (899485) | more than 8 years ago | (#15338861)

"Debug everywhere" is true. My phone's JVM crashed once because I overflowed an integer. In Java, a supposedly "safe" language. Phone manufacturers really need to get their acts together. Perhaps if some company came out with a Java-on-a-chip solution that allowed most of the phone to run in Java, then interfacing would be easier and reliability would be higher (because you're only debugging the one Java implementation instead of the native OS plus a JVM tacked on to that).

true (1)

geo.georgi (809888) | more than 8 years ago | (#15336699)

That's even much much more true for J2ME than for standard Java. The used JVMs have more bugs than any normal piece of software. I agree, it is much harder to write embedded JVM, you have many different operating systems and hardware, but still some bugs should be found and fixed easy with automated test suite.

I recently found a bug on my Nokia 6600. If you set your time zone to a negative one against Greenwich (for example GMT-2), your application will not start if it is using Calendar functions. Set the time zone back (GMT+1) and it works OK. And worse, it seems the bug can be dated many years back on different Nokia phones and I'm almost sure it is not fixed on the current ones.

And my lovely one is on Nokia 7650. It sends the HTTP header like
GET / HTTP1,1
instead of GET / HTTP1.1
if your phone language is one that uses comma for number separation (like German). Switch to English and it works (OK, they were still other bugs to care about). Of course almost every server responds with Bad Request on such one. Tell the user, he need to use English menu, or to go to the service center for firmware upgrade to use your application...

Re:true (1)

ObsessiveMathsFreak (773371) | more than 8 years ago | (#15336882)

It sends the HTTP header like
GET / HTTP1,1
instead of GET / HTTP1.1


Might have been written in France.

Today's fun fact: In France, instead of using a decimal point, a decimal comma is used. Thus $4.56 is written in France as, $4,56. Also, a superscript is used instead of a subscript to delineate multiples of a thousand. Hence $1,234,567.89 is written $1'234'567,89 .

P.S. Why the hell isn't the euro symbol visible on Slashcode?

Re:I think you mean... (0)

Anonymous Coward | more than 8 years ago | (#15337228)

More like "Write Once, Go Through Hell and High Water Running Everywhere" (unless you master the art of preprocessing). I hope MIDP 3 makes game development way better since oviously, the 2.0 Game API is basic at best (unless you're a pro and make your own GameCanvas classes), but it could be better. You know, some better collision methods that set up collision rectangles according to a particular Sprite frame and simultaneous key presses wouldn't hurt either. I just hate how non-Java phones treat Midlets like crap with their built in piss-poor middleware that runs them half-assed ::coughintentJavaMidletManagercough:: . Besides that, funny how Motorola isn't opening up their Linux OS for phones as much as they're doing it for Java. Oh well.

Re:I think you mean... (1)

robmv (855035) | more than 8 years ago | (#15338108)

Well. I still prefer to debug everywhere than write multiple programs and later have to debug each of them, or are you the kind of "developer" that do not test on each supported platform?

Re:I think you mean... (1)

edxwelch (600979) | more than 8 years ago | (#15338560)

Whoever made that statement was off his mind. There is no such thing as writing cross platform software without testing and debugging on each platform.
The point is that Java is mostly portable, there's no perfect solution - but it's a hunderd times better than the alternatives.

Re:I think you mean... (1)

SolitaryMan (538416) | more than 8 years ago | (#15340529)

Write once, debug till the end of time.

Good luck (3, Interesting)

bunions (970377) | more than 8 years ago | (#15336406)

If there's an area that really needs compile-once, run-anywhere it's cell phones. Last time I looked at MIDP it was really hobbled by catering to the lowest common denominator - IIRC, all you had for user interaction was up, down, select and keypad entry. Hopefully there's some progress on that front.

Re:Good luck (1)

955301 (209856) | more than 8 years ago | (#15336687)

Hopefully there's some progress on that front.

You're hopes haven't gone without regard. There is now an annoyImmediateVicity() method that replays your default ring tone.

Wake me up when Verizon Wireless joins in (4, Insightful)

feijai (898706) | more than 8 years ago | (#15336426)

Until then, I'll still be stuck with intentionally Java-broken phones. Unity my butt.

Re:Wake me up when Verizon Wireless joins in (1)

DaHat (247651) | more than 8 years ago | (#15336853)

If you are going to belittle Verizon for poor Java support you really should go the whole way and get after them for:

  • Crippled Bluetooth
  • Filtering out *.mp3 files being transferred OTA
  • Crippled memory card access (v710/e815)
  • Preventing text messages from other networks
  • Refusing to compete with other networks despite massive shifts in industry
  • Using CDMA!

Re:Wake me up when Verizon Wireless joins in (1)

PipsqueakOnAP133 (761720) | more than 8 years ago | (#15391967)

The first five points, yes, I agree.

However, using CDMA is actually a benefit to me and is pretty much the only reason I stayed with Verizon so long. In short, their use of CDMA is what gives my phone a better reception, data handling, and reliability over other networks using GSM. (Sprint's a bit of a mess just cuz they haven't invest in enough cdma towers)

Regardless, I'm also using a E815 with java imported from canada on the verizon network.

Re:Wake me up when Verizon Wireless joins in (2, Informative)

Anonymous Coward | more than 8 years ago | (#15336854)

Depending on your phone, they're fairly easy to crack and replace the firmware with functional variants (I have a working E815 with a hello world java app on it). And don't forget, Motorola helps them break their phones.

Re:Wake me up when Verizon Wireless joins in (1)

blindd0t (855876) | more than 8 years ago | (#15337454)

Here is my wishful thinking at its best...

[Motorola]: while wearing a big ring, punches Verizon on the forehead
[Verizon]: ouch, what the?!
[Motorola]: Unity!!!

(Gotta love Chappelles Show)

-d0t

Why bother (for the US) (1)

Overzeetop (214511) | more than 8 years ago | (#15336488)

Every major cell phone provider seems the defend their RF real estate with hobbled phones and pay-to-breathe business model.

Oh, well, at least there'll be something cool to look forward to when they finally move this alpha to an island somewhere.

Re:Why bother (for the US) (1)

bunions (970377) | more than 8 years ago | (#15336691)

You're exactly right. The cell phone industry in the US is what's supressing all kinds of interesting new technology.

To: N.S.A. +1, informative (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15336523)


I am the leaker [rawstory.com] .

Remember: F$ck Bush.

Sincerely,
K. Trout, Infidel

Re:To: N.S.A. +1, informative (0)

Anonymous Coward | more than 8 years ago | (#15336715)

No, u r teh phailure.

Jad preverifier. (0)

Anonymous Coward | more than 8 years ago | (#15336655)

A Jad preverifier would be a nice start.

Wha?? (0, Flamebait)

gregarican (694358) | more than 8 years ago | (#15336672)

write-once, run everywhere. Hasn't this been the unofficial motto of Java for years now? And how true is it now compared to 1997? Utopian credo apparently.

Re:Wha?? (1)

bunions (970377) | more than 8 years ago | (#15336720)

data point: I developed a large GUI application in Java (sob) and write-once, run everywhere worked. It was pretty neat seeing the same jars run on windows, osx, and linux. It even ran under solaris, if you can believe that. ;)

Java applets. (1)

thealsir (927362) | more than 8 years ago | (#15336903)

Nuff said.

Course it'd be nice if the JVM were a little easier to install on linux...and getting it to work with the browser didn't require a million hacks..

Re:Java applets. (1)

LDoggg_ (659725) | more than 8 years ago | (#15337441)

Applets are only a problem write-once-run-anywhere-wise if you use the long outdated <applet> tag (and thus the garbage MS 1.14 jvm) instead of using the plugin and specifying the required JVM version.

Course it'd be nice if the JVM were a little easier to install on linux...and getting it to work with the browser didn't require a million hacks..

rpm -ivh someJVM.rpm ;
ln -s /usr/java/somevm/jre/plugins/i386/javaplugin.so /usr/lib/mozilla/plugins/

Yeah, way different than other plugins...

Re:Wha?? (1)

Billly Gates (198444) | more than 8 years ago | (#15337259)

Alot of this has been credited with the introduction of Swing replacing awt which made the write once, debug everywhere true because of the way the window managers of different platforms kept getting in the way.

Re:Wha?? (1)

znaps (470170) | more than 8 years ago | (#15337613)

I downloaded Opera Mini - which is a Java app - the other day for my w810i, worked perfectly. Seems like it's possible to me.

Infoworld is an Ad museum (1)

LittleBigScript (618162) | more than 8 years ago | (#15336677)

Wow. Just look at all the ads on the page. There is even a pop-up. I thought those things were extinct for the larger websites. If you go to the top right of the page it folds down to give you a better look at, that's right, more ads.

With a name like Infoworld...

Re:Infoworld is an Ad museum (1)

chicken_moo (822458) | more than 8 years ago | (#15336760)

Of course, its an apt name... they're giving you lots and lots of INFO on a WORLD of products... ba-dum-chsh!

Re:Infoworld is an Ad museum (1)

mrbobjoe (830606) | more than 8 years ago | (#15339260)

With a name like Infoworld...
Guess Ads 'R' Us was taken...

the "write-once, run everywhere" motto is true (1, Funny)

ranjix (892606) | more than 8 years ago | (#15336708)

I can speak only of myself, but since I started writing java code, I started running everywhere...

Re:the "write-once, run everywhere" motto is true (1)

josepha48 (13953) | more than 8 years ago | (#15336755)

for MOST java code, this is true. I have found a few instances where it is not. Dealing with things like sockets. There are several ways you can do sockets, and if you do them one way they wont work under windows but will under *NIX.

Also they are not talking about Java J2SE or J2EE, they are talking about J2ME. Under the J2ME, there is a write once and maybe run everywhere. This is especially present under cell phones. Most software can be run anywhere, but then much can't. I had a tetris game under my old motorola phone. I got it a few months ago. When I got a new phone with T-mobile, the clerk said they could transfer the game and all I had to do was call customer service. When I called customer service, they said that the games were phone specific, and it would not work, even though it was a Java game. Either she was lying to me or J2ME does not write once and run everywhere like Java is supposed to.

Yes I know it was a java game, because when it started up, it started with 'loading Java'. If I was lied to then I should be able to sue. The phone support even said, if I got a phone of the same manufacturer that I could not transfer the game because it would not work and that the games are phone specific. I'd love for someone to prove me wrong, so I can go after t-imoble.

Re:the "write-once, run everywhere" motto is true (1)

H0p313ss (811249) | more than 8 years ago | (#15336984)

FYI: That wooshing noise was the joke going over your head.

Re:the "write-once, run everywhere" motto is true (1)

josepha48 (13953) | more than 8 years ago | (#15344811)

Actually no the joke did not go over my head, I just didn't find it funny.

Re:the "write-once, run everywhere" motto is true (2, Funny)

ranjix (892606) | more than 8 years ago | (#15336866)

probably I didn't stress enough in my post:

since I started writing in Java, I started running everywhere...

now that I repeat it, it doesn't sound funny anymore. forget it

Re:the "write-once, run everywhere" motto is true (1)

everphilski (877346) | more than 8 years ago | (#15336938)

poor dude

In Soviet Russia (1)

Billly Gates (198444) | more than 8 years ago | (#15337342)

You run everywhere by writting java code. ... wait a minute?

Pocket PC (0, Interesting)

Anonymous Coward | more than 8 years ago | (#15336750)

As much as I hate to bring it up, Microsoft has become the leader in mobility development. Why? Because the Java camp DOES NOT HAVE tools a VB developer can use.

WORA should be changed to ATBDBA (Able to be developed by anyone).

Before the flames kick in, you can not honestly tell me one can develop, test, and deploy with Eclipse any quicker than with Visual Studio 2005!

I WISH it was there, but it is not. I have no joy in paying more Microsoft Taxes, but time is money and I can build a great PPC application in c# in a fraction of time it would take me to do it in Java.

It's the tools, not the platform, that make great software!

Netbeans? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15336884)

Tried Netbeans? Y'know, GUI builder, works for J2ME... And does MIDP GUI design too [google.com] ?

Re:Pocket PC (1)

Anonymous Coward | more than 8 years ago | (#15337007)

How do you figure? Last time I checked, J2ME had the commanding market share. I can count the number of BREW phones I've developed for on the fingers on one hand, and I've seen even less of anything else. Since I've developed for Sprint, Nextel, and Verizon at this point, I should think I've gotten pretty good coverage of what's going around...

Re:Pocket PC (1)

GalacticCmdr (944723) | more than 8 years ago | (#15337451)

Before the flames kick in, you can not honestly tell me one can develop, test, and deploy with Eclipse any quicker than with Visual Studio 2005! I WISH it was there, but it is not. I have no joy in paying more Microsoft Taxes, but time is money and I can build a great PPC application in c# in a fraction of time it would take me to do it in Java. It's the tools, not the platform, that make great software!

Actually yes I can develop a program (beyond the simplisitic "Hello World" and its ilk) faster in Eclipse/Java than VS2005/C#. I work in both arenas on a daily basis and while I would tap VS2005 as having a very edge is functionality its not enough to offset a few of C# (and .NETs) more glaring problems.

I do agree whole-heartedly that it is the tools that really help lift a language and while VS2005 is (in my opinion) currently superior to Eclipse - the third-party tools of Java are far superior to those offered for C#. Thus I can develop faster in Java than I can in C#.

Re:Pocket PC (1)

ElGuapoGolf (600734) | more than 8 years ago | (#15337481)

That's great... you can write for your PocketPC phones, and your... PocketPC phones.

Meanwhile, feature phones (which is where the money is) run J2ME.

Re:Pocket PC (1)

Trelane (16124) | more than 8 years ago | (#15337637)

Are you serious? There are any number of them, including Sun's, Metrowerks', Borland's (at least a while ago), and so on. In fact, Sun's is free of charge, and is drag-n-drop.

Re:Pocket PC (1)

MemoryDragon (544441) | more than 8 years ago | (#15338097)

Ahem first of all, the mipd development tools are free and always have been, secondly, if you need a good midp development platform, Eclipse is not your friend Netbeans is, also free of charge. Thirdly you can get the dev kits for most mobile phones from the phone vendors themselves, also free of charge... Are you sure you ever had a serious look at midp development?

Re:Pocket PC (0)

Anonymous Coward | more than 8 years ago | (#15338163)

The guy said tools a VB developer could use, not tools a Java developer could use. There is a HUGE diff.

Re:Pocket PC (1)

MemoryDragon (544441) | more than 8 years ago | (#15338450)

Mobile phones are a different ballpark for now, the display is so limited and often so distinctive, that visual drawing tools do not make sense in this area for now. A meta ui like the midp uses it makes way more sense. Things might change, but for now as long as there are myriads of cellphones with small displays and lowres still in the market which have to be serviced forget it. Graphical rad tools have their place, on cellphones for now they dont. Things will look differently in a year or two. But cellphones are a completely different ballpark compared to PDAs for now, unless you have a smartphone or can target a specific model.

Re:Pocket PC (1)

Wyatt Galen Houtz (858073) | more than 8 years ago | (#15338208)

THis is because msft controls the hardware that is used. The devices are so specific that msft gets a direct contract with motorola, or whoever, and linux never has a chance... monopoly

Check opensource.motorola.com (1)

dbateman (150302) | more than 8 years ago | (#15336807)

Although you can't get it there yet, check http://opensource.motorola.com/ [motorola.com] where it appears the discussion on this is suppossed to take place, at least from Motorola's point of view..

D.

MIDP, Cell Phone Vendors, and Carriers (3, Insightful)

deanj (519759) | more than 8 years ago | (#15336829)

I've been to many JavaOne conferences. I've heard the cry to develop for MIDP.

I listened to the vendors and Sun, and all the "There's lots of opportunity".

You know what? That was complete bullshit.

The hurdles a small development company (3 or 4 guys, or smaller) has to go through to get an app developed is one thing. That can be handled. Code is code. Even with bugs in some of their phones (Hi there, Samsung), issues can be worked around.

The real problem is dealing with the phone vendors and the carriers. The vendors less so than the carriers. They charge an enormous amount of money to do "compliance" testing, and then, IF you're lucky, you'll get picked to be put on their download lists. And then they take a massive cut of the purchase price.

Like I said, this is IF you're lucky. The last time we looked into it, small publishers had to get accepted by bigger publishers just to get your app noticed.

This is yet another instance of the unbridled greed that cell phone carriers have in this market; Handhelds, such as Treo (Palm & now, Windows), don't have the crap to deal with that Java apps do.

Stick with Palm/Windows unless you can get picked up by a big publishers (JAMDAT, etc). The headaches with working with Sprint's "support" (ha!) isn't worth it.

Re:MIDP, Cell Phone Vendors, and Carriers (1)

oliderid (710055) | more than 8 years ago | (#15340897)

On the marketing side. There is a very weak support for applications. J2ME market is mainly dedicated to video games. When you app is about financial stuff, personnal productivity or anything else...You are in trouble.

Concerning the "certification" of your MIDP app to be listed on most carriers. It was done by third parties Two years ago (I left that market I don't know if it's still the case). There were around 5 companies doing that.

It costs a lot of money. You have to be "certified" for every single models...And in every single language you support (Nokia, Motorolla and others, I guess more than 60 per year. My app supports three languages). It was around $250-500 US per model and per language if I remind well.

So I tested the process. I picked my own mobile phone (T610) in the list because I knew my application works on that device. It was developped, tested, tuned for it.

After two weeks I received a letter telling me that my application failed because the tester didn't find the "back" feature (to go back to the previous screen).

The funny side is that I sticked to the MIDP framework and my Back button was the default one. on the T610 the back button is a bit weird. You have to get used to the phone or read the manual. So the third party was in fact refusing the MIDP framework, or the Sony Ericsson implementation.

You multiply this experience by a factor 100 and you see the budget and the time you need to be fully "certified"...And it doesn't mean yet that you may access the market...You still have to convince carriers to list your apps. I suspect this is even a bigger challenge...I remember that Nokia was proposing its own list to carriers. You would need a budget of $4000 US or more per year To be listed. Then the carrier and Nokia takes around 70% of the revenue.

Mosts carriers proposes only video games to their clients.

When you see the modest turnover generated by most mobile applications, your clearly see that you are going to lose a lot of money. I left it and I joined the Blackberry market where things look more "business friendly". (you only need $100 US to be recognized by blackberry and access protected features on Blackberry APIs, there is a big distributor Handango and few others. Royalties are around 60%...Quite high but not other fees.)

On the technical side...Most J2ME mobile phones can't support floating point (CLDC 1.1). The first time in my life that I had to develop an application on such a backward system. And you that the hardware can support it...if you choose the Symbian framework you can easily access this feature.

MIDP 1.0 and 2.0 are relatively nice framework for video games and only video games. It is a dead end for anything else.

So let's see what MIDP 3.0 could do...Anyway I'm glad to see that I least one company recognizes that there is a "big" problem.

Olivier

Motorola/Nextel was good for J2ME (3, Interesting)

FerretFrottage (714136) | more than 8 years ago | (#15336870)

I've done some J2ME development and it can be chore. Phone display sizes/interfaces (MIDP stuff) aside, there are a couple of other things that make the development environment less than ideal.
--Most phone still on supoprt CLDC 1.0 while CLDC 1.1 has been available for a couple of years (major benefit of 1.1 is floating point support)
--Mobile carrier support for development

Nextel (now Sprint) was the best IMHO WRT J2ME with their iDen program. Motorola made development documentation easily available (Nokia does too IIRC) and even provided documentation and examples to their java location APIs. I must say it was pretty cool to develop a J2ME geocaching app that could work almost as well as a dedicated GPS unit (with the phone you don't have a much accuracy as a dedicated unit, but I was still able to find the caches). The bonus was that the phone app could then send a query to the geocache site with your current location and then retrieve nearby locations; I used this a few times while on vacation.

Yeah, it was fun, but since J2ME location APIs (if available) are vendor sepcific (no JSR was even in the works at the time when I did this), it wasn't just write once debug everywhere, it was write everywhere, debug everywhere. Sure factory patterns and the like make development easier, but with J2ME you want your code to be as small as possible and sometimes what might be the "best" OO approach may not be practical on a J2ME device.
   

Re:Motorola/Nextel was good for J2ME (1)

bunions (970377) | more than 8 years ago | (#15337088)

"Nextel (now Sprint) was the best IMHO WRT J2ME with their iDen program"

Plus you could actually simple buy a cable from the manufacturer to deploy your app onto your own phone and not have to jump through the nine hojillion hoops the other vendors made you jump through.

It was mentioned above, but just to reiterate: dealing with any of the non-nextel cell companies was, from a developer perspective, a -titanic- pain in the ass.

Re:Motorola/Nextel was good for J2ME (0)

Anonymous Coward | more than 8 years ago | (#15337211)

I'd have to disagree. I'm developing for Nextel phones as we speak, and I dearly miss Sprint's OTA provisioning. Just download your apps from your own ftp server. This opposed to having to deal with yet another cable, and don't even get me started on the driver and WebJAL headaches....

Re:Motorola/Nextel was good for J2ME (2, Informative)

Amon Re (102766) | more than 8 years ago | (#15338161)

JSR 179 is the standard for J2ME location services. http://www.jcp.org/en/jsr/detail?id=179 [jcp.org]

Re:Motorola/Nextel was good for J2ME (1)

edxwelch (600979) | more than 8 years ago | (#15338623)

You can easily survive without CDLC 1.1, if you know a bit of maths. And there are some free fixed point libraries available as well.
Suriviving without oo is a different matter, for small games no problem, but with a big code base you're going to have a horrible time. Of course, if you're only developing for mid and high end phones you don't need to take such drastic steps.

Re:Motorola/Nextel was good for J2ME (1)

FerretFrottage (714136) | more than 8 years ago | (#15338761)

I know you can and I did such math manipulations to work around the lack of floating point, the "problem" if you will, is that it requires more code. More code == more space (especially since you would likely make it some sort of math lib for reuse purposes). And space can be at a premium when developing/deploying J2ME apps. If there was no CLDC 1.1, then fine, but there is and there has been now for a couple of years. I wish I knew the reason why so many phones were staying with the 1.0 version (maybe 1.1 takes up that much more space itself....I really don't know).

Re:Motorola/Nextel was good for J2ME (1)

edxwelch (600979) | more than 8 years ago | (#15340664)

The math routine libraries take a tiny amount of space ... all you need is sqrt, cos, sin and arc tan... that's just a few bytes (actually I don't think CDLC 1.1 even has arc tan)

Yeah, riiiight..... (1)

KZigurs (638781) | more than 8 years ago | (#15337121)

And that from a vendor who currently has the worst java implementation (slowest, buggiest, generally sluggish interfaces and long time until events are delivered where apropriate) on the market...

Re:Yeah, riiiight..... (1)

Billly Gates (198444) | more than 8 years ago | (#15337318)

The power of opensource.

Have the community fix their broken software for free. :-)

Now if only Nvidia and ATI could release their specs so we could stop using their bug ridden blob drivers.

WHY did you have to do this to me?? (1)

martinultima (832468) | more than 8 years ago | (#15337362)

Right when I think I've gotten that song out of my head, too!

And its 2Q 2006 (0)

Anonymous Coward | more than 8 years ago | (#15337491)

And where is the A910?

Still no development kit at motocoder.

they are kidding? (1)

crodrigu1 (819002) | more than 8 years ago | (#15337528)

Just try to get the Nokia J2ME: 1) Join Nokia web site 2) Download the J2ME 3) Ask for a key to finish the installation 4) The installation crashes 5) You need to download again 6) Repeat steps 3 to 6 And this is for Nokia, Motorola has something similar and of course LG Then there is not way to test you code in the millon phones (same Phone series, different results) so J2ME is dead (at least for me)

Please Don't Make My Daddy Mad! (-1, Troll)

Son_of_CmdrTaco (975055) | more than 8 years ago | (#15337711)

He gives me food and hugs for sucking on his pee-pee, and when you people make him mad, he takes it out on me and makes it really rough on my little bottom. Daddy loves me, although sometimes it feels creepy when he does. He told me not to tell anyone, though.

write once (0, Flamebait)

Arandir (19206) | more than 8 years ago | (#15338245)

Motorola's goal is "write-once, run everywhere" implementation capabilities.

It would be nice if Java itself could have that capability...

Re:write once (1)

Arandir (19206) | more than 8 years ago | (#15344231)

Who the hell marked this down as "flamebait"? Obviously you've never tried to "run anywhere" that wasn't a Sun approved platform. And even with them you're still going to encounter major hickups.

J2ME will *never* be write-once, run-anywhere. (1)

ThinkingInBinary (899485) | more than 8 years ago | (#15338850)

J2ME will never be write-once, run-anywhere. And it's not Sun's fault, it's the developers' fault. Just like on Windows, all the devs want their applications to have cool, skinned UI's, and they all create (relatively) proprietary, skinned, custom interfaces. Of course the images have to be a different size and the buttons have to be labelled differently for each phone, so they have to make different versions. Add on to that the stack of API's that are only supported on some phones (JTWI helped, but not much), and you have a system that basically requires building custom JAR files for each phone, if not actually recompiling the program itself.

We should really praise these efforts, since anything that encourages portability is good, but, realistically, developers are too lazy and too obsessed with looks to write an app that just uses a standard GUI and/or adjusts to screen size and device features.

Yeah, but Eclipse will still suck (1)

cgrayson (22160) | more than 8 years ago | (#15339442)

<troll><spam>Love it or hate it -- ah never mind, just hate it. Eclipse sucks [faroutshirts.com] .</spam></troll>

What a bunch of hogwash (1)

Heembo (916647) | more than 8 years ago | (#15339449)

Motorola seems to go OUT OF THEIR WAY to make it really hard to write code on their "much lauded" Razr phone. ESPECIALLY when it comes to working with the phone book. One of the executitives of one of my clients wants to change all of the phone numbers on his RAZR and have different "profiles" as he travels internationally, and he wants them synced up to the database in the home office. Motorola has locked out the RAZR's native phone book to developers. Someone please please prove me wrong!

No international format support? (1)

beeblebrox (16781) | more than 8 years ago | (#15340570)

Has he tried +... numbers? I believe (but stand to be corrected) that it's up to the network to handle that.

Since you mention international travel I'm guessing he has a GSM RAZR (Cingular/T-Mobile). My SonyEricsson on Cingular handles international format numbers without problems, tested in the US, Canada and a couple of European countries so far.

Re:No international format support? (1)

Heembo (916647) | more than 8 years ago | (#15340810)

He has 300 India contacts, 200 British contacts - some overlap, basically different profiles for different countries. And the key is, he ONLY wants the right contacts in his phone for each country - and he wants to synch the new profile over the net via only his phone. If this was a Nokia phone, this would be a no-brainer. But Motorola LOCKS OUT developers from the native Razr phone unless they approve of your project via MotoCoder - a bunch of BS. Screw Motorola! Burn your Razr NOW!

Re:What a bunch of hogwash (1)

mgblst (80109) | more than 8 years ago | (#15342616)

This is true for all j2me phones. The run in a java sandbox, so have really limited abilities. This is the way they were designed, so no use getting upset at Motorola about it. If you find a phone that supports symbian (like some nokias) you have better control over the phone.

Re:What a bunch of hogwash (1)

Heembo (916647) | more than 8 years ago | (#15344616)

Ah, you must work for Motorola. The J2ME standard **does** provide an API to access the native phone book, except that Motorola purposely blocks that API unless you pay them to be some official vendor. The same API works seemlessly with Nokia/Symbian phones.

Re:What a bunch of hogwash (1)

mgblst (80109) | more than 8 years ago | (#15349506)

Isn't that a new api though? No, JSR 75 (just checked) so you are right.

SuperWaba (1)

Phoinix (666047) | more than 8 years ago | (#15340837)

From what I've read, Superwaba is better than the other claimed standard alternatives. Anyone has some experience in mobile Java development to confirm or refute that:

http://java.about.com/od/superwabamobilevm/ [about.com]

http://en.wikipedia.org/wiki/SuperWaba [wikipedia.org]

http://www.superwaba.com.br/en/swxj2me.asp [superwaba.com.br]
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...