From dnuechte at amperecomputing.com  Wed Jun 13 17:23:44 2018
From: dnuechte at amperecomputing.com (Dave Nuechterlein)
Date: Wed, 13 Jun 2018 17:23:44 +0000
Subject: Introduction
Message-ID: <CY4PR01MB2309EFEB621FF0FA801142DACB7E0@CY4PR01MB2309.prod.exchangelabs.com>

I am Dave Nuechterlein from Ampere Computing, and am looking forward to jumping into Aarch64 port development.



From shade at redhat.com  Thu Jun 14 07:56:14 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Jun 2018 09:56:14 +0200
Subject: Introduction
In-Reply-To: <CY4PR01MB2309EFEB621FF0FA801142DACB7E0@CY4PR01MB2309.prod.exchangelabs.com>
References: <CY4PR01MB2309EFEB621FF0FA801142DACB7E0@CY4PR01MB2309.prod.exchangelabs.com>
Message-ID: <6eb0b0ea-f207-ba32-6405-6e85810e93d9@redhat.com>

On 06/13/2018 07:23 PM, Dave Nuechterlein wrote:
> I am Dave Nuechterlein from Ampere Computing, and am looking forward to jumping into Aarch64 port development.

Hi, and welcome. You might want to subscribe to the list where most aarch64 port peeps hang out:
 http://mail.openjdk.java.net/pipermail/aarch64-port-dev/

-Aleksey



From ngortheone at gmail.com  Sat Jun 16 19:27:20 2018
From: ngortheone at gmail.com (Ngor)
Date: Sat, 16 Jun 2018 15:27:20 -0400
Subject: Workspace setup
Message-ID: <CAKJNb8-=5RNr+RvFZgFhD-b6Hfgn1ZOsmCQ9_85y68G_6dju9A@mail.gmail.com>

Hello community,

I am new to mailing lists and JDK sources, so do not throw stones at me
please:)

I want to setup a dev environment for JDK sources so I can fiddle with it
locally, compile and run.
Question that I have is the following: what set of tools do developers use
to work on JDK sources both C++ and Java?  (vim/idea/netbeas) And where can
I find doc on how to set the project for a particular IDE?

Thanks,
Ihor

From thomas.stuefe at gmail.com  Sun Jun 17 06:54:06 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 17 Jun 2018 08:54:06 +0200
Subject: Workspace setup
In-Reply-To: <CAKJNb8-=5RNr+RvFZgFhD-b6Hfgn1ZOsmCQ9_85y68G_6dju9A@mail.gmail.com>
References: <CAKJNb8-=5RNr+RvFZgFhD-b6Hfgn1ZOsmCQ9_85y68G_6dju9A@mail.gmail.com>
Message-ID: <CAA-vtUx2gmdGQm81kAFaKxmx7ngiPpfV_Qcup76VE1ScxHOcjw@mail.gmail.com>

On Sat, Jun 16, 2018 at 9:27 PM, Ngor <ngortheone at gmail.com> wrote:
> Hello community,
>

Hi Ngor the One,

> I am new to mailing lists and JDK sources, so do not throw stones at me
> please:)
>
> I want to setup a dev environment for JDK sources so I can fiddle with it
> locally, compile and run.
> Question that I have is the following: what set of tools do developers use
> to work on JDK sources both C++ and Java?  (vim/idea/netbeas) And where can
> I find doc on how to set the project for a particular IDE?
>

People use different setups; there is no canonical one.

For the C++ hotspot sources, setups range from plain vi and emacs over
Visual Code/Atom to CDT, CLion, Netbeans or even (though seems rare)
Visual Studio.

I personally use both vi and CDT to edit the sources, on both Windows
and Linux, though the setup is significantly easier on Linux. I do not
build in CDT though, I build on the command line.

If you choose CDT, Volker has a nice project setup plus good
description: https://github.com/simonis/HotSpot9_Eclipse_Project (Note
that it only really works well on Linux.)

For netbeans, there is a project inside the jdk sources itself, see
make/nb_native; last time I used it this worked almost out of the box
with some minor tweaks.

I cannot comment on other IDEs.

As for the java sources, I use standard Eclipse, but Intellij and
Netbeans seem more common. See here for a more in depth discussion:

http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000272.html

Best Regards, Thomas

> Thanks,
> Ihor

From brian.goetz at oracle.com  Tue Jun 19 18:15:27 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Jun 2018 14:15:27 -0400
Subject: Method and Field Literals
In-Reply-To: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
Message-ID: <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>

There are a number of concepts being conflated here.

Java already has _method references_, which are a way to describe the 
operational, but not the nominal, behavior of a method.? (You can 
convert the method reference String::isEmpty to a Predicate<String>, but 
you can't (easily) recover the provenance that it comes from 
String::empty.)

