RE: 8207830: [aix] disable jfr in build and tests

Hi Vladimir, Thanks for looking at my change. > Thank you for fixing aot check in hotspot.m4 I guess this does no harm if aot is enabled, but I saw it on aix. > Add new method vmHasJFR() Fixed. New partial webrev: http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/02/ The other

Re: adding additional numbers to the Java version string

OK. Despite our deep interest in version strings, we rarely use Runtime.Version. On Thu, Jul 19, 2018 at 12:42 PM, Tony Printezis wrote: > Hi Martin, > > Yes, we have also used the opt field too. However, if I understand the > spec correctly, when doing version comparisons, the opt string is

Re: RFR: JDK-8207365: Make man pages optional

Erik: The patch adds a configure parameter --enable-manpages/--disable-manpages, default is enabled, just like before the change. The patch also changes the Oracle configuration in jib-profiles.js to disable manpages. Bug: https://bugs.openjdk.java.net/browse/JDK-8207365 Webrev:

RFR: JDK-8207365: Make man pages optional

Hello, The man pages are currently not being actively maintained by anyone, so we would like to make including them in the build optional. Oracle produced builds will disable inclusion of man pages. (This was already the case for OracleJDK builds but will now also be true for Oracle produced

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

This looks ok to me. /Erik On 2018-07-19 13:11, Tony Printezis wrote: Thanks for the explanation. So I think I’ll just leave it as is. New webrev: http://cr.openjdk.java.net/~tonyp/8207849/webrev.1/ The only new changes are in the

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

Thanks for the explanation. So I think I’ll just leave it as is. New webrev: http://cr.openjdk.java.net/~tonyp/8207849/webrev.1/ The only new changes are in the spec.gmk.in file. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 4:01:14 PM, Erik

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

On 2018-07-19 12:52, Tony Printezis wrote: Erik, Many thanks for looking at this change! I can totally add the VERSION_EXTRAX variables to the spec.gmk file. Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

Erik, Many thanks for looking at this change! I can totally add the VERSION_EXTRAX variables to the spec.gmk file. Related: I was not sure what to do with VERSION_NUMBER_ALL_POSITIONS. Right now, VERSION_NUMBER_FOUR_POSITIONS is exposed to the spec.gmk file but I'm not sure exactly where it’s

Re: adding additional numbers to the Java version string

Hi Martin, Yes, we have also used the opt field too. However, if I understand the spec correctly, when doing version comparisons, the opt string is compared alphanumerically. So if you add any numbers to it, you have to plan ahead and pad with enough 0s to make sure the comparison works as

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 2:31 PM, Erik Joelsson wrote: > > I can do that. Do you have a bug? > No. > /Erik > > On 2018-07-19 10:57, Christian Thalinger wrote: >> >> >> On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson > > wrote: >> This looks good to me, but will

Re: RFR: 8207849: Allow the addition of more number to the Java version string (S)

Hello Tony, I think this looks ok. We like to keep AC_SUBST calls paired with variables in spec.gmk.in so please add corresponding VERSION_EXTRAX variables there. /Erik On 2018-07-19 11:46, Tony Printezis wrote: Hi all, Here’s the webrev for this:

RFR: 8207849: Allow the addition of more number to the Java version string (S)

Hi all, Here’s the webrev for this: http://cr.openjdk.java.net/~tonyp/8207849/webrev.0/ I’m no configure expert so I basically did a cut-and-paste of what was already there. If there’s a way to do this better (maybe, cut down on the awkward code replication), let let me know. The decision to

Re: custom extension for make/SourceRevision.gmk

I can do that. Do you have a bug? /Erik On 2018-07-19 10:57, Christian Thalinger wrote: On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson mailto:erik.joels...@oracle.com>> wrote: This looks good to me, but will need coordination when pushed as I said earlier. Do you want to push it

Re: custom extension for make/SourceRevision.gmk

On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson wrote: > This looks good to me, but will need coordination when pushed as I said > earlier. > Do you want to push it so it’s easier? /Erik > > On 2018-07-19 10:04, Christian Thalinger wrote: > > > > On Jul 19, 2018, at 12:57 PM, Erik Joelsson >

Re: 8207830: [aix] disable jfr in build and tests

Build changes look good. /Erik On 2018-07-19 10:22, Vladimir Kozlov wrote: Tests changes are good. Thank you for fixing aot check in hotspot.m4 In VMProps.java I would suggest to follow code pattern from other features. Add new method vmHasJFR() which returns "true" or "false" instead of:

Re: adding additional numbers to the Java version string

At Google we use --with-version-opt to put in local version data - that works for us. --with-version-patch is also available for third party build use. On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson wrote: > Since JEP 223 specifies an arbitrary length (something I had missed > before), I

Re: 8207830: [aix] disable jfr in build and tests

Tests changes are good. Thank you for fixing aot check in hotspot.m4 In VMProps.java I would suggest to follow code pattern from other features. Add new method vmHasJFR() which returns "true" or "false" instead of: map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild()); We may need such

