Attendees: Tobi, Dan H, John, Frederic, Karen short meeting due to Oracle meeting conflict immediately following.
I. Inline class static field circularity It is necessary to eagerly load any embedded fields that we want to actually flatten. This can lead to circularities - either directly or indirectly. Question was whether we need to consider actual flattening (not the same as flattenability) for statics? Benefits and costs? Performance - from earlier hotspot experiments, an additional indirection on static fields had no significant performance cost. Costs: complexity for circularities larger than directly containing self Conclusion: we can offer flattenable semantics for statics and not actually flatten them. II. <init> John: Propose inline factory: static <init> that returns self JVMS will need modifications - e.g. relax structural constraints Verifier will allow invokespecial for existing <init> that returns void only Core reflection will see these new static <init> methods as constructors MethodHandles will see these as both constructors and static methods ed. note: clarification from John - for java.lang.reflect: all <init> constructors and static <init> methods will be exposed as constructors. Neither will be exposed as methods. This is because java.lang.Reflect is about language-level constructs. for java.lang.invoke: findConstructor will only find constructors that use the new/dup/invokespecial model. MethodHandles will see these only as static methods. This is because the java.lang.invoke package is about “bytecode behaviors”. Dan H: full range of access controls on static <init> ? John: yes Dan H: will non inline classes have a static <init> ? John: no. non-inline classes should have an instance <init>()V inline classes may not have an instance <init>()V, and may define a static <init>()this Karen: can an inline class omit a static <init>? John: yes - e.g. anonymous class - name is not mentionable in a descriptor
