Is there a meaningful way of collecting feedback for a JSR/JEP before entering it as a proposal?

Question

I intend to launch a JEP/JSR to introduce an alternative access operator into the Java Language Specification. I've worked out how the proposal could look like, and now I want to collect feedback on said proposal (for example, if I am the 999th person to suggest this one thing). I want to do this preferably before actually starting the proposal. However there seems to be no forum or board around either the openJDK or the Java Community Process. At least I was unable to find anything. I did however find a #openjdk IRC channel, but aside from people entering and leaving, there seems to be no communication there.

If I want to go the least invasive/intrusive way of getting my idea along to other people, what way would I choose? Is there no alternative than actually launching a JSR and awaiting active feedback?

Aside from the actual question, because it was asked what the exact idea is:

The Java programming language allows the chaining of expressions in order to signify a flow of operations within a larger expression, and to ease access to 'deep' values.

String fieldText = tableProvider.getTable(tableKey).getRow(rowKey).getField(columnKey).text;

However, if the '.' accessor tries to access a nullary object, a NullPointerException is thrown, making any unchecked access risky. Even if the fallback for such a case is simply null or a static primitive value, a developer needs to handle every possible NullPointer-scenario explicitly. Alternatively they can generally catch the NullPointerException, which requires the returned value to be stored to a variable defined in a scope outside the try-catch block, so it can later be accessed outside the try-catch statement. However, this also catches NullPointerExceptions thrown within any accessed method, which might not be intended.

To avoid this, a new accessor is proposed, which aborts the resolution of a chained expression, in case the accessor would access a nullary object, and instead falls back to null, or a specified default value.

String fieldText = tableProvider.getTable(tableKey)°getRow(rowKey)°getField(columnKey)°text;

int i = tableProvider.getTable(tableKey)°getRow(rowKey)°getField(columnKey)°index ?: (-1);

In this example, if any of the invokes methods (getTable, getRow or getField) return null, the entire chained expression would terminate and return null (or -1), rather than throw a NullPointerException.

The above is the Motivation section of a plain JEP/JSR I wrote up. ° is just a placeholder for any operator, that would not cause arbitrary interpretation. The actual draft specifies a bunch of non-goals as well, which among others are

• Not having to handle null in places where null is not expected.
• Deprecate NullPointerException.
• Generally replace the '.' accessor.
• Catch already thrown NullPointerExceptions.
• Generally replace the Optional class in it's function as return type.

Edit: It appears that the concept I am suggesting is already part of kotlin (among others), but comprised of two features: the 'safe navigation operator', as well as the 'elvis operator'. The former is what I want to focus on.

Answer 1

JEP 1 says:

It is expected [...] that the typical new proposal will start as an idea explored informally and shaken out within a specific Group, then drafted as a JEP for further review and comment, then endorsed by that Group's Lead and later the relevant Area Lead, and then submitted for acceptance by the OpenJDK Lead. Discussions along the way will usually take place in e-mail, but review meetings may be useful for particularly large or contentious proposals.

So basically the idea should be discussed by e-mail (usually this means in a mailing list). There is a big list of Java mailing lists for various topics. Maybe you find a group related to your proposal there.

I think most language changes are sponsored by the compiler group, so their mailing list could be good starting point to get further directions about where to discuss and or even spark a discussion there.