4

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.

TreffnonX
  • 2,924
  • 15
  • 23
  • would be cool if you could explain your proposal in a few words, here. there are plenty of jdk developers on this forum. may be, fi they find it interesting... – Eugene Jul 09 '19 at 09:03
  • In compliance with StackOverflow's guideline of not asking questions that will trigger statements of opinion or polls, I tried to leave the exact spec out intentionally. but I will add a bit of info, as a side note. – TreffnonX Jul 09 '19 at 10:50
  • 1
    That is an entirely new logic resp. language, with a respectable overhead. _I am not criticising the idea (hey I am propagating Esperanto), but you need some fundament._ (1) Show how Optional map works (in comparison). (2) Consider a more general construct, like expression+catch: `x.getY().getZ() :| NullpointerException ? null`. (3) Similar constructs in other languages. (4) blog/contact and test implementation – Joop Eggen Jul 09 '19 at 11:29
  • @JoopEggen I do, in the full JSR/JEP. To make it short: It is not intended to catch a NullPointerException, or any other. In fact, that is a non-goal. I want to avoid throwing an exception in the first place. If i catch Exceptions, I hide exceptions that should be thrown, and not caught there. – TreffnonX Jul 09 '19 at 11:36
  • Yes but is hard to turn that into conventional concepts like _continuations_ or such, or functional _after_ operator `o`. But maybe you find support for a `?.` operator. – Joop Eggen Jul 09 '19 at 11:49
  • 1
    Null-safe calls and elvis operator are already a well known concept in other JVM languages. But I'm not sure if they should be mixed in the same proposal since they aren't actually related much. Independently they might have more chance to be considered. – kapex Jul 09 '19 at 11:58
  • I did not know that there was an elvis-operator in kotlin and other languages. For me, the null-safe call is the primary concept I want to push. The fallback value just seemed natural and necessary for non-Object fields/variables. – TreffnonX Jul 09 '19 at 12:06
  • @kapex Thank you for that hint. Kotlin has both required features (null-safe calls and elvis operator). In combination they reflect the inteneded concept. While it is still essentially two features, they pretty much go hand in hand, it seems. I can use this as a good reference. (And proof of concept) – TreffnonX Jul 09 '19 at 12:22

1 Answers1

2

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.

kapex
  • 28,903
  • 6
  • 107
  • 121