Customer has Builder 4.1 which supports Java 1.4. Now some JARs had to be exchanged to ones that are compiled with 1.6.. This does not work when importing and compiling them in Builder 4.1. What possibilities do we have to solve the issue?
– Builder 4.1: The Builder uses the same JVM as MagicDraw (here 1.4), in order to compile the wrapper for the imported Java classes. So the classes cannot be compiled with a higher Java version (here 1.6). The wrapper are used that Java can communicate with the Bridge Server. They are generated, when the model is compiled.
– Console 4.1: Here we have on one side the JVM, to run the Console with Tomcat, on the other side a JVM, that executes the imported Java classes. These two JVM do not have to be identical. However, the JVM that executes the Java classes should be the same version that was used to compile the wrapper. Respectively, it is also possible to use a higher version (as it is the case in the Console, where in the Java preference may be Java 1.6).
So in order to solve the issue above, one has to upgrade Builder to 5.1 which with MagicDraw 16.9 (or 17.0) supports Java 1.6.
A workaround is to just copy the new classes (the ones that are wrapped in the wrapper) directly to D:E2E_BRIDGE_DATAbridge_repositoryjavalib. This only works if the calls in the wrapper are still the same.
It is awkward because this has to be redone with every deployment of the service.
Could we solve this by pointing MagicDraw to the JRE 1.6? What would I have to consider and to do in such a case if this workaround was feasible?
You must be logged in to reply to this topic.