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

[Brian Goetz]

> But that's what the mailing list is here for, isn't it?

Actually, that's not what this mailing list is for.  This is the 
*development* list for the Amber project.  That means discussions on the 
implementation, collaboration between implementors, bug reports, 
experience reports, etc, on the various JEPs that are actively being 
developed in Project Amber.

We try not to be too restrictive when discussions wander out into 
"wouldn't it be nice if" -- sometimes these are helpful and aligned with 
the work going on here -- but that's not the charter of this list.

> The unfortunate truth is that modern developers are very unforgiving when
> getting to know a new language, and one public static void main(String[]
> args) later they will have acquired a burning hatred for Java (If not
> immediately driven off by the main method, then when they have to write
> multiple static methods). To you and me, it's not much of a big deal, but a
> vast amount of people do not share the same opinion. If Java is to stay
> competitive, this is an ugly side of the general dev community we'll have
> to end up facing one way or another- There's only so much that
> supercharging the JVM's performance can do, if a large amount of developers
> still find the language a torture to work with, we're done for, and there
> is absolutely no shortage of hatred for the language's syntax (It's not an
> uncommon event for people to exclaim "Companies still use Java???" in
> absolute shock when asked if they have any knowledge of it!). Of course
> turning Java into a language overladen with sugar and having 50 ways to do
> the same thing is out of the question- I too enjoy how explicit it is most
> of the time,

All of this is true.  I think the reason that you got a 
less-positive-than-expected response is that it is also the case that 
*all of this is well understood*.   We are well aware that "public 
static void main" is an unfriendly onramp.  This is obvious.  Fixing it 
in the right way is not obvious, will take time, and in fact something 
that we've already laid some of the groundwork on, as referenced in the 
mail that Steve pointed to.  And it competes for priority and resources 
with all the other "obvious" ideas of how to make Java better.

It is very common that people will show up on a forum like this thinking 
"If I just manage to convince them there's a problem, something will 
happen."  Believe me, we understand the problem. (Or perhaps the dozens 
of interlocking problems that give rise to this state of affairs.)  We 
also understand the other million problems facing Java, and have to 
balance our efforts carefully.

> but we should at least try to get rid of extra verbosity that
> can be confirmed to not benefit anyone in any way whatsoever (Ignoring the
> current discussion, isn't that what records were introduced for?).

Actually, no!  The boilerplate-reduction benefits of records is a bonus, 
but was not the point.  Records are about the language having a direct 
way to describe *data as data*.  This is a semantic upleveling, not a 
mere boilerplate-reduction.  The boilerplate reduction *derives from* 
the semantic upleveling.

If we started with a goal of "reduce the boilerplate of POJO classes", 
the result would look more like Lombok or one of the million "bean 
generator" frameworks.  That would not have been a successful direction 
to take the language.  So no, records were not about "getting rid of 
verbosity", they were about *saying what you mean.*  There's a big 
difference.