Re: Record bytecode format not described in JEP 359
Thank Vicente, I suppose you also have visible and invisible annotations as attribute too ? Rémi - Mail original - > De: "Vicente Romero" > À: "Remi Forax" , "amber-spec-experts" > > Envoyé: Vendredi 4 Octobre 2019 23:33:27 > Objet: Re: Record bytecode format not described in JEP 359 > Hi Remi, > > In the meantime you should be able to access the current definition of > the Record attribute at [1]. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8225058 > > On 10/4/19 3:52 PM, Remi Forax wrote: >> Hi everyone, >> i'm implementing the support of record (and sealed types) in ASM as an >> experimental (preview if you prefer) feature of the future ASM8. >> >> The JEP 359 [1], doesn't include the bytecode format of the Record >> attribute, is >> there a reason ? >> >> Rémi > > [1] https://openjdk.java.net/jeps/359
Re: Record bytecode format not described in JEP 359
Hi Remi, In the meantime you should be able to access the current definition of the Record attribute at [1]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8225058 On 10/4/19 3:52 PM, Remi Forax wrote: Hi everyone, i'm implementing the support of record (and sealed types) in ASM as an experimental (preview if you prefer) feature of the future ASM8. The JEP 359 [1], doesn't include the bytecode format of the Record attribute, is there a reason ? Rémi [1] https://openjdk.java.net/jeps/359
Re: Record bytecode format not described in JEP 359
The JEP issue has a sub-task, JVMS for records, which is where the spec would be attached. There is currently no draft there, but we'll post one soon. On 10/4/2019 3:52 PM, Remi Forax wrote: Hi everyone, i'm implementing the support of record (and sealed types) in ASM as an experimental (preview if you prefer) feature of the future ASM8. The JEP 359 [1], doesn't include the bytecode format of the Record attribute, is there a reason ? Rémi [1] https://openjdk.java.net/jeps/359
Record bytecode format not described in JEP 359
Hi everyone, i'm implementing the support of record (and sealed types) in ASM as an experimental (preview if you prefer) feature of the future ASM8. The JEP 359 [1], doesn't include the bytecode format of the Record attribute, is there a reason ? Rémi [1] https://openjdk.java.net/jeps/359
Re: Exploring inference for sealed types
Of course! My bad. Compilation unit which usually maps to .java file
when compiling files...
That's perfectly sensible as a scope to define inference within.
Regards, Peter
On 10/2/19 11:08 PM, Alex Buckley wrote:
You speak of "compilation unit" as if it means the scope of work
performed by javac and Maven. ("compiles each module separately as its
own compilation unit") That's not the meaning. The meaning is as
given in
https://docs.oracle.com/javase/specs/jls/se13/html/jls-7.html#jls-7.3
On 10/2/2019 1:43 PM, Peter Levart wrote:
Is compilation unit really the right choice to base inference on?
For example, a program may be composed of several modules compiled
all at once in a single compilation unit (javac supports that). This
same program may be compiled with a build system such as Maven, which
compiles each module separately as its own compilation unit. Would we
really want the semantics of a program (or successful compilation
thereoff) depend on the choice of the build tool?
What about using (module, compilation unit) as the base to perform
inference within? I understand that compiler may only infer things
within a compilation unit and module is usually compiled as a whole
in one compilation unit (possibly together with other modules).
Regards, Peter
