Hi Daniel,
I have made some revisions both to "Version.java" and
"ApplicationContext.java" so that this problem should not occur. In
addition, I made the system property "java.runtime.version" available
(parsed into a Version) via the "getJavaVersion()" method, in addition
to the existing "JVM Version" (system property "java.vm.version"). I'm
considering deprecating this "getJVMVersion()" method as I don't think
it is necessary anymore (if ever?). Also I have added a
"VersionTest.java" so that anything that could break the new Version
parsing can at least be caught by tests in the build process....
So, a few things:
1) We plan to release a maintenance update (version 2.0.5) very shortly.
2) The code currently in SVN for both "branches/2.0.x" and "trunk" have
a solid fix for this issue, plus tests.
3) What do you think of deprecating the "getJVMVersion()" method in
ApplicationContext, in favor of the (new) "getJavaVersion()" method I
have just introduced? Deprecating and finally removing it should remove
any future potential of parsing problems with third-party JVM version
strings, such as you are seeing.
Anything else we can do for you?
Thanks,
~Roger Whitcomb
On 4/25/17 12:51 PM, Mangold, Daniel Julius wrote:
Hi Sandro,
I tried an application which uses Pivot version 2.0.4 (I suppose the original
release - the jar file was tagged like that). This application also uses Pivot
WTK which executes Version.decode during startup, so when I tried to start the
application with SAP JVM it directly crashed.
In my opinion, asking for the VM version and trying to parse the version is
difficult (and not a good idea except for a very good reason) because there is
not only Oracle JVM out there and each one has a different string pattern. To
be on the safe side you would have to get the String of each JVM + Version
(1.5, 1.6...1.8) and write a corresponding JUnit test.
Due to a lack of time I did not debug further through the Pivot WTK code to see
what is finally done with the VM Version information. But if there is not a
very good reason why components (like major/minor) of the VM Version is really
needed, I would think of removing that Version class. If it is just for Logging
Purposes, then the complete String can also be logged without parsing it.
(If it is just about if the app is running on Java 1.6 or 1.8, maybe a better choice is
to ask for System.getProperty("java.version") instead of java.vm.version - but
it is just a guessing that other JVMs have a more similar pattern for that property).
But as you wrote, I agree that the minimum would be to have a try-catch block
and to handle the case that the version information cannot be parsed.
If you want to try an application with depends on Apache Pivot WTK and the
first thing it does is to crash with a rather cryptic exception, that's not
nice.
Best regards,
Daniel
P.S. I really love that there is something like Apache frameworks and people
who contribute code in their leisure time. But please accept that I cannot
contribute to this framework currently and because my email Inbox already
receives a lot of emails every day please understand that I do not register to
that mailing list. I hope I could still help a bit by reporting the issue.
-----Original Message-----
From: Sandro Martini [mailto:sandro.mart...@gmail.com]
Sent: Dienstag, 25. April 2017 19:35
To: Mangold, Daniel Julius <daniel.mang...@sap.com>
Subject: Fwd: Issue in Version.decode with SAPJVM
Sorry, I forgot to add your address ...
---------- Forwarded message ----------
From: Sandro Martini <sandro.mart...@gmail.com>
Date: 2017-04-25 19:34 GMT+02:00
Subject: Re: Issue in Version.decode with SAPJVM
To: Developers - Apache Pivot <dev@pivot.apache.org>
Hi Daniel,
thanks for tell us the problem, probably none of us used Pivot with
SAP VM so we didn't noticed before, sorry.
Last, to post questions/requests/etc in our mailing list you should
subscribe (don't worry it's free and simple), as seen
[here](http://pivot.apache.org/lists.html) or your posts won't be
accepted.
We just resolved a blocking issue with latest Oracle JDK 8 Patch 131,
see [PIVOT-99](https://issues.apache.org/jira/browse/PIVOT-993).
I'm thinking if this time is would be better for us to decode the last
part (anything after the major.minor.patch) as a string instead of the
(just updated) short value.
Or anyway do the decode in a try/catch block so in case of problems a
warning could be written in logs but application would start the same
...
Roger (and Daniel, and all others) , what approach do you prefer ?
Maybe a new, dedicated issue could be better to track this issue.
Version.decode("8.1.028 25.51-b14");
Luckily we just add a JUnit test class for testing version decode, so
a test on your version string could be put there :-) .
Daniel, just for info, are you using Pivot-2.0.4 or a snapshot (2.0.x
or 2.1.0 from trunk) ?
Be free to ask us for further info.
Thanks for now.
Bye,
Sandro
2017-04-25 11:31 GMT+02:00 Mangold, Daniel Julius <daniel.mang...@sap.com>:
Hello everyone,
I hope this is the right place to report issues.
I just wanted to run an application which has a dependency to Apache Pivot
2.0.4.
The application calls org.apache.pivot.wtk.DesktopApplicationContext.main which
inherits from ApplicationContext.
ApplicationContext has a static initializer block with this code line:
jvmVersion = Version.decode(System.getProperty("java.vm.version"));
With my SAP JVM the system property has this string:
8.1.028 25.51-b14
Which results in a
Exception in thread "main" java.lang.NumberFormatException: For input string: "028
25"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Byte.parseByte(Byte.java:149)
at java.lang.Byte.parseByte(Byte.java:175)
at org.apache.pivot.util.Version.decode(Version.java:156)
If you do not have a SAP JVM, you can easily reproduce the issue with this code
line:
Version.decode("8.1.028 25.51-b14");
Maybe the problem is that the requested property is java.vm.version. When I try
with just java.version, it does not throw an exception:
Version v = Version.decode(System.getProperty("java.version"));
System.out.println(v.getMajorRevision());
System.out.println(v.getMinorRevision());
System.out.println(v.getMaintenanceRevision());
System.out.println(v.getUpdateRevision());
Output:
1
8
0
112
(The getProperty for java.version returns 1.8.0_112)
Best regards,
Daniel
