3 ms·
> It turns out that lots of software makes assumptions about the classloader structure and which classloaders load it. They tried doing it that way early in Jig
by needusername 9y ago
> It turns out that lots of software makes assumptions about the classloader structure and which classloaders load it. They tried doing it that way early in Jigsaw's life and backed off because too much stuff broke.
Do you have a source for this? I have trouble accepting this argument for two reasons. First WilFly 7 and later (modular service container) completely changed the classloader layout to a non-traditional, non-hierarchical one. The amount of breakage introduced was negligible. In my experience the biggest source of breakage was read-only JNDI which is completely unrelated.
Second they (Oracle people working on Jigsaw) were completely unaware of the amount of breakage encapsulating internal APIs would introduce and had to back out of it at the last minute (i.e. this year). This suggest to me they did at best minimal testing, they certainly never even started a hello world Spring or Guice application.
My recollection from one of many Jigsaw talks that Mark Reinhold gave at was they would have to implement a SAT solver (like OSGi) and didn't want to do that because reasons.
- mike_hearn 9y agoMy source is a comment to that effect on the JPMS/Jigsaw mailing lists, from Mark Reinhold. I don't have the link off hand unfortunately and pipermail is from the dark ages so searching for it again would take time. I think the Oracle guys were aware of how much would break when they blocked access to internal APIs, but felt the costs were worth it and/or that people would adjust their code during the Java 9 development cycle so the breakage would be less by the end. Another cited reason was simply getting to the point of shipping something. Java 9 is already quite late. I can see why they'd punt features to future releases to try and ship what they have.