when I install the applet on my java card the result is this error:
APDU 00C00000 lc: 00 cmdData: le: 13 expStatus: ????
Response: '027100000E0A00000000000128450000016A88'
Status: '9000'
Additional response data received: 016A88 but expected: '019000' '016101'
I'm using SimAllianceLoader_v2 for installation.
my applet installed correctly on java card 2
the problem solved somehow.
first problem was that all the used libraries was not compatible with java card 3.0.4
the second problem was with another installed applet even though the aid was different, but just one of this two custom applets could be installed on the sim card.
Related
I am using REDHAWK 2.0.5, and I am attempting to launch a domain using the instructions in section '11.1.1 Launching a Domain' of the REDHAWK documentation:
https://redhawksdr.github.io/Documentation/mainch11.html#x13-30800011.2
I receive the following error after clicking OK in step 3 when attempting to register the GPP device on the Domain Manager:
terminate called after throwing an instance of 'boost:exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'
what(): bad lexical cast: source type value could not be interpreted as target
Does anyone have experience with this issue? Or, any suggestions about what the cause might be?
This sounds like it could be an issue with the version of boost libraries you have installed. Can you tell me which linux flavor and version you're using, and how you installed the Redhawk framework itself?
I want to write a tiny "hello world" J2ME MIDlet. In a sample like this one, classes in javax.microedition.lcdui.* are used for display output. When I try to compile it in Eclipse, I get the error,
The import javax.microedition.lcdui cannot be resolved
I've installed JME SDK 3.4, and I'm able to run MIDlets that don't import javax.microedition.lcdui.*. I read somewhere that lcdui can be obtained from the wireless toolkit; and Oracle says that the wireless toolkit has been integrated into JME SDK as of 3.0+.
So why can't Eclipse find it?
OK, I think I know the answer now.
I got back to the JME SDK 3.4 documentation page on Using Sample projects, and created and ran an instance of UIDemo. It uses lcdui classes, but it runs flawlessly - no errors about inability to resolve javax.microedition.lcdui.*.
The difference appears to be that the working sample uses different libraries than the one I tried at first. The first one uses org.elipse.mtj.JavaMEContainer/Oracle Java(TM) Platform Micro Edition SDK 3.4/IMPNGDevice1,
while the one that works uses org.elipse.mtj.JavaMEContainer/Oracle Java(TM) Platform Micro Edition SDK 3.4/JavaMEPhone1. They contain different sets of jars, e.g. the working one contains midp_2.1.jar, while the earlier one has impng_1.0.jar.
A follow-up question might be, why doesn't IMP-NG have lcdui in it? Well, those who pay attention to what they're doing will have read that
This JSR [for IMP-NG] will define a J2ME profile targeting embedded networked devices that wish to support a Java runtime environment similar to the Mobile Information Device Profile (MIDP) version 2.0, but that do not provide the graphical display capabilities required by MIDP 2.0.
The Information Module Profile - Next Generation (IMP-NG) will be a strict subset of MIDP 2.0, where at least the APIs relating to GUI functionality (the LCDUI) are removed. Functionality not already present in MIDP 2.0 is not anticipated or desired. "
The next question might be, why did I end up selecting IMP-NG when I was going through the tutorial... when I really do want a MIDlet that does something graphically? But I'm not sure I care, now that it's working.
The new me sdk 8.2, as I understood after browsing all class and in packages, does not provides any class to develop user interface. not like sdk 3.4, that have many graphical components.
Im new here and trying to develop a applet for Javacard. While following a sample code from a website, I get stuck here. NetBeans says the Package javacardx.framework does not exist.
Im using NetBeans 7.3.1
I would have not linked the Java Classic Jar file properly. Please help me
You cannot program against the standard Java API for Java Card. Java Card only uses (most of the) Java syntax and .class files as intermediate compilation results. Instead you need to configure the libraries of the Java Card SDK. Furthermore you need to run the Java Card converter, and for this you need the converted binaries and "export files" of those libraries.
More information can be found in the Java Card Development Quickstart Guide of the Java Card Netbeans plugin.
My company uses an applet which needs JNI to access some PKI features.
This is a very stable (+4 years) solution and is already in production in several clients.
It's a signed (Thawte Certificate) applet and it worked fine until JRE7 21 - now a security exception has popped (all Applet JNI solutions we have are presenting the same issue).
I checked Java applet stopped working after update to JRE 7u21 and Cannot launch applet using Java 7u21. I've checked Java 7 Update 21 Security Improvements in Detail, but it doesn't mention anything about JNI.
I've already tried using TurstedLibrary and recompiling it with JDK7 21 but it still pops the security exception.
I'd like to check with you guys if you had the same issue and if someone is able to use Java + JNI again (don't know if there's some new stuff to sign the DLL or something like that)..
Update:
Working - got it through http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#trusted_library
Adding the correct Trusted Library manifest make it stop prompting the error - remembering that you need to use JDK7 21.
I'm developing a piece of software for my University and am currently attempting to implement NFC functionality which requires me to move from my standard Sun wireless tool-kit platform (implemented through NetBeans) to a Nokia platform (also implemented through NetBeans).
The problem is, whenever I compile the code with the Nokia platform implementation and run the program, on the Nokia phone I have or in the emulator, the phone displays a box stating "Invalid Application. Delete?" with a yes/no answer. This stops the installation of the application. The strange part is that if I compile the exact same code with the Sun platform implementation it runs without any issues on the Nokia phone. I have tried this with two different Nokia SDKs (the Series 40 Nokia 6212 NFC SDK and the Series 40 5th Edition SDK) with the same results.
What is the Nokia SDK doing differently?
There seems to be some kind of discrepancy between a project created using a Sun platform and a project created in a Nokia platform.
Although the original program, initially created with the Sun platform, compiled with the Nokia platform caused the application to be invalid, when I created a new project from scratch using the Nokia platform and just copied the source of the original program over the program worked. There is no discernible difference in the JAD/manifest files between the two.
If you've copied source code, you may have not copied the "manifest.midlets", i.e. tells the OS which "forms" to create. You'll usually find this in the project properties.
(e.g. in NetBeans IDE - Application Descriptor, "Midlets" tab - it shouldn't be empty).
Make sure that the following attributes (key:value pairs) are in the JAD file and also the manifest file in the JAR file:
MIDlet-Name
MIDlet-Version
MIDlet-Vendor
MIDlet-Jar-URL
MIDlet-Jar-Size