State of javac support for lworld-values.

John Rose john.r.rose at oracle.com
Tue Mar 27 01:28:00 UTC 2018


> On Mar 26, 2018, at 6:10 PM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> 
> 
> On Tuesday 27 March 2018 05:43 AM, John Rose wrote:
>> As far as javac is concerned, until a type has made the leap into the
>> value-type world, it is a reference type, and can pull all the crazy tricks
>> that are permitted to references, even when they are in poor taste.
>> 
>> Adding in new hard restrictions on a half-way point seems (IMO) to
>> create a new entity in the Java type system, neither value nor
>> reference, but something in between.  I think we'd regret that.
>> Soft restrictions will let us avoid such a hard commitment.
>> 
>> The appropriate escape hatch is annotations, which are not allowed
>> to change semantics (generally speaking) but are allowed to gate
>> lint-like behavior.  Karen's idea to mark VBC's is a good one, but it
>> must be interpreted with one eye on existing reference semantics,
>> which means that warnings (not errors) are the appropriate severity,
>> akin to the raw-type and unchecked warnings on today's generics.
> 
> OK, I read the above as essentially an endorsement for a lenient mode in javac for classes which are somehow recognized as having arrived from valuedom after having inhabited the reference world - i.e value based classes.
> 
> I was operating with missionary zeal that I managed to get infused in, to minimize the surface area where null pollution may originate - I can certainly attenuate that zeal :) A warning to Mr/Ms Programmer that he/she is may be about to blow his/her foot and sit back and watch: can be done.
> 
> (I still think javac's stern carping mode does not block the project from the goals of using javac to write tests or do experiments in separate compilation - by virtue of -source 10 mode, but I will look into the lenient mode in earnest)

I like your zeal.  :-)

Warnings are a good middle ground:  The end user is allowed to ignore them,
but may also choose to attend to them.  And @SuppressWarnings is a good
tool to record relevant decisions in source code.

I want to make sure I am addressing the right question:  I was mainly
speaking about VBCs, which are currently defined as object types, not
about new value types.  I think making a "lint mode" for them positions
us to deal with the cross-compilation problems of new values and old
clients, and vice versa.

You are talking (also / instead) about types which are known positively to
be value types, by inspecting their classfiles, and asking what happens to
code which still "thinks they are objects".  A non-lenient mode would
say, "you started down this path, now update *all* your code".  There
is a time for this, when the user really does want all the code checked
together.  I think I agree that a current source-level should enable this
strict checking; in any case there should be a command line switch
that turns it on (if it's not the default).

The lenient mode for this case would say, "oh, some of your code
apparently doesn't know about value types yet, so we will cut it
some slack".  Again, I think the source-level flag is a good way
to signal this intent, but in any case there should be some command
line switch.

I think we are agreeing that the right slack to cut, in the latter case,
is to observe that the old code is being compiled in an "world view",
and therefore it *couldn't* observe that something is a value type,
any more than it could observe that something is a C++ or Smalltalk
class.  Value classes are not on the menu.

When javac does see such a classfile (a true value type) while
working on "old" sources, then about the only reasonable thing
it can do (besides stop and complain) is to pretend that the
new value type is just a VBC, with the @ValueBased
annotation, and issue the right warnings from that viewpoint.
Maybe it can issue warning language that also says, "hey,
I happen to know that if you recompiled at the top source
level you'd get an error here".

(And this is the application of my argument, that warnings on
VBCs should be lenient, not strict; this reasoning carries across
to the case of cross-compiling with true VTs that must be
temporarily viewed as if they were only VBCs.)

— John


More information about the valhalla-dev mailing list