Rhino 1.9/2.0 and JDK 17

[andreabergia]

It would be very nice to adopt JDK 17, for multiple reasons: record, multiline strings, switch expressions. In the last few years, my feeling is that the Java ecosystem is moving on the latest LTS release at a good time frame and asking people to use JDK 17 is pretty reasonable today - Spring is doing it, for example.

It's been a while since 1.8 and there's a ton of changes already in, but some of the stuff that @aardvark179 is working on, such as those discussed in #2054, will require some breakage of the API.

My proposal is that we release a 1.9 from master soon-ish, without any major breaking changes, and then start integrating all the things that working requires breaking changes for a future 2.0 release, with the JDK 17 requirement.

Let's discuss! 🙂

[aardvark179]

I think it might be worth creating a feature branch for 2.0 which we could regularly rebase on top of master. I don't think we should rush to 2.0 because we want to try and get pretty much all the API change we need into that, and that might take time. In the meantime we may want to add changes to some pre-2.0 release to help smooth the transition, and we should try to avoid blocking potential smaller feature releases that might still be valuable in the interim.

I don't want @rbri, or us, to be unable to make a sensible release, or to have to refactor multiple times, because we're in the middle of developing 2.0 features and haven't got the APIs settled yet.

[andreabergia]

Yeah, that's what I had in mind, but thanks for clarifying it and making it explicit.

[aardvark179]

I think it's also worth having a discussion of what we want to do before we make a 2.0 release. Since we probably want to get all the external API changes into that release I think we should definitely include:

1. Changes to function signatures in preparation for better spec compliance. #2050 which would change the call and construct interfaces.
2. Separation of scopes and objects #2163 which is useful for later optimisations and would also affect those interfaces.
3. Changing the interfaces for put and delete to return a boolean and allow us to become more spec compliant on various property operations.
4. I think we should at least have done enough prototyping of property maps (Optimisation strategies for Rhino #1865), possibly via improving activation frames, to have a good feeling of whether that will affect our external APIs.

[rbri]

My proposal is that we release a 1.9 from master soon-ish, without any major breaking changes, and then start integrating all the things that working requires breaking changes for a future 2.0 release, with the JDK 17 requirement.

At least regarding HtmlUnit i like to move forward at the beginning of next year to version 5 - and JDK 17. So change of the jdk is fine for me. And regarding the features i'm fine with breaking something as long as we go forward with js. My fork is in sync with the head and I do not have to manage backward compatibility at the code level. I only like to be compatible with the current browsers...