Don't change the classpath
Support for JAR files in Codename One has been a source of confusion despite my previous post on the matter
so its probably a good idea to revisit this subject again and clarify all the details. The first source of confusion is changing the classpath. You should NEVER change
the classpath or add an external JAR via the NetBeans/Eclipse classpath UI. The reasoning here is very simple, these IDE's don't package the JAR's into the final executable and even if they did these JAR's would probably use features unavailable or inappropriate for the device (e.g. java.io.File etc.).
There are two use cases for wanting JAR's and they both have very different solutions:
- Modularity - you want to divide your work to an external group. For this purpose use the cn1lib approach.
- Work with an existing JAR. For this you will need native interfaces.
Lets start with modularity since its simpler and you can pretty much read my previous post on the matter
which covers it pretty accurately. You can create a cn1lib in NetBeans although its really just a simple ant project with some special targets and a simple ant task for stubbing. In it you can write all your source code (including native code and libs as described below), when you build the file you will get a cn1lib file that you can place in your projects lib directory. After a right click and refresh project libs completion will be available for you and you will be able to work as if the code was a part of your project. Native JAR's/Libs
For the second use case of existing JAR's we have a more complex situation, the JAR could depend on features unavailable in Codename One and even if it doesn't it might be compiled in a way that isn't supported by Codename One.
So taking an arbitrary JAR off the internet and expecting it to work on a mobile device is something that will probably never happen for any platform. Android supports using JAR's since it is based around the java language
, some JAR's might even work on J2ME/RIM. To make use of this capability we can just place the JAR's as is under the native/android directory (and respectively for J2ME/RIM). The way to go for iOS support would be to use .a files (iOS static libraries) which will get linked with your app in the same way that the JAR's get linked. The problem is that you still won't be able to use the JAR (or .a file) from
within your code, this JAR would be platform specific and you would need to write the "bridging" code to connect it to the native layer. To learn more about native interfaces I suggest reading the developer guide but basically what you need to do is define a native interface e.g.:
Here you can define the interface between your application (which can't directly access the jar or .a file) and the native code which can. Now you can right click the interface select: Generate Native Access and go the native directory where you can edit the native code.
Notice that the jar will not appear in your IDE's code completion and the code might be marked as "red" with error messages. That is because we can't compile that code on the client, only on the server since we don't have the native Android/iOS SDK's installed on your PC or Mac (and even if we did, integrating so many difference pieces of software is problematic).
Supporting an arbitrary JAR off the internet is something no one will ever be able to fully deliver on, although we do hope the cn1lib format will take off since it is pretty open and has many advantages over the standard jar format (proper javadoc based code completion is HUGE).
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended.... If that is the case please let us know via the comments section below.