[jsr294-modularity-eg] Strawman for the reflective API

[Glyn Normington]

Some comments on the reflective API strawman:

1. Maybe I'm missing something obvious, but please could you explain the 
rationale for the Superpackage class belonging to the java.lang.reflect 
package rather than java.lang?

2. ClassLoader.findSuperpackage does not appear to follow the normal rules 
of class loader delegation as there is no loadSuperpackage analogue of 
loadClass. Is this because we expect findSuperpackage to be driven in the 
defining class loader of the first class of the superpackage to be loaded? 
If so, what happens if a superpackage needs to be loaded before any of its 
member classes, e.g. for the purpose of reflection? Couldn't it then end 
up being loaded in the 'wrong' class loader relative to where member 
classes will be loaded?

3. There is no ClassLoader.findLoadedSuperpackage method analogous to 
findLoadedClass, so what enables findSuperpackage to return consistent 
results if it is called twice, either serially or concurrently, with 
identical input parameters? For example, suppose two threads load class 
files (in a single class loader) belonging to a superpackage which has not 
yet been loaded. We need to ensure that we end up with one Superpackage 
instance and that both class loads succeed and the resultant class 
instances refer to the Superpackage instance.

The main difference from Bryan's API is, of course, the inability to load 
legacy .class files into a superpackage. Since the issues relate to 
requirements rather than API details, I'll post my view to the runtime 
model thread.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 14/06/2007 04:08:18 
AM:

> Experts,
> 
> I have uploaded a strawman proposal for the superpackage reflective API 
to 
> the expert group private homepage, see http://jcp.org/en/eg/view?id=294 
. 
> Please let me know if you have problems accessing it.
> 
> The ZIP file contains the javadoc output for all affected packages plus 
a 
> differences file that lists all the changes on a single HTML page.
> 
> Included are both the changes to the core reflection API and the 
language 
> model API. The javax.lang.model updates are courtesy of Joe Darcy and 
will 
> be defined by the JSR 269 maintenance team as a maintenance revision of 
> that JSR. They are included here to allow the JSR 294 EG to examine 
them. 
> If there are any comments on those changes, I can establish contact with 

> that team to allow us to resolve any issues.
> 
> If you have any comments on the API, please let Alex and myself know. I 
> would also like to encourage everyone to look at the API Bryan sent out 
> last week and compare and contrast.
> 
> Observers, we do not yet have the infrastructure in place on OpenJDK to 
> allow us to make the API available to the public. I am told that this 
> issue will be resolved within the next few weeks. As soon as that 
happens 
> we will post the files there. Apologies for any inconvenience.
> 
> Andreas.
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070614/8fb942b1/attachment.html