[PATCH] buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
I've adapted the build.gradle to use java -fullversion instead of java
-version, parsing the result with a regexp.
diff -r 9b5fc7c1e5e6 build.gradle
--- a/build.gradle Fri Aug 07 18:35:42 2015 -0700
+++ b/build.gradle Thu Aug 27 15:52:11 2015 +0200
@@ -719,29 +719,27 @@
if (!file(JAVAH).exists()) throw new Exception(Missing or incorrect
path to 'javah': '$JAVAH'. Perhaps bad JDK_HOME? $JDK_HOME)
if (!file(JAVADOC).exists()) throw new Exception(Missing or
incorrect path to 'javadoc': '$JAVADOC'. Perhaps bad JDK_HOME?
$JDK_HOME)
-
+
// Determine the verion of Java in JDK_HOME. It looks like this:
//
-// $ java -version
-// java version 1.7.0_45
-// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
-// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
-//
-// We need to parse the second line
-def inStream = new java.io.BufferedReader(new
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,
-version).start().getErrorStream()));
+// $ java -fullversion
+// for OpenJDK: openjdk full version 1.8.0_45-internal-b14
+// for Oracle JDK: java full version 1.8.0_45-b14
+
+def inStream = new java.io.BufferedReader(new
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,
-fullversion).start().getErrorStream()));
try {
-if (inStream.readLine() != null) {
-String v = inStream.readLine();
-if (v != null) {
-int ib = v.indexOf( (build );
-if (ib != -1) {
-String ver = v.substring(ib + 8, v.size() - 1);
-
-defineProperty(jdkRuntimeVersion, ver)
-defineProperty(jdkVersion, jdkRuntimeVersion.split(-)[0])
-defineProperty(jdkBuildNumber,
jdkRuntimeVersion.substring(jdkRuntimeVersion.lastIndexOf(-b) + 2))
-}
-}
+def v = inStream.readLine();
+
+if (v != null) {
+ def pattern =
java.util.regex.Pattern.compile(^[^\]*\((\\d+(?:\\.\\d+)*)_(\\d+))(?:-\\w+)?(?:-b(\\d+))\\$)
+ def matcher = pattern.matcher(v)
+
+ if (matcher.matches()) {
+defineProperty(jdkVersion, matcher.group(1))
+defineProperty(jdkRuntimeVersion, matcher.group(2))
+defineProperty(jdkUpdate, matcher.group(3))
+defineProperty(jdkBuildNumber, matcher.group(4))
+ }
}
} finally {
inStream.close();
Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats
It's not directly related to JEP 257, no. Just some outstanding cleanup. Btw, speaking of JEP 257, we plan to integrate that to 9-dev today. -- Kevin Michael Berry wrote: +1 for deprecation - I haven't used VP6 in a long while, and would value the whole thing being open source more than its inclusion. Out of interest, is this anything to do with JEP 257? I started looking at this with Kirill's guidance a year or so ago, but sadly many other things had to take precedence so I didn't really have the time. Michael On 27 August 2015 at 12:39, Scott Palmer swpal...@gmail.com wrote: On Aug 27, 2015, at 2:29 AM, Dr. Michael Paus m...@jugs.org wrote: Am 26.08.15 um 22:25 schrieb Scott Palmer: Then legacy formats could be provided in optional downloads and new formats can be supported without the need to integrate them within the JRE code. To me this sounds again like a Java/JavaFX specific solution which, to my opinion, is a dead-end road. I think it would be much more important that JavaFX can directly use all system installed codecs. I simply don't understand why it is possible to install a codec pack on a machine and almost all software, with the exception of JavaFX, is able to immediately use that and only JavaFX based applications are not. Michael I agree that codecs that are usable by the system’s default media framework should work. However, I believe that is already supported in most cases, is it not? It's not - JavaFX can decode the audio / video / container formats that it knows about through its GStreamer plugins, and nothing else (unless you compile them in yourself, which isn't all that hard.) There still needs to be a guarantee that certain specific codecs will work wherever JFXMEdia is supported. Otherwise you lose a significant bit of cross-platform compatibility. Media assets that you ship with your application need to be able to play, regardless of how the end user has configured their specific codec environment. Scott
Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats
+1 for deprecation - I haven't used VP6 in a long while, and would value the whole thing being open source more than its inclusion. Out of interest, is this anything to do with JEP 257? I started looking at this with Kirill's guidance a year or so ago, but sadly many other things had to take precedence so I didn't really have the time. No, that's unrelated. I suspect we'll hear something about that soon... Oh, I see Kevin let the cat out of the bag. Well, there you go :) I agree that codecs that are usable by the system’s default media framework should work. However, I believe that is already supported in most cases, is it not? It's not - JavaFX can decode the audio / video / container formats that it knows about through its GStreamer plugins, and nothing else (unless you compile them in yourself, which isn't all that hard.) Not entirely true... on the Mac, GStreamer does not support HLS, that gets routed through QTKit (for = 10.7) or AVFoundation (10.8+). With VP6 gone there will actually be no need for GStreamer on Mac at all. It *used* to be the case that we allowed anything the native platform provided, in the previous media stack (JMC if anyone was paying attention). The big issue, as Kirill pointed out, was it was very difficult to support due to the vast combinations of operating systems and codecs/media formats and (more importantly) there are security implications. There are internal discussions ongoing about how we're approaching this problem. The security aspects only affect webstart and plugin, standalone applications aren't as much of a concern (except from a supportability standpoint) so maybe some compromise can be reached. I would actually favor allowing formats supplied by the underlying native platform over trying to figure out how to provide a pluggable codec interface, but it needs to be done in a way that's sustainable and does not expose security vulnerabilities. Again, I'm not promising anything, just know that complaints and requests have been heard and are being taken into consideration. -DrD-
Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats
On 27 August 2015 at 19:53, David DeHaven david.deha...@oracle.com wrote: +1 for deprecation - I haven't used VP6 in a long while, and would value the whole thing being open source more than its inclusion. Out of interest, is this anything to do with JEP 257? I started looking at this with Kirill's guidance a year or so ago, but sadly many other things had to take precedence so I didn't really have the time. No, that's unrelated. I suspect we'll hear something about that soon... Oh, I see Kevin let the cat out of the bag. Well, there you go :) Awesome, that's good to hear! I agree that codecs that are usable by the system’s default media framework should work. However, I believe that is already supported in most cases, is it not? It's not - JavaFX can decode the audio / video / container formats that it knows about through its GStreamer plugins, and nothing else (unless you compile them in yourself, which isn't all that hard.) Not entirely true... on the Mac, GStreamer does not support HLS, that gets routed through QTKit (for = 10.7) or AVFoundation (10.8+). With VP6 gone there will actually be no need for GStreamer on Mac at all. Sorry, my mistake - I'm used to the media stack on Windows where this is (I think) always the case. It *used* to be the case that we allowed anything the native platform provided, in the previous media stack (JMC if anyone was paying attention). The big issue, as Kirill pointed out, was it was very difficult to support due to the vast combinations of operating systems and codecs/media formats and (more importantly) there are security implications. Perhaps a political issue as oppose to a technical one, but (on the support side of things rather than the security side) would best efforts here with a warning that it might not work 100% reliably be better than not at all? There are internal discussions ongoing about how we're approaching this problem. The security aspects only affect webstart and plugin, standalone applications aren't as much of a concern (except from a supportability standpoint) so maybe some compromise can be reached. Without wishing to drag this further off topic (perhaps it should be split into a separate discussion!), from memory at the moment the Java code won't allow any format down to the native layer (gstreamer) unless it matches one of the types it's aware of. Would it be possible to remove this hard requirement (perhaps with a flag?) If this was done then it would probably be a small bit of boilerplate in the native layer to pass the stream down to the relevant plugin. If it doesn't exist then we haven't lost anything, if it does then the stream can be played without an issue. This wouldn't change anything by default, but it would mean that anyone could then drag custom gstreamer plugins into the correct JRE directory and have them work straight off. Considering that many applications bundle a JRE anyway these days, that would make it trivial for those who wanted to to support any other codec / container type that GStreamer offered, and would (presumably) remove the support / legal burden on Oracle of distributing and maintaining these plugins. Hopefully that ticks the sustainability and security boxes? Michael I would actually favor allowing formats supplied by the underlying native platform over trying to figure out how to provide a pluggable codec interface, but it needs to be done in a way that's sustainable and does not expose security vulnerabilities. Again, I'm not promising anything, just know that complaints and requests have been heard and are being taken into consideration. -DrD- -- Thanks, Michael
JEP 253 Update: new JavaDoc ready for review
Hi all, As promised the other week here is an updated javadoc export of the proposed APIs for JEP 253. It includes the APIs for the third subproject (new CSS APIs), and it also _removes_ the APIs for the second subproject (InputMap APIs). The URL for the JavaDoc is here: http://jonathangiles.net/javafx/jdk9/jep253/6/ The CSS APIs are ready for review, but we are the first to admit that the javadoc is incomplete. We plan to do a big javadoc push on these docs in the next week, but we didn't want to hold up the first review until then. If you have questions on certain API, please let us know - at the very least it may inform our javadoc efforts! The InputMap API has been removed as we have decided now is not the right time to move that forward. For one it has not yet been met with universal community praise :-), but for two it doesn't feel right to release it without the behaviors themselves becoming public. I worried that without the behaviors being public that the InputMap was a bit of a 'map to nowhere'. My hope is that we can resolve this in an update release of JDK 9. The plan now is to remove the second subproject from JEP 253 to have it correctly tracking our intentions, so I will be doing that in the coming week. However, all is not lost! The InputMap continues to live on inside our behaviors code, and will continue to form the basis for future iterations and investigations. It already is a much nicer approach than we had previously for our behaviors, so I'm quite happy that even though we haven't scored the points for new public API, we've scored code quality points at least. We look forward to your feedback, -- Jonathan
Just pushed the updated GStreamer for JEP 257
I just pushed the changeset for JEP 257 [1] [2] on behalf of Alexander Matveev to the openjfx 9-dev repo. If you have any questions about the new GStreamer, please let Alexander or Kirill know. This will be in next week's early access build of JDK 9 (build 80). As previously announced [3] this means that JavaFX for JDK 9 will no longer build or run on some older Linux distros. -- Kevin [1] http://openjdk.java.net/jeps/257 [2] https://bugs.openjdk.java.net/browse/JDK-8043352 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-August/017722.html
CFV: New OpenJFX Committer: Alexander Matveev
I hereby nominate Alexander Matveev [1] to OpenJFX Committer. Alexander was an initial member of JavaFX team at Oracle when the OpenJFX project was created, and was on the initial list of approved committers [2]. His status as OpenJFX committer was not recorded at that time on the Census. This CVF is intended to correct this oversight. Alexander's changes prior to JavaFX becoming open-source were significant (which is why he was on the initial list of committers). In particular, Alexander, along with the rest of the media team, contributed much of the code that went into the open-source changeset that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: hg log -r aee256fde55 Counting his contribution to that changeset, Alexander now also has the requisite number of changes in the open-source repo to become a committer. hg log -M -u matvee Votes are due by September 10, 2015. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks, -- Kevin [1] http://openjdk.java.net/census#almatvee [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer
Re: Usage of internal API's in charts
Ok. That what I assumed. Shall we try to compile a list with needed API's? -Sven Am 26.08.2015 19:19 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: I've also extended charts and have also been confronted with internal APIs. -- Pedro Duque Vieira
Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats
On 27.08.2015 9:29, Dr. Michael Paus wrote: To me this sounds again like a Java/JavaFX specific solution which, to my opinion, is a dead-end road. I think it would be much more important that JavaFX can directly use all system installed codecs. I simply don't understand why it is possible to install a codec pack on a machine and almost all software, with the exception of JavaFX, is able to immediately use that and only JavaFX based applications are not. Although this is an off-topic I'll answer to your question. Security and testing are the reasons. It's virtually impossible to test every possible codec on every possible platform. Many of them are proprietary so we don't control their code/can't fix their bugs. And all blame that JavaFX can't play this/can't play that will fall on our heads. And it can open many potential security vulnerabilities.
