True, such a crazy rewrite scheme would be most useful when handling
unversioned code,
but even 5 years down the line when most java code out there is
versioned and modularized properly, such a scheme - especially for
code which lies 'on the boundary' between modules would be very useful
still. A way to take code which is written for version X of a certain
library and make it semi-magically work with version Y (which is
newer, better, and not entirely compatible with X) is very useful.
On Feb 27, 3:21 am, Alex Buckley <alex.buck...@sun.com> wrote:
> 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 <reini...@gmail.com> 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 <alex.buck...@sun.com> wrote:
>
> > > On Feb 25, 7:59 pm, Reinier Zwitserloot <reini...@gmail.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
