0

It is possible to compile an app for OS 6.0 and run it on a 5.0 device, for instance, and as long as you don't use newer APIs you are ok (I've just made a test 2 minutes ago just to make sure).

I'm using eclipse 3.6 with the last BB plugin to develop an app where we need to use barcode scanning only when available (API 6.0 and higher). The cleanest solution would have been not to load the conflictive classes when in lower versions. If this were Java SE I'd have encapsulated all uses of the barcode API in a class (lets call it OS6Impl), also created a default OS5Impl, and I'd have instantiated one or the other using reflection at runtime depending on the OS level of the device.

But this is BB and that is not enough, so we had to resort to preprocessor directives and manage 2 different versions of the app. In case the preprocessor flags disable the new API features, the resulting preprocessed OS6Impl.java file is stripped of all content. I can see this by looking at the file inside the .preprocessed folder, and also opening the generated jar file, where no OS6Impl.class file is present. When flags enable the new features, the OS6Impl.java file has code inside and the OS6Impl.class file is included in the jar.

This is OK and should work on both OS5 and OS6 devices compiling both versions with JRE 6. But it doesn't. The preprocessing is OK, the class is not included in the jar (so it shouldn't be in the cod), but when we run it in a 5.0 device it shows an error message ("module not found"). The module is "net_rim_barcodescanner", which we intend to use to scan barcodes only in 6.0+ devices.

I had to compile for JRE 5.0 to get rid of the error. This is ridiculous, since code compiled for 6.0 that doesn't use newer APIs is able to run in lower versions as I said before. I've verified several times that no import of the newer APIs are used other than in the OS6Impl.java class, that the preprocessor directives are set up correctly, and that a clean and build was done after each preprocessor directive change. Also rebooted the blackberry after installing each cod.

And now to compile a version or another, we have not only to modify the directives in the app descriptor, but also to modify the build path to switch the JRE to 5 or 6.

What kind of dependencies are added when using preprocessor directives to strip incompatible code? Why are those dependencies not added when compiling compatible code without preprocessor directives? Isn't the preprocessor something that runs before the compiler?

Mister Smith
  • 27,417
  • 21
  • 110
  • 193
  • not the answer to particular question, because now I don't develop for blackberry platform. But when I was I gave up eclipse because of its strange and buggy behaviour and used Netbeans + [BlackBerry Ant Tools](http://bb-ant-tools.sourceforge.net/) + [Antenna Preprocessor](http://antenna.sourceforge.net/wtkpreprocess.php). Check these tools combination if you did not resolve your issue. –  Aug 24 '14 at 08:58

1 Answers1

1

No, while some programs may work, all are not guaranteed to work that way. The reason is same as why java would refuse to load a class compiled with a higher version JDK.

Let me explain. With every change in version, some new opcodes and VM constants are also added. These opcodes govern the generation of the class file, whereas the other constants are used in the generated cod file. If the higher version compiler generates any of these opcodes / constants while generating the cod, the lower runtime would not understand them.

To understand the differences, check out the net.rim.ide.core.VMConst class from the JDWP.jar in the bin directory of your JDK. While there are no opcode differences between 5.0 and 6.0, there are some new VM constants added. In 7.0, two new opcodes have been added.

Thus, there are chances that the cod generated by compiling with 6.0 may not be understood by the 5.0 runtime.

How to compile for different OS:

Use Ant with BB Ant Tools. You can then create multiple targets, using different JDK to compile in one click. It also becomes very easy to create different build targets for different screen sizes to reduce the size of the generated cod files.

Adwiv
  • 1,283
  • 9
  • 15