[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