It's not too late for access control

[Jochen Theodorou]

On 16.07.2016 00:26, dalibor topic wrote:
>
>
> On 15.07.2016 15:39, Jochen Theodorou wrote:
>> On 15.07.2016 14:55, dalibor topic wrote:
>> [...]
>> And if adopting the more correct practices requires them to make a huge
>> breaking change? Maybe even getting rid of base principles?
>
> Commitment bias to accumulated technical debt is completely
> understandable. Unfortunately, it's also a bad guiding principle, as the
> nice picture of "shoveling forward" in
> http://ferd.ca/on-technical-debt-shoveling-forward.html illustrates.

You seem to be talking about achieving a certain goal and doing that 
using the wrong mechanisms... What about features that exist only 
because you have been able to trick the API or the JVM?

Just as an example... because the JVM used to have a URLClassloader when 
starting, it was possible to add classes there at runtime and @Grab was 
born to make use of that. Now this is no longer possible, @Grab will no 
longer work on JDK9 in many many cases. Why is that technical debt? 
There is simply no way to make this work like before anymore.

Or another example... back in early Java8, when the Verifier was changed 
to be more strict and broke about every single Groovy program out there, 
that did have overloaded constructors in the super class... if that 
change had not been undone, this would have been the end of Groovy, 
since there is no alternative way. And the verification was perfectly 
valid for Java. So is that technical debt?

bye Jochen