Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 2.0.5, 2.1.0
    • Component/s: None
    • Labels:
      None

      Description

      As reported in our Dev mailing list, the check on JVM version that we do doesn't work with JVM different than Oracle Java.
      For example the SAP JVM with version "8.1.028 25.51-b14" generates the problem, which is blocking.
      The discussion thread is visible for example [here](http://apache-pivot-developers.417237.n3.nabble.com/Issue-in-Version-decode-with-SAPJVM-td4027425.html).

      We should check if log a warning and continue the execution, or parse anything after he major.minor.patch as a string ...

        Issue Links

          Activity

          Hide
          rwhitcomb Roger Whitcomb added a comment -

          PIVOT-996: Yet more safety measures: Parse the version strings inside a new
          "safelyDecodeVersion()" method that traps all exceptions and provides an
          "empty" version (that is, "0.0.0_00") in case of any errors. This is what
          the Pivot version already did, so use the same technique for the JVM and Java
          versions.

          Change the Javadoc for the three accessor methods to note this change of
          behavior in case of errors.

          Note: This should make application startup possible no matter what might
          happen to version strings in the future. We don't want these types of
          urgent issues to come up ever again, to where the user application won't
          start just because of a JVM update/change.

          "trunk":
          Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java
          Transmitting file data .done
          Committing transaction...
          Committed revision 1792807.

          Reworked and merged to "branches/2.0.x":
          Sending .
          Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java
          Transmitting file data .done
          Committing transaction...
          Committed revision 1792808.

          Show
          rwhitcomb Roger Whitcomb added a comment - PIVOT-996 : Yet more safety measures: Parse the version strings inside a new "safelyDecodeVersion()" method that traps all exceptions and provides an "empty" version (that is, "0.0.0_00") in case of any errors. This is what the Pivot version already did, so use the same technique for the JVM and Java versions. Change the Javadoc for the three accessor methods to note this change of behavior in case of errors. Note: This should make application startup possible no matter what might happen to version strings in the future. We don't want these types of urgent issues to come up ever again, to where the user application won't start just because of a JVM update/change. "trunk": Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data .done Committing transaction... Committed revision 1792807. Reworked and merged to "branches/2.0.x": Sending . Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data .done Committing transaction... Committed revision 1792808.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          PIVOT-996: Add new code to ApplicationContext to get the Java Runtime version,
          which is in addition to the Java JVM version, and to make it available to other
          code as a new API call.

          Added this new call to VersionTest to make sure the "decode()" and then "toString()"
          methods deal nicely with this value. Just to make sure we can catch the failure
          during testing if this ever gets broken again.

          I want to consider deprecating the "getJVMVersion()" method as I don't think it
          is useful (anymore, if it ever was?); however, I have not done that in this
          submission.

          "trunk":
          Sending core\test\org\apache\pivot\util\test\VersionTest.java
          Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java
          Transmitting file data ..done
          Committing transaction...
          Committed revision 1792793.

          "branches/2.0.x":
          Sending .
          Sending core\test\org\apache\pivot\util\test\VersionTest.java
          Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java
          Transmitting file data ..done
          Committing transaction...
          Committed revision 1792794.

          Show
          rwhitcomb Roger Whitcomb added a comment - PIVOT-996 : Add new code to ApplicationContext to get the Java Runtime version, which is in addition to the Java JVM version, and to make it available to other code as a new API call. Added this new call to VersionTest to make sure the "decode()" and then "toString()" methods deal nicely with this value. Just to make sure we can catch the failure during testing if this ever gets broken again. I want to consider deprecating the "getJVMVersion()" method as I don't think it is useful (anymore, if it ever was?); however, I have not done that in this submission. "trunk": Sending core\test\org\apache\pivot\util\test\VersionTest.java Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data ..done Committing transaction... Committed revision 1792793. "branches/2.0.x": Sending . Sending core\test\org\apache\pivot\util\test\VersionTest.java Sending wtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data ..done Committing transaction... Committed revision 1792794.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Okay, make a version simple change to Version.java to account for this specific case, and added a test method to VersionTest to test it.
          "trunk":
          Sending core\src\org\apache\pivot\util\Version.java
          Sending core\test\org\apache\pivot\util\test\VersionTest.java
          Transmitting file data ..done
          Committing transaction...
          Committed revision 1792775.

          "branches/2.0.x":
          Sending .
          Sending core\src\org\apache\pivot\util\Version.java
          Sending core\test\org\apache\pivot\util\test\VersionTest.java
          Transmitting file data ..done
          Committing transaction...
          Committed revision 1792783.

          Show
          rwhitcomb Roger Whitcomb added a comment - Okay, make a version simple change to Version.java to account for this specific case, and added a test method to VersionTest to test it. "trunk": Sending core\src\org\apache\pivot\util\Version.java Sending core\test\org\apache\pivot\util\test\VersionTest.java Transmitting file data ..done Committing transaction... Committed revision 1792775. "branches/2.0.x": Sending . Sending core\src\org\apache\pivot\util\Version.java Sending core\test\org\apache\pivot\util\test\VersionTest.java Transmitting file data ..done Committing transaction... Committed revision 1792783.
          Hide
          rwhitcomb Roger Whitcomb added a comment -

          Looking at the code, there are two possible ways to fix this that I see:
          1. Just use "java.version" instead of "java.vm.version" in the ApplicationContext static initialization. This is problematic since there is a public API that returns this value – could break customer code. But, I'm wondering if "java.version" isn't more helpful anyway, than the JVM version (or maybe this is what was intended all along, and it is essentially a typo?).
          2. Figure out a bullet-proof way to parse weird version strings. Also problematic, since we don't know what new schemes could come about in the future that might break the parsing.

          My inclination is to try to figure out 2), but put it out for comment about 1). Thoughts?

          Show
          rwhitcomb Roger Whitcomb added a comment - Looking at the code, there are two possible ways to fix this that I see: 1. Just use "java.version" instead of "java.vm.version" in the ApplicationContext static initialization. This is problematic since there is a public API that returns this value – could break customer code. But, I'm wondering if "java.version" isn't more helpful anyway, than the JVM version (or maybe this is what was intended all along, and it is essentially a typo?). 2. Figure out a bullet-proof way to parse weird version strings. Also problematic, since we don't know what new schemes could come about in the future that might break the parsing. My inclination is to try to figure out 2), but put it out for comment about 1). Thoughts?
          Hide
          smartini Sandro Martini added a comment - - edited

          This is not directly related to changes of PIVOT-993 (just resolved), but maybe a more general solution could be good to handle all cases.

          Show
          smartini Sandro Martini added a comment - - edited This is not directly related to changes of PIVOT-993 (just resolved), but maybe a more general solution could be good to handle all cases.

            People

            • Assignee:
              rwhitcomb Roger Whitcomb
              Reporter:
              smartini Sandro Martini
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development