Classes without Object support at runtime

Julian Waters tanksherman27 at gmail.com
Sat Apr 30 08:44:00 UTC 2022


Hi all,

As part of a small suggestion towards the drafts for new language features,
could we have classes that have no support from the JVM whatsoever for
creating instances of themselves? (Essentially acting as a container for
methods, much like static utility classes but with less boilerplate).
Although Java's object system is powerful, quite a sizable amount of Java
code in production doesn't require the massive amount of flexibility and
utility that objects provide, and in this instance the language bares its
ugly head and begins making developers "pay heavy taxes" (as the amber-docs
put it) to write code that isn't tightly bound to OOP, in this instance
"objectless" classes could help developers write more concise code without
going through the pain of all the extra ceremony to write code that's
stateless or doesn't need to take advantage of objects. How they're
declared and any useful features that could be tacked on to them could be
discussed later on, but right now getting their basic structure right is
probably more important.

It'd be illegal for them to have an instance initialization
method/constructor at compile time and runtime, no other classes can extend
them, and anything declared inside them is always ACC_STATIC. As a bonus,
since this type of class wouldn't have to worry about subclasses, we could
change their access modifiers at the language level for convenience, so
that protected instead means it can only be accessed within the same
package, and have no access modifier mean "public" by default. This class
type would have none of the runtime infrastructure needed to create
instances of itself, and the new and invokespecial <init> opcodes would
ideally not accept this type of class, though there may be a runtime cost
related to checks that would have to be put in place for this which I'm not
currently aware of

Would appreciate feedback on the idea and any improvements that could be
made to it/any possible shortcomings

best regards,
Julian


More information about the amber-dev mailing list