RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the ct.sym file. To simplify the construction, the CreateSymbols tool does not produce fil

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

Hi Brad, This is very similar to what I do. Some small comments inline. On 29. 04. 20 21:02, Bradford Wetmore wrote: Jan, What is your current recommended technique to use NetBeans to build/edit/test OpenJDK for normal OpenJDK library developers? After many versions of Netbeans, my current

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 2020-04-30 09:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the ct.sym file. To simplify the construction, the

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 30. 04. 20 9:49, Magnus Ihse Bursie wrote: On 2020-04-30 09:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 30/04/2020 08:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the ct.sym file. To simplify the construction, t

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 2020-04-30 12:41, Alan Bateman wrote: On 30/04/2020 08:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a constant timestamp for the files inside the ct.

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 2020-04-30 10:21, Jan Lahoda wrote: On 30. 04. 20 9:49, Magnus Ihse Bursie wrote: On 2020-04-30 09:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a co

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

On 30. 04. 20 14:29, Magnus Ihse Bursie wrote: On 2020-04-30 12:41, Alan Bateman wrote: On 30/04/2020 08:03, Jan Lahoda wrote: Hi, The building of lib/ct.sym is not reproducible, due to timestamps of files inside the file (which is basically a zip file). The proposed solution is to use a

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > The code for setting up Java compilation has long been quite hard to > understand, and has a tricky API. Part of this is due to the support for > the sjavac ("smart javac") system. We do not use sjavac anymore, and it > has not been tested for long. Part of the sjavac ef

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

On 2020-04-30 14:55, Florian Weimer wrote: * Magnus Ihse Bursie: The code for setting up Java compilation has long been quite hard to understand, and has a tricky API. Part of this is due to the support for the sjavac ("smart javac") system. We do not use sjavac anymore, and it has not been tes

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

On 2020-04-30 15:07, Magnus Ihse Bursie wrote: On 2020-04-30 14:55, Florian Weimer wrote: * Magnus Ihse Bursie: The code for setting up Java compilation has long been quite hard to understand, and has a tricky API. Part of this is due to the support for the sjavac ("smart javac") system.

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > I made sure that no build performances were measured on my system, and > since I saw no such indication, I did not make any more systematic analysis. > > What is the difference if you run with or without the javac server? Thanks. Which configure flags do you want me to t

Re: mistriggered "error: warnings found and -Werror specified" for java warnings

we don't need jtreg for this to occur: Compiling 127 files for BUILD_java.compiler.interim /home/ralf/build/openjdk-hg/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java:30: warning: [preview] RecordComponentElement is an API that is part of a preview feature impor

macOS hardened runtime issue - missing entitlements

Hello, Yesterday I filled an issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/1720 ) about restrictions on access to some resources when running a Java .jar (tested microphone, but suspect there are more resources involved,

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

On 2020-04-30 15:50, Florian Weimer wrote: * Magnus Ihse Bursie: I made sure that no build performances were measured on my system, and since I saw no such indication, I did not make any more systematic analysis. What is the difference if you run with or without the javac server? Thanks.

Re: mistriggered "error: warnings found and -Werror specified" for java warnings

Hello Ralf, On 2020-04-29 18:18, Ralf H wrote: we don't need jtreg for this to occur: Compiling 127 files for BUILD_java.compiler.interim /home/ralf/build/openjdk-hg/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java:30: warning: [preview] RecordComponentElement

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > On 2020-04-30 15:50, Florian Weimer wrote: >> * Magnus Ihse Bursie: >> >>> I made sure that no build performances were measured on my system, and >>> since I saw no such indication, I did not make any more systematic analysis. >>> >>> What is the difference if you run with

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

Hello, I could reproduce this and found the issue. There is a typo in the conditional. Posting review. /Erik On 2020-04-30 10:43, Florian Weimer wrote: * Magnus Ihse Bursie: On 2020-04-30 15:50, Florian Weimer wrote: * Magnus Ihse Bursie: I made sure that no build performances were meas

RFR: JDK-8244210: The javac server is never used

Hello, A minor mistake in JDK-8244036 is causing the javac server to never be used, which is rather severly increasing build times. Before that change, the global variable ENABLE_SJAVAC was used to determine if the server should be activated. After the change, the global variable has changed

Re: RFR: JDK-8244210: The javac server is never used

Erik: Looks good. Tim Hello, A minor mistake in JDK-8244036 is causing the javac server to never be used, which is rather severly increasing build times. Before that change, the global variable ENABLE_SJAVAC was used to determine if the server should be activated. After the change, the g

Re: RFR: JDK-8244210: The javac server is never used

Looks good, Erik, Thanks! /Claes On 2020-04-30 21:10, Erik Joelsson wrote: Hello, A minor mistake in JDK-8244036 is causing the javac server to never be used, which is rather severly increasing build times. Before that change, the global variable ENABLE_SJAVAC was used to determine if the

Re: RFR: JDK-8244210: The javac server is never used

* Erik Joelsson: > A minor mistake in JDK-8244036 is causing the javac server to never be > used, which is rather severly increasing build times. > > Before that change, the global variable ENABLE_SJAVAC was used to > determine if the server should be activated. After the change, the > global v

RFR: JDK-8244214: Change to VS2019 for building on Windows at Oracle

Please review this change which changes the compiler version used to build for Windows at Oracle to Visual Studio 2019. http://cr.openjdk.java.net/~erikj/8244214/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8244214 /Erik

Re: RFR: JDK-8244214: Change to VS2019 for building on Windows at Oracle

Looks good. Cheers, Mikael > On Apr 30, 2020, at 3:37 PM, Erik Joelsson wrote: > > Please review this change which changes the compiler version used to build > for Windows at Oracle to Visual Studio 2019. > > http://cr.openjdk.java.net/~erikj/8244214/webrev.01/ > > https://bugs.openjdk.jav