Java does not yet have _field references_, but extending the notion of 
method references to fields is likely to be fairly tractable.

But, you asked for method and field _literals_.? I think what you want 
here is a symbolic reference to a method or field, which allows you to 
get at the nominal description, but not necessarily (directly) the 
operational behavior.

Finally, you didn't ask for this, but you probably meant to: you'd like 
to be able to use method and field literals as arguments to annotations, 
as you can currently do with class literals.


There are a number of dimensions in which we might extend the current 
notion of method references:
 ?- Other conversion targets (jlr.Method, jli.MethodHandle) in addition 
to functional interfaces;
 ?- control over overload selection, so that you could say (for example) 
Foo::bar(int, int) rather than saying Foo::bar and relying on overload 
selection via target typing (needed if your target type doesn't provide 
enough information to do overload selection for you, such as such as 
jlr.Method);
 ?- extending to fields, either with functional interface target types, 
or others, as above;
 ?- exposing nominal information in addition to operational 
capabilities, so that callers can reconstruct the nominal information 
from which the references was constructed;
 ?- supporting the above sorts of references as annotation parameters.


You probably want some or all of these; others may want a different 
subset.? The current status is that, while we've spent a fair amount of 
time analyzing the bounds of the various problems, they're not features 
we've prioritized to deliver right now, because there are other features 
that we feel offer better return-on-effort.? But, that could change.


On 11/22/2014 10:51 AM, arjan tijms wrote:
>> FWIW, method/field literals would be very useful for POJO-centric libraries
> such as JPA/Hibernate, Bean Validation etc.
>
> Absolutely, in fact JPA is now simulating Field Literals by means of
> generating a so-called Metamodel for every entity class. See
> https://docs.oracle.com/javaee/6/tutorial/doc/gjiup.html#gjivl
>
> In short, given a class:
>
> public class Foo {
>      public String bar;
> }
>
> JPA generates a class Foo_:
>
> @Static @Metamodel(Foo.class)
> public class Foo_ {
>      public static volatile SingularAttribute<Foo, String> bar;
> }
>
> Everywhere a Field Literal would be actually needed, we then use
> Foo_.bar, half telling ourselves that there's the imaginary operator
> "_.".
>
> While this works, it's a nasty workaround and for some reason it's
> always an issue to generate that Metamodel. Real Field Literals would
> make this so much easier.
>
> Kind regards,
> Arjan Tijms


From forax at univ-mlv.fr  Tue Jun 19 18:40:58 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 19 Jun 2018 20:40:58 +0200 (CEST)
Subject: Method and Field Literals
In-Reply-To: <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
Message-ID: <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "arjan tijms" <arjan.tijms at gmail.com>, "discuss" <discuss at openjdk.java.net>
> Envoy?: Mardi 19 Juin 2018 20:15:27
> Objet: Re: Method and Field Literals

> There are a number of concepts being conflated here.
> 
> Java already has _method references_, which are a way to describe the
> operational, but not the nominal, behavior of a method.? (You can
> convert the method reference String::isEmpty to a Predicate<String>, but
> you can't (easily) recover the provenance that it comes from
> String::empty.)

The non easy way is to make the method reference Serializable, serialize it and extract the Serialization proxy which contains the class, the method etc.
Tagir has recently posted a code that does that:  
https://gist.github.com/amaembo/cbe9e1a8f3f8d240beb080343670f0c2

> 
> Java does not yet have _field references_, but extending the notion of
> method references to fields is likely to be fairly tractable.
> 
> But, you asked for method and field _literals_.? I think what you want
> here is a symbolic reference to a method or field, which allows you to
> get at the nominal description, but not necessarily (directly) the
> operational behavior.
> 
> Finally, you didn't ask for this, but you probably meant to: you'd like
> to be able to use method and field literals as arguments to annotations,
> as you can currently do with class literals.
> 
> 
> There are a number of dimensions in which we might extend the current
> notion of method references:
> ?- Other conversion targets (jlr.Method, jli.MethodHandle) in addition
> to functional interfaces;
> ?- control over overload selection, so that you could say (for example)
> Foo::bar(int, int) rather than saying Foo::bar and relying on overload
> selection via target typing (needed if your target type doesn't provide
> enough information to do overload selection for you, such as such as
> jlr.Method);
> ?- extending to fields, either with functional interface target types,
> or others, as above;
> ?- exposing nominal information in addition to operational
> capabilities, so that callers can reconstruct the nominal information
> from which the references was constructed;
> ?- supporting the above sorts of references as annotation parameters.
> 
> 
> You probably want some or all of these; others may want a different
> subset.? The current status is that, while we've spent a fair amount of
> time analyzing the bounds of the various problems, they're not features
> we've prioritized to deliver right now, because there are other features
> that we feel offer better return-on-effort.? But, that could change.
> 

