Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Programming IT

Five Years On, Has J2ME's Time Finally Arrived? 93

Posted by michael from the no dept.
jg21 writes "Although he admits to having been frustrated by the slow adoption of the J2ME platform, software developer Eric Giguere believes that we're 'turning the corner.' He remembers Sun demonstrating Java running on Palm OS 'way back in 1999 when so many hoped the wireless Java revolution was just around the corner. Five years on, with notable successes such as the J2ME-enabled BlackBerry wireless handheld, that has already made a billionaire of RIM founder Mike Lazaridis, Giguere claims that, with most of the new handsets being produced supporting either JTWI or else its key component - version 2 of the Mobile Information Device Profile (MIDP) - developers finally now have a more consistent and capable platform to use for application development. Anyone wandering round this week's CES may be inclined to agree."
This discussion has been archived. No new comments can be posted.

Five Years On, Has J2ME's Time Finally Arrived? More

Five Years On, Has J2ME's Time Finally Arrived?

Comments Filter:

  • Java Orphans? (Score:4, Interesting)

    by 4of12 ( 97621 ) on Thursday January 06, 2005 @03:21PM (#11280017) Homepage Journal

    Not to be a troll, but what is it with all these intriguing Java products, free for downloading, that don't go too far?

    • Jini
    • Java 2D
    • Java 3D
    • Java Mail
    • etc.
    Is it that they are insufficient, too expensive, not completely open, or what?

    • Re:Java Orphans? (Score:2, Insightful)

      by Anonymous Coward
      of the 4 you mentioned, only JINI is, as far as I know, not being extensively used...The others are APIs that are incorporated into J2EE or J2SE products to provide functionality. For example, JavaMail is the API that's used when you want to send and manipulate email.
    • Most companies have a preferred language. If you're developing in java, then the products you mention will just be more reasons of why you *can* do what you want using java. It's flexible like that.

    • Re:Java Orphans? (Score:3, Insightful)

      by sporty ( 27564 )
      They stay as sperate products unless they pick up enough steam.


      Java2D got integrated as anyone who uses swing will want it. I think jini is included, but i'm not sure. Java mail, i'm sure will be in a j2ee implementation soon enough.


      Instead of flat out bloating the API by adding stuff, ala php, they incubate it out in the wild.

    • every time someone sends an email from a java application.

      Granted, it's not the easiest API in the world and I greatly simplified all that complexity into:

      Email email = new Email();
      email.setRecipients(String[] recipients);
      email.setSender(String sender);
      email.setSubject(String subject)
      email.setBody(String body)
      and finally...

      boolean success = email.send();

      But the code implementing this is quite a bit more, required a long time debugging the mail relay issue (required authentication!), and othe

    • Well, Java 2D has been part of the Standard Edition since version 1.2, so I'm not sure what you're on about there.

      As for the rest.. The strategy is perfectly clear. Sun makes a bunch of java add-ons in the com.sun.* heirarchy and releases them. If they catch on, they eventually get integrated into Standard Edition.

      Swing, Sound and ImageIO for instance.

  • Anyone? Anyone? (Score:1, Insightful)

    by AntsInMyPants ( 819105 )
    A slashdot story on the front page this long with no replies? Maybe the real question is, Does any one care if J2EE is ready for primetime.
    • did you mean J2ME? or you are confusing J2EE with J2ME?
    • We don't care, because we've all moved past java. Spend long enough programming in Python or Ruby and Java starts to look like combining the performance of those languages with the ease of programming of C.

  • ...slow adoption????? (Score:3, Informative)

    by gl4ss ( 559668 ) on Thursday January 06, 2005 @03:58PM (#11280539) Homepage Journal
    HELLO????

    open any teenager magazine(at least in europe) and half the adverts are for j2me games(and ringtones.. sigh.).

    and practically all phones are coming with j2me now...

  • Sorry, but running code in a Sandbox (separated from the DATA) makes it pretty much worth a pinch o' bat guano.

    The alternative, of course, is Active X, but that's like sharing dirty needles.

    There needs to be a happy medium where it is easy (i.e., happens automatically) to have the program get access to the OS's API, but some things are protected. Whoever can figure that one out will win a prize.

    • Re:J2ME is worthless (Score:1, Informative)

      by Anonymous Coward
      Does anyone know of a real (not vaporware) on-device debug capability for a J2ME device? There was supposed to be one for the KVM I was using but it really just wasn't there at all.
    • J2ME adoption has been tremendous. Go read Java Turns 5! [sun.com]. This means there is an opportunity out there to make some dough by creating J2ME-based solutions. Up to you if you want to take advantage of this opportunity...

      ceo
      www.j2medeveloper.com
    • Wait .. you mean that J2ME isn't Java for Windows ME?
    • Sorry, but running code in a Sandbox (separated from the DATA) makes it pretty much worth a pinch o' bat guano.

      Can you present some case to your proposition or are you expecting that people take it axiomatically? I wonder why a perfectly good method for code security is not good. And for old ActiveX, Microsoft is doing pretty much the same as Java in .Net.

    • Re:J2ME is worthless (Score:4, Interesting)

      by hey! ( 33014 ) on Thursday January 06, 2005 @10:41PM (#11284514) Homepage Journal
      Well, not necessarily. Midlets are sandboxed for good reasons -- the last thing you need is to have your phone acting like IE with pop up ads, spyware etc.

      That said, if sandboxing is a problem there is always personal profile if you are working on PDAs. It is pretty much just a slimmed down J2SE with pretty much all the access to the hardware you'd need, with AWT, which may not be your favorite toolkit, but is sufficient for PDA work. IBM's Websphere has SWT on PocketPC, which is clean and nice.

      Even sandboxed, there are lots of useful applications that could be written other than the more or less pathetic games that seem to dominate this space.

      I see two main issues with J2ME as a whole. The first issue is that performance is so limited. The ones I've used are OK once JIT has had a chance to do its magic, but getting the application off the dime on startup can be pretty painful. A lot of applications for mobile development require responsiveness. The Pizza delivery guy is going to freak if his delivery tracking program takes twenty seconds to launch while he's sitting on the doorstep.

      You could locate a lot of your business logic off the phone, but in that case you might as well consider going browser based.

      The second issue is that not many people have experience developing for such a constrained user interface. You just can't try to shrink down the same old things you do on a VGA resolution monitor to a PDA or worse yet a phone. There's a shift in style you have to make that takes some practice.
      Actually, trying to do some non-trivial stuff on a PDA is good design exercise, and changes the way you look at other kinds of user interfaces.
    • there's a file access api, too, available in at least nokia 6630 to my knoweledge(and really, there's a way to store data otherwise anyhow).

      so, basically, someone already won your prize. the phones offer some access to os api, leaving some inaccessible.

      and i don't really get why you couldn't have data _in_ the sandbox.

      but you don't really sound like you got a fucking clue about what you're talking since you've thrown in activex too, which is not really in use anywhere in the millions and millions of j2me

  • Here's a working link (Score:3, Informative)

    by Eric Giguere ( 42863 ) on Thursday January 06, 2005 @04:52PM (#11281283) Homepage Journal

    Here's the actual working link [javadevelo...ournal.com] to my guest editorial.

    Eric

    • Re:Here's a working link (Score:1, Funny)

      by Anonymous Coward
      Eric:

      You're a respected Java developer...do you actually think you'll get good discussion from a site populated by script kiddies who think PHP is the answer to everything? C'mon, when you see people comparing J2ME to ActiveX, or mistaking J2ME for J2EE, you really are in the wrong place...

      Slashdot makes javalobby look like a respectable forum! ;-)

  • Why it won't gain ground (Score:3, Interesting)

    by trajano ( 220061 ) on Friday January 07, 2005 @01:04AM (#11285254) Homepage Journal
    I tried to develop some applications for my cellphone using J2ME, unfortunately when I did try to do it I found several limitations. Primarily because it does not take advantage of features provided by the device.

    Although for the most part J2ME is meant to be as portable for as many devices as possible, it would've been nice to provide facilities to manipulate common PDA features such as: address book, calendar and todo list. I was surprised I couldn't even touch those when I was doing MIDP development before.

    J2ME is more about connectivity to remote systems which may be good for business applications, its also very expensive to deploy because of the costs of cell phone air time. Still its not too bad.

    With J2ME and all the drawing facilities, another common application type you can build with this are games. I've seen a few java based games and they're not too too bad.

    I think it would gain ground if Symbian releases a library that provides direct access to its core facilities such as changing the screen saver, the background images, and replacing the application menu. Mind you there are applications that do these already, though you have to pay for it for something so simple, although setting up the C development environment for Symbian is difficult too.
    • I tried to develop some applications for my cellphone using J2ME, unfortunately when I did try to do it I found several limitations. Primarily because it does not take advantage of features provided by the device.

      This is why MIDP2.0 is a good thing, which was the point of the article. Did you RTFA? :)

      Seriously though, this is also a benefit as well as a drawback. If java had an all-encompassing API, it would likely be too big for a lot of handsets, cost too much to implement, and therefore fail as a l
      • I did use MIDP2.0 when developing, and all it had were simple forms, networking and a 2D drawing engine. From what I saw of the API it didn't have any of the contact management features I was originally looking for.

        As far as security implications, we already have code signing to check for trusted sources.

        As for the title, I still think it won't gain ground unless Symbian provides APIs to take advantage of the phone's capabilities, combined with Sun providing a Service Provider Interface with some common

    • I think it would gain ground if Symbian releases a library that provides direct access to its core facilities such as changing the screen saver, the background images, and replacing the application menu.

      Well... Those are exactly the kind of things I do not want a random application to touch. If there is good reason why a 3rd party application should get to set my phone wallpaper, I'd like to hear it. I'm not picking a fight here, I'd really like to know if you have a reason for a move that (in my book)

      • That's why we have code signing in-place with a lot of J2ME. Without those facilities, its like working in an unsigned applet on a web browser which allows you to do just plain networking and graphics.

        If that's the way of the future, Sun wouldn't have developed Java Web Start to provide full access to the machine as long as it asks permission first.
  • J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

    J2ME MIDP 2.0 was better in terms of features, but little else.

    If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?

    Put down the SUN cup with MicroJava and get into rehab.

    • By the way, is there anyone into developing J2ME games or applications? I'm working for a QA company and I have some questions regarding the mobile market...

    • Re:J2ME? (Score:2, Interesting)

      by mooZENDog ( 567187 )
      J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

      With respect, I don't think it was the MIDP1.0 that fragmented the market (after all, it was a specification) - just the fact that the different handset manufacturers implementations of MIDP1.0 were different is what produced dissimilar results.

      If anything, MIDP1.0 united the market (nowadays, nearly all handsets come with a MIDP implementation) because it had a broad enough scope and was small en
      • J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

        With respect, I don't think it was the MIDP1.0 that fragmented the market (after all, it was a specification) - just the fact that the different handset manufacturers implementations of MIDP1.0 were different is what produced dissimilar results.

        Beg to differ, MIDP 1.0 had so many holes that device manufacturers were "free" to fill in the gaps for their devices in any way that they could to make it wo
  • I do not care that J2ME is on its way out the door, for a one simple reason. In 5 Years do you think we are going to need a Mobile Edition of any platform, Hardware will beable to run everything we run on our desktops today.
  • Coincidentally, I'm working on a J2ME project within my internship right now.

    I've been running into this really frustrating problem of code running flawlessly on emulators, why they refuse to even start on actual devices (I only tested it with Nokia devices sofar). You click on the application, and nothing happens. You just remain in the application selection menu.

    the culprit is always a certain part of the code. If I comment it out, it runs fine on the device as well. But that's what makes it so weird: a

    • I really can't imagine how one could do any serious development if the emulator on one's development machine isn't 100% compatible (or at least as close to 100% compatible as possible) to the real thing.

      Trust me, this is not an uncommon situation in mobile/handheld programming -- it's not unique to J2ME. Hard to say what exactly is the cause of your problem without seeing any code. What does the code look like?

      Eric
      Eric's J2ME Pages [ericgiguere.com]

      • Well, before I actually place any code snippets here (it might be contractually problematic), I could describe it briefly.

        I wrote a function (part of a MIDlet) that parses an XML file using the KXML2 library.

        In a separate MIDlet, I had tested this code with a simple form, showing the output. That worked, both on the emulator and on my device (my trusty Nokia 6600).

        Then I tried to use this code in my main MIDlet. I tried launching this function from a thread, which itself would be launched from within a C

        • When a J2ME application won't even start, it usually indicates some kind of verification error. This will often happen if a required class is missing. Are you included all the kXML2 class files in your MIDlet suite? Don't forget that you need the pull parser classes as well. I always just put the source for these right into my projects, they're so small it's the simplest solution.

          Eric
          • Hey, this is odd: the MIDlet started working om my phone after I had removed the Bouncy Castle midp_classes.zip from the Java build path!

            But the Bouncy Castle classes don't give any problems until I use any code that employs KXML2.

            I assume that the reason why it only goes wrong why I actually include the function call is because the obfuscator removes the entire XML parser code when it sees that the function is never called.

            However, midp_classes.zip continues to stop de MIDlet from running, regardless we

            • I've had problems with Bouncy Castle, yes, and again it was simpler to extract the classes I needed from the Bouncy Castle library and include them directly. I'd do that. I don't remember what it was exactly, but it was easier to just package what I needed directly with the app.

              For those who are confused: Bouncy Castle [bouncycastle.org] refers to an open source Java cryptography library developed by the Legion of the Bouncy Castle. (Dumb name, but good code. Better than the reverse!)

              Eric

              • Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

                At least I can continue working on my project now. The encryption part would have been of later concern anyway.

                I have one different question for you, though:

                If I have to retrieve data from several url's (PNG images, XML data, etc), then how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog, ins

                • Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

                  I was able to extract the encryption classes I needed. See my tech tip Data Encryption for J2ME Profiles [sun.com] for details.

                  how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog

                  This depends on the device, but in general with MIDP 2.0 you can use the permissions mechanism to basically have the u

Slashdot Top Deals

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Close