Submitting a JEP

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Submitting a JEP

Daniel Trebbien
Hello,

I have an idea for enhancing the Java programming language (
https://github.com/dtrebbien/JEP-Unreachable-Assertions ).  It is my
understanding that in order to change the Java programming language, a JSR
will need to be written, but that a good first step is to submit a JDK
Enhancement Proposal to gauge support for the idea.  I read JEP 1: JDK
Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 )
and followed the instructions:  I wrote a draft JEP using the template (
http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash
submit at openjdk dot java dot net", converted back to a valid email
address.

That was five days ago and I have not received a response.  It could very
well be that people are busy.  I would like to confirm, though, that the
emailing procedure is still used now that JEPs are being migrated to the
JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ).

Is "jep dash submit at openjdk dot java dot net" actively monitored?

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

Brian Goetz-2
The proposal is a bad fit for the assertion facility, since the
assertion facility is designed to be disabled, and what you want is
something that can't be disabled.

But here's an alternative:

     throw new UnreachableAssertionException("why");

This doesn't need a language feature.  It doesn't even need a special
exception class:

     throw new AssertionError("Unreachable: blah blah");

Adding language features has a significant cost; we prefer to spend that
where there are not practical alternatives.



On 10/5/2017 5:27 PM, Daniel Trebbien wrote:

> Hello,
>
> I have an idea for enhancing the Java programming language (
> https://github.com/dtrebbien/JEP-Unreachable-Assertions ).  It is my
> understanding that in order to change the Java programming language, a JSR
> will need to be written, but that a good first step is to submit a JDK
> Enhancement Proposal to gauge support for the idea.  I read JEP 1: JDK
> Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 )
> and followed the instructions:  I wrote a draft JEP using the template (
> http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash
> submit at openjdk dot java dot net", converted back to a valid email
> address.
>
> That was five days ago and I have not received a response.  It could very
> well be that people are busy.  I would like to confirm, though, that the
> emailing procedure is still used now that JEPs are being migrated to the
> JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ).
>
> Is "jep dash submit at openjdk dot java dot net" actively monitored?
>
> Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

David M. Lloyd-3
On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz <[hidden email]> wrote:
> The proposal is a bad fit for the assertion facility, since the assertion
> facility is designed to be disabled, and what you want is something that
> can't be disabled.

I believe that in the document, Mr. Trebbien explicitly explained why
the assertion facility is a bad fit, and was specifically not
suggesting it be used, but rather using it as an example and template
for the new feature.

> But here's an alternative:
>
>     throw new UnreachableAssertionException("why");
>
> This doesn't need a language feature.

It does, because you cannot put "throw" statements in places where the
compiler has statically determined that control flow cannot reach,
which is a key part of the justification of the feature described in
the document.

This is a feature that I for one have sorely missed for many years
now, especially in more complex state-oriented code where exit points
cannot be made visually clear.

>  It doesn't even need a special
> exception class:
>
>     throw new AssertionError("Unreachable: blah blah");
>
> Adding language features has a significant cost; we prefer to spend that
> where there are not practical alternatives.
>
>
>
>
> On 10/5/2017 5:27 PM, Daniel Trebbien wrote:
>>
>> Hello,
>>
>> I have an idea for enhancing the Java programming language (
>> https://github.com/dtrebbien/JEP-Unreachable-Assertions ).  It is my
>> understanding that in order to change the Java programming language, a JSR
>> will need to be written, but that a good first step is to submit a JDK
>> Enhancement Proposal to gauge support for the idea.  I read JEP 1: JDK
>> Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 )
>> and followed the instructions:  I wrote a draft JEP using the template (
>> http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash
>> submit at openjdk dot java dot net", converted back to a valid email
>> address.
>>
>> That was five days ago and I have not received a response.  It could very
>> well be that people are busy.  I would like to confirm, though, that the
>> emailing procedure is still used now that JEPs are being migrated to the
>> JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ).
>>
>> Is "jep dash submit at openjdk dot java dot net" actively monitored?
>>
>> Daniel
>
>



--
- DML
Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

Daniel Trebbien
On Fri, Oct 6, 2017 at 7:24 AM, David Lloyd <[hidden email]> wrote:

> On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz <[hidden email]>
> wrote:
> > The proposal is a bad fit for the assertion facility, since the assertion
> > facility is designed to be disabled, and what you want is something that
> > can't be disabled.
>
> I believe that in the document, Mr. Trebbien explicitly explained why
> the assertion facility is a bad fit, and was specifically not
> suggesting it be used, but rather using it as an example and template
> for the new feature.
>

Specifically, in the Alternatives section (
https://github.com/dtrebbien/JEP-Unreachable-Assertions/blob/master/jep.md#alternatives
), I discuss why neither allowing the proposed "unreachable assertions" to
be disabled, nor amending §14.21 Unreachable Statements to allow
unreachable `assert false' statements, is preferred.

The JLS specifies in §14.10 that an assertion is either enabled or
disabled.  However, the JLS does not specify how assertions are enabled or
disabled.

Unless I am mistaken, there is no standard way to guarantee that assertions
compiled into a CLASS file will be disabled at runtime.  Therefore, unless
the distributor of Java software uses some sort of post-compilation
assertion stripping from CLASS files, the programmers must assume that
assertions might be enabled at runtime.

> But here's an alternative:
> >
> >     throw new UnreachableAssertionException("why");
> >
> > This doesn't need a language feature.
>
> It does, because you cannot put "throw" statements in places where the
> compiler has statically determined that control flow cannot reach,
> which is a key part of the justification of the feature described in
> the document.
>
> This is a feature that I for one have sorely missed for many years
> now, especially in more complex state-oriented code where exit points
> cannot be made visually clear.
>

Yes.  §14.21 Unreachable Statements requires unreachable statements to be
compile-time errors, so you currently cannot place a statement like `throw
new UnreachableAssertionException("why");' at points defined to be
unreachable.
Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

Mario Torre-5
I'm reading the proposal a bit and I don't think it's a very good idea
to introduce another keyword.

While it may be nice to have such statement, effectively you are
promoting bad programming use cases.

If we take the stack overflow link as an example, it's clear that the
developer could simply rearrange his code to be more stable by using
some of the advanced features of Java like classes and inheritance ;)
or at worse by just documenting the need to add the return after the
else branch

In all the other examples you give in the proposal, unless I'm
misreading them, it seem that they are not unreachable statements in a
sense that can the statically defined, but are simply cases that the
developer "knows" they won't happen, but they may, and so they can be
solved by an assert or by a runtime exception.

So the only use case I see is the stack overflow one, but it seems to
me this is just bad code practices, which is branching points with
multiple return statements, that is always asking for troubles.

In the short term future we will get enhanced switches with patterns,
which turns switches into expression, and it makes the stack overflow
example a lot easier to write without side effects.

Cheers,
Mario

2017-10-06 16:30 GMT+02:00 Daniel Trebbien <[hidden email]>:

> On Fri, Oct 6, 2017 at 7:24 AM, David Lloyd <[hidden email]> wrote:
>
>> On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz <[hidden email]>
>> wrote:
>> > The proposal is a bad fit for the assertion facility, since the assertion
>> > facility is designed to be disabled, and what you want is something that
>> > can't be disabled.
>>
>> I believe that in the document, Mr. Trebbien explicitly explained why
>> the assertion facility is a bad fit, and was specifically not
>> suggesting it be used, but rather using it as an example and template
>> for the new feature.
>>
>
> Specifically, in the Alternatives section (
> https://github.com/dtrebbien/JEP-Unreachable-Assertions/blob/master/jep.md#alternatives
> ), I discuss why neither allowing the proposed "unreachable assertions" to
> be disabled, nor amending §14.21 Unreachable Statements to allow
> unreachable `assert false' statements, is preferred.
>
> The JLS specifies in §14.10 that an assertion is either enabled or
> disabled.  However, the JLS does not specify how assertions are enabled or
> disabled.
>
> Unless I am mistaken, there is no standard way to guarantee that assertions
> compiled into a CLASS file will be disabled at runtime.  Therefore, unless
> the distributor of Java software uses some sort of post-compilation
> assertion stripping from CLASS files, the programmers must assume that
> assertions might be enabled at runtime.
>
>> But here's an alternative:
>> >
>> >     throw new UnreachableAssertionException("why");
>> >
>> > This doesn't need a language feature.
>>
>> It does, because you cannot put "throw" statements in places where the
>> compiler has statically determined that control flow cannot reach,
>> which is a key part of the justification of the feature described in
>> the document.
>>
>> This is a feature that I for one have sorely missed for many years
>> now, especially in more complex state-oriented code where exit points
>> cannot be made visually clear.
>>
>
> Yes.  §14.21 Unreachable Statements requires unreachable statements to be
> compile-time errors, so you currently cannot place a statement like `throw
> new UnreachableAssertionException("why");' at points defined to be
> unreachable.



--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/
Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

David M. Lloyd-3
On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre
<[hidden email]> wrote:
> I'm reading the proposal a bit and I don't think it's a very good idea
> to introduce another keyword.
>
> While it may be nice to have such statement, effectively you are
> promoting bad programming use cases.

I disagree.  The use case for this *construct* (I say "construct"
because it doesn't have to be a statement, and really that's
bikeshedding at this point) is where the code in question is complex,
not necessarily because it is done "badly" but because there is no
other reasonable choice.  Yes you can replace a switch statement with
a class hierarchy, but what if that increases your code size from 100s
of K to 1000s?  What if you're writing something for a small
environment (embedded or cloud) where code density is important?  What
if you're writing a DFA like this one [1] (note how my throw must be
commented out here) where introducing inheritance or other "proper OO"
techniques would increase complexity and decrease performance beyond
an acceptable margin?

It is not realistic to assume that all code should be structured in
one way, or that inheritance is always an option; there is no
programming language yet for which this kind of assumption is
reasonable.  In Java in particular, such compromises are and always
will be necessary.  You cannot establish the requirements for the size
and shape of the output based on enforcing certain coding techniques
and tools; instead you must choose the techniques and tools which
allow you to meet the requirements of your software.

Java is still a procedural language no matter how much we might wish
to pretend otherwise, and procedural languages are subject to certain
realities and constraints.  This construct eases one such constraint
and would result in better code, not worse.  Consider for example that
your IDE of choice could highlight locations where unreachability is
asserted, yet static analysis shows that reaching the code is
possible.  In this case the user would be inclined to document why the
condition is actually unreachable, which only helps maintainability
down the road.

[1] https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/wildfly/common/expression/Expression.java#L376

--
- DML
Reply | Threaded
Open this post in threaded view
|

Re: Submitting a JEP

Daniel Trebbien
In reply to this post by Mario Torre-5
On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre <[hidden email]
> wrote:

> I'm reading the proposal a bit and I don't think it's a very good idea
> to introduce another keyword.
>
> While it may be nice to have such statement, effectively you are
> promoting bad programming use cases.
>
> If we take the stack overflow link as an example, it's clear that the
> developer could simply rearrange his code to be more stable by using
> some of the advanced features of Java like classes and inheritance ;)
> or at worse by just documenting the need to add the return after the
> else branch
>

This wasn't explicitly stated in my proposal, but I am the one who asked
the question on Stack Overflow.

In my case, the code in question (part of my SLF4J Helper plugin for
NetBeans IDE; http://plugins.netbeans.org/plugin/72557/slf4j-helper )
performs static analysis of Java code through its representation as Java
compiler tree object hierarchies and javax.lang.model types.  It is not
particularly easy programming because I have to try to understand and
handle without exception every possible object hierarchy representing an
expression tree that the plugin might see in attempting to analyze some
piece of Java code.  This is complicated by things like ErroneousTree (
https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ErroneousTree.html
) and ErrorType (
https://docs.oracle.com/javase/8/docs/api/javax/lang/model/type/ErrorType.html
) whose existence implies to me that the object hierarchies that my plugin
could encounter might not even correspond to well-formed code.

If all branches of the if-else if-else chain ended with a return statement,
then you're right that I could factor out that code into a helper method
and return the result of calling that helper method in the switch case.
But, not all branches return something.  Some branches continue or break an
enclosing loop, for example.

I do have comments explaining the need to prevent fall-through.  This is
not a very nice solution, however, because like Mr. Lloyd's DFA parsing
example, the code does not fit on one screen.  So, I could duplicate the
comments at the top and bottom, but still not see them depending on where I
am in the code.


>
> In all the other examples you give in the proposal, unless I'm
> misreading them, it seem that they are not unreachable statements in a
> sense that can the statically defined, but are simply cases that the
> developer "knows" they won't happen, but they may, and so they can be
> solved by an assert or by a runtime exception.
>
> So the only use case I see is the stack overflow one, but it seems to
> me this is just bad code practices, which is branching points with
> multiple return statements, that is always asking for troubles.
>
> In the short term future we will get enhanced switches with patterns,
> which turns switches into expression, and it makes the stack overflow
> example a lot easier to write without side effects.


This seems like Rust's pattern matching.  Practically everything in Rust
can be used as an expression, including `match', which is similar to the
`switch' statement in Java.  For example, here is some Rust code that I
wrote to parse Valgrind suppression files:
https://github.com/dtrebbien/valgrind-rs/blob/4b26c6f/src/lib.rs#L196  This
updates the parsing state based on the result of `match' on the current
parsing state.

While nifty, I don't think "expression switches" would address the problem.