Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUI

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

I don't believe this is a hugely relevant scenario to begin with, and I don't think you understood the complexity of supporting several preview versions in one implementation.

I was tempted to ask you to prepare a PR for what you think to be easy, but I'm not sure who would review it.

I'll focus on issues where I know that they're relevant and that I can fix them. I won't continue in this particular discussion.

On 22.01.25 17:22, Mickael Istria wrote:

You're only looking at the trivial part, but you miss the tons of locations that query this data. With your proposal we would never be able to remove any preview checks of features that have long matured, and we would even need separate checks for repeated previews with changes between them.

am I missing anything?

I found JavaFeature.isPreview() has 2 consumers:

* ProblemReporter.validateJavaFeatureSupport(...)

* ProblemReporter.validateRestrictedKeywords(...)

both do take can access the compliance from `this.option.sourceLevel`.

So it would be possible to replace each call to `isPreview()` by some `isPreview(this.options.sourceLevel)` which would instead of directly returning true/false, would look like

```

enum JavaFeature {

   ...

   int lastPreviewVersion; // set to 0 if was never preview

   boolean isPreview(long compliance) {

      return compliance <= lastPreviewVersion

   }

```

--

Mickael Istria

Eclipse IDE developer, for Red Hat