From dmitricerkas at yahoo.com Mon Nov 7 08:17:20 2022 From: dmitricerkas at yahoo.com (Dmitri Cerkas) Date: Mon, 07 Nov 2022 08:17:20 -0000 Subject: I thing that the structure of "4.3.3 The Class String" paragraph should be slightly different. Small "Java Language Specification" improvement. In-Reply-To: <1356806459.1000529.1663581776987@mail.yahoo.com> References: <1741598286.3392751.1655734316482.ref@mail.yahoo.com> <1741598286.3392751.1655734316482@mail.yahoo.com> <1356806459.1000529.1663581776987@mail.yahoo.com> Message-ID: <2027698971.328971.1667809033520@mail.yahoo.com> Hello JLS Team, I thing that the content of? "4.3.3 The Class String" paragraph should be the following: "Instances of class String represent sequences of Unicode code points. String literals (?3.10.5) and text blocks (?3.10.6) are references to instances of class String. A String object has a constant (unchanging) value. The string concatenation operator + (?15.18.1) implicitly creates a new String object when the result is not a constant expression (?15.29). "With that new structure of?"4.3.3 The Class String" we have the following linked sequence of information: 1)?sequences of Unicode code points2)?Instances of class String represent sequences of "1)"3)?String literals (?3.10.5) and text blocks (?3.10.6) are references to "2)" and then we speak about unchanging and changing values of the String objects:4)?A String object has a constant (unchanging) value.The string concatenation operator + (?15.18.1) implicitly creates a new String object when the result is not a constant expression (?15.29). I think it make more sense. Thank you very much and have a nice day,Dmitri. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pietro.braione at unimib.it Sat Nov 26 10:00:40 2022 From: pietro.braione at unimib.it (Pietro Braione) Date: Sat, 26 Nov 2022 10:00:40 -0000 Subject: Class creation in JVM specification vs Hotspot behavior Message-ID: <27616E20-3618-4A77-AB7F-DD3BC45D9770@unimib.it> Hello to all the JVMS and Hotspot experts; I hope you can help me clarifying an issue. Section 5.3.2 of the JVMS discusses the class creation/loading procedure for classes with an user-defined class loader, but what it says seems to disagree with what Hotspot actually does. Section 5.3.2, third paragraph, says that when L is a user-defined class loader and L must create a class with name N, first, the method L.loadClass(N) is invoked, that actually loads and creates a class C, and then L is registered as an initiating loader for C. But apparently Hotspot does not register L as an initiating loader, at least from what appears by debugging this code snippet (I have the same results with Temurin OpenJDK 8 and OpenJDK 17): package example; class Foo { } class Test { public static void main(String[] args) { ClassLoader L = new ClassLoader() { }; //1 L.loadClass(?example.Foo?); //2 L.loadClass(?example.Foo?); //3 } } After statement 2 L is the initiating loader of a class C with name Foo, and the application class loader is the defining loader for C. When statement 3 is executed, the method ClassLoader.loadClass(String, boolean) is invoked, whose first step is invoking the method ClassLoader.findLoadedClass(String) to determine whether the class is already loaded. The Javadoc of this method states: "Returns the class with the given binary name if this loader has been recorded by the Java virtual machine as an initiating loader of a class with that binary name. Otherwise null is returned.? So, being L an initiating loader for C, the invocation of L.findLoadedClass(?Foo?) should return C. Instead, it returns null. So I am lead to conclude that of the three, one: either the behavior of ClassLoader.findLoadedClass(String) disagrees with its Javadoc documentation, and the method does *not* return all the classes for which the classloader is an initiating loader; or Hotspot fails in registering L as an initiating loader of C - which would be bad since it would also mean that Hotspot fails to check a loading constraint (Section 5.3); or there is a mistake in the JVMS, section 5.3.2 and L should not be registered as an initiating loader for C. Am I missing something? Cheers Pietro Braione University of Milano-Bicocca From hyagomvale at gmail.com Sun Nov 27 18:22:43 2022 From: hyagomvale at gmail.com (Hyago M. Vale) Date: Sun, 27 Nov 2022 18:22:43 -0000 Subject: Section 8.1.1. Class Modifiers Message-ID: "The static modifier remains only to member classes and local classes." In the removed JLS snippet, erroneously include local classes as eligible to receive the static modifier -------------- next part -------------- An HTML attachment was scrubbed... URL: