Classes without Object support at runtime

[Brian Goetz]

When it comes to evolving the programming model, it is always more 
helpful to discuss what problem you are trying to solve, than the shape 
of any particular solution.  You allude to the problem briefly ("pay 
heavy taxes") but I would start there.  Adding new kinds of classes adds 
complexity to "everybody's Java"; such complexity has to be paid for 
somehow.  What payoff are you imagining?

On 4/30/2022 4:44 AM, Julian Waters wrote:
> 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