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
