Participate
Idea Closed (Closed: 06/03/2010 01:37 PM BST) |
|
This idea has expired |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
| |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
After mulling over the comments on a post over at William's blog, I wonder if it'd be possible to provide a separate J2ME runtime for download (similar to how it was implemented on Palm OS) or shipped as an installer in the firmware image that automatically installs on the first boot of a device, to work around the myriad of issues related to integrating J2ME into the Symbian Platform itself... Just a thought, and I can see that it might be unworkable/have unique problems of it's own. 
Posted on 04/27/2009 04:05 PM BST
, Last Modified on 06/03/2010 01:37 PM BST
 Comments (14)
I also read the comments on William's blog, however, I'm not sure if you talk about Sun JME? That has a non-free license, right? That is, Symbian devices could be shipped without Jave being included by default (they would be cheaper due to that vendors wouldn't need to pay the license fee) and users could download the run-time separately and pay for it? If not choosing "Sun's way", then create our own JME implementation and deviate from the already very fragmented ecosystem? Well, somehow this needs to be resolved ...
1
 
1
For the sake of completeness, I'd like to see devices ship with a preintegrated J2ME Runtime, although Sun's J2ME Runtime is GPLed which has it's own set of problems (given that it has to be heavily integrated into an EPLed OS) which led to me suggesting that it could be shipped separately. Of course, I believe that IBM have a J2ME Runtime, and there is the Esmertec VM (although I'm not familiar with it) although I don't know if they're willing to provide a redistributable. Does anyone know about Nokia's runtime?
1
0
I personally don't think it is a good idea to get J2ME out of Symbian devices. Today I feel proud to have a Symbian device, just because, it supports so many applications, and half of them being J2ME based too.
As far as J2ME platform as separate download, I don't think many non-technical persons would do that, as we see around, common people just download applications, and use them, nothing beyond that...
I would love to see J2ME platform stay with Symbian.... So strictly there should be no WORKAROUNDS for this important platform...
P.S. I am myself a Symbian developer, not a J2ME developer, but I do use so many of J2ME applications...
2
0
I couldn't agree more. I also use Symbian OS for the rich and deep set of APIs and runtimes, and would hate to see Java removed, given that it would mean that folks couldn't run a lot of 3rd party applications (the Google stuff, and a myriad of games come to mind). It'd make the platform less attractive that way, too (since users would think "This dumbphone runs Java applications. Why doesn't my nice new Symbian OS smartphone?")...
1
0
Hi everyone, this is an excerpt from the slideset that was presented by Nokia during the working group sessions back in december last year; it is a proposal to provide Java for the Foundation; the idea was to have a non-Foundation package to replace the existing Java environment on S60: Slide 5 .O {font-size:149%;}
AFAIK, there hasn't been any update on the subject so far. I can bring the subject up in one of the Foundation forum if necessary, but since this is one of those 3rd party IP issue, it is supposed to be dealt with by Nokia...
3
0
I welcome the idea of Apache Harmony project being used to deploy a widely used open source Java VM to Symbian devices, but what are the cons besides the advantages (popular, suitable license, etc.)? For example, would we go for a (full or not) JSE implementation? How much effort would it require to make it suitable to be used in mobile environment? Would it make sense (technically and from business' point of view) to use an already existing mobile port e.g. Android?
1
0
Hmm, how much effort would it take to retrofit Dalvik to support J2ME/standard Java bytecode? I doubt it'd make much sense, and having compatibility with Dalvik bytecode probably won't be that useful, given that Symbian OS doesn't have the Android-specific APIs, and only has a small subset of "real" Java APIs.
0
0
Hmm, how much effort would it take to retrofit Dalvik to support J2ME/standard Java bytecode? I doubt it'd make much sense, and having compatibility with Dalvik bytecode probably won't be that useful, given that Symbian OS doesn't have the Android-specific APIs, and only has a small subset of "real" Java APIs. I don't think we should start thinking about how the two (Dalvik and a standard JME VM) would fit together, since I feel that there would be major contradictions between the two that we couldn't resolve without investing too much in it. For example, Dalvik relies on that an application runs in its own VM, whereas in JME everything is running in the same sandbox. Then, according to Wikipedia regular "JME VMs are stack-machines whilst Dalvik is a register machine". The problem is that I can see the cons of making use of Dalvik, too. The biggest one being that we would adopt a non-widely used not-yet-standard (will it ever be?) technology that has not proven yet. Well, some could say that JME has already proven and it proved that it's not worth living, but still: is Android the right way?
2
0
I talked to the head of Java product management in S60 software in Monaco. It's not all finalised yet but you can be sure the Symbian Foundation will have a Java solution, sooner rather than later I understand. The key point is that there are other Java ME VMs than the one provided by Sun. I believe there have been updates since the slide provided by Fred (was that a public piece of info? :-) ). In parallel, I talked to Benoit from Qt, who knows someone on the board of one of the VM vendors who'd approached him (as a kind of back channel) about contributing their VM to the Symbian Foundation. So having had independent confirmation from two channels I'd say just wait and let the people involved sort it out. There will be something and it will be open source is what I took from the conversations. As Gabor says though, it's all a bit irrelevant apart from tidying up a hole because Java ME is slowly but surely dying. It'll be around for a long while but I expect adoption and usage to fall and improvements to have very little investment.
2
0
Great stuff, Mark! Is it worth closing this thread, if that's the case? Or do we have to/should we let it run it's course a little longer, just in case anyone has other ideas, or the Big Plan(TM) falls through?
0
0
This is a difficult subject for a number of reasons:
That said, if you look at the popularity/relevance of the various languages at the Tiobe Programming Community Index it's difficult for Symbian to ignore Java. As a result, we are pro-actively working with Nokia and their VM provider (IBM) to provide a Java solution (under an R&D agreement) in the forthcoming Symbian releases. We have spoken to other players in the industry, but all are tied to IBM or SUN in some way. Longer-term, we'll be working with the community to find a Royalty Free solution to the Java problem. Bearing in mind, google had this conversation some time ago and came up with "Dalvik" as their solution; unless attitudes have shifted 180 degrees we may need to consider something as radical ourselves. I support the spirit of this idea, but I'm not generally supportive of workarounds which add complexity for developers and end users. As such have voted to scrap this particular idea, but please keep the constructive dialogue and ideas flowing around runtimes....
Robert Technology Management - Runtimes
2
0
Any more news/progress on this, out of interest? I think the horse has already started to decay though, so there's probably no point beating it some more, I assume...
0
0
A little, but not positive. The third party vendor who had expressed an interest in contributing their VM didn't actually want to give it away for free (and it wasn't free of Sun IP anyway). This leaves the main option as a rather longer term clean-room implementation approach... still not 100% decided as far as I'm aware, but not a dead issue yet either.
1
0
Hello, I'm working as a new product manager for Nokia Symbian Devices Java implementation (S60 Java Runtime). I'd just like to say that we are working on this issue still. The VM has been one critical pieces for this to happen since most other parts we have already available that we could contribute to. (See for more discussion on other thread.) But on the other hand from app developer's perspective, in Java ME implementations VM is just one piece of the puzzle. E.g. reagarding application compatibility the set of API implementations part of Java Runtime actually is more interesting than the VM itself. If VM is anyway stable and confirming to the VM specs apps will run OK; there's of course performance differences but regarding whether existing Java applications really work depends on API impelmentations. So I actually find the API implementations to be common/same across vendors more important than that the VM is the same. That way there's more guarantee that the behavior of the application is the same in different vendor devices. There was a question of Nokia's Java Runtime. Nokia has currently two different runtime implementations for Series 40 and S60 devices. (In past there was different Symbian UIs e.g. Series 80 and so on they all had the core parts of the runtime from the same codebase but "visible" parts of the UI implemented differently.) In current S60 implementation out there in devices the core parts are stemming back to Symbian OS Java implementation. See the above linked thread, I talk there a little bit of a re-write of core parts we've recently done. The actual VM in the S60 implementation has changed during the time. Currently IBM J9 VM is used (from 3rd ed fp 2 devices onward). If you want to check it this is visible to developers e.g. when getting debug outputs (System.out etc.) ;-) The API set is implemented by Nokia. The same goes with Series 40, Nokia has it's own implementation for APIs. The APIs in many cases are very integrated to platform functionalities. Similarly other functionalities like security, drm, installation and application management (how to start apps etc.) etc., they are all very closely integrated to platform and Nokia has it's own implementation. In S60 this is visible e.g. so that end user doesn't need to distinguish that an application is a Java app vs. native app: they both end up in application shell and can be added to home screen as links etc. In some other devices where 3rd party Java ME solutions are used this may not be the case but Java apps are more treated special. Unfortunately close integration means that these parts of the code are platform dependent. In the re-write of core parts we've done we've tried to keep end user visible integration where's it's essential but still have done code so that it could be possible ported to other platforms too. We've used as much of possible Java code and in native parts used standard C/POSIX APIs (in Nokia terms OpenC/PIPS etc.). In UI we are in future relying on Qt, which is cross platform. And this we can run this exactly implementation now currently also on desktop (nice for tools, development time both runtime dev and app dev.) :-)
1
0
|
Sign in or Register
Idea Stats
Team Members
Similar Ideas
Who Else is Viewing0 Members, 0 guests
Email Group |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
/ 2 