Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Motorola Seeks Mobile Unity at JavaOne 87

Posted by ScuttleMonkey from the shiny-happy-people dept.
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."
This discussion has been archived. No new comments can be posted.

Motorola Seeks Mobile Unity at JavaOne More

Motorola Seeks Mobile Unity at JavaOne

Comments Filter:

  • I think you mean... (Score:3, Funny)

    by MrNonchalant ( 767683 ) on Monday May 15, 2006 @01:35PM (#15336391)
    Write once, debug everywhere.

    Zing!
    • 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 th
      • 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?
    • 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?
    • 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.
    • Write once, debug till the end of time.

  • Good luck (Score:3, Interesting)

    by bunions ( 970377 ) on Monday May 15, 2006 @01:36PM (#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.
    • 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 (Score:5, Insightful)

    by feijai ( 898706 ) on Monday May 15, 2006 @01:38PM (#15336426)
    Until then, I'll still be stuck with intentionally Java-broken phones. Unity my butt.
    • 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!
      • 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 (Score:2, Informative)

      by Anonymous Coward
      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.
    • 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
  • 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.

  • Wha?? (Score:1, Flamebait)

    by gregarican ( 694358 )
    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.
    • 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. ;)
    • 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..
      • 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...
    • 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.

    • I downloaded Opera Mini - which is a Java app - the other day for my w810i, worked perfectly. Seems like it's possible to me.
  • 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...
  • I can speak only of myself, but since I started writing java code, I started running everywhere...
  • 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 (Score:4, Insightful)

    by deanj ( 519759 ) on Monday May 15, 2006 @02:27PM (#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.

    • 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 mod

  • Motorola/Nextel was good for J2ME (Score:4, Interesting)

    by FerretFrottage ( 714136 ) on Monday May 15, 2006 @02:31PM (#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.
       
    • "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.
    • JSR 179 is the standard for J2ME location services. http://www.jcp.org/en/jsr/detail?id=179 [jcp.org]
    • 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.
      • 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 (may
  • 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...
    • 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.

  • Right when I think I've gotten that song out of my head, too!
  • 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)

  • write once (Score:1, Flamebait)

    by Arandir ( 19206 )
    Motorola's goal is "write-once, run everywhere" implementation capabilities.

    It would be nice if Java itself could have that capability...
    • 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. 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

  • <troll><spam>Love it or hate it -- ah never mind, just hate it. Eclipse sucks [faroutshirts.com].</spam></troll>
  • 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!
    • 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.
      • 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!
    • 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.
  • 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]

Slashdot Top Deals

After all is said and done, a hell of a lot more is said than done.

Close