Results 1 to 4 of 4

Thread: dmServer 2.0 and Java 5

  1. #1
    Join Date
    Nov 2009
    Posts
    5

    Default dmServer 2.0 and Java 5

    Hi All,

    Our project has strong requirement to use Java 5. We work with dmServer 1.0.2 currently, but it will be really good for us to take advantages of dmServer 2.0; in particular we want to migarte our .par archives to .plan files. Could you please clarify, is there way to utilize this feature without migration on Java 6?

    Thanks,
    Ilya
    Last edited by Ilya Katsov; Nov 26th, 2009 at 03:09 AM.

  2. #2
    Join Date
    Oct 2008
    Location
    Winchester, UK
    Posts
    535

    Default

    dm Server 2.0 requires Java 6, so I'm afraid you'll have to run under Java 6 to use 2.0.

    However it should be possible to compile your code for Java 5 against Java 5 class libraries and have it run under Java 6 because of Java's reasonable backward compatibility story. It all depends on why you have a strong requirement to use Java 5 and what restrictions that actually places on you.
    Glyn Normington
    SpringSource

  3. #3
    Join Date
    Nov 2009
    Posts
    5

    Default

    Glyn,

    thank you for quick response. Unfortunately Java5 is our business requirement and we have no possibility to migrate a production system on Java6.

    We are able to spend some time tuning dm Server 2.0 at code level to make it compatible with Java 5 (at least partially) or migrating some features from dm Server 2.0 to 1.0.2. So, my question may be posed as follows: Is it reasonable to try tuning of dm Server 2.0 at code level to migrate it on Java5? Does dm Server 2.0 use Java 6 features so extensively that migration will have very high LOE?

    Thanks,
    Ilya
    Last edited by Ilya Katsov; Nov 26th, 2009 at 12:42 AM.

  4. #4
    Join Date
    Oct 2008
    Location
    Winchester, UK
    Posts
    535

    Default

    Unfortunately I think either of those approaches is likely to be prohibitively expensive.

    The Java 6 dependencies in dm Server 2.0 are fairly localised but critical. For example, 2.0 depends on Java 6 JMX features, critical to the function of the admin console and the shell, and Java 6 concurrency utilities.

    Backporting function from 2.0 to 1.0.2 is likely to be costly since the design of the two versions is so radically different.

    I would recommend staying on vanilla 1.0.2 until your business requirements allow you to upgrade to Java 6.
    Glyn Normington
    SpringSource

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •