On Feb 24, 9:26 pm, Reinier Zwitserloot <[email protected]> wrote:
> A tonne of libraries out there will all of a sudden break when the new
> java8 (or whatever) is released with new methods on java.util.List,
> because they mistakenly specified compatibility with 7+. There's no
> way to test for this, certainly not at first (at some point I expect
> findbugs and other tools can find likely problems in this area). Also
> known as a clustersomething.
I'd assume that it's rather easy to test for such situations
automatically.
I mean, tools like https://sigtest.dev.java.net/faq.html and
http://clirr.sourceforge.net/ have existed for a while out there, and
any sufficiently large project has their own built from scratch.
The missing component to make it work smoothly is being able to
given a version constraint figure out where to find the source code
for
the dependency or the corresponding binary object or a representation
of
its exported API. Given a module system, it shouldn't take much effort
to mine the metadata and put it to such use.
You can do all kinds of fun things automatically once you have a
metadata graph, where nodes carry actually useful annotations,
like tests, sources, etc. rather then just a bunch of binary blobs.
See http://www.cpantesters.org/show/JSON.html#JSON-2.14 for a
tiny example.
A fun blog to read on the tangetial subject of modernizing a platform
is chromatic's at http://www.modernperlbooks.com/mt/index.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