BTW, if we want to support MethodHandle (or j.l.r.Method) at some point, we should re-use the same idea we use for the Serialization, use a non-conventional cast:
  MethodHandle mh = (MethodHandle & Predicate<String>)String::isEmpty;

with Predicate<String> used only to provide the necessary type information, this has the advantage of not requiring to change the grammar thus lowering the cost to introduce such feature.

cheers,
R?mi


> 
> On 11/22/2014 10:51 AM, arjan tijms wrote:
>>> FWIW, method/field literals would be very useful for POJO-centric libraries
>> such as JPA/Hibernate, Bean Validation etc.
>>
>> Absolutely, in fact JPA is now simulating Field Literals by means of
>> generating a so-called Metamodel for every entity class. See
>> https://docs.oracle.com/javaee/6/tutorial/doc/gjiup.html#gjivl
>>
>> In short, given a class:
>>
>> public class Foo {
>>      public String bar;
>> }
>>
>> JPA generates a class Foo_:
>>
>> @Static @Metamodel(Foo.class)
>> public class Foo_ {
>>      public static volatile SingularAttribute<Foo, String> bar;
>> }
>>
>> Everywhere a Field Literal would be actually needed, we then use
>> Foo_.bar, half telling ourselves that there's the imaginary operator
>> "_.".
>>
>> While this works, it's a nasty workaround and for some reason it's
>> always an issue to generate that Metamodel. Real Field Literals would
>> make this so much easier.
>>
>> Kind regards,
> > Arjan Tijms

From john.r.rose at oracle.com  Tue Jun 19 20:50:46 2018
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 19 Jun 2018 13:50:46 -0700
Subject: Method and Field Literals
In-Reply-To: <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
Message-ID: <8FD80727-5364-4AA0-B620-B112D4256ADD@oracle.com>

On Jun 19, 2018, at 11:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> BTW, if we want to support MethodHandle (or j.l.r.Method) at some point, we should re-use the same idea we use for the Serialization, use a non-conventional cast:
>  MethodHandle mh = (MethodHandle & Predicate<String>)String::isEmpty;
> 
> with Predicate<String> used only to provide the necessary type information, this has the advantage of not requiring to change the grammar thus lowering the cost to introduce such feature.

After the above code executes I would *not* expect the following to be true:

  assert(mh instanceof Predicate);

So there's something fishy about the cast to the conjunctive type:  It doesn't
yield an expression value of the type claimed by the cast.

One possible fix:  Declare that such casts are themselves poly expressions,
to the extent that they are allowed to drop the "inconvenient" part of the type,
for certain target types like MH.

? John

From forax at univ-mlv.fr  Tue Jun 19 22:09:36 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 20 Jun 2018 00:09:36 +0200 (CEST)
Subject: Method and Field Literals
In-Reply-To: <8FD80727-5364-4AA0-B620-B112D4256ADD@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <8FD80727-5364-4AA0-B620-B112D4256ADD@oracle.com>
Message-ID: <71544985.877892.1529446176179.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "discuss" <discuss at openjdk.java.net>
> Envoy?: Mardi 19 Juin 2018 22:50:46
> Objet: Re: Method and Field Literals

> On Jun 19, 2018, at 11:40 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> BTW, if we want to support MethodHandle (or j.l.r.Method) at some point, we
>> should re-use the same idea we use for the Serialization, use a
>> non-conventional cast:
>> MethodHandle mh = (MethodHandle & Predicate<String>)String::isEmpty;

>> with Predicate<String> used only to provide the necessary type information, this
>> has the advantage of not requiring to change the grammar thus lowering the cost
>> to introduce such feature.

> After the above code executes I would *not* expect the following to be true:

> assert(mh instanceof Predicate);

> So there's something fishy about the cast to the conjunctive type: It doesn't
> yield an expression value of the type claimed by the cast.

The MH can be an instanceof of Predicate by resurrecting the user-defined MethodHandle we have buried during the JSR 292, but it will complicate all JSR 292 implementations for no gain. 
So yes, the mh should not be an instanceof the target type. 

Technically, the cast to a target type is not really a cast even today, a cast take an instance and return an instance, the constant method reference/lambda cast is an eta transformation that take nothing (from the stack) and supply an instance. 

> One possible fix: Declare that such casts are themselves poly expressions,
> to the extent that they are allowed to drop the "inconvenient" part of the type,
> for certain target types like MH.

I'm not sure that a poly-expression can drop a constraint. I still think it should be seen as an eta transformation like any other constant lambda/method reference creation. 
At runtime, it's a ldc to a ConstantDynamic that returns either a MethodHandle or a j.l.r.Method (extracted from the MH via a MethodHandleInfo). 

> ? John

R?mi