Re: custom extension for make/SourceRevision.gmk

This looks good to me, but will need coordination when pushed as I said earlier. /Erik On 2018-07-19 10:04, Christian Thalinger wrote: On Jul 19, 2018, at 12:57 PM, Erik Joelsson > wrote: On 2018-07-19 09:54, Christian Thalinger wrote: On Jul 19,

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:57 PM, Erik Joelsson wrote: > > > > On 2018-07-19 09:54, Christian Thalinger wrote: >> >> >>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >> > wrote: >>> >>> >>> On 2018-07-19 09:16, Christian Thalinger wrote:

Re: custom extension for make/SourceRevision.gmk

On 2018-07-19 09:54, Christian Thalinger wrote: On Jul 19, 2018, at 12:44 PM, Erik Joelsson > wrote: On 2018-07-19 09:16, Christian Thalinger wrote: Well, the issue is this: exploded-image: exploded-image-base release-file   release-file:

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:44 PM, Erik Joelsson wrote: > > > On 2018-07-19 09:16, Christian Thalinger wrote: >> >> >> Well, the issue is this: >> >> exploded-image: exploded-image-base release-file >> >> release-file: create-source-revision-tracker >> >> store-source-revision: >>

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:46 PM, Erik Joelsson wrote: > > One thing though. Since you are renaming the top file, we need to coordinate > pushing of this change since we are relying on the old name. We can keep the old name, if you want, but that wouldn’t be very consistent with other files.

Re: custom extension for make/SourceRevision.gmk

One thing though. Since you are renaming the top file, we need to coordinate pushing of this change since we are relying on the old name. /Erik On 2018-07-19 09:44, Erik Joelsson wrote: On 2018-07-19 09:16, Christian Thalinger wrote: Well, the issue is this: exploded-image:

Re: custom extension for make/SourceRevision.gmk

On 2018-07-19 09:16, Christian Thalinger wrote: Well, the issue is this: exploded-image: exploded-image-base release-file   release-file: create-source-revision-tracker store-source-revision:       +($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f SourceRevision.gmk

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:08 PM, Erik Joelsson wrote: > > Hello, > On 2018-07-19 07:43, Christian Thalinger wrote: >> >> >>> On Jul 18, 2018, at 3:28 PM, Christian Thalinger >> > wrote: >>> >>> >>> On Jul 18, 2018, at 1:46 PM, Erik Joelsson >>>

Re: custom extension for make/SourceRevision.gmk

Hello, On 2018-07-19 07:43, Christian Thalinger wrote: On Jul 18, 2018, at 3:28 PM, Christian Thalinger mailto:cthalin...@twitter.com>> wrote: On Jul 18, 2018, at 1:46 PM, Erik Joelsson > wrote: Hello Christian, Sometimes we need hooks both close to

Re: custom extension for make/SourceRevision.gmk

> On Jul 18, 2018, at 3:28 PM, Christian Thalinger > wrote: > > > >> On Jul 18, 2018, at 1:46 PM, Erik Joelsson wrote: >> >> Hello Christian, >> >> Sometimes we need hooks both close to the beginning and close to the end of >> the file, and in that case we create a

Re: adding additional numbers to the Java version string

Hi Erik, Thanks for the response. I created: https://bugs.openjdk.java.net/browse/JDK-8207849 (infrastructure/build is the right component for this, right?) and I’ll post a webrev soon. Tony — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On July 19, 2018 at 9:53:42 AM,

Re: adding additional numbers to the Java version string

Since JEP 223 specifies an arbitrary length (something I had missed before), I agree the build should support a few extra version numbers. /Erik On 2018-07-18 13:22, Tony Printezis wrote: Hi all, According to the Java version string spec (JEPs 223 and 322) the first part of the version

Re: [8u] RFR 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped]

Hi Erik, On Wed, 2018-07-18 at 18:10 +0200, Severin Gehwolf wrote: > webrev with info line removed: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/webrev.03/ > > HG-export: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8036003/JDK-8036003.jdk8.export.patch > > Could you please