[thejakumarsk]

Hi,

I am trying to implement jni in my midlet using S60 3rd edition FP2 sdk, which has eSWT support, If I see eSWT implementation, they are loading native (symbian) dll using org.eclipse.swt.internal.Libray class using Libary.loadLibary method. I tried to use the same method to load my native dll, midlet is giving Authorization failed error during installation. It is because of lack of permission to access org.eclipse.swt.Libary class, Is there any other way of using jni implementation.

Your help will be appreciated great.

Thanks
Theja

[grahamhughes]

You cannot implement JNI on CLDC. CLDC is specifically intended to prevent that.

Graham.

[thejakumarsk]

Hi grahamhughes,

Thanks for your reply.

I understand that, there is no direct method to implement jni. But, If you look at eswt implementation for S60, they are using jni. You can check org.eclipse.swt.internal.Libary.loadLibray method where they are using it to load eswt.dll. And it is public, static method. So it is likely, AMS(application manager software) failed to recognizet Library.java class existance or my midlet is not granted with appropriate permission, So, installation is failing saying "Authorization failed". Is there a way I can set the midlet permission to make it work. I checked eswt implementation I could not find, where they have imposed package restriction on swt classes. How can I use Browser.java where I cannot use Libary.java. I may be wrong in understanding the eswt package, Any help?

Thanks & Regards
Theja

[grahamhughes]

There is not direct way, nor an indirect way.

Classes that are part of the Java Runtime on the device are able to do things that classes in an installed JAR are not. You can only access the runtime library using the public API (the API that is documented in the JavaDocs). You can't use other classes. Some classes will be implementation-specific (for example, they might exist on the emulator, but not on the device). Other classes might be subject to security restrictions. In this case, the JVM might not let you access classes in the org.eclipse.swt.internal packages. There is no "permission" you can enable to change this.

Similarly, it is forbiden for a class in an installed JAR to contain any methods declared "native". Classes in the on-device run-time can contain native methods. This is a strict rule of CLDC.

I'm afraid JNI on CLDC is not an option.

Graham.

[thejakumarsk]

Hi Graham,

Yes, you are correct, some classes are not accessible unless they are exposed as public api.
But, You can still use 'native' method in midlet classes using 'dummy class and outside jar updation' technique. Only missing part is
dll loading mechanism. Thanks for your help.

Regards
Theja

[grahamhughes]

Would you care to elaborate on this technique?

Graham.

[thejakumarsk]

Ya sure,

Ex : You want to implement a JNI class called HelloWorld.java, But, if you use 'native' keyoword in method signature preverification will fail. So, in order to avoid this conflict: implement a dummy method like this.

dummy class just to pass preverification:

public class HelloWorld{

public String sayHello(){
}
}

use above class in your midlet while generating jar file(preverification will pass). Once you generate the jar file, Make a new class externally like below one.

Actual class to be installed on device:

public class HelloWorld{

public native String sayHello();
}

using 'jar -uf' java command line tool update the jar file with the above class. Update your jad attributes with latest jar size. Now try installing this jar on emulator/device, Application will install without any problem.
I tested it on emulator, It works fine. I dont know about it's fate on actual device. I hope it works fine on device too!

But, this exercise is worthless untill we get a class to load native dll from cldc.

Regards
Theja

[grahamhughes]

But the class won't load, because the VM's verifier will reject it.

Graham.

[thejakumarsk]

No way,

It ran like a charm. I was not able to call jni method(coz, lack of jni facility), But, I called other member method, It worked.
so, technique is flawless.

Regards
Theja

[grahamhughes]

Way. As soon as the verifier hits that method, verification will fail.

But... good luck with it! :)

Graham.

[thejakumarsk]

I doubt, It should have checked this cldc violation as soon as it loaded class. Anyway, there is no support for loading dll now, so, i cant test it. :-)

I dont think, it will differentiate user classes and library classes at runtime. Once, it is installed, It might treat both classes equal. Its just my guess.

Regards
Theja

[grahamhughes]

Not necessarily. Verification doesn't need to happen at load time. Verification of a method can wait until the method is invoked.

The VM will certainly differentiate between user and system classes. It's fundamental to the CLDC security model. This is why, for example, you cannot instantiate a MIDlet class, and why you get an error when you try to call the loadLibrary() method (while the eSWT classes can call it without problem).

As you say, since you cannot load a library anyway, it is a moot point. Preventing you from using your own native methods requires nothing more than to block access to loading external libraries.

Graham.

[thejakumarsk]

No, you have mistaken, I said, I am not able to install a midlet which uses org.eclipse.swt.internal.Library class because of "Authorization failed" error. This is during installation time. I guess, If I succeeded in this step, I would be able to use 'native' method just like library classes. I dont see any reason why it will block a midlet from calling native method after successfull installation. Is there any reference docs about cldc architecture and restriction. I am interested to go through it.

Regards
Theja

[gorkem.ercan]

Hi Theja,

Graham is very correct on this one. The internal classes are accessible by only runtime's own implementation classes. If a midlet refers to internal implementation classes, java installer will fail at installation time(just like you are experiencing). There are no security permissions available that will enable you to pass java installer's checks. Even if you could pass the install time check runtime has a more rigorous check that would not allow your midlet to execute internal implementation classes.

--
Gorkem

[grahamhughes]

The reason why it would block access to native methods is: because it is required to do so.

You can get the CLDC-1.1 specification from here.

Both the CLDC-1.0 and 1.1 specs state:

The set of native functions accessible to the virtual machine is closed, meaning that the application programmer cannot download any new libraries containing native functionality, or access any native functions that are not part of the Java libraries provided by the CLDC, profiles or licensee open classes.

A compliant CLDC implementation is required to ensure that an installed application cannot increase the number of native methods accessible to it, above those made available through public APIs.

That's not to say that it is impossible to find a bug that could be exploited, but if you did that, you would probably be writing an application that works only on one firmware version of one device (before the bug was fixed).

Graham.