Review of JEP draft

[Julian Waters]

Hi David,

I was under the impression that the reason the standard for introducing new
opcodes is so stringent was partially due to the constraints imposed by the
current single byte scheme. Is that not the case in practice? In any case,
I'll keep this JEP shelved in case it may be of use in the future.

best regards,
Julian

On Fri, Mar 18, 2022 at 8:30 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Julian,
>
> On 17/03/2022 10:19 pm, Julian Waters wrote:
> > Hi everyone,
> >
> > If you don't mind a little reading, can I get a review of the following
> JEP
> > draft at
> >
> https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8283291?filter=allissues&orderby=created+DESC%2C+priority+DESC%2C+updated+DESC
> ?
> > Apologies if this is not the proper way to submit a JEP, I'm a little new
> > to this.
>
> The bar is set very, very high, for introducing new bytecodes and
> consequently running out of them has not been a problem in practice. The
> reason the bar has been set so high is because the impact of a new
> bytecode on the whole Java ecosystem is enormous. Numerous new features
> have considered the possibility of adding a new bytecode, but very few
> have actually done so, instead flexible mechanisms like invokeDynamic,
> were introduced, that could then be used to implement a range of other
> features.
>
> If we had almost no spare bytecodes left, and we regularly added new
> bytecodes, then this would be a problem that needs solving. But as it
> stands I don't see a real problem that needs solving here.
>
> YMMV.
>
> Cheers,
> David
>
> > Have a great day!
> >
> > best regards,
> > Julian
>