Hello all !

So there are rumours going around, that it is categorically impossible to access native functionality from a Midlet. I understand where you're coming from and would like to share with you to the following generic workaround :

How many of you have tried the following:

1) Open a server side socket in "C++" on 127.0.0.1 and start listening.
2) Connect to it from a client socket in your midlet
3) Open a java. lang.OutputStream and if you need to an InputStream, too
4) Send commands via OutputStream
5) Receive them on the server side and handle them
6) Feed back any results if needed
7) Enjoy the fruits on a Java level

For Symbian, you can see code for a suitable EXE file under:
http://www.symcpp.com/solution/

I was recently astonished, that it works really easy on Windows Mobile, too.
So I would be cheeky enough to say that it might even be a platform independent workaround. That's good news isn't it?

Here are some FAQs on the topic:

1) You must be joking?? Everybody tells me ?t's impossible !

Yes, that seems to be one of the reasons why it took so long to become public. It's a psychological thing, if you're told something is impossible, you're discouraged to put in the minimum effort necessary to prove them wrong, aren't you?

2) I have heard rumours and ideas of the concept on the net, but never have seen any code.

Yep, that's what I started off with too, but I followed the idea thru to the end.

I'm pretty sure that lots of commercial parties are using the technique, but AFAIK nobody has made it public so far. As for code, for Symbian there'll be lots soon and for Windows it's so easy that it's not really necessary to document in depth.

3) What are the limitations in terms of native function types you can access?

AFAIK very few limitations. However, the required labour is very high in complex cases. In easy cases, it's low.

4) Does this mean, that you need a native program resident all the time?

Yep, that's the price to pay. But it can save you from a total native rewrite!

5) What about autostart / Start on boot behaviour for the native daemon?

That is often desirable and there are several options in Symbian. I'm sorry, but I haven't researched the scenario on Windows Mobile yet.

For further information, feel free to contact me: arvvv@gmx.net
or checkout the website :-) (http://www.symcpp.com/)

 

 

That's not really platform independant. You have to write (platform dependant) C++ code for each handset.

Have you tested this extensively, and if so how was the performance?

 

 

True, you need a native agent all the time. When I said "platform independent" I was referring to the concept as such (localhost mechanism).

Yes, I've got instances of this implemented commercially. Two on Symbian and one on Windows Mobile. The "performance" of them are pretty pleasing because they make projects possible, that were not otherwise. In terms of efficiency, there are hardly any drawbacks because sockets communicating via localhost are very fast.

Hope I could help, regards.

 

 

It still is impossible...


No it's not at all... first of all, there is no common API that let's you access functions, and secondly, using C++ is in affect platform dependant. Futhermore, on 99% of the phones out there, you cannot even install anything else besides Java apps. Only the Symbian, linux and windows phones can do that, and for those, you could just as well develop a java that IS simply able to use native function (still making it non platform independant).


It's not as if you've shown us a miracle or something. It won't still work on the majority of the phones... It's not psychological at at all, It's just in the spec.


Sure there is no code, very logical, since it is not platform independant... Why use the technique anyway... If you are already using C++, and your app is not going to be platform independant, why use java also. I'd go C++ all the way...


Platform independantness is the biggest limitation...


You can't rewrite something that wasn't there in the first place. Since native functions are not possible in j2me, the things you want to do, could not be done. In effect, there is no code. So you'll have to start over anyway..

 

 

Thanks for your feedback deepspace,

you've pointed out nicely the platforms it applies to. Of course, one has to be able to install native programs.

So the platforms the workaround applies to are restricted to Symbian, Windows and Linux. Sorry for my over-enthusiasm when saying the workaround was "platform-independent". I only meant the localhost-localhost mechanism and the abstract concept as such. It does read a bit deceptively.

I also should have made clear that I'm talking about the Smartphone market only.


I agree that it is not a miracle, it's actually pretty straight forward. However, fact is that it has just came to the surface quite recently and is being frequently deployed. I would like to emphasise that it very well makes projects possible that were otherwise not. This is not speculation, this is history.


The CLDC provides sockets as a fairly safe loophole to the sandbox model. In the first moment, one might not think this is sufficient to access native functions. If additionally, you constantly hear this and that is not possible, you might be discouraged to even start bothering about a workaround.

This is not psycho-babble -> it's pretty easy to follow. Symbian itself was planning to make this workaround work long ago. There were two factors, why they didn't bother for a long time:

1) They weren't absolutely sure whether it worked
2) Like you, they questioned the added value in the first place

The added value has proven to be much higher than anticipated !


Sounds smart, but is it?
This workaround is especially interesting for people with an existing Midlet, who want to port it to another Phone Model. Let's say, on the target Model you're missing a JSR which is supported on your original Phone(s). You've got three main options:

1) A total native rewrite: Not economic and Java people dread it.
2) Dont' support this Model: That's what often happens in practice.
3) Use this workaround: Very ecomomic, powerful and fast. Especially if the Midlet is large and only one or a few native functions are in the way.

Fair play to you, if you prefer a total native rewrite. That means you're a good C++ programmer. Good for you. So am I. Not everybody is. Firms that want to focus on a consistent Java product can outsource the C++ bits to guys like us.

Symbian, at least, seems to be quite enthusiastic about the whole thing because there's going to be a Whitepaper released on the topic soon (which is already finished).

Thanks again for your feedback and regards,

 

 

Well, you have some interesting points that make me a bit more positive about this way of doing things ;)

Still don't see what is new and special about this thought. Middleware like CORBA have always used sockets to communicate between languages...

I guess, what is really needed on top of this, to make it much more platform independant, is a CORBA like, but much more lightweight middleware technologie to make the access to the C++ (of whatever might be used) much easyer and generic!

 

 

Hi there !

You're absolutely right. What I think you mean by "platform independent" is unfortunately, usually an illusion on present MIDP for mobile devices.

It's only possible for extremely simple Midlets that don't use any JSRs. As soon as you use them, you're already at the mercy of handset manufacturers, aren't you? I reckon, that's even worse than being at the mercy of a software supplier (like e.g. Adobe on the Desktop).

When using this workaround, you can patch any missing JSRs or protect yourself from becoming dependent on them. You can also patch together exactly the native functionality you need across different JSRs.

Other benefits I'm working on include:

1) Gain access to native functions that are not even accessible with current JSR sets. (with this workaround you can prinicipally access almost anything- really, for example I managed to route a list of running processes up to Java)

2) Let your Midlet appear as if it were a native app. (Many software vendors would prefer this, because they don't want their users have to access the Midlet Manager)

3) Make the hybrid (mixture of Java and native program) be installable and runnable as a single native program. This is just an illusion to the user - of course, there are several components to the architecture. But I believe you can make the user gather the impression, he's dealing with one native program. That would emansipate Midlets to native programs in this respect. Please also see my question concerning the PushRegistry !

On Symbian, I know how to perform 1 2 3) it's just 2+ 3) missing on Windows.

You're perfectly right - the root of all of these problems on mobile devices is a lack of true unification. Java's vision includes precisely that, but it has been jeopardised on mobile devices.


excellent ! I totally agree !
Just another truelly platform independent layer on top of device specific APIs that is accessible to Java or even better both Java and C++.

These C++ APIs are often not particularily developer friendly in the first place so you can add value by making them more usable.

That's exactly what I would have planned to start next (for Symbian first).

This workaround I'm talking about all of the time is often referred to as the "Bridge".
This "lightweight middleware technologie" is probably more than one single person can handle. If anyone is interested, I'll probably be doing some first proofs of concept on it soon. I've got plenty of ideas and will put them on the website http://www.symcpp.com.

Thanks again deepspace for the excellent feedback !

 

 

Nice plans!

One thing is still bothering me thought: The real reason why java cannot access vital phone functions, cannot autostart, and cannot run in the background: SECURITY

All of these "api" make spying on users, worms and viruses very easy!

 

 

Absolutely. It's difficult to maintain the best of both worlds:

1) Maximum flexibility, power and functionality for Java developers

and

2) Security - as described by you

Sockets have been granted as a way out of the sandbox. Because of the increasing need for security, it is questionable, whether the access to native functions will be relaxed in any other way, in the years to come.

That, however, precisely is the life insurance of the workaround / framework !
This framework would be obsolete as soon as, say, JNI were re-introduced.

Thanks again !

 

 

I'm happy to say, that the Symbian Whitepaper I was on about has now been released. It's called: "Extending the reach of midlets"

http://www.symbian.com/developer/techlib/papers/java_MIDP.asp
(top paper)

Greetings,

 

 

Arvind,
I note in the whitepaper that the workaround requires support for resolution of localhost address on the device, do you have a feel for whether this is generally available on symbian devices?
Regards
Frank

 

 

Hi Frank !

Interesting question ! I know what you're referring to now - it's probably the bullet at the end of the list of criteria, that have to be met in general:

"Local loopback support and resolution of "localhost" or 127.0.0.1 IP address."

This has never been an issue on Symbian nor on any other platform (Windows / Linux) that fulfills the other criteria in the list. The factor, that usually rules out the workaround is when you're simply not allowed to install native apps.

I know, in the paper, it reads, as if this might be some sort of additional requirement. However, in practice, devices that meet the first three criteria will automatically have no problems with the one you're mentioning.

It is a known issue on Symbian on the other hand, that some devices have the hang to invoke a lookup, if you use "localhost". So just use 127.0.0.1 instead and you should be on the safe side.

I've never encountered problems, when using "127.0.0.1" on any platform.

Hope that helps a bit, otherwise, feel free to ask again :-)

Regards, Arvind.

 

 

Hello Everyone,
No JNI support in MIDP 2.0 ? Baloney!!! The silver bullet by the name of "The Bridge" exists as is detailed by Arvind Gupta !!! It works 100 % of the time and is not only restricted to windows and Symbian, But Linux too.. I have recently implemented it on Linux and it works Marvellous..

I have been working on Motorola A768 A780 A760 .. all are linux phones and the applications that i am creating for them required me to use MIDP for Graphics. I created Graphics and used the Workaround (Bridge) to talk to my Native Application. So yes it does work.

Any of you who encountered any problem on the Linux Phone, let me know... for Symbian and windows talk to Arvind..i will be creating a website shortly as soon as i get some time, devoted to Linux/MIDP solutions. Will post it to this forum once its ready.

 

 

many regards to Mr arvind gupta.

actually iwas been supposed to write a midlet which must give the cell id of current operator. as every body knows that jsr 179 is quite costly and it didn't fit to my purpose . so i was trying some other alternative , i found great help from the natware . and now i am able to do the processing with the cell id in j2me which is actually been retrived by native C++ functions .

the natware helps me a lot . it opens a new dimentions of programming in MIDP and symbian OS , as i am a very newbie in both language so i cant tell enough about the usage. i can speak on BREW SDK rather.

 

 

Hi citu_rai !

Glad it helped you ! :-)

Feel free to ask, if you need further information !

Thanks for using the "Bridge" and regards,

Arvind.