Hello David,
On 11/01/21 12:02 pm, David Holmes wrote:
Hi Jaikiran,
On 11/01/2021 2:43 pm, Jaikiran Pai wrote:
I build the JDK from source using "make images". When I use that JDK
binary, the user name of the user who built the binary "leaks" into
some of the runtime system properties and (of
On Tue, 15 Dec 2020 23:15:23 GMT, Magnus Ihse Bursie wrote:
> The `templates` directory in `make` is an odd bird. It actually contains data
> files that the license checker needs, so it should move to `make/data`.
This pull request has now been integrated.
Changeset: bd344184
Author:Magnus
On Tue, 15 Dec 2020 23:38:02 GMT, Magnus Ihse Bursie wrote:
> The "symbol" files in make/hotspot/symbols are a list of exported symbols
> from libjvm. As such, they are an essential data source for the build system,
> and they should reside in make/data, not mixed with the hotspot make source
Hi Jaikiran,
On 11/01/2021 2:43 pm, Jaikiran Pai wrote:
I build the JDK from source using "make images". When I use that JDK
binary, the user name of the user who built the binary "leaks" into some
of the runtime system properties and (of course as a result) into the
output of java -version. H
On Fri, 8 Jan 2021 19:17:17 GMT, Phil Race wrote:
>> That code for sure should be called, it is even improved recently by
>> JDK-8255681
>> I'll check how it was intended to work.
>
> I hadn't noticed that line - and definintely not realised it was recent.
> I suppose he must have had a way to t
On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote:
> Proposed updates to JNI error handling.
src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
> 39:NSLog(@"%@",[NSThread callStackSymbols]); \
> 40:if ([NSThread isMainThread] == NO) { \
> 41:if ((*env)->
On Fri, 8 Jan 2021 19:05:09 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:
>
>> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \
>> 45: (*env)->ExceptionDescribe(env); \
>> 4
I build the JDK from source using "make images". When I use that JDK
binary, the user name of the user who built the binary "leaks" into some
of the runtime system properties and (of course as a result) into the
output of java -version. Here's the output of java -version of such a
built JDK:
On Mon, 11 Jan 2021 02:14:17 GMT, Hao Sun
wrote:
>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>> wel
> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
>
> Introduced since gcc-9 [3
10 matches
Mail list logo
