Initial discussion of solutions for issues presented in amber-dev/2022-May/007322

[Julian Waters]

Hi Kasper,

Yes, it is true that this seems to just be a minor inconvenience at first,
but the real issue is when you have to scale such code to bigger
applications. Writing public static methods and fields over and over again
is not a very fun thing to do, for instance. Besides this, I was also
thinking of the possible savings that could be in the JVM itself- This was
not just meant as a quality of life change for developers. You are correct
that an entirely new class probably isn't the best way to tackle the
problem- That's why this is labelled as a rough discussion on a mailing
list, not a full blown Java Enhancement Proposal ;) (In fact, I wasn't the
one that came up with the idea of package level methods)

(Regarding final interfaces, I'm not sure as of yet whether you could
remove object support in the runtime itself for classes acting only as
namespaces with this approach unfortunately)

best regards,
Julian

On Thu, May 19, 2022 at 3:22 PM Kasper Nielsen <kasperni at gmail.com> wrote:

>
>
> On Thu, 19 May 2022 at 05:33, Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Previously a list of issues were laid out in a previous posting to help
>> visualize the problem and (try to help) guide future attempts at tackling
>> it. I'd thought I'd just throw a few wild ideas out here at the moment to
>> keep things going for now in the background as work on Amber continues.
>>
>> As mentioned, a significant amount of Java boilerplate stems from code
>> that
>> is written procedurally- Functionally if you will. These usually take the
>> form of final classes with constructors that throw exceptions, which only
>> contain static methods.
>
>
> I don't think I've ever come across a codebase where the problem you are
> describing has resulted in any significant boilerplate. Yes, writing
> private
> throwing constructors is annoying. But that's about it, a minor annoyance
> at
> most.
>
> If this really is such a big issue. I think you can solve this a lot
> easier than
> by adding a new type of class. For example, by allowing interfaces to be
> declared final. In which case they can neither be implemented nor
> instantiated.
> And as a result, the only types of members that would be allowed on a final
> interface would be static fields and methods.
>
> /Kasper
>