RFR: 8349848: Support lint control of sunapi diagnostics

[Archie Cobbs]

On Mon, 17 Feb 2025 09:55:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR creates a new lint category `proprietary` that controls the mandatory warning "Foo is internal proprietary API and may be removed in a future release".
>> 
>> This allows developers to suppress this warning using `-Xlint:-proprietary` and/or `@SuppressWarnings`.
>
> @archiecobbs I think it's a bit premature to create a PR for this as it sends a confusing message to developers about the future of these APIs. The APIs in the jdk.unsupported module, otherwise known as the "critical internal APIs" (see JEP 260), have no future. It's a feature that javac generates a warning that can't be suppressed with `@SuppressWarnings` when compiling code that uses classes in this module. The roadmap to remove these classes has now progressed to a warning at runtime (see JEP 498). A future JEP will remove the ability to suppress the warning at runtime.  The long standing (undocumented) workaround to use `-XDignore.symbol.file` when compiling with `-Werror` requires a nose peg but I think we are stuck with it, and the status quo, until jdk.unsupported module is removed.

@AlanBateman @lahodaj @mcimadamore ,

Thanks for your comments. Sounds like this idea isn't very popular :)

I feel that before throwing in the towel on this one and in the interest of due diligence I should do my best to provide my rationale on the other side of the coin and if that doesn't persuade you (which it probably won't) then I'm happy to drop it.

First, let's not conflate the existence of a technical mechanism with specific policy goals about specific API's. I'm in complete agreement with JEP 260 and the steps & timeline for deprecating then removing these dangerous APIs.

This PR is simply providing a technical mechanism for people to manage their compilations - is that really such a bad thing? The existence of this mechanism doesn't imply any opinion about the wisdom of relying on deprecated API's. The default behavior is always going to be a mandatory warning - great! To suppress the warning, a developer has to make a deliberate choice.

By way of analogy, consider how the deprecation and removal of old API's has a symmetry with the addition and preview of new API's. In both cases, there is a three-step process.

For the removal of API's:
1. Fully Available
2. Available but Deprecated
3. Removed

For the addition of API's:
1. Not Available (does not exist yet)
2. Available as Preview
3. Fully Available

In both cases, Step 2 serves as a transition period where, without special compiler flags, a mandatory warning or compiler error is generated. The point is to say "You are being officially warned that this feature is in transition".

Now why do we allow suppressing the mandatory preview error/warning, even though the feature being relied upon has a non-trivial chance of disappearing (string templates, anyone?). Because when a developer adds those flags they are saying "I am explicitly acknowledging and accepting this risk, now stop bothering me".

We're in the same situation with critical API's - the status of the feature is tenuous, so by default they get the warning. If they then choose to suppress it with `-Xlint:-proprietary` they are saying "I am explicitly acknowledging and accepting this risk, now stop bothering me".

Let's not patronize developers. They are capable of understanding the risks and trade-offs. Anyway, practically speaking, if you believe that the verbosity of a warning is what determines whether a developer chooses to rely on `Unsafe` or not, you are kidding yourself. People use `Unsafe` because it gets the job done, warnings be damned, so they can deal with higher priority stuff. When it eventually disappears, they'll deal with it however they have to; you don't need to worry about their being surprised. They will have been sufficiently warned - which is the whole point here, isn't it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23650#issuecomment-2663674687