[jsr294-modularity-eg] Runtime model
Bryan Atsatt
bryan.atsatt at oracle.com
Mon Jul 16 18:32:12 EDT 2007
Glyn and I both agreed that the use case is limiting external access to
legacy classes in a module. Supporting this at runtime allows the
unmodified legacy classes to continue to run in pre-Java 7 environments,
thus simplifying build/support/distribution.
// Bryan
Andreas Sterbenz wrote:
> Bryan Atsatt wrote:
>> So. Let me invert the question: why *not* support runtime binding?
>
> Earlier [1] you said:
>
> > While I think development time class rewriting is likely a decent
> > solution, it would be unreasonably complex/expensive if deferred to
> > runtime. Does anyone have a use case for binding legacy classes to a
> > superpackage at runtime?
>
> Do you have a use case now? If not, we should not let code at runtime
> change the semantics of application class files and avoid the
> complications and other problems that would introduce.
>
> Andreas.
>
>
> [1]
> http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2007-June/000105.html
>
>
>
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
More information about the jsr294-modularity-eg
mailing list