×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Implementation consistency

    The developers of standards should think carefully about adding more API functionality, without addressing the issue of implementation standards.

    Developers aiming to release products on a wide range of devices (notable game development houses) face a huge and ever-growing cost of supporting multiple devices. This expense will soon become prohibitive for all but the largest companies.

    Testing standards for Java applications (Java Verified), driven by device manufacturers, force developers to cope with the failings of the devices they must support. Yet device manufacturers are able to use the Java name, in some cases with a disasterously poor runtime implementation.

    In the world of mobile, Java falls short of it's "write once, run everywhere" philosophy.

  2. #2
    Registered User
    Join Date
    Jun 2006
    Posts
    3

    Re: Implementation consistency

    I agree that there are a lot of problematic virtual machines already installed in different mobile phones on the market. They all claim to be MIDP-x and CLDC-x complaint but the truth is that they are far from it and not reliable at all.

    Anyway, in my experience these poor KVMs implementations are available mostly on phones based on different platforms but had no choice but to include some form of Java compatibility. A lot of people are not going to buy a phone if it is not Java enabled no matter what. It is a fact that that Java phones are associated with the huge availability of free applications and games on the internet.

    So what happens is that the user gets a poor experience from the Java applications. In contrast, the user gets a good impression from all the native applications from the platform. I am not sure it is completely intentional but it happens for sure.

    Although Java on mobile phones presents it issues, it is still the most disseminated mobile platform available. So if you are not targeting some specific new feature and want to expose your application to a broad audience, is your best shot.

    I really miss a completely horizontal platform but lets face the reality. You could not have expected it to be so easy, right?
    David Jose Momenso

  3. #3
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Implementation consistency

    I expect it to be easier.

    Of course, there is no "write once, run everywhere" for anything but a fairly basic product. Differences in screen size, heap size, storage size, performance, API availability, etc. mean that you need many different JARs to support multiple devices, if you want to exploit what devices can do.

    However, even with the slickest development and porting process, the porting will invariably cost more than the development.

    Ironically, this is not the case for BREW, a native, C/C++ based platform. Not even on Motorola and Nokia devices, where BREW has been added as an after-thought. There is far more consistency in API implementation.

    Most of the Java porting effort is simply to work around bugs in the implementations.

    MIDP-1 Series 60s leak memory for images.
    MIDP-2 Series 60s leak memory for 3D models.
    Many devices have problems with transparency in PNGs.
    Some devices cannot execute drawRect() or drawLine() correctly.
    One Samsung has a completely non-functional HttpConnection.
    Several devices return incorrect values from Font.charWidth() and charsWidth().
    Drawing text or primatives to mutable Images crashes some devices.
    Numerous devices have problems with setClip().
    On at least one Motorola, the Vector class is missing the copyInto() method.
    Many Sony Ericsson devices can be completely destroyed by Java apps.
    Some devices return 0 rather than -1 at the end of a stream.
    Many devices don't deliver keyReleased() events for all keys.

    I could go on. A particular problem is the handling of interrupts. Java Verified (sponsored by Sun and by manufacturers) requires applications to pause gracefully on an interrupt, and then to resume in the same state (or a paused state if appropriate), and to have no adverse affect on the device. Many devices make this requirement a complete nightmare to meet.

    Sun have a (very expensive) test kit for MIDP implementations. Sadly, there is no requirement for manufacturers to use it.

    End of gripe.

    Graham.

  4. #4
    Nokia Developer Champion
    Join Date
    Feb 2006
    Location
    Santiago, Chile
    Posts
    83

    Re: Implementation consistency

    Hi Graham,
    I was shocked when I read this:
    "Many Sony Ericsson devices can be completely destroyed by Java apps."
    Can you elaborate on that?

    Also, is there a guide/site/thread that lists all the issues you mention? (and maybe the workarounds)

    Cheers,
    AW


    Quote Originally Posted by grahamhughes View Post
    I expect it to be easier.

    Of course, there is no "write once, run everywhere" for anything but a fairly basic product. Differences in screen size, heap size, storage size, performance, API availability, etc. mean that you need many different JARs to support multiple devices, if you want to exploit what devices can do.

    However, even with the slickest development and porting process, the porting will invariably cost more than the development.

    Ironically, this is not the case for BREW, a native, C/C++ based platform. Not even on Motorola and Nokia devices, where BREW has been added as an after-thought. There is far more consistency in API implementation.

    Most of the Java porting effort is simply to work around bugs in the implementations.

    MIDP-1 Series 60s leak memory for images.
    MIDP-2 Series 60s leak memory for 3D models.
    Many devices have problems with transparency in PNGs.
    Some devices cannot execute drawRect() or drawLine() correctly.
    One Samsung has a completely non-functional HttpConnection.
    Several devices return incorrect values from Font.charWidth() and charsWidth().
    Drawing text or primatives to mutable Images crashes some devices.
    Numerous devices have problems with setClip().
    On at least one Motorola, the Vector class is missing the copyInto() method.
    Many Sony Ericsson devices can be completely destroyed by Java apps.
    Some devices return 0 rather than -1 at the end of a stream.
    Many devices don't deliver keyReleased() events for all keys.

    I could go on. A particular problem is the handling of interrupts. Java Verified (sponsored by Sun and by manufacturers) requires applications to pause gracefully on an interrupt, and then to resume in the same state (or a paused state if appropriate), and to have no adverse affect on the device. Many devices make this requirement a complete nightmare to meet.

    Sun have a (very expensive) test kit for MIDP implementations. Sadly, there is no requirement for manufacturers to use it.

    End of gripe.

    Graham.

  5. #5
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Implementation consistency

    Quote Originally Posted by awoywood View Post
    I was shocked when I read this:
    "Many Sony Ericsson devices can be completely destroyed by Java apps."
    Can you elaborate on that?
    Early firmware K500 and K700 devices can have problems with 3D games. In rare cases, the device will stop working, permanently. Early JP7 devices have problems with file-system corruption.

    Quote Originally Posted by awoywood View Post
    Also, is there a guide/site/thread that lists all the issues you mention? (and maybe the workarounds)
    I just picked a bunch of issues off the top of my head, as an example of the kind of problems faced by J2ME developers who want to support a large number of devices. (And who may be forced to support a large number of devices, in order to hit certain sales channels.)

    Any company that develops to a large device list will have a list if issues like these. Probably, thousands of issues like these.

    Some manufacturers will publish some bug lists (see Known Issues in the Nokia 6600 as an example). Most bugs must be discovered the hard way, and then you have to devise a work around. In many cases, there simply is no work around.

    Cheers,
    Graham.

  6. #6
    Nokia Developer Champion
    Join Date
    Feb 2006
    Location
    Santiago, Chile
    Posts
    83

    Re: Implementation consistency

    Graham,
    indeed, we also have a list of issues, but the SonyEricsson-destroy-bug was new for me :-)

    Its strange to see that many companies offer porting services or software (tira, mobile-distillery) and nobody offers a list of issues by model, simply as that... I would buy it.

    Regards,
    Alejandro.

  7. #7
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Implementation consistency

    Well... Tira Wireless are dead.

    If you're a porting shop, information like that is part of your competitive advantage. I used to be the development manager for the mobile device porting team at I-play, so I know how much we invested in building our device knowledge. We'd never have allowed our competitors to get access to it.

    It's a double-edged sword. J2ME games are not really rocket-science, and I've seen quite good games written by under-graduates in their spare time. But the whole porting and testing thing stops them entering the market. The big organisations benefit from it, in a way.

    On the other hand, the spiralling cost of porting is J2ME's biggest enemies. It is this that drives developers away from J2ME, and towards Symbian, i-phone, Flash Lite, where they can hit a good sized market with one build.

    Cheers,
    Graham.

  8. #8
    Nokia Developer Champion
    Join Date
    Feb 2006
    Location
    Santiago, Chile
    Posts
    83

    Re: Implementation consistency

    It's true that the porting knowledge is a entry barrier for new developers, perhaps that is one of the biggest advantages of iphone. In J2ME there are simply too many things to care about: distribution, permissions/signing/java verified, porting.

    But again, there are so many java phones out there, and also so many developers, and no company between both to make things smoother. I believe porting alone is not a good bussiness. You're dealing with the complexity of a process, not really adding value to it. Maybe that happended to Tira.
    There is a need to make the whole process easier: from developing to receiving the royalties.

    That should be the job of an initiative like Ovi! Everybody would develop for Nokia ... if the whole process was more fluid and self-contained than now. For instance, requiring the verifying or signing with third parties is a really a bad idea. Nokia has a root certificate in most phones!

Similar Threads

  1. Nokia JSR 172 implementation: (1)Missing end tag for Body or Envelope
    By bgrand in forum Mobile Java Networking & Messaging & Security
    Replies: 2
    Last Post: 2008-10-30, 19:38
  2. Bug (?) in JSR-82 implementation
    By astfgl in forum Tools and SDK Feedback (Closed)
    Replies: 3
    Last Post: 2008-06-25, 13:52
  3. When does Nokia go to the Symbian SCOMO Implementation ?
    By emcneil@bitfone.com in forum OMA DM/DS/CP
    Replies: 0
    Last Post: 2008-05-07, 00:38
  4. Replies: 1
    Last Post: 2003-04-18, 04:30

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×