Opinionated comments on mobile phone industry news
|
All entries are written by Anders Borg, CEO and Consultant of Abiro, that has a long experience in strategic planning, developing embedded and Java software, usability aspects, and the mobile phone industry in general. You can also read the latest Mobile News entries on your phone via wap.abiro.com, and we provide many News Feeds from popular news services. For advertising and contribution queries, please use the feedback form. News feed (local) FeedBurner Feed
|
|
Wednesday, November 15, 2006
Open source Java, what will it actually mean?
Laymen and developers alike misinterpret what the terms are from now on. I won't pretend I'm an open source expert in any way, so I might miss the point too.
Note that we are talking both SE and ME here, but for obvious reasons my main interest is ME.
My understanding is this:
* This till allow third party to develop enhancements to Sun's Java base code
* Enhancements need to be handed back to the community under the GPL terms
* Sun still provides the licenses
What I had hoped was that somewhere in here there would be a side effect of decreased fragmentation, but I don't find any.
ME is very different from SE in that SE is always used as is. There's no provider of variants of SE. In the case of ME it's quite different, where KVM providers make optimizations and other changes, and in cases write their own KVM altogether.
What I haven't figured is what happens from now on if a KVM provider or a phone manufacturer chooses to use the ME base code and then optimize it for its own purposes. Under the GPL terms such optimizations should be given back to the community, but those optimizations and changes could be quite extensive and even non-generic, and such have been done for years already. What happens with adaptations that are already deployed?
Theoretically, as the HotSpot VM is part of the open source "package", providers might in theory not need to make any optimizations, but then the question is what they offer in terms of value, beyond what's already in HotSpot and the configuration, profile and JSR implementations. JSR implementations beyond Sun's offering?
Quote: The initial release features a buildable phone implementation targeting mass-market handsets and the Java ME Technology Compatibility Kit (TCK) framework
I'll post more when I know more. As I said, I'm no expert on open source, so be gentle in your comments :).
More on this:
Free and Open Source Java Project Overview
Note that we are talking both SE and ME here, but for obvious reasons my main interest is ME.
My understanding is this:
* This till allow third party to develop enhancements to Sun's Java base code
* Enhancements need to be handed back to the community under the GPL terms
* Sun still provides the licenses
What I had hoped was that somewhere in here there would be a side effect of decreased fragmentation, but I don't find any.
ME is very different from SE in that SE is always used as is. There's no provider of variants of SE. In the case of ME it's quite different, where KVM providers make optimizations and other changes, and in cases write their own KVM altogether.
What I haven't figured is what happens from now on if a KVM provider or a phone manufacturer chooses to use the ME base code and then optimize it for its own purposes. Under the GPL terms such optimizations should be given back to the community, but those optimizations and changes could be quite extensive and even non-generic, and such have been done for years already. What happens with adaptations that are already deployed?
Theoretically, as the HotSpot VM is part of the open source "package", providers might in theory not need to make any optimizations, but then the question is what they offer in terms of value, beyond what's already in HotSpot and the configuration, profile and JSR implementations. JSR implementations beyond Sun's offering?
Quote: The initial release features a buildable phone implementation targeting mass-market handsets and the Java ME Technology Compatibility Kit (TCK) framework
I'll post more when I know more. As I said, I'm no expert on open source, so be gentle in your comments :).
Free and Open Source Java Project Overview
Comments:
Post a Comment
Links to this post:
<< Home
The fragmentation issue - if I understand you correctly - is more of a fork issue. At the press conference in SecondLife, it was said that forks were expected and encouraged - but only those that passed rigorous testing would get the Java name.
So I think it's controlled fragmentation... not sure.
So I think it's controlled fragmentation... not sure.
True, but troublesome all the same, as application developers only want to see one platform.
Different implementations will of course have different support for JSRs etc, but that's possible to control and adapt to, but outright bugs and "misunderstandings" is another thing.
I've found that the bytecode interpreter is never a problem across different providers, but class implementations definitely are.
Implementations passing TCK still have bugs, even in basic functionality, which indicates TCK is not complete.
Another issue is that there are no UI design guidelines for MIDP lcdui, at all. Of course these should inherit look-n-feel from the phone's base UI, but if one phone handles line breaks and another one doesn't, and one phone handles POPUP menus and another one doesn't (both supposedly being MIDP 2 phones) what's the developer supposed to do? Jump off the bridge? Revert to Canvas for everything? When working with enterprise applications that's definitely not ideal.
Different implementations will of course have different support for JSRs etc, but that's possible to control and adapt to, but outright bugs and "misunderstandings" is another thing.
I've found that the bytecode interpreter is never a problem across different providers, but class implementations definitely are.
Implementations passing TCK still have bugs, even in basic functionality, which indicates TCK is not complete.
Another issue is that there are no UI design guidelines for MIDP lcdui, at all. Of course these should inherit look-n-feel from the phone's base UI, but if one phone handles line breaks and another one doesn't, and one phone handles POPUP menus and another one doesn't (both supposedly being MIDP 2 phones) what's the developer supposed to do? Jump off the bridge? Revert to Canvas for everything? When working with enterprise applications that's definitely not ideal.
Post a Comment
Links to this post:
<< Home
