On 16.07.2016 09:18, Jochen Theodorou wrote:
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?
In that case, I'd suggest first working on bringing the necessary
features into the missing platform layers, and once they are available,
migrating to them.
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?
When someone deliberately breaks out of the boundary of what's supported
functionality in a platform, they consciously trade off the benefits of
that action against the risk of their code falling apart further down
the road.
In other words, the benefit needs to be sufficiently advantageous to
allow them to invest a part of its gains in eliminating the problem
before the risk eventually materializes, for example by working on
introducing the feature in a supported way at the appropriate layer of
the platform, and then migrating to it.
If the benefit isn't sufficiently advantageous for that, or if they fail
to plan adequately to eliminate the risk, then they might have a problem
in some version of the future. But the core problem is not that a risk
they consciously undertook eventually materializes, it's with risk
assessment and decision making - and it's an entirely human thing to not
get quite right.
A nice, long read on that from a security perspective is here:
https://www.schneier.com/essays/archives/2008/01/the_psychology_of_se.html
In open source ecosystems, there is often an additional human factor -
people responsible for making the trade offs may be long gone from a
project (as well as the associated benefits), by the time the risk they
consciously introduced into a piece of software materializes.
So tools for conscious risk (re-)assessment are important, such as
jdeps, or -XX:+CheckEndorsedAndExtDirs, ... as is empathy.
cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
