OK, I see now. I don't think it's crazy stuff. It's the kind of creative thinking not done by existing module systems because they don't have to handle unversioned and versioned code simultaneously.
As we start to split up the JRE, we'll see what kind of binary incompatibilities look desirable either for 7 or post-7. I'll get back to you :-) Alex On Feb 26, 4:34 pm, Reinier Zwitserloot <[email protected]> wrote: > I was more talking about e.g. a classloader that will on-the-fly > rewrite 'old style' code to 'new style' code. For example, it would on- > the-fly rewrite something like: > > Point p = foo.getSize(); > p.x = 10; > bar.setSize(p); > > to: > > MutablePoint p = MutablePoint.of(foo.getSize()); > p.x = 10; > bar.setSize(p.toPoint()); > > Where the code to do that rewrite ships along with the library itself > (e.g. the above 'template solution' would be a part of Point v8. > > Crazy stuff, perhaps. I don't think any programming language has gone > here before. But that's what I'm talking about: If something like that > was added, we really could unshackle almost all the old API and fix > it, thinking -only- of making sure the legions of java coders can keep > up with the changes mentally. > > On Feb 26, 8:44 pm, Alex Buckley <[email protected]> wrote: > > > On Feb 25, 7:59 pm, Reinier Zwitserloot <[email protected]> wrote: > > > > Alex, you haven't explained how we can migrate list safely, then. > > > > If lots and lots of legacy code cannot accept new-style lists, then > > > trying to integrate with the older code is going to be a very > > > frustrating exercise. > > > In general, legacy code CANNOT use new-style lists. If JDK8 makes > > binary-incompatible changes to List, e.g. drops size(), then only 8- > > aware clients must get it. If JDK8 makes source-incompatible changes > > to List, e.g. adds filter(), then only 8-aware extenders must get it. > > > There is no middle ground here; if incompatible changes are made in > > version n (an enormous decision!), then some legacy code is stuck > > forever in the pre-n world. Legacy code is implicitly bound to 7.* > > classes on a 7 VM, an 8 VM, a 9 VM, etc. > > > For generics, there was a middle ground: legacy code was permitted to > > use generic types with warnings where type correctness was > > compromised. Those warnings were necessary even if the program is > > ultimately type-safe. At least for modules, there is no such ambiguity > > because it's clear which features are used by legacy code that are not > > provided by a new List. > > > > Which brings us back to my original point: > > > > Modularization is very cool, and we really need it, but without some > > > serious wrapping/view/translation tricks, modularization is not going > > > to allow us to fix bad core API. Some work on the fringe might be > > > possible if sun is okay with losing backwards compatibility in very > > > rare circumstances. > > > Let's think about wrappers. Suppose JDK8 wants to drop a class. To > > offer migration to a legacy client, the only possible option is to > > leave the class in place but to annotate all its methods with > > @CarefulThisMethodIsREALLYDeprecatedAsOf("8") and make the bodies > > throw RuntimeException. We could imagine strategies like "javac: give > > warnings in version n and errors in n+1" but ultimately the client is > > going to have change their code. The provider wants that change to > > happen ASAP. The easiest change for the client is to modularize itself > > - this doesn't have to mean much more than declaring a dependency on > > JDK 7.*. (And javac + a module system can assume this dependency > > automatically, as I said.) > > > But look: if the client can be recoded to not use the dropped class, > > then the "skeleton" class was unnecessary in the first place, since > > it'll be obvious that a formerly usable class has become unusable. If > > the client cannot be recoded to avoided the dropped class, then 7.* is > > its dependency forever and the skeleton class adds nothing. > > > Other changes are harder. Suppose JDK8 changes a class from public to > > module-private. Classes in the same module can still use it so the > > method bodies need to stay intact. The trick of having a method check > > who calls it at runtime (as proposed > > inhttp://wiki.apidesign.org/wiki/AlternativeBehaviour) > > won't work since access control applies at compile-time. > > > Once the provider has made the choice to break binary compatibility, > > the only option seems to be to let multiple versions (old "unbroken" > > and new "broken") coexist. > > > Alex --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
