bildwelt
E2E FORUM
E2E Bridge E2E Commerce

What do I have to consider regarding Java versions when using the Java adapter?

E2E Forum Modeling & Development What do I have to consider regarding Java versions when using the Java adapter?

This topic contains 2 replies, has 1 voice, and was last updated by  Jörg 4 years, 6 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #511

    Jörg
    Moderator

    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?

    #512

    Jörg
    Moderator

    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.

    #513

    Jörg
    Moderator

    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?

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.