On 04.02.24 17:38, Oscar N wrote:
[...]
Jochen Theodorou:
VMPlugin should not call into SBA or InvokerHelper.
Should I be copying over code in that case? Or should it be calling DGM
instead?
if you have code that is there to produce an unmodifiable list by DGM
and that logic of that depends on the VM version, then I expect this
code in the plugin and DGM calling the plugin. If there is code shared
between VMplugin and other code parts and the shared part does not
depend on the VM version, then maybe the VM variant needs reduction to
the really version dependent part and the caller needs to handle the rest.
In short I would like to keep the VM specific code parts as small as
possible.
I actually now wonder why you do Arrays.stream(values).toList(); in the
Java16 version. Would List.of be better if all elements are not null? If
yes, then why not check them? And why go with List#of and catch-NPE
instead of stream before?
Stream#toList ends up creating the same kind of object (with its JVM
@Stable optimisations) as List#of (see
java.util.stream.ReferencePipeline#toList). The difference is the former
allows nulls, while the latter iterates over each parameter and throws
an NPE if any are null. Using the try-catch approach is slower because
in the worst-case scenario it would be performing lots of null checks
only to give up and use Collections#unmodifiableList, which the JVM
can't optimise as easily due to being backed by a mutable collection.
yeah, well that is what I did mean with keeping the responsibilities
specific. When does it really matter how many list elements there are?
Only if the list has a certain size. This size is imho not given in case
of records. Thus I think it is perfectly fine for record to list
conversion code to check all elements for null, but not for a
potentially millions of entries long list if it can be avoided. That
means the requirements for the bytecode case and for a general DGM entry
are not 100% the same.
bye Jochen
