From gavin.bierman at oracle.com Mon Jun 10 08:43:19 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 10 Jun 2024 08:43:19 +0000 Subject: javac misalignment with the JLS In-Reply-To: References: Message-ID: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Hi Emilia, Thanks. Could you file this as a bug and I?ll attend to it? Cheers, Gavin On 9 Jun 2024, at 00:16, Emilia L?pez wrote: Hi, Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 Regards, Emilia L?pez -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Fri Jun 21 08:53:56 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Fri, 21 Jun 2024 08:53:56 +0000 Subject: javac misalignment with the JLS In-Reply-To: References: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Message-ID: Thanks Emilia. That?s very helpful. Don?t worry about the categorisation, we?ll deal with it. Best wishes, Gavin > On 20 Jun 2024, at 23:01, Emilia L?pez wrote: > > Hi, > > The report is now publicly available as JDK-8334172 [1], as delayed as I am. > > I did submit it as a javac bug, I was unsure whether it's a compiler > or a spec issue, but I had to only pick one category. > > [1] https://bugs.openjdk.org/browse/JDK-8334172 > > Thanks. Regards, > Emilia L?pez > > > On Mon, 10 Jun 2024 at 12:29, Emilia L?pez wrote: >> >> Hi Gavin, >> >> I submitted a bug report through the bug database submission form and >> it is awaiting triage, thanks. >> >> Regards, >> Emilia L?pez >> >> >> On Mon, 10 Jun 2024 at 05:43, Gavin Bierman wrote: >>> >>> Hi Emilia, >>> >>> Thanks. Could you file this as a bug and I?ll attend to it? >>> >>> Cheers, >>> Gavin >>> >>> On 9 Jun 2024, at 00:16, Emilia L?pez wrote: >>> >>> Hi, >>> >>> Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? >>> >>> [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 >>> >>> Regards, >>> Emilia L?pez >>> >>> From emilia.lopezf.1999 at gmail.com Sat Jun 8 23:17:14 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Sat, 08 Jun 2024 23:17:14 -0000 Subject: javac misalignment with the JLS Message-ID: Hi, Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 Regards, Emilia L?pez -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia.lopezf.1999 at gmail.com Mon Jun 10 15:29:23 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Mon, 10 Jun 2024 15:29:23 -0000 Subject: javac misalignment with the JLS In-Reply-To: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> References: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Message-ID: Hi Gavin, I submitted a bug report through the bug database submission form and it is awaiting triage, thanks. Regards, Emilia L?pez On Mon, 10 Jun 2024 at 05:43, Gavin Bierman wrote: > > Hi Emilia, > > Thanks. Could you file this as a bug and I?ll attend to it? > > Cheers, > Gavin > > On 9 Jun 2024, at 00:16, Emilia L?pez wrote: > > Hi, > > Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? > > [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 > > Regards, > Emilia L?pez > > From emilia.lopezf.1999 at gmail.com Thu Jun 20 22:02:11 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Thu, 20 Jun 2024 22:02:11 -0000 Subject: javac misalignment with the JLS In-Reply-To: References: <75214109-347B-4293-82EC-9C775A6D2DFA@oracle.com> Message-ID: Hi, The report is now publicly available as JDK-8334172 [1], as delayed as I am. I did submit it as a javac bug, I was unsure whether it's a compiler or a spec issue, but I had to only pick one category. [1] https://bugs.openjdk.org/browse/JDK-8334172 Thanks. Regards, Emilia L?pez On Mon, 10 Jun 2024 at 12:29, Emilia L?pez wrote: > > Hi Gavin, > > I submitted a bug report through the bug database submission form and > it is awaiting triage, thanks. > > Regards, > Emilia L?pez > > > On Mon, 10 Jun 2024 at 05:43, Gavin Bierman wrote: > > > > Hi Emilia, > > > > Thanks. Could you file this as a bug and I?ll attend to it? > > > > Cheers, > > Gavin > > > > On 9 Jun 2024, at 00:16, Emilia L?pez wrote: > > > > Hi, > > > > Upon reading the JLS, chapter ?7.7.1 Module Declaration - Dependences [1], the spec does not mention anything regarding multiple appearances of the requires modifiers (transitive and static), however javac errs if static is declared multiple times, and if transitive is declared twice or more consecutively, the second time the token is consumed as a module name, despite the BNF indicating any amount of {RequiresModifier} instances; the English description is lacking. Is the Java language specification wrong, lacking or missing in describing this aspect of compilation of modular compilation units? Or does javac not abide by it? > > > > [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-7.html#jls-7.7.1 > > > > Regards, > > Emilia L?pez > > > > From thihup at gmail.com Fri Jun 28 17:53:46 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Fri, 28 Jun 2024 17:53:46 -0000 Subject: Corrections to typographical errors in the JVM Specification Message-ID: Dear all, I hope this message finds you well. I have identified a few typographical errors in the Verifier section of the JVM specification, specifically within the Prolog code. Below are the details of the corrections required: *4.10.1.6. Type Checking Methods with Code* *Current:* isInitHandler(Environment, Handler) :- Environment = environment(_Class, Method, _, Instructions, _, _), isInit(Method). member(instruction(_, invokespecial(CP)), Instructions), CP = method(MethodClassName, '', Descriptor). *Correction:* isInitHandler(Environment, Handler) :- Environment = environment(_Class, Method, _, Instructions, _, _), isInit(Method), member(instruction(_, invokespecial(CP)), Instructions), CP = method(MethodClassName, '', Descriptor). *Change:* Corrected the period (.) to a comma (,) after isInit(Method) to ensure proper clause continuation. *4.10.1.8. Type Checking for protected Members* *Current:* classesInOtherPkgWithProtectedMember(Class, MemberName, MemberDescriptor, MemberClassName, [class(MemberClassName, L) | Tail], T] :- *Correction:* classesInOtherPkgWithProtectedMember(Class, MemberName, MemberDescriptor, MemberClassName, [class(MemberClassName, L) | Tail], T) :- *Change:* Corrected the mismatched bracket from T] to T). *4.10.1.9. Type Checking Instructions: baload* *Current:* instructionIsTypeSafe(baload, Environment, _Offset, StackFrame, NextStackFrame, ExceptionStackFrame) : nth1OperandStackIs(2, StackFrame, ArrayType), isSmallArray(ArrayType), validTypeTransition(Environment, [int, top], int, StackFrame, NextStackFrame), exceptionStackFrame(StackFrame, ExceptionStackFrame). *Correction:* instructionIsTypeSafe(baload, Environment, _Offset, StackFrame, NextStackFrame, ExceptionStackFrame) :- nth1OperandStackIs(2, StackFrame, ArrayType), isSmallArray(ArrayType), validTypeTransition(Environment, [int, top], int, StackFrame, NextStackFrame), exceptionStackFrame(StackFrame, ExceptionStackFrame). *Change:* Corrected the colon (:) to a double colon (:-) to indicate the correct predicate definition. *4.10.1.9. Type Checking Instructions: ldc, ldc_w, ldc2_w* *Current:* instructionHasEquivalentTypeRule(ldc_w(CP), ldc(CP)) *Correction:* instructionHasEquivalentTypeRule(ldc_w(CP), ldc(CP)). *Change:* Added a period (.) at the end to properly terminate the clause. I hope these corrections are helpful. Please let me know if any further clarification is needed. Best regards, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymiel314 at gmail.com Sun Jun 2 15:29:17 2024 From: rymiel314 at gmail.com (Emilia Kond) Date: Sun, 02 Jun 2024 15:29:17 -0000 Subject: Interpretation of rewritten uninitialized type of invokespecial Message-ID: Hi The JVMS, Java 22 Edition, 4.10.1.9.invokespecial has this to say about invokespecial instructions that call an method: If we are initializing an object within its constructor, its type is initially uninitializedThis. This type will be rewritten to the type of the class of the method. I am confused on which method is referred to by "the method", since there are two, the one we are currently in, and the one we are currently calling. The provided Prolog terms seem to suggest it's the one we are calling: instructionIsTypeSafe(invokespecial(CP), Environment, _Offset, StackFrame, NextStackFrame, ExceptionStackFrame) :- CP = method(MethodClassName, '', Descriptor), parseMethodDescriptor(Descriptor, OperandArgList, void), reverse(OperandArgList, StackArgList), canPop(StackFrame, StackArgList, TempFrame), TempFrame = frame(Locals, [uninitializedThis | OperandStack], Flags), currentClassLoader(Environment, CurrentLoader), rewrittenUninitializedType(uninitializedThis, Environment, class(MethodClassName, CurrentLoader), This), rewrittenInitializationFlags(uninitializedThis, Flags, NextFlags), substitute(uninitializedThis, This, OperandStack, NextOperandStack), substitute(uninitializedThis, This, Locals, NextLocals), substitute(uninitializedThis, top, Locals, ExceptionLocals), NextStackFrame = frame(NextLocals, NextOperandStack, NextFlags), ExceptionStackFrame = frame(ExceptionLocals, [], Flags). rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, MethodClass) :- MethodClass = class(MethodClassName, CurrentLoader), thisClass(Environment, MethodClass). rewrittenUninitializedType(uninitializedThis, Environment, MethodClass, MethodClass) :- MethodClass = class(MethodClassName, CurrentLoader), thisClass(Environment, class(thisClassName, thisLoader)), superclassChain(thisClassName, thisLoader, [MethodClass | Rest]). The MethodClass parameter of rewrittenUninitializedType is constructed from the class of the methodref that is being invoked by invokespecial, and it is also the out parameter used as This. However, it hasn't always been this way, the Prolog term from the JVMS, Java 7 edition, 4.10.1.9.invokespecial contains the following term: rewrittenUninitializedType(uninitializedThis, Environment, _MethodClass, This) :- thisClass(Environment, This). Here, the interpretation seems to be that the rewritten type should be the class of the method we're currently in. This change was made in Java 8. Which interpretation is correct? It is my understanding that the current Prolog code refers to the class of the method being called? Is my understanding incorrect? I've checked the source code of the hotspot verifier, and it seems to replace uninitializedThis with the type of the current class, so it is the latter interpretation. If we take the constructor of a simple class with a field, it may look something like this: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."":()V 4: aload_0 5: iconst_0 6: putfield #7 // Field foo:I 9: return It is problematic if after verifying the invokespecial at address 1, the resulting type in local 0 is java.lang.Object, because the putfield at address 6 will fail, because java.lang.Object does not have that field. Does this make the Prolog terms of the current standard incorrect? Additionally, it contains the variables MethodClassName and CurrentLoader, which are never used, which also seems like a mistake? It also contains thisClassName and thisLoader, which seem to be treated as if they are variables, but written as if they are atoms, since they begin with a lowercase letter. Regards Emilia Kond -------------- next part -------------- An HTML attachment was scrubbed... URL: