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

[Michal Cierniak]

I haven't looked at this strawman yet but I looked a bit at Bryan's
and I read Glyn's comments.  I have a very naive question: why do we
need separate runtime representation of modules (277) and
superpackages (294)?  Shouldn't we strive to have only one class to
represent both concepts?  Maybe I'm oversimplifying but this sounds
achievable to me.

On 6/13/07, Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote:
> 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
>