Submitting a JEP
david.lloyd at redhat.com
Fri Oct 6 15:45:41 UTC 2017
On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre
<neugens.limasoftware at gmail.com> 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  (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.
More information about the discuss