From Stanley.Ho at Sun.COM  Mon May 14 12:17:01 2007
From: Stanley.Ho at Sun.COM (Stanley M. Ho)
Date: Mon, 14 May 2007 12:17:01 -0700
Subject: Reminder: Updated JSR-277 specification (04/19/2007)
In-Reply-To: <46319FA2.10102@sun.com>
References: <46282FC0.1040100@sun.com> <46319FA2.10102@sun.com>
Message-ID: <4648B5AD.7030801@sun.com>

Hi JSR 277 experts,

If you still have any input on the updated early draft specification,
please send them in as soon as possible.

Thanks,
- Stanley

From Stanley.Ho at sun.com  Mon May 14 12:36:00 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Mon, 14 May 2007 12:36:00 -0700
Subject: JSR 277 EG observer mailing list
In-Reply-To: <46412161.9020902@sun.com>
References: <46400CFB.1020004@sun.com> <46412161.9020902@sun.com>
Message-ID: <4648BA20.5070206@sun.com>

Hi JSR 277 experts,

Just an update. This EG mailing list has been hooked up with the
observer list over the weekend, and you will find the public mailing
list archive here:

http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/

- Stanley

From Stanley.Ho at sun.com  Mon May 14 14:54:43 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Mon, 14 May 2007 14:54:43 -0700
Subject: Reminder: i18n strawman
Message-ID: <4648DAA3.9030502@sun.com>

Hi JSR 277 experts,

This is a kindly reminder. If you have inputs on the i18n strawman,
please send them in by 5/21/2007. Even if you have reviewed the strawman
and have no comments, it would still be good to let us know.

Thanks,
- Stanley


-------- Original Message --------
Subject: Strawman: i18n support
Date: Mon, 07 May 2007 17:09:41 -0700
From: Stanley M. Ho <Stanley.Ho at Sun.COM>
Reply-To: Java Community Process JSR #277 Expert List <JSR-277-EG at JCP.ORG>
Organization: Sun Microsystems, Inc.
To: JSR-277-EG at JCP.ORG

Hi JSR 277 experts,

I've been working with Masayoshi Okutsu (i18n lead) and Naoto Sato in
the Java SE team to come up with a strawman for the i18n support. This
strawman was developed based on the initial i18n requirements we
discussed in the EG several weeks ago, as well as on the assumption that
we simply want to reuse the existing module distribution format (i.e.
jam files) and repository infrastructure for packaging and deploying
resources.

I have uploaded the strawman [1] to the expert group home page for
download. If you prefer to receive them in email, please let me know and
I'll send it to you directly.

I would like to get your inputs by 5/21/2007, so we can determine how to
refine the strawman further.

Thanks,
- Stanley

[1] i18n strawman
http://www.jcp.org/en/eg/download/jsr-277-i18n-strawman-05022007.pdf?id=277&fileId=3417

From cierniak at google.com  Mon May 14 15:01:55 2007
From: cierniak at google.com (Michal Cierniak)
Date: Mon, 14 May 2007 15:01:55 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <4648DAA3.9030502@sun.com>
References: <4648DAA3.9030502@sun.com>
Message-ID: <237294540705141501v6c42ec97i35145e94c2e81be0@mail.gmail.com>

Stanley,

It is not clear to me from the doc if i8n relies on the assumption
that a package may be split across multiple modules.  Can you clarify?

Thanks,
Michal

On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> Hi JSR 277 experts,
>
> This is a kindly reminder. If you have inputs on the i18n strawman,
> please send them in by 5/21/2007. Even if you have reviewed the strawman
> and have no comments, it would still be good to let us know.
>
> Thanks,
> - Stanley

From cierniak at google.com  Mon May 14 15:40:08 2007
From: cierniak at google.com (Michal Cierniak)
Date: Mon, 14 May 2007 15:40:08 -0700
Subject: Re-export (was: Updated JSR-277 specification (04/19/2007))
Message-ID: <237294540705141540j3e19bea6oa9697343c6533a29@mail.gmail.com>

Stanley,

Do you also think that JSR-294 will have to understand re-exports to
correctly enforce information hiding at compile time?  If so, do you
expect that if module A imports and re-exports module B then all of
B's exports will be added to A's exports?  If this question is
answered in the draft, I missed the answer.

Independently of 294's decision, do you think that this should happen
for 277 modules?  I don't have a strong preference one way or another
but I think that it may be a little better if we required that B's
exported classes are added to A's export list.  The benefit is that
some of the resolution and validation algorithms might become simpler.
 The downside is that we will repeat information in multiple places.
We would have to decide what happens if the B's exports as seen at the
time of building A are different form the actual exports of the
version of B that is wired at runtime and from this point of view, I
can see arguments pro and con (personally I think that this will be
better overall but I can imagine that others may have a different
opinion).

Michal

On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> Hi JSR 277 experts,
>
> If you still have any input on the updated early draft specification,
> please send them in as soon as possible.
>
> Thanks,
> - Stanley
>

From Stanley.Ho at sun.com  Mon May 14 16:18:24 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Mon, 14 May 2007 16:18:24 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <237294540705141501v6c42ec97i35145e94c2e81be0@mail.gmail.com>
References: <4648DAA3.9030502@sun.com>
	<237294540705141501v6c42ec97i35145e94c2e81be0@mail.gmail.com>
Message-ID: <4648EE40.5050802@sun.com>

Hi Michal,

Yes, the i18n strawman currently assumes that the class-based resource
bundles in multiple modules are in the same Java package (but each with
different superpackage membership), and this is consistent with the
existing practice in using the java.util.ResourceBundle API.

Based on the earlier EG discussions, we have agreed to explicitly
disallow split packages during shallow validation so developers are not
encouraged to use them and we don't have to deal with all the issues
that split packages may cause. However, the existing i18n practice
somewhat contradicts what we encourage developers to do.

That said, this may not be a big problem after all, since split packages
would still be disallowed during module initialization. This also
implies that a target module can't import resource modules directly and
must rely on the ResourceBundle API to look up resources, and personally
I think this is acceptable (if other EG members have different opinions,
I would like to hear them). Therefore, we could still discourage split
packages in general and only let developers use them in this special case.

The obvious alternative is to require class-based resource bundles in
multiple modules to be in different Java packages. Unfortunately, this
is incompatible with the existing practice in translating resource
bundles, and I'm concerned that this would hurt adoption.

What do you think?

- Stanley


Michal Cierniak wrote:
> Stanley,
>
> It is not clear to me from the doc if i8n relies on the assumption
> that a package may be split across multiple modules.  Can you clarify?
>
> Thanks,
> Michal

From cierniak at google.com  Mon May 14 16:36:51 2007
From: cierniak at google.com (Michal Cierniak)
Date: Mon, 14 May 2007 16:36:51 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <4648EE40.5050802@sun.com>
References: <4648DAA3.9030502@sun.com>
	<237294540705141501v6c42ec97i35145e94c2e81be0@mail.gmail.com>
	<4648EE40.5050802@sun.com>
Message-ID: <237294540705141636q2832e6bcy2de28f633235cdc4@mail.gmail.com>

I think that it's reasonable if we decide that the only way that split
packages may manifest themselves is as resources via the
ResourceBundle API.  I was worried about code for the same package
coming from multiple modules but it seems that you're not suggesting
this.

Thanks!
Michal

On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> Hi Michal,
>
> Yes, the i18n strawman currently assumes that the class-based resource
> bundles in multiple modules are in the same Java package (but each with
> different superpackage membership), and this is consistent with the
> existing practice in using the java.util.ResourceBundle API.
>
> Based on the earlier EG discussions, we have agreed to explicitly
> disallow split packages during shallow validation so developers are not
> encouraged to use them and we don't have to deal with all the issues
> that split packages may cause. However, the existing i18n practice
> somewhat contradicts what we encourage developers to do.
>
> That said, this may not be a big problem after all, since split packages
> would still be disallowed during module initialization. This also
> implies that a target module can't import resource modules directly and
> must rely on the ResourceBundle API to look up resources, and personally
> I think this is acceptable (if other EG members have different opinions,
> I would like to hear them). Therefore, we could still discourage split
> packages in general and only let developers use them in this special case.
>
> The obvious alternative is to require class-based resource bundles in
> multiple modules to be in different Java packages. Unfortunately, this
> is incompatible with the existing practice in translating resource
> bundles, and I'm concerned that this would hurt adoption.
>
> What do you think?
>
> - Stanley
>
>
> Michal Cierniak wrote:
> > Stanley,
> >
> > It is not clear to me from the doc if i8n relies on the assumption
> > that a package may be split across multiple modules.  Can you clarify?
> >
> > Thanks,
> > Michal
>

From Stanley.Ho at sun.com  Mon May 14 18:12:52 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Mon, 14 May 2007 18:12:52 -0700
Subject: Re-export (was: Updated JSR-277 specification (04/19/2007))
In-Reply-To: <237294540705141540j3e19bea6oa9697343c6533a29@mail.gmail.com>
References: <237294540705141540j3e19bea6oa9697343c6533a29@mail.gmail.com>
Message-ID: <46490914.9010809@sun.com>

Hi Michal,

Michal Cierniak wrote:
> Stanley,
>
> Do you also think that JSR-294 will have to understand re-exports to
> correctly enforce information hiding at compile time?  If so, do you
> expect that if module A imports and re-exports module B then all of
> B's exports will be added to A's exports?  If this question is
> answered in the draft, I missed the answer.

I think the module-aware compiler will definitely need to understand
re-exports for proper compilation. That said, whether this is done at
the JSR 294's level will depend on the outcome of the "import"
discussion in the JSR 294 EG, which I expect will happen sometimes soon.

> Independently of 294's decision, do you think that this should happen
> for 277 modules?  I don't have a strong preference one way or another
> but I think that it may be a little better if we required that B's
> exported classes are added to A's export list.  The benefit is that
> some of the resolution and validation algorithms might become simpler.
> The downside is that we will repeat information in multiple places.
> We would have to decide what happens if the B's exports as seen at the
> time of building A are different form the actual exports of the
> version of B that is wired at runtime and from this point of view, I
> can see arguments pro and con (personally I think that this will be
> better overall but I can imagine that others may have a different
> opinion).
>
> Michal

I certainly like the simplicity; unfortunately, I don't think this will
work at runtime if I correctly understand what you proposed. :-(
Supposes module A imports modules B and C, and module B also imports and
re-exports module C. Using the expanded-export-list approach would cause
module A fail to initialize - the shallow validation could detect
duplicate types from the imported modules B and C but would be unable to
determine if the duplicate types were originated from the same module C.
Under the current algorithms in the updated specification, module A
would be initialized successfully, which is the correct behavior.

- Stanley

From cierniak at google.com  Mon May 14 22:13:45 2007
From: cierniak at google.com (Michal Cierniak)
Date: Mon, 14 May 2007 22:13:45 -0700
Subject: Re-export (was: Updated JSR-277 specification (04/19/2007))
In-Reply-To: <46490914.9010809@sun.com>
References: <237294540705141540j3e19bea6oa9697343c6533a29@mail.gmail.com>
	<46490914.9010809@sun.com>
Message-ID: <237294540705142213o640b4c7fqcf918a7be9abf2d@mail.gmail.com>

On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> Supposes module A imports modules B and C, and module B also imports and
> re-exports module C. Using the expanded-export-list approach would cause
> module A fail to initialize - the shallow validation could detect
> duplicate types from the imported modules B and C but would be unable to
> determine if the duplicate types were originated from the same module C.
> Under the current algorithms in the updated specification, module A
> would be initialized successfully, which is the correct behavior.

Well, this is true if we don't mark such types as "re-exported".  What
if C's exports that are added to B's are marked with a bit that means
"re-exported"?  Your example would still work and we would get better
error diagnostic.  For instance if your example was expanded to make B
import and re-export C and D.  If a signature of a method of one of
B's exported types contained a type from C and the version of C that
was wired to B at runtime lacked that type, we would have no idea why
B failed to validate.  Was it malformed to begin with?  Or was it that
one of its imports changed?

If no one else thinks that this might be useful, I will not really
press for such a feature.  As I said in my previous email, I don't
really have a strong opinion.  I was asking to get a clarification
what your intent was.

Michal

From glyn_normington at UK.IBM.COM  Tue May 15 06:53:03 2007
From: glyn_normington at UK.IBM.COM (Glyn Normington)
Date: Tue, 15 May 2007 14:53:03 +0100
Subject: Reminder: i18n strawman
In-Reply-To: <237294540705141636q2832e6bcy2de28f633235cdc4@mail.gmail.com>
Message-ID: <OF75FE40FA.C2D5D8CF-ON802572DC.004C1287-802572DC.004C46D6@uk.ibm.com>

The ResourceBundle API does not only use resource (*.properties) lookups.
It also attempts class loads to find resource bundles, effectively needing
to load classes from a split package.

Glyn

Michal Cierniak <cierniak at GOOGLE.COM> wrote on 15/05/2007 00:36:51:

> I think that it's reasonable if we decide that the only way that split
> packages may manifest themselves is as resources via the
> ResourceBundle API.  I was worried about code for the same package
> coming from multiple modules but it seems that you're not suggesting
> this.
>
> Thanks!
> Michal
>
> On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> > Hi Michal,
> >
> > Yes, the i18n strawman currently assumes that the class-based resource
> > bundles in multiple modules are in the same Java package (but each
with
> > different superpackage membership), and this is consistent with the
> > existing practice in using the java.util.ResourceBundle API.
> >
> > Based on the earlier EG discussions, we have agreed to explicitly
> > disallow split packages during shallow validation so developers are
not
> > encouraged to use them and we don't have to deal with all the issues
> > that split packages may cause. However, the existing i18n practice
> > somewhat contradicts what we encourage developers to do.
> >
> > That said, this may not be a big problem after all, since split
packages
> > would still be disallowed during module initialization. This also
> > implies that a target module can't import resource modules directly
and
> > must rely on the ResourceBundle API to look up resources, and
personally
> > I think this is acceptable (if other EG members have different
opinions,
> > I would like to hear them). Therefore, we could still discourage split
> > packages in general and only let developers use them in this special
case.
> >
> > The obvious alternative is to require class-based resource bundles in
> > multiple modules to be in different Java packages. Unfortunately, this
> > is incompatible with the existing practice in translating resource
> > bundles, and I'm concerned that this would hurt adoption.
> >
> > What do you think?
> >
> > - Stanley
> >
> >
> > Michal Cierniak wrote:
> > > Stanley,
> > >
> > > It is not clear to me from the doc if i8n relies on the assumption
> > > that a package may be split across multiple modules.  Can you
clarify?
> > >
> > > Thanks,
> > > Michal
> >






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: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070515/a54896ca/attachment-0001.html 

From cierniak at google.com  Tue May 15 07:22:49 2007
From: cierniak at google.com (Michal Cierniak)
Date: Tue, 15 May 2007 07:22:49 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <OF75FE40FA.C2D5D8CF-ON802572DC.004C1287-802572DC.004C46D6@uk.ibm.com>
References: <237294540705141636q2832e6bcy2de28f633235cdc4@mail.gmail.com>
	<OF75FE40FA.C2D5D8CF-ON802572DC.004C1287-802572DC.004C46D6@uk.ibm.com>
Message-ID: <237294540705150722w7ae9a8b6v912d2cee962e11d7@mail.gmail.com>

Glyn, thanks for pointing this out!

Stanley, do you think that we could restrict the uses of the
ResourceBundle API in this context to not load code?

For the context: my recollection is that we had a consensus to not
allow split packages but since this discussion took place a long time
ago, it could be that I don't remember it well.

Michal

On 5/15/07, Glyn Normington <glyn_normington at uk.ibm.com> wrote:
>
> The ResourceBundle API does not only use resource (*.properties) lookups.
> It also attempts class loads to find resource bundles, effectively needing
> to load classes from a split package.
>
>  Glyn

From bryan.atsatt at oracle.com  Tue May 15 16:50:30 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Tue, 15 May 2007 16:50:30 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <237294540705150722w7ae9a8b6v912d2cee962e11d7@mail.gmail.com>
References: <237294540705141636q2832e6bcy2de28f633235cdc4@mail.gmail.com>
	<OF75FE40FA.C2D5D8CF-ON802572DC.004C1287-802572DC.004C46D6@uk.ibm.com>
	<237294540705150722w7ae9a8b6v912d2cee962e11d7@mail.gmail.com>
Message-ID: <464A4746.70302@oracle.com>

Yes, I was going to point this out as well. In fact, at Oracle, our
translators *require* us to use ListResourceBundle subclasses. They will
not translate property file based resource bundles; I've never gotten a
full answer as to the reason for this, but I think it is a tools
restriction.

This same restriction was imposed when I was at IBM, so I would guess
that it may be widespread...

// Bryan

Michal Cierniak wrote:
> Glyn, thanks for pointing this out!
>
> Stanley, do you think that we could restrict the uses of the
> ResourceBundle API in this context to not load code?
>
> For the context: my recollection is that we had a consensus to not
> allow split packages but since this discussion took place a long time
> ago, it could be that I don't remember it well.
>
> Michal
>
> On 5/15/07, Glyn Normington <glyn_normington at uk.ibm.com> wrote:
>>
>> The ResourceBundle API does not only use resource (*.properties) lookups.
>> It also attempts class loads to find resource bundles, effectively
>> needing
>> to load classes from a split package.
>>
>>  Glyn
>

From stanley.ho at Sun.COM  Tue May 15 23:35:31 2007
From: stanley.ho at Sun.COM (Stanley M. Ho)
Date: Wed, 16 May 2007 00:35:31 -0600
Subject: Reminder: i18n strawman
Message-ID: <LISTSERV%2007051600353177@JAVA.SUN.COM>

On Tue, 15 May 2007 07:22:49 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:

>Glyn, thanks for pointing this out!
>
>Stanley, do you think that we could restrict the uses of the
>ResourceBundle API in this context to not load code?

Michal, since we will define the actual requirements for the ResourceBundle
API changes in Java SE 7, we could certainly restrict the usage of
ListResourceBundle in the ResourceBundle API when the target module attempts
to load resource bundles from the resource modules.

I have briefly talked to the folks in the i18n team in Java SE, and their
impression was that PropertyResourceBundle is much more commonly used than
ListResourceBundle among developers. However, there are some applications
(including the JDK) relying on ListResourceBundle, so supporting
PropertyResourceBundle alone in the module system may not be a sufficient
solution.

>For the context: my recollection is that we had a consensus to not
>allow split packages but since this discussion took place a long time
>ago, it could be that I don't remember it well.
>
>Michal

Right. The EG has the consensus on not to support split packages in the
module system. So far, we have only enforced the policy on shallow
validation, so module cannot import other modules with split packages. I
don't think we want to alter this policy in type consistency validation, as
it does simplify our general design a bit. That said, I think the question
for the EG is whether we want to enforce the no-split-packages policy across
the board (and drop the ListResourceBundle support as a result), or enforce
the policy only during type consistency validation and make split packages a
special case in loading class-based resource bundles through the
ResourceBundle API.

- Stanley

P.S. This is a repost. Apparently, I have email problems with jcp.org again,
and please ignore if you receive more than one copy of my reply.

From stanley.ho at sun.com  Tue May 15 23:39:10 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Wed, 16 May 2007 00:39:10 -0600
Subject: Legacy classes in a module
Message-ID: <LISTSERV%2007051600391020@JAVA.SUN.COM>

Hi JSR 277 experts,

This is regarding the semantic of legacy classes in a module, and is one of
the outstanding issues in the updated specification (Section 2.14) that I
would like to get your inputs.

Typically, classes in a module are "module" classes - Java classes that have
superpackage membership. However, it is also possible that developers may
want to make use of legacy classes in a module, e.g. using an existing xml
parser in a module. There are two possible use cases I can think of:

1. Developers simply make use of the legacy classes as implementation
details in the module. In this case, the exported module classes neither
expose nor reference the legacy classes in the export signatures, and the
legacy classes in the module should not be made visible to the importing
modules.

2. Developers use the legacy classes as part of the public API in the
module. In this case, the legacy classes in the module should be made
visible to the importing modules. The exported module classes may expose or
reference the legacy classes in the export signatures, but this is not required.

I think it's important for us to recognize and support both use cases.
However, this may be difficult for us to determine which use case is the
developers' real intention. Adding to the mix is that lack of module level
access control for the legacy classes, and there is not much we can do once
the legacy classes are leaked out from the module classloader.

That said, I think it's still important for us to define the semantics for
both use cases in the specification. Here is what I propose:

a. Consider #1 to be the default.
b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses) for
developers to indicate the module is in the #2 category.
c. If @ExportLegacyClasses is declared, the
ModuleDefinition.getExportedClasses() would include the legacy classes.

Note that unless this annotation is declared in the module definition, the
importing modules will never attempt to load the legacy classes from the
imported module during classloading delegation as the classloading
delegation algorithm always checks getExportedClassed() first (see algorithm
in 7.3.1, step 4). However, if other code obtains a reference of the module
classloader somehow and invokes loadClass() directly with the legacy class
name, the module classloader will still return the legacy class, and this is
consistent with the existing classloader behavior.

Let me know if you have inputs. If there are better ways to deal with this
issue, I would like to hear them as well.

- Stanley

P.S. This is also a repost due to email problems. Please ignore if you
receive more than one copy of this message.

From glyn_normington at UK.IBM.COM  Wed May 16 07:09:43 2007
From: glyn_normington at UK.IBM.COM (Glyn Normington)
Date: Wed, 16 May 2007 15:09:43 +0100
Subject: Legacy classes in a module
In-Reply-To: <LISTSERV%2007051600391020@JAVA.SUN.COM>
Message-ID: <OFBBB449FF.EECE76FC-ON802572DD.004AE48F-802572DD.004DCD54@uk.ibm.com>

Hi Stanley

"Stanley M. Ho" <stanley.ho at SUN.COM> wrote on 16/05/2007 07:39:10:

> Hi JSR 277 experts,
>
> This is regarding the semantic of legacy classes in a module, and is one
of
> the outstanding issues in the updated specification (Section 2.14) that
I
> would like to get your inputs.
>
> Typically, classes in a module are "module" classes - Java classes that
have
> superpackage membership. However, it is also possible that developers
may
> want to make use of legacy classes in a module, e.g. using an existing
xml
> parser in a module. There are two possible use cases I can think of:

I can't tell from this whether the developer has the freedom to recompile
the legacy classes, but I assume not otherwise it would be trivial to
include them as superpackage members. (Also, there are use cases where a
developer needs to use an existing JAR, but doesn't have the source or the
rights to crack the JAR open and fiddle with the contents.)

>
> 1. Developers simply make use of the legacy classes as implementation
> details in the module. In this case, the exported module classes neither
> expose nor reference the legacy classes in the export signatures, and
the
> legacy classes in the module should not be made visible to the importing
> modules.
>
> 2. Developers use the legacy classes as part of the public API in the
> module. In this case, the legacy classes in the module should be made
> visible to the importing modules. The exported module classes may expose
or
> reference the legacy classes in the export signatures, but this is
> not required.
>
> I think it's important for us to recognize and support both use cases.
> However, this may be difficult for us to determine which use case is the
> developers' real intention. Adding to the mix is that lack of module
level
> access control for the legacy classes, and there is not much we can do
once
> the legacy classes are leaked out from the module classloader.
>
> That said, I think it's still important for us to define the semantics
for
> both use cases in the specification. Here is what I propose:
>
> a. Consider #1 to be the default.

Agreed.

> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
for
> developers to indicate the module is in the #2 category.

Note that this does not enable a developer to expose some but not all of
the legacy classes in a module.

> c. If @ExportLegacyClasses is declared, the
> ModuleDefinition.getExportedClasses() would include the legacy classes.
>
> Note that unless this annotation is declared in the module definition,
the
> importing modules will never attempt to load the legacy classes from the
> imported module during classloading delegation as the classloading
> delegation algorithm always checks getExportedClassed() first (see
algorithm
> in 7.3.1, step 4). However, if other code obtains a reference of the
module
> classloader somehow and invokes loadClass() directly with the legacy
class
> name, the module classloader will still return the legacy class, and
this is
> consistent with the existing classloader behavior.

Is this proposal meant to include the case of creating a module from
legacy classes alone? If so, I guess the module would need an 'empty'
superpackage definition such as:

@Version("2.9.0")
@ExportLegacyClasses
superpackage org.apache.xerces {}

>
> Let me know if you have inputs. If there are better ways to deal with
this
> issue, I would like to hear them as well.
>
> - Stanley
>
> P.S. This is also a repost due to email problems. Please ignore if you
> receive more than one copy of this message.

Glyn






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: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070516/5d656731/attachment-0001.html 

From bryan.atsatt at oracle.com  Wed May 16 10:40:47 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Wed, 16 May 2007 10:40:47 -0700
Subject: Legacy classes in a module
In-Reply-To: <LISTSERV%2007051600391020@JAVA.SUN.COM>
References: <LISTSERV%2007051600391020@JAVA.SUN.COM>
Message-ID: <464B421F.3050503@oracle.com>

While the current strawman suggests that superpackage classes will have
modified class files (e.g. naming their superpackage), there is a
proposal on the table that eliminates this requirement.

If eliminated, the only requirement to include "legacy" classes in a
superpackage will be to have the superpackage artifact present. In a 277
module, any mixture of new and "legacy" classes (likely in separate
jars) could then fall under the umbrella superpackage. And this whole
issue is eliminated...

// Bryan

Stanley M. Ho wrote:
> Hi JSR 277 experts,
>
> This is regarding the semantic of legacy classes in a module, and is one of
> the outstanding issues in the updated specification (Section 2.14) that I
> would like to get your inputs.
>
> Typically, classes in a module are "module" classes - Java classes that have
> superpackage membership. However, it is also possible that developers may
> want to make use of legacy classes in a module, e.g. using an existing xml
> parser in a module. There are two possible use cases I can think of:
>
> 1. Developers simply make use of the legacy classes as implementation
> details in the module. In this case, the exported module classes neither
> expose nor reference the legacy classes in the export signatures, and the
> legacy classes in the module should not be made visible to the importing
> modules.
>
> 2. Developers use the legacy classes as part of the public API in the
> module. In this case, the legacy classes in the module should be made
> visible to the importing modules. The exported module classes may expose or
> reference the legacy classes in the export signatures, but this is not required.
>
> I think it's important for us to recognize and support both use cases.
> However, this may be difficult for us to determine which use case is the
> developers' real intention. Adding to the mix is that lack of module level
> access control for the legacy classes, and there is not much we can do once
> the legacy classes are leaked out from the module classloader.
>
> That said, I think it's still important for us to define the semantics for
> both use cases in the specification. Here is what I propose:
>
> a. Consider #1 to be the default.
> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses) for
> developers to indicate the module is in the #2 category.
> c. If @ExportLegacyClasses is declared, the
> ModuleDefinition.getExportedClasses() would include the legacy classes.
>
> Note that unless this annotation is declared in the module definition, the
> importing modules will never attempt to load the legacy classes from the
> imported module during classloading delegation as the classloading
> delegation algorithm always checks getExportedClassed() first (see algorithm
> in 7.3.1, step 4). However, if other code obtains a reference of the module
> classloader somehow and invokes loadClass() directly with the legacy class
> name, the module classloader will still return the legacy class, and this is
> consistent with the existing classloader behavior.
>
> Let me know if you have inputs. If there are better ways to deal with this
> issue, I would like to hear them as well.
>
> - Stanley
>
> P.S. This is also a repost due to email problems. Please ignore if you
> receive more than one copy of this message.
>

From bryan.atsatt at oracle.com  Wed May 16 11:15:57 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Wed, 16 May 2007 11:15:57 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <LISTSERV%2007051600353177@JAVA.SUN.COM>
References: <LISTSERV%2007051600353177@JAVA.SUN.COM>
Message-ID: <464B4A5D.9060807@oracle.com>

ListResourceBundle cannot be demoted to second-class citizen status in
the module system (Perhaps you haven't seen my earlier response?).

There is a solution to the split package problem, and, while it does
change the development model slightly, I think that is in line with the
more significant model change of moving to a module system...

Introduce a package naming convention for resource bundles deployed as
modules. The convention would allow ResourceBundle.getBundle() to easily
map from the "base" name to the actual bundle package name.

For example, if we introduce the convention that resource bundle "base"
names are mapped such that "resources" is appended to the package name,
then calling ResourceBundle.getBundle with:

   "com.acme.MyResources"

Would actually search for resources with the base name:

   "com.acme.resources.MyResources"

thus sidestepping the split package issue.

Yes, this requires developers to actually define their resources using
this naming convention, but I don't see that as a significant burden.
Especially when you consider the benefit of not having to package all
translations in the primary module.

To avoid potential package name collisions, we should consider using a
more distinct name than simply "resources", e.g.:

   "com.acme.resource_bundle.MyResources"
   "com.acme.module_resources.MyResources"
   "com.acme._resources_.MyResources"

// Bryan



Stanley M. Ho wrote:
> On Tue, 15 May 2007 07:22:49 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:
>
>> Glyn, thanks for pointing this out!
>>
>> Stanley, do you think that we could restrict the uses of the
>> ResourceBundle API in this context to not load code?
>
> Michal, since we will define the actual requirements for the ResourceBundle
> API changes in Java SE 7, we could certainly restrict the usage of
> ListResourceBundle in the ResourceBundle API when the target module attempts
> to load resource bundles from the resource modules.
>
> I have briefly talked to the folks in the i18n team in Java SE, and their
> impression was that PropertyResourceBundle is much more commonly used than
> ListResourceBundle among developers. However, there are some applications
> (including the JDK) relying on ListResourceBundle, so supporting
> PropertyResourceBundle alone in the module system may not be a sufficient
> solution.
>
>> For the context: my recollection is that we had a consensus to not
>> allow split packages but since this discussion took place a long time
>> ago, it could be that I don't remember it well.
>>
>> Michal
>
> Right. The EG has the consensus on not to support split packages in the
> module system. So far, we have only enforced the policy on shallow
> validation, so module cannot import other modules with split packages. I
> don't think we want to alter this policy in type consistency validation, as
> it does simplify our general design a bit. That said, I think the question
> for the EG is whether we want to enforce the no-split-packages policy across
> the board (and drop the ListResourceBundle support as a result), or enforce
> the policy only during type consistency validation and make split packages a
> special case in loading class-based resource bundles through the
> ResourceBundle API.
>
> - Stanley
>
> P.S. This is a repost. Apparently, I have email problems with jcp.org again,
> and please ignore if you receive more than one copy of my reply.
>

From cierniak at google.com  Wed May 16 12:25:05 2007
From: cierniak at google.com (Michal Cierniak)
Date: Wed, 16 May 2007 12:25:05 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <464B4A5D.9060807@oracle.com>
References: <LISTSERV%2007051600353177@JAVA.SUN.COM>
	<464B4A5D.9060807@oracle.com>
Message-ID: <237294540705161225i7aa527f1ka093ddd7dc1d0e46@mail.gmail.com>

I also think that this would not be too burdensome.

On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> ListResourceBundle cannot be demoted to second-class citizen status in
> the module system (Perhaps you haven't seen my earlier response?).
>
> There is a solution to the split package problem, and, while it does
> change the development model slightly, I think that is in line with the
> more significant model change of moving to a module system...
>
> Introduce a package naming convention for resource bundles deployed as
> modules. The convention would allow ResourceBundle.getBundle() to easily
> map from the "base" name to the actual bundle package name.
>
> For example, if we introduce the convention that resource bundle "base"
> names are mapped such that "resources" is appended to the package name,
> then calling ResourceBundle.getBundle with:
>
>    "com.acme.MyResources"
>
> Would actually search for resources with the base name:
>
>    "com.acme.resources.MyResources"
>
> thus sidestepping the split package issue.
>
> Yes, this requires developers to actually define their resources using
> this naming convention, but I don't see that as a significant burden.
> Especially when you consider the benefit of not having to package all
> translations in the primary module.
>
> To avoid potential package name collisions, we should consider using a
> more distinct name than simply "resources", e.g.:
>
>    "com.acme.resource_bundle.MyResources"
>    "com.acme.module_resources.MyResources"
>    "com.acme._resources_.MyResources"
>
> // Bryan

From cierniak at google.com  Wed May 16 14:17:54 2007
From: cierniak at google.com (Michal Cierniak)
Date: Wed, 16 May 2007 14:17:54 -0700
Subject: Legacy classes in a module
In-Reply-To: <464B421F.3050503@oracle.com>
References: <LISTSERV%2007051600391020@JAVA.SUN.COM>
	<464B421F.3050503@oracle.com>
Message-ID: <237294540705161417o2199c3bbp26d2de3f68e1f2db@mail.gmail.com>

I would like to add that even if superpackage classes do name their
superpackage in the new world, it wouldn't be difficult to require the
JRE to "rewrite" legacy classes on the fly if they are loaded from a
JAR embedded in a JAM.  In that case, the legacy classes would end up
being members of the superpackage associated with the containing JAM.

We might run into other problems because legacy classes do not
necessarily play by the rules of the new module-aware world but this
is independent of whether we rewrite them to add superpackage
membership info.

Michal

On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> While the current strawman suggests that superpackage classes will have
> modified class files (e.g. naming their superpackage), there is a
> proposal on the table that eliminates this requirement.
>
> If eliminated, the only requirement to include "legacy" classes in a
> superpackage will be to have the superpackage artifact present. In a 277
> module, any mixture of new and "legacy" classes (likely in separate
> jars) could then fall under the umbrella superpackage. And this whole
> issue is eliminated...
>
> // Bryan
>

From stanley.ho at sun.com  Thu May 17 12:11:07 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Thu, 17 May 2007 13:11:07 -0600
Subject: Reminder: i18n strawman
Message-ID: <LISTSERV%2007051713110786@JAVA.SUN.COM>

On Wed, 16 May 2007 11:15:57 -0700, Bryan Atsatt <bryan.atsatt at ORACLE.COM>
wrote:

>ListResourceBundle cannot be demoted to second-class citizen status in
>the module system (Perhaps you haven't seen my earlier response?).

Yes, I agreed it's important for us to support ListResourceBundle.

>There is a solution to the split package problem, and, while it does
>change the development model slightly, I think that is in line with the
>more significant model change of moving to a module system...
>
>Introduce a package naming convention for resource bundles deployed as
>modules. The convention would allow ResourceBundle.getBundle() to easily
>map from the "base" name to the actual bundle package name.
>
>For example, if we introduce the convention that resource bundle "base"
>names are mapped such that "resources" is appended to the package name,
>then calling ResourceBundle.getBundle with:
>
>   "com.acme.MyResources"
>
>Would actually search for resources with the base name:
>
>   "com.acme.resources.MyResources"
>
>thus sidestepping the split package issue.
>
>Yes, this requires developers to actually define their resources using
>this naming convention, but I don't see that as a significant burden.
>Especially when you consider the benefit of not having to package all
>translations in the primary module.
>
>To avoid potential package name collisions, we should consider using a
>more distinct name than simply "resources", e.g.:
>
>   "com.acme.resource_bundle.MyResources"
>   "com.acme.module_resources.MyResources"
>   "com.acme._resources_.MyResources"
>
>// Bryan

I was under the assumption that we didn't want to change the way developers
define their resources. That said, I am fine with using some packaging
naming convention to sidestep the split package issue.

If we go down this path, I think we will need to expand Bryan's suggestion a
bit. The ResourceBundle API may search multiple resource modules in order to
look up the resources (from more restrictive locales to less restrictive
locales), so it is important for resources in the resource modules for each
locale to have unique package name to avoid potential conflict regardless
the lookup order. e.g.

   "com.acme_en.MyResources"
   "com.acme_ja.MyResources_ja"
   "com.acme_fr.MyResources_fr"
   "com.acme_fr_CH.MyResources_fr_CH"

Note that the locale information is repeated twice. If we want to simplify
it further, we can require the locale information to be specified only as
part of the package name of the resource, but not as part of the filename of
the resource:

   "com.acme_en.MyResources"
   "com.acme_ja.MyResources"
   "com.acme_fr.MyResources"
   "com.acme_fr_CH.MyResources"

- Stanley

P.S. This is another repost. My email problems with jcp.org continue, and
please ignore if you receive more than one copy of my reply.

From stanley.ho at sun.com  Thu May 17 13:48:47 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Thu, 17 May 2007 14:48:47 -0600
Subject: Legacy classes in a module
Message-ID: <LISTSERV%2007051714484731@JAVA.SUN.COM>

Hi Glyn,

On Wed, 16 May 2007 15:09:43 +0100, Glyn Normington
<glyn_normington at UK.IBM.COM> wrote:

>I can't tell from this whether the developer has the freedom to recompile
>the legacy classes, but I assume not otherwise it would be trivial to
>include them as superpackage members. (Also, there are use cases where a
>developer needs to use an existing JAR, but doesn't have the source or the
>rights to crack the JAR open and fiddle with the contents.)

Yes, this is to address the situation where the developer does not have the
freedom to recompile the legacy classes but he still want to make use of
them in the module.

>> b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
>for
>> developers to indicate the module is in the #2 category.
>
>Note that this does not enable a developer to expose some but not all of
>the legacy classes in a module.

Right. It should be very easy if we want to change it to support finer
granularity, but I would like to keep it simple for now.

>Is this proposal meant to include the case of creating a module from
>legacy classes alone? If so, I guess the module would need an 'empty'
>superpackage definition such as:
>
>@Version("2.9.0")
>@ExportLegacyClasses
>superpackage org.apache.xerces {}

No, this proposal is only intended to address the first bullet in Section
2.14 in the updated specification. If the developer has the rights to
repackage the legacy classes with the module metadata, most likely he also
has access to the source thus he has the freedom to recompile, and I think
the recommendation would be for him to migrate the legacy JAR to be a simple
module archive.

- Stanley

From stanley.ho at sun.com  Thu May 17 14:11:55 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Thu, 17 May 2007 15:11:55 -0600
Subject: Legacy classes in a module
Message-ID: <LISTSERV%2007051715115587@JAVA.SUN.COM>

Regardless, I think we still need to distinguish whether the legacy classes
should be considered module private (use case #1) or made visible externally
(use case #2). I don't think we can really know the developer's intent by
looking at the legacy classes alone. Even if rewriting is involved, we still
need to distinguish these cases in order to have the proper export
information in the superpackage.

- Stanley


On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:

>I would like to add that even if superpackage classes do name their
>superpackage in the new world, it wouldn't be difficult to require the
>JRE to "rewrite" legacy classes on the fly if they are loaded from a
>JAR embedded in a JAM.  In that case, the legacy classes would end up
>being members of the superpackage associated with the containing JAM.
>
>We might run into other problems because legacy classes do not
>necessarily play by the rules of the new module-aware world but this
>is independent of whether we rewrite them to add superpackage
>membership info.
>
>Michal
>
>On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
>> While the current strawman suggests that superpackage classes will have
>> modified class files (e.g. naming their superpackage), there is a
>> proposal on the table that eliminates this requirement.
>>
>> If eliminated, the only requirement to include "legacy" classes in a
>> superpackage will be to have the superpackage artifact present. In a 277
>> module, any mixture of new and "legacy" classes (likely in separate
>> jars) could then fall under the umbrella superpackage. And this whole
>> issue is eliminated...
>>
>> // Bryan
>>

From cierniak at google.com  Thu May 17 15:21:20 2007
From: cierniak at google.com (Michal Cierniak)
Date: Thu, 17 May 2007 15:21:20 -0700
Subject: Legacy classes in a module
In-Reply-To: <LISTSERV%2007051715115587@JAVA.SUN.COM>
References: <LISTSERV%2007051715115587@JAVA.SUN.COM>
Message-ID: <237294540705171521t58613439hb7a2f59d0a23d39f@mail.gmail.com>

Yes, I was only addressing one aspect of the problem.

On 5/17/07, Stanley M. Ho <stanley.ho at sun.com> wrote:
> Regardless, I think we still need to distinguish whether the legacy classes
> should be considered module private (use case #1) or made visible externally
> (use case #2). I don't think we can really know the developer's intent by
> looking at the legacy classes alone. Even if rewriting is involved, we still
> need to distinguish these cases in order to have the proper export
> information in the superpackage.
>
> - Stanley
>
>
> On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:
>
> >I would like to add that even if superpackage classes do name their
> >superpackage in the new world, it wouldn't be difficult to require the
> >JRE to "rewrite" legacy classes on the fly if they are loaded from a
> >JAR embedded in a JAM.  In that case, the legacy classes would end up
> >being members of the superpackage associated with the containing JAM.
> >
> >We might run into other problems because legacy classes do not
> >necessarily play by the rules of the new module-aware world but this
> >is independent of whether we rewrite them to add superpackage
> >membership info.
> >
> >Michal
> >
> >On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> >> While the current strawman suggests that superpackage classes will have
> >> modified class files (e.g. naming their superpackage), there is a
> >> proposal on the table that eliminates this requirement.
> >>
> >> If eliminated, the only requirement to include "legacy" classes in a
> >> superpackage will be to have the superpackage artifact present. In a 277
> >> module, any mixture of new and "legacy" classes (likely in separate
> >> jars) could then fall under the umbrella superpackage. And this whole
> >> issue is eliminated...
> >>
> >> // Bryan
> >>
>

From bryan.atsatt at oracle.com  Thu May 17 19:01:09 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Thu, 17 May 2007 19:01:09 -0700
Subject: Legacy classes in a module
In-Reply-To: <LISTSERV%2007051715115587@JAVA.SUN.COM>
References: <LISTSERV%2007051715115587@JAVA.SUN.COM>
Message-ID: <464D08E5.7070500@oracle.com>

I am assuming that in this scenario the module developer would be
allowed to make this explicit in the superpackage declaration itself.
That is, superpackage member declarations could include packages from
the "legacy" jars. 294 simply has to allow declared member packages to
be AWOL at compile time.

BTW: The proposal I referred to earlier assumes that the runtime
artifact of a superpackage (e.g. a SuperPackage class instance) is
*assigned* to each class during ClassLoader.defineClass(). This
decouples the superpackage and class file artifacts while solving the
superpackage "loading" problem for the VM. It obviously makes it trivial
for "legacy" classes to be assigned into a superpackage as they are
defined. (It also makes it possible to extend the superpackage at
runtime, but that may be going too far.)

// Bryan

Stanley M. Ho wrote:
> Regardless, I think we still need to distinguish whether the legacy classes
> should be considered module private (use case #1) or made visible externally
> (use case #2). I don't think we can really know the developer's intent by
> looking at the legacy classes alone. Even if rewriting is involved, we still
> need to distinguish these cases in order to have the proper export
> information in the superpackage.
>
> - Stanley
>
>
> On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak <cierniak at GOOGLE.COM> wrote:
>
>> I would like to add that even if superpackage classes do name their
>> superpackage in the new world, it wouldn't be difficult to require the
>> JRE to "rewrite" legacy classes on the fly if they are loaded from a
>> JAR embedded in a JAM.  In that case, the legacy classes would end up
>> being members of the superpackage associated with the containing JAM.
>>
>> We might run into other problems because legacy classes do not
>> necessarily play by the rules of the new module-aware world but this
>> is independent of whether we rewrite them to add superpackage
>> membership info.
>>
>> Michal
>>
>> On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
>>> While the current strawman suggests that superpackage classes will have
>>> modified class files (e.g. naming their superpackage), there is a
>>> proposal on the table that eliminates this requirement.
>>>
>>> If eliminated, the only requirement to include "legacy" classes in a
>>> superpackage will be to have the superpackage artifact present. In a 277
>>> module, any mixture of new and "legacy" classes (likely in separate
>>> jars) could then fall under the umbrella superpackage. And this whole
>>> issue is eliminated...
>>>
>>> // Bryan
>>>
>

From glyn_normington at UK.IBM.COM  Fri May 18 00:38:00 2007
From: glyn_normington at UK.IBM.COM (Glyn Normington)
Date: Fri, 18 May 2007 08:38:00 +0100
Subject: Legacy classes in a module
In-Reply-To: <464D08E5.7070500@oracle.com>
Message-ID: <OFEBFB5E03.3AF7631F-ON802572DF.0029C13C-802572DF.0029F0C1@uk.ibm.com>

Hi Bryan

Your proposal has considerable benefits. Do you have a feel for its
acceptability to the JSR 294 Expert Group? I don't think we've discussed
it (properly) over there.

Glyn

Bryan Atsatt <bryan.atsatt at ORACLE.COM> wrote on 18/05/2007 03:01:09:

> I am assuming that in this scenario the module developer would be
> allowed to make this explicit in the superpackage declaration itself.
> That is, superpackage member declarations could include packages from
> the "legacy" jars. 294 simply has to allow declared member packages to
> be AWOL at compile time.
>
> BTW: The proposal I referred to earlier assumes that the runtime
> artifact of a superpackage (e.g. a SuperPackage class instance) is
> *assigned* to each class during ClassLoader.defineClass(). This
> decouples the superpackage and class file artifacts while solving the
> superpackage "loading" problem for the VM. It obviously makes it trivial
> for "legacy" classes to be assigned into a superpackage as they are
> defined. (It also makes it possible to extend the superpackage at
> runtime, but that may be going too far.)
>
> // Bryan
>
> Stanley M. Ho wrote:
> > Regardless, I think we still need to distinguish whether the legacy
classes
> > should be considered module private (use case #1) or made visible
externally
> > (use case #2). I don't think we can really know the developer's intent
by
> > looking at the legacy classes alone. Even if rewriting is involved, we
still
> > need to distinguish these cases in order to have the proper export
> > information in the superpackage.
> >
> > - Stanley
> >
> >
> > On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak
> <cierniak at GOOGLE.COM> wrote:
> >
> >> I would like to add that even if superpackage classes do name their
> >> superpackage in the new world, it wouldn't be difficult to require
the
> >> JRE to "rewrite" legacy classes on the fly if they are loaded from a
> >> JAR embedded in a JAM.  In that case, the legacy classes would end up
> >> being members of the superpackage associated with the containing JAM.
> >>
> >> We might run into other problems because legacy classes do not
> >> necessarily play by the rules of the new module-aware world but this
> >> is independent of whether we rewrite them to add superpackage
> >> membership info.
> >>
> >> Michal
> >>
> >> On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> >>> While the current strawman suggests that superpackage classes will
have
> >>> modified class files (e.g. naming their superpackage), there is a
> >>> proposal on the table that eliminates this requirement.
> >>>
> >>> If eliminated, the only requirement to include "legacy" classes in a
> >>> superpackage will be to have the superpackage artifact present. In a
277
> >>> module, any mixture of new and "legacy" classes (likely in separate
> >>> jars) could then fall under the umbrella superpackage. And this
whole
> >>> issue is eliminated...
> >>>
> >>> // Bryan
> >>>
> >






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: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070518/e7722aff/attachment-0001.html 

From bryan.atsatt at oracle.com  Fri May 18 11:42:27 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Fri, 18 May 2007 11:42:27 -0700
Subject: Legacy classes in a module
In-Reply-To: <OFEBFB5E03.3AF7631F-ON802572DF.0029C13C-802572DF.0029F0C1@uk.ibm.com>
References: <OFEBFB5E03.3AF7631F-ON802572DF.0029C13C-802572DF.0029F0C1@uk.ibm.com>
Message-ID: <464DF393.2060808@oracle.com>

No, we haven't yet, but we should.

Another benefit you have may have spotted is that an OSGi implementation
of 277 modules could support "split superpackages" by having the loaders
involved assign a common SuperPackage instance. While none of us likes
split packages, if we are to truly make OSGi a first-class citizen in
the 277/294 world, this side-effect of the proposal should be seriously
considered.

// Bryan

Glyn Normington wrote:
>
> Hi Bryan
>
> Your proposal has considerable benefits. Do you have a feel for its
> acceptability to the JSR 294 Expert Group? I don't think we've discussed
> it (properly) over there.
>
> Glyn
>
> *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 18/05/2007 03:01:09:
>
>  > I am assuming that in this scenario the module developer would be
>  > allowed to make this explicit in the superpackage declaration itself.
>  > That is, superpackage member declarations could include packages from
>  > the "legacy" jars. 294 simply has to allow declared member packages to
>  > be AWOL at compile time.
>  >
>  > BTW: The proposal I referred to earlier assumes that the runtime
>  > artifact of a superpackage (e.g. a SuperPackage class instance) is
>  > *assigned* to each class during ClassLoader.defineClass(). This
>  > decouples the superpackage and class file artifacts while solving the
>  > superpackage "loading" problem for the VM. It obviously makes it trivial
>  > for "legacy" classes to be assigned into a superpackage as they are
>  > defined. (It also makes it possible to extend the superpackage at
>  > runtime, but that may be going too far.)
>  >
>  > // Bryan
>  >
>  > Stanley M. Ho wrote:
>  > > Regardless, I think we still need to distinguish whether the legacy
> classes
>  > > should be considered module private (use case #1) or made visible
> externally
>  > > (use case #2). I don't think we can really know the developer's
> intent by
>  > > looking at the legacy classes alone. Even if rewriting is involved,
> we still
>  > > need to distinguish these cases in order to have the proper export
>  > > information in the superpackage.
>  > >
>  > > - Stanley
>  > >
>  > >
>  > > On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak
>  > <cierniak at GOOGLE.COM> wrote:
>  > >
>  > >> I would like to add that even if superpackage classes do name their
>  > >> superpackage in the new world, it wouldn't be difficult to require the
>  > >> JRE to "rewrite" legacy classes on the fly if they are loaded from a
>  > >> JAR embedded in a JAM.  In that case, the legacy classes would end up
>  > >> being members of the superpackage associated with the containing JAM.
>  > >>
>  > >> We might run into other problems because legacy classes do not
>  > >> necessarily play by the rules of the new module-aware world but this
>  > >> is independent of whether we rewrite them to add superpackage
>  > >> membership info.
>  > >>
>  > >> Michal
>  > >>
>  > >> On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
>  > >>> While the current strawman suggests that superpackage classes
> will have
>  > >>> modified class files (e.g. naming their superpackage), there is a
>  > >>> proposal on the table that eliminates this requirement.
>  > >>>
>  > >>> If eliminated, the only requirement to include "legacy" classes in a
>  > >>> superpackage will be to have the superpackage artifact present.
> In a 277
>  > >>> module, any mixture of new and "legacy" classes (likely in separate
>  > >>> jars) could then fall under the umbrella superpackage. And this whole
>  > >>> issue is eliminated...
>  > >>>
>  > >>> // Bryan
>  > >>>
>  > >
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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/
>
>
>
>
>
>

From stanley.ho at sun.com  Fri May 18 12:27:21 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Fri, 18 May 2007 13:27:21 -0600
Subject: Legacy classes in a module
Message-ID: <LISTSERV%2007051813272162@JAVA.SUN.COM>

Hi Bryan,

On Thu, 17 May 2007 19:01:09 -0700, Bryan Atsatt <bryan.atsatt at ORACLE.COM>
wrote:

>I am assuming that in this scenario the module developer would be
>allowed to make this explicit in the superpackage declaration itself.
>That is, superpackage member declarations could include packages from
>the "legacy" jars. 294 simply has to allow declared member packages to
>be AWOL at compile time.

>From the perspective of JSR 277, I think what we need is simply a way to
determine from the module metadata whether/which legacy classes should be
made visible externally or not, and this is orthogonal to how it is
expressed in the syntax in JSR 294.

Because it is unclear how legacy classes will be handled in JSR 294, I am
assuming that the module developer would make this explicit in the form of
metadata annotation with the superpackage. Do you have any problem if we go
with the @ExportLegacyClasses proposal for now so we can move on to other
issues?

>BTW: The proposal I referred to earlier assumes that the runtime
>artifact of a superpackage (e.g. a SuperPackage class instance) is
>*assigned* to each class during ClassLoader.defineClass(). This
>decouples the superpackage and class file artifacts while solving the
>superpackage "loading" problem for the VM. It obviously makes it trivial
>for "legacy" classes to be assigned into a superpackage as they are
>defined. (It also makes it possible to extend the superpackage at
>runtime, but that may be going too far.)
>
>// Bryan

The proposal you referred to is in the scope of JSR 294 but out of the scope
of JSR 277, so I think it will be more appropriate if you raise and discuss
that proposal with the JSR 294 EG.  ;)

- Stanley

From stanley.ho at sun.com  Fri May 18 12:41:03 2007
From: stanley.ho at sun.com (Stanley M. Ho)
Date: Fri, 18 May 2007 13:41:03 -0600
Subject: Another reminder: i18n strawman
Message-ID: <LISTSERV%2007051813410389@JAVA.SUN.COM>

Hi JSR 277 experts,

This is another reminder. If you still have inputs on the i18n strawman,
please send them in as soon as possible. In case you need more time to
review the strawman, please let me know. Otherwise, I would interpret the
silent to mean either you are fine with the strawman's content or your
concern has already been raised by other EG members. ;)

Thanks,
- Stanley


On Mon, 14 May 2007 14:54:43 -0700, Stanley M. Ho <Stanley.Ho at SUN.COM> wrote:

>Hi JSR 277 experts,
>
>This is a kindly reminder. If you have inputs on the i18n strawman,
>please send them in by 5/21/2007. Even if you have reviewed the strawman
>and have no comments, it would still be good to let us know.
>
>Thanks,
>- Stanley
>
>-------- Original Message --------
>Subject: Strawman: i18n support
>Date: Mon, 07 May 2007 17:09:41 -0700
>From: Stanley M. Ho <Stanley.Ho at Sun.COM>
>Reply-To: Java Community Process JSR #277 Expert List <JSR-277-EG at JCP.ORG>
>Organization: Sun Microsystems, Inc.
>To: JSR-277-EG at JCP.ORG
>
>Hi JSR 277 experts,
>
>I've been working with Masayoshi Okutsu (i18n lead) and Naoto Sato in
>the Java SE team to come up with a strawman for the i18n support. This
>strawman was developed based on the initial i18n requirements we
>discussed in the EG several weeks ago, as well as on the assumption that
>we simply want to reuse the existing module distribution format (i.e.
>jam files) and repository infrastructure for packaging and deploying
>resources.
>
>I have uploaded the strawman [1] to the expert group home page for
>download. If you prefer to receive them in email, please let me know and
>I'll send it to you directly.
>
>I would like to get your inputs by 5/21/2007, so we can determine how to
>refine the strawman further.
>
>Thanks,
>- Stanley
>
>[1] i18n strawman
>http://www.jcp.org/en/eg/download/jsr-277-i18n-strawman-05022007.pdf?id=277&fileId=3417

From bryan.atsatt at oracle.com  Fri May 18 12:58:08 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Fri, 18 May 2007 12:58:08 -0700
Subject: Legacy classes in a module
In-Reply-To: <LISTSERV%2007051813272162@JAVA.SUN.COM>
References: <LISTSERV%2007051813272162@JAVA.SUN.COM>
Message-ID: <464E0550.5080708@oracle.com>

Of course--we can revisit this if 294 adopts my proposed model...

// Bryan

Stanley M. Ho wrote:
> Hi Bryan,
>
> On Thu, 17 May 2007 19:01:09 -0700, Bryan Atsatt <bryan.atsatt at ORACLE.COM>
> wrote:
>
>> I am assuming that in this scenario the module developer would be
>> allowed to make this explicit in the superpackage declaration itself.
>> That is, superpackage member declarations could include packages from
>> the "legacy" jars. 294 simply has to allow declared member packages to
>> be AWOL at compile time.
>
>>From the perspective of JSR 277, I think what we need is simply a way to
> determine from the module metadata whether/which legacy classes should be
> made visible externally or not, and this is orthogonal to how it is
> expressed in the syntax in JSR 294.
>
> Because it is unclear how legacy classes will be handled in JSR 294, I am
> assuming that the module developer would make this explicit in the form of
> metadata annotation with the superpackage. Do you have any problem if we go
> with the @ExportLegacyClasses proposal for now so we can move on to other
> issues?
>
>> BTW: The proposal I referred to earlier assumes that the runtime
>> artifact of a superpackage (e.g. a SuperPackage class instance) is
>> *assigned* to each class during ClassLoader.defineClass(). This
>> decouples the superpackage and class file artifacts while solving the
>> superpackage "loading" problem for the VM. It obviously makes it trivial
>> for "legacy" classes to be assigned into a superpackage as they are
>> defined. (It also makes it possible to extend the superpackage at
>> runtime, but that may be going too far.)
>>
>> // Bryan
>
> The proposal you referred to is in the scope of JSR 294 but out of the scope
> of JSR 277, so I think it will be more appropriate if you raise and discuss
> that proposal with the JSR 294 EG.  ;)
>
> - Stanley
>

From Stanley.Ho at sun.com  Thu May 17 11:49:59 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Thu, 17 May 2007 11:49:59 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <464B4A5D.9060807@oracle.com>
References: <LISTSERV%2007051600353177@JAVA.SUN.COM>
	<464B4A5D.9060807@oracle.com>
Message-ID: <464CA3D7.1040203@sun.com>

Bryan Atsatt wrote:
> ListResourceBundle cannot be demoted to second-class citizen status in
> the module system (Perhaps you haven't seen my earlier response?).

Yes, I agreed it's important for us to support ListResourceBundle.

> There is a solution to the split package problem, and, while it does
> change the development model slightly, I think that is in line with the
> more significant model change of moving to a module system...
>
> Introduce a package naming convention for resource bundles deployed as
> modules. The convention would allow ResourceBundle.getBundle() to easily
> map from the "base" name to the actual bundle package name.
>
> For example, if we introduce the convention that resource bundle "base"
> names are mapped such that "resources" is appended to the package name,
> then calling ResourceBundle.getBundle with:
>
>   "com.acme.MyResources"
>
> Would actually search for resources with the base name:
>
>   "com.acme.resources.MyResources"
>
> thus sidestepping the split package issue.
>
> Yes, this requires developers to actually define their resources using
> this naming convention, but I don't see that as a significant burden.
> Especially when you consider the benefit of not having to package all
> translations in the primary module.
>
> To avoid potential package name collisions, we should consider using a
> more distinct name than simply "resources", e.g.:
>
>   "com.acme.resource_bundle.MyResources"
>   "com.acme.module_resources.MyResources"
>   "com.acme._resources_.MyResources"
>
> // Bryan

I was under the assumption that we didn't want to change the way
developers define their resources. That said, I am fine with using some
packaging naming convention to sidestep the split package issue.

If we go down this path, I think we will need to expand Bryan's
suggestion a bit. The ResourceBundle API may search multiple resource
modules in order to look up the resources (from more restrictive locales
to less restrictive locales), so it is important for resources in the
resource modules for each locale to have unique package name to avoid
potential conflict regardless the lookup order. e.g.

    "com.acme_en.MyResources"
    "com.acme_ja.MyResources_ja"
    "com.acme_fr.MyResources_fr"
    "com.acme_fr_CH.MyResources_fr_CH"

Note that the locale information is repeated twice. If we want to
simplify it further, we can require the locale information to be
specified only as part of the package name of the resource, but not as
part of the filename of the resource:

    "com.acme_en.MyResources"
    "com.acme_ja.MyResources"
    "com.acme_fr.MyResources"
    "com.acme_fr_CH.MyResources"

- Stanley

From Stanley.Ho at sun.com  Fri May 18 12:23:27 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Fri, 18 May 2007 12:23:27 -0700
Subject: Legacy classes in a module
In-Reply-To: <464D08E5.7070500@oracle.com>
References: <LISTSERV%2007051715115587@JAVA.SUN.COM>
	<464D08E5.7070500@oracle.com>
Message-ID: <464DFD2F.3050109@sun.com>

Hi Bryan,

Bryan Atsatt wrote:
> I am assuming that in this scenario the module developer would be
> allowed to make this explicit in the superpackage declaration itself.
> That is, superpackage member declarations could include packages from
> the "legacy" jars. 294 simply has to allow declared member packages to
> be AWOL at compile time.

 From the perspective of JSR 277, I think what we need is simply a way
to determine from the module metadata whether/which legacy classes
should be made visible externally or not, and this is orthogonal to how
it is expressed in the syntax in JSR 294.

Since it is unclear how legacy classes will be handled in JSR 294, I am
assuming that the module developer would make this explicit in the form
of metadata annotation with the superpackage. Do you have any problem if
we go with the @ExportLegacyClasses proposal in JSR 277 for now so we
can move on to other issues?

> BTW: The proposal I referred to earlier assumes that the runtime
> artifact of a superpackage (e.g. a SuperPackage class instance) is
> *assigned* to each class during ClassLoader.defineClass(). This
> decouples the superpackage and class file artifacts while solving the
> superpackage "loading" problem for the VM. It obviously makes it trivial
> for "legacy" classes to be assigned into a superpackage as they are
> defined. (It also makes it possible to extend the superpackage at
> runtime, but that may be going too far.)
>
> // Bryan

The proposal you referred to is in the scope of JSR 294 but out of the
scope of JSR 277, so I think it will be more appropriate if you raise
and discuss the proposal with the JSR 294 EG. ;)

- Stanley

From Stanley.Ho at sun.com  Tue May 15 18:48:45 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Tue, 15 May 2007 18:48:45 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <237294540705150722w7ae9a8b6v912d2cee962e11d7@mail.gmail.com>
References: <237294540705141636q2832e6bcy2de28f633235cdc4@mail.gmail.com>
	<OF75FE40FA.C2D5D8CF-ON802572DC.004C1287-802572DC.004C46D6@uk.ibm.com>
	<237294540705150722w7ae9a8b6v912d2cee962e11d7@mail.gmail.com>
Message-ID: <464A62FD.1040404@sun.com>

Michal Cierniak wrote:
> Glyn, thanks for pointing this out!
>
> Stanley, do you think that we could restrict the uses of the
> ResourceBundle API in this context to not load code?

Michal, since we will define the actual requirements for the
ResourceBundle API changes in Java SE 7, we could certainly restrict the
usage of ListResourceBundle in the ResourceBundle API when the target
module attempts to load resource bundles from the resource modules.

I have briefly talked to the folks in the i18n team in Java SE, and
their impression was that PropertyResourceBundle is much more commonly
used than ListResourceBundle among developers. However, there are some
applications (including the JDK) relying on ListResourceBundle, so
supporting PropertyResourceBundle alone in the module system may not be
a sufficient solution.


> For the context: my recollection is that we had a consensus to not
> allow split packages but since this discussion took place a long time
> ago, it could be that I don't remember it well.

Right. The EG has the consensus on not to support split packages in the
module system. So far, we have only enforced the policy on the shallow
validation, so module cannot import other modules with split packages. I
don't think we want to alter this policy in type consistency validation,
as this policy does simplify our general design a bit. That said, I
think the question for the EG is whether we want to enforce the
no-split-packages policy beyond type consistency validation (and drop
the ListResourceBundle support as a result), or enforce the policy only
during type consistency validation and make split packages a special
case in loading class-based resource bundles through the ResourceBundle API.

- Stanley

From Stanley.Ho at sun.com  Wed May 16 18:53:40 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Wed, 16 May 2007 18:53:40 -0700
Subject: Reminder: i18n strawman
In-Reply-To: <464B4A5D.9060807@oracle.com>
References: <LISTSERV%2007051600353177@JAVA.SUN.COM>
	<464B4A5D.9060807@oracle.com>
Message-ID: <464BB5A4.709@sun.com>

Bryan Atsatt wrote:
> ListResourceBundle cannot be demoted to second-class citizen status in
> the module system (Perhaps you haven't seen my earlier response?).

Sorry, I missed that, but I agreed it's important for us to support
ListResourceBundle.

> There is a solution to the split package problem, and, while it does
> change the development model slightly, I think that is in line with the
> more significant model change of moving to a module system...
>
> Introduce a package naming convention for resource bundles deployed as
> modules. The convention would allow ResourceBundle.getBundle() to easily
> map from the "base" name to the actual bundle package name.
>
> For example, if we introduce the convention that resource bundle "base"
> names are mapped such that "resources" is appended to the package name,
> then calling ResourceBundle.getBundle with:
>
>   "com.acme.MyResources"
>
> Would actually search for resources with the base name:
>
>   "com.acme.resources.MyResources"
>
> thus sidestepping the split package issue.
>
> Yes, this requires developers to actually define their resources using
> this naming convention, but I don't see that as a significant burden.
> Especially when you consider the benefit of not having to package all
> translations in the primary module.
>
> To avoid potential package name collisions, we should consider using a
> more distinct name than simply "resources", e.g.:
>
>   "com.acme.resource_bundle.MyResources"
>   "com.acme.module_resources.MyResources"
>   "com.acme._resources_.MyResources"
>
> // Bryan

I was under the assumption that we didn't want to change the way
developers define their resources. That said, I am fine with using some
packaging naming convention to sidestep the split package issue.

If we go down this path, I think we will need to expand Bryan's
suggestion a bit. The ResourceBundle API may search multiple resource
modules in order to look up the resources (from more restrictive locales
to less restrictive locales), so it is important for resources in the
resource modules for each locale to have unique package name to avoid
potential conflict regardless the lookup order. e.g.

    "com.acme.locale_en.MyResources"
    "com.acme.locale_ja.MyResources_ja"
    "com.acme.locale_fr.MyResources_fr"
    "com.acme.locale_fr_CH.MyResources_fr_CH"

Note that the locale information is repeated twice. If we want to
simplify it further, we can require the locale information to be
specified only as part of the package name of the resource, but not as
part of the filename of the resource:

    "com.acme.locale_en.MyResources"
    "com.acme.locale_ja.MyResources"
    "com.acme.locale_fr.MyResources"
    "com.acme.locale_fr_CH.MyResources"

- Stanley

From Stanley.Ho at sun.com  Fri May 18 15:27:08 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Fri, 18 May 2007 15:27:08 -0700
Subject: Email problem
Message-ID: <464E283C.4050207@sun.com>

Hi,

Apparently, my email problem has just been fixed, but you will now
receive all the emails that I attempted to send/re-send in the last few
days - please ignore them.

Sorry for any confusion.

- Stanley

From Stanley.Ho at sun.com  Tue May 15 19:01:08 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Tue, 15 May 2007 19:01:08 -0700
Subject: Legacy classes in a module
Message-ID: <464A65E4.7030606@sun.com>

Hi JSR 277 experts,

This is regarding the semantic of legacy classes in a module, and is one
of the outstanding issues in the updated specification (Section 2.14)
that I would like to get your inputs.

Typically, classes in a module are "module" classes - Java classes that
have superpackage membership. However, it is also possible that
developers may want to make use of legacy classes in a module, e.g.
using an existing xml parser in a module. There are two possible use
cases I can think of:

1. Developers simply make use of the legacy classes as implementation
details in the module. In this case, the exported module classes neither
expose nor reference the legacy classes in the export signatures, and
the legacy classes in the module should not be made visible to the
importing modules.

2. Developers use the legacy classes as part of the public API in the
module. In this case, the legacy classes in the module should be made
visible to the importing modules. The exported module classes may expose
or reference the legacy classes in the export signatures, but this is
not required.

I think it's important for us to recognize and support both use cases.
However, this may be difficult for us to determine which use case is the
developers' real intention. Adding to the mix is that lack of module
level access control for the legacy classes, and there is not much we
can do once the legacy classes are leaked out from the module classloader.

That said, I think it's still important for us to define the semantics
for both use cases in the specification. Here is what I propose:

a. Consider #1 to be the default.
b. Add a new superpackage-level annotation (e.g. @ExportLegacyClasses)
for developers to indicate the module is in the #2 category.
c. If @ExportLegacyClasses is declared, the
ModuleDefinition.getExportedClasses() would include the legacy classes.

Note that unless this annotation is declared in the module definition,
the importing modules will never attempt to load the legacy classes from
the imported module during classloading delegation as the classloading
delegation algorithm always checks getExportedClassed() first (see
algorithm in 7.3.1, step 4). However, if other code obtains a reference
of the module classloader somehow and invokes loadClass() directly with
the legacy class name, the module classloader will still return the
legacy class, and this is consistent with the existing classloader behavior.

Let me know if you have inputs. If there are better ways to deal with
this issue, I would like to hear them as well.

- Stanley

From Stanley.Ho at sun.com  Fri May 18 16:39:49 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Fri, 18 May 2007 16:39:49 -0700
Subject: Legacy classes in a module
In-Reply-To: <464E0550.5080708@oracle.com>
References: <LISTSERV%2007051813272162@JAVA.SUN.COM>
	<464E0550.5080708@oracle.com>
Message-ID: <464E3945.50903@sun.com>

Sounds good. Unless I hear any objection from the EG, I will go with the
@ExportLegacyClasses proposal to handle the legacy classes for now.

- Stanley


Bryan Atsatt wrote:
> Of course--we can revisit this if 294 adopts my proposed model...
>
> // Bryan

From glyn_normington at UK.IBM.COM  Sat May 19 10:52:16 2007
From: glyn_normington at UK.IBM.COM (Glyn Normington)
Date: Sat, 19 May 2007 18:52:16 +0100
Subject: Legacy classes in a module
In-Reply-To: <464DF393.2060808@oracle.com>
Message-ID: <OFB20E0079.FFBE26DC-ON802572E0.0061DC88-802572E0.00622B5A@uk.ibm.com>

Good point, so let's discuss the implications on the JSR 294 list in due
course as it would change the class loading restrictions in the current
294 strawman. If you can expand on this aspect at all before floating your
proposal, it would help us all to work through the implications.

Glyn

Bryan Atsatt <bryan.atsatt at ORACLE.COM> wrote on 18/05/2007 19:42:27:

> No, we haven't yet, but we should.
>
> Another benefit you have may have spotted is that an OSGi implementation
> of 277 modules could support "split superpackages" by having the loaders
> involved assign a common SuperPackage instance. While none of us likes
> split packages, if we are to truly make OSGi a first-class citizen in
> the 277/294 world, this side-effect of the proposal should be seriously
> considered.
>
> // Bryan
>
> Glyn Normington wrote:
> >
> > Hi Bryan
> >
> > Your proposal has considerable benefits. Do you have a feel for its
> > acceptability to the JSR 294 Expert Group? I don't think we've
discussed
> > it (properly) over there.
> >
> > Glyn
> >
> > *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 18/05/2007 03:01:09:
> >
> >  > I am assuming that in this scenario the module developer would be
> >  > allowed to make this explicit in the superpackage declaration
itself.
> >  > That is, superpackage member declarations could include packages
from
> >  > the "legacy" jars. 294 simply has to allow declared member packages
to
> >  > be AWOL at compile time.
> >  >
> >  > BTW: The proposal I referred to earlier assumes that the runtime
> >  > artifact of a superpackage (e.g. a SuperPackage class instance) is
> >  > *assigned* to each class during ClassLoader.defineClass(). This
> >  > decouples the superpackage and class file artifacts while solving
the
> >  > superpackage "loading" problem for the VM. It obviously makes it
trivial
> >  > for "legacy" classes to be assigned into a superpackage as they are
> >  > defined. (It also makes it possible to extend the superpackage at
> >  > runtime, but that may be going too far.)
> >  >
> >  > // Bryan
> >  >
> >  > Stanley M. Ho wrote:
> >  > > Regardless, I think we still need to distinguish whether the
legacy
> > classes
> >  > > should be considered module private (use case #1) or made visible
> > externally
> >  > > (use case #2). I don't think we can really know the developer's
> > intent by
> >  > > looking at the legacy classes alone. Even if rewriting is
involved,
> > we still
> >  > > need to distinguish these cases in order to have the proper
export
> >  > > information in the superpackage.
> >  > >
> >  > > - Stanley
> >  > >
> >  > >
> >  > > On Wed, 16 May 2007 14:17:54 -0700, Michal Cierniak
> >  > <cierniak at GOOGLE.COM> wrote:
> >  > >
> >  > >> I would like to add that even if superpackage classes do name
their
> >  > >> superpackage in the new world, it wouldn't be difficult to
require the
> >  > >> JRE to "rewrite" legacy classes on the fly if they are loaded
from a
> >  > >> JAR embedded in a JAM.  In that case, the legacy classes would
end up
> >  > >> being members of the superpackage associated with the containing
JAM.
> >  > >>
> >  > >> We might run into other problems because legacy classes do not
> >  > >> necessarily play by the rules of the new module-aware world but
this
> >  > >> is independent of whether we rewrite them to add superpackage
> >  > >> membership info.
> >  > >>
> >  > >> Michal
> >  > >>
> >  > >> On 5/16/07, Bryan Atsatt <bryan.atsatt at oracle.com> wrote:
> >  > >>> While the current strawman suggests that superpackage classes
> > will have
> >  > >>> modified class files (e.g. naming their superpackage), there is
a
> >  > >>> proposal on the table that eliminates this requirement.
> >  > >>>
> >  > >>> If eliminated, the only requirement to include "legacy" classes
in a
> >  > >>> superpackage will be to have the superpackage artifact present.
> > In a 277
> >  > >>> module, any mixture of new and "legacy" classes (likely in
separate
> >  > >>> jars) could then fall under the umbrella superpackage. And this
whole
> >  > >>> issue is eliminated...
> >  > >>>
> >  > >>> // Bryan
> >  > >>>
> >  > >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /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/
> >
> >
> >
> >
> >
> >






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: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070519/86dabb40/attachment.html 

From Stanley.Ho at sun.com  Mon May 21 14:50:09 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Mon, 21 May 2007 14:50:09 -0700
Subject: Another reminder: i18n strawman
In-Reply-To: <LISTSERV%2007051813410389@JAVA.SUN.COM>
References: <LISTSERV%2007051813410389@JAVA.SUN.COM>
Message-ID: <46521411.8010101@sun.com>

Hi JSR 277 experts,

Since I have not heard any further input on the i18n strawman, I suppose
the EG is fine with the strawman overall except the split package issue
which has been raised and discussed. Unless I hear any objection, I will
incorporate the i18n strawman along with the feedback you have provided
into the next revision of the specification.

Thanks,
- Stanley

From bryan.atsatt at oracle.com  Mon May 21 18:21:12 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Mon, 21 May 2007 18:21:12 -0700
Subject: Another reminder: Updated JSR-277 specification (04/19/2007)
In-Reply-To: <463F7C11.8090601@sun.com>
References: <463A28ED.8080302@sun.com> <463A6323.1050307@oracle.com>
	<463F7C11.8090601@sun.com>
Message-ID: <46524588.6070203@oracle.com>

Hey Stanley,

More comments inline.

// Bryan

Stanley M. Ho wrote:
> Hi Bryan,
>
> Thanks for the inputs. See my comments inline.
>
> Bryan Atsatt wrote:
>> Stanley,
>>
>> Here are my comments on both the spec and the apis.
>>
>> // Bryan
>>
>> SPEC
>> ====
>>
>> 1.5
>>
>> You are assuming that module-name==superpackage-name, right? Otherwise,
>> if we add import statements to 294, then these would have to specify
>> module names, thus creating a circular dependency.
>
> Right. I will clarify it in the next revision of the spec.
>
>> 2.1
>>
>> "is properly understood as a mathematical abstraction"
>>
>> This phrase seems unnecessary, and comes across as a bit highbrow to me.
>>
>> "A module archive is inherently sealed, and it does not reference any
>> resource externally"
>>
>> The term "sealed" here could be confused with the manifest attribute.
>> Perhaps a better term is "self-contained". And the second phrase is a
>> bit confusing also, since imports do reference external "resources".
>> Perhaps if you said "may not directly reference external classes or
>> resources"?
>
> I will look for better words to describe it.
>
>> 2.2
>>
>> Should state that module name must == superpackage name.
>>
>> 2.4
>>
>> The members definition should be a list of *packages*, not classes. That
>> is all the 294 proposal supports (I actually can't see it at the moment
>> since my HD died, but this is my recollection!). I think it is
>> reasonable to assume it will stay this way.
>
> The member declared in the source file is indeed a list of packages.
> That said, based on my understanding of 294, the compiler would expand
> the member packages to a list of classes in the artifact. I will clarify
> it in the spec.
>
>> Version may be optional in a superpackage, but it is mandatory for a
>> module, right? This should be clarified.
>
> "mandatory" would mean something that we can check and enforce. Since
> version is declared using annotation in a superpackage, I don't think we
> can enforce it at build time. That said, we can still enforce it at
> deployment time if this is what you meant.

Yes, the 277 spec should describe it as mandatory, and we should enforce
it at runtime. If it becomes possible to enforce it a compile time, we
would do so.

>
>> The example members list should be package names only.
>>
>> 2.7.3
>>
>> I like this addition.
>
> I'm glad to know.
>
>> 2.7.4
>>
>> There may well be cases in which a module wants to re-export a subset of
>> imported classes/resources. We should consider supporting this case.
>
> Could you describe the actual use cases for this?

Package a.b contains and exports classes C and D.
Package x.y imports a.b, but only wants to re-export C.

>
>> Refactoring in this way results in a perhaps unexpected runtime/memory
>> overhead. A pure wrapper module that re-exports must have its own class
>> loader, and, even though it won't define any classes, the VM *cache*
>> will be updated as that loader is used.

I think we need to think hard about this issue. The OSGi model of import
by *package name* decouples the importer from any explicit binding to a
bundle/module name. Refactoring under that model is *much* cleaner, and
far more natural. As is the usage model. After all, Foo.java import
statements contain package/class names, *not* module names. Programmers
think in terms of classes and packages.

Peter makes this point pretty strongly, and I have to say I agree
wholeheartedly:

http://www.aqute.biz/Blog/2006-04-29

>>
>> 4.1
>>
>> Since not everyone uses the Sun terms (FCS, GA), we might want to also
>> define qualifier here as "beta", or "pre-release", or
>> "release-candidate". And a "release" version must not have a qualifier.
>
> I will clarify it.
>
>> 5.2.2
>>
>>
>> We should also make it clear that resources will also often be contained
>> in "legacy" jars, for which no ClassesDirectoryPath is required.
>
> There is related to an open issue on how we want to support "legacy"
> jars in the implementation. I will open up a new thread for the
> discussion on this topic.
>
>> 5.6
>>
>> Might be a good idea to explicitly state that the Class-Path attribute
>> is ignored.
>
> Right.
>
>> #3 This would appear to rule out OSGi's support of split packages. This
>> spec should enable each ModuleSystem to control this behavior.
>
> The JAM file is the distribution format for the module system defined by
> 277, and I don't think the treatment of JAR manifest in this section
> applies to OSGi.

Sure, for the manifest of a .jam file. But the statement:

"All packages defined in a module definition are inherently sealed, and
this entry is ignored by the module system."

is pretty broad, and would seem to indicate that it applies to the
definitions produced by any module system.


>
>> 6.1
>>
>> Third paragraph: Remove the leading "Besides, "
>>
>> 6.2.2
>>
>> Repository shutdown must define the semantics for any module instances
>> from that repository.
>>
>> I still strongly believe we need a module shutdown method that
>> optionally disables the loader.
>>
>> And this should also be used during repository shutdown. See my comments
>> below for section E.5.
>
> This is on my radar, and is briefly mentioned in E.4 and E.5. We will
> need to discuss what kind of lifecycle support we want to provide, and I
> will open a new thread for the discussion soon.
>
>> 6.2.3/6.3
>>
>> For EE and other similar systems, it may be useful to have different
>> VisibilityPolicy instances per Repository. We may want to have a
>> getter/setter here, with the default implementation of get returning the
>> default policy.
>
> Could you describe the use cases you had in mind for this?

It creates a nice way to create wrapper repository instances that
provide a customized view...

EE systems are required to isolate applications from each other. And
each may have very different external dependencies. If each repository
instance can have its own VisibilityPolicy, then a wrapper Repository
can be constructed for each application, using a different policy.

Same goes for ImportOverridePolicy.

>
>> 6.2.6
>>
>> Local repository instances will "know" when any of these events occurs
>> (via their API). Remote ones will not, so reload() is a reasonable
>> method.
>>
>> Should reload be *required* before any repository returns new/modified
>> instances?
>
> My expectation is that most repository implementations would want to
> optimize their performance by caching most things in memory and not poll
> the underlying storages unless they have to, so I think "reload" should
> be required. That said, if you have use cases that show otherwise, I
> would be interested to know about them.

I'm just considering the simple case of deploying a new module to a
LocalRepository. I think it will be a bit surprising if some special act
is required to make it available. For example, this would fail:

   localRepos.install(aModuleNamedSue);
   ModuleDefinition sue = localRepos.find("sue");

And it is pretty awkward to insert a call to reload() here. Given that
the primary client of Repository is ModuleSystem, I guess the
preparation logic can call reload() and re-try IFF a suitable definition
cannot be found.

>
>> 6.5.1
>>
>> It isn't clear from this that each repository instance sharing an
>> interchange dir must have a unique "expansion" directory.
>>
>> While some variant subclass could be created that uses appropriate
>> locking to share the expansion dir, the provided LocalRepository does
>> not.
>
> I think this will be up to each repository implementation to decide. No
> matter what the implementation strategy is, it should not affect the
> repository's semantic.

Yes, but LocalRepository is a specific implementation, and one that
requires an expansion directory for each instance, right? We should make
that clear.

>
>> 6.5.3
>>
>> #5 Should be "shut down" not "shutted down".
>>
>> 7.1.1/7.1.2
>>
>> Should say that a system property may be used to control the type
>> returned by ModuleSystem.getDefault().
>
> This method would be used to return the default module system which has
> ties with the underlying JRE implementation. As we discussed, this is
> not replaceable, so I don't think providing a system property for
> override makes sense. ;)

Thinking about this a bit more, the idea of a "default" module system is
a bit odd. Certainly there will be one module system used by the JRE
itself, and this is what you were thinking about here. And clearly
LocalRepository and URLRepository are hard-wired to this same module
system, so it makes some sense to be able to say in the javadoc for
these classes that they use the "default" module (which needs to be
added, btw). Do you have any other uses in mind? Perhaps we should be
more explicit:

    public static ModuleSystem getJREModuleSystem();


Regardless, what I was really thinking about before is ModuleSystem
initialization.

ModuleDefinition has a getModuleSystem() method, but how is it
implemented? Our model so far appears to assume that ModuleSystem
instances will be shared, which is certainly reasonable, but... how? One
simple model is that it is module system dependent, e.g. each module
system implementation provides a singleton or equivalent. But this just
pushes the problem up a layer, since the runtime type of
ModuleDefinition will vary based on module system.

I see that you added a ctor arg/getModuleSystem() method to Repository
as well. In this model, the type problem is pushed up one more layer. It
is the Repository implementation that must know the ModuleDefinition
type, and therefore the ModuleSystem type.

But we need to specify exactly how the initial repositories are
configured/initialized, using the correct types, so that the JRE can
instantiate them. (I took a cut at this in the class loading doc, if you
recall.) This should be added to Appendix E--even if some of the details
are JVM vendor specific, the requirements must at least be defined.


But... didn't we decide long ago that a repository should not be
restricted to a single module system? With a multi-repository search
model, this is less of an issue, but why impose this limit? Composite
implementations might have a hard time implementing getModuleSystem().

Perhaps we should consider a model in which we:

1. Require ModuleSystem implementations to have a globally unique name.
(There aren't likely to be hundreds of them, so this shouldn't be much
of a hardship!)

2. Have a persistent configuration mechanism for ModuleSystems, like the
one for the initial Repository instances. In addition to the runtime
types for ModuleSystem subclasses, the instances themselves will likely
need configuration, just like Repositories (logging, security,
import/visibility policies, etc.)

3. During startup, the JRE initializes the registered ModuleSystems,
then the registered Repositories.

4. Add to ModuleSystem:

    public abstract String getName();

    public static ModuleSystem getModuleSystem(String name);
    public static List<ModuleSystem> getModuleSystems();

Now repository implementations are not involved in *instantiating*
ModuleSystems; they look them up by name.

(and having a centralized lookup mechanism may enable other interesting
behaviors)

>
>> I think we need more flexible mechanisms to control this. At the very
>> least, there should be a way to define it in the local JRE in a
>> persistent fashion.
>>
>> But we also may want a way for the launcher to choose the default module
>> system based on some delegation model. Perhaps the available systems can
>> be specified in a config file, each in a standard 277 module. And the
>> launcher's search algorithm could iterate across the ModuleSystem
>> instances and ask each to try loading the main module.
>>
>> Obviously the specifics need to be worked out, but you get the idea.
>
> This will depend on the implementation logic in the launcher in the JDK,
> but the launcher is out of scope in the 277 spec. On the other hand, if
> the launcher requires APIs from 277 in order to do its work, then we
> will need to consider the requirements.
>
>> 7.3.1
>>
>> #4, bullet 2: loadClass() must not mask any thrown Error or
>> RuntimeException by converting it to a ClassNotFoundException! This
>> would make debugging the problem much more difficult, and would be a
>> significant change in class loader behavior.
>
> I will make the logic more clear.
>
>> 7.3.2.2
>>
>> The search order for resources MUST be the same as that for classes. I
>> can support this statement if you like.
>
> How to actually support the notion of exported resources is another open
> issue, and I will open a new thread on this soon.
>
>> We should also say something about the protocol for resource URLs.

Shouldn't we? Like whether there will be a new protocol for them, or not.

>>
>> E.5
>>
>> Again, module shutdown can only be performed within the scope of some
>> larger construct, such as an EE application/container.
>>
>> Such an environment can and does have an explicit lifecycle model,
>> including threading.
>>
>> Consider what can (and will!) happen after a module uninstall, if that
>> module is left "alive"...
>>
>> If the uninstall removes the deployed module from the storage, then
>> subsequent subsequent attempts to load classes/resources from that
>> module can fail (depending on what is cached by the underlying
>> ZipFile/file system/OS implementation).
>>
>> And it doesn't need to be a direct call to loadClass(). I have often
>> seen this kind of failure happen with lazy dependency loading.
>>
>> So, the uninstall either must defer physically removing the deployed
>> module until all instances are gone, or it must schedule them for
>> removal on next startup, or whatever... crazy complexity.
>>
>> Can the storage of a shutdown repository be safely deleted? Not if any
>> process is still using it.
>>
>> For all of these reasons, I strongly believe we need a module shutdown
>> method. And yes, its use must be well documented!
>
> If I understand your requirements properly, I think what you are really
> asking is a classloader disable/shutdown method, and such a method would
> be called when a module is released (or shutdown) from the module system
> in the context of EE servers.
>
>> API
>> ---
>
> Since the APIs are still evolving significantly, I would like to defer
> most of that discussions until the next revision of the spec and APIs
> are available for the EG to review. That said, I will take your comments
> into account when the APIs are refactored.
>
> - Stanley
>
>
>> ModuleDefinition
>>
>> * The getModuleDefinitionContent() method must return a list of
>> instances, since multiple jars/directories may be present. Might also
>> make sense to shorten the name to getContents() since the return type
>> makes it pretty clear what you are getting.
>>
>>
>> ModuleDefinitionContent
>>
>> * The semantics of the open() method are fuzzy: who calls it, and when?
>> Can it be safely called multiple times? What happens when the other
>> methods are called and open() hasn't occurred?
>>
>> * Perhaps the open should be automatic on use of any accessor method if
>> needed?
>>
>> * There should be an isOpen() method.
>>
>> * I think the name should be shortened to ModuleContent. It is not
>> actually part of the definition.
>>
>>
>> JamsModuleDefinition
>>
>> * Should be singular: JamModuleDefinition
>>
>>
>> ImportPolicy
>>
>> * Should have a static getDefault() method.
>>
>>
>> Version/VersionRange/VersionContstraint
>>
>> (See proposal in earlier email)
>>
>>
>> PlatformBinding
>>
>> * Why not just call this "Platform"? It is no different than Version,
>> just another attribute that can be used to filter during resolution.
>>
>>
>> ModuleArchiveInfo
>>
>> * Need a way to get this from either a Module or a ModuleDefinition.
>>
>>
>> Repository
>>
>> * Implementations of findModuleDefinition() will want to discover if the
>> query contains a module name (equality test only!), so that the name can
>> be used as a primary key. Either we should add a method to Query to test
>> for this, or we should pass a name argument to this method. In the
>> latter case, a null name must be allowed.
>

From heavy at UNGOVERNED.ORG  Tue May 22 05:41:20 2007
From: heavy at UNGOVERNED.ORG (Richard S. Hall)
Date: Tue, 22 May 2007 08:41:20 -0400
Subject: Another reminder: Updated JSR-277 specification (04/19/2007)
In-Reply-To: <46524588.6070203@oracle.com>
References: <463A28ED.8080302@sun.com> <463A6323.1050307@oracle.com>
	<463F7C11.8090601@sun.com> <46524588.6070203@oracle.com>
Message-ID: <4652E4F0.3080200@ungoverned.org>

Bryan Atsatt wrote:
> Hey Stanley,
>
> More comments inline.
>
> // Bryan
>
> Stanley M. Ho wrote:
>> Hi Bryan,
>>
>> Thanks for the inputs. See my comments inline.
>>
>> Bryan Atsatt wrote:
>>> Stanley,
>>>
>>> Here are my comments on both the spec and the apis.
>>>
>>> // Bryan
>>>
>>> SPEC
>>> ====
>>>
>>> 1.5
>>>
>>> You are assuming that module-name==superpackage-name, right? Otherwise,
>>> if we add import statements to 294, then these would have to specify
>>> module names, thus creating a circular dependency.
>>
>> Right. I will clarify it in the next revision of the spec.
>>
>>> 2.1
>>>
>>> "is properly understood as a mathematical abstraction"
>>>
>>> This phrase seems unnecessary, and comes across as a bit highbrow to
>>> me.
>>>
>>> "A module archive is inherently sealed, and it does not reference any
>>> resource externally"
>>>
>>> The term "sealed" here could be confused with the manifest attribute.
>>> Perhaps a better term is "self-contained". And the second phrase is a
>>> bit confusing also, since imports do reference external "resources".
>>> Perhaps if you said "may not directly reference external classes or
>>> resources"?
>>
>> I will look for better words to describe it.
>>
>>> 2.2
>>>
>>> Should state that module name must == superpackage name.
>>>
>>> 2.4
>>>
>>> The members definition should be a list of *packages*, not classes.
>>> That
>>> is all the 294 proposal supports (I actually can't see it at the moment
>>> since my HD died, but this is my recollection!). I think it is
>>> reasonable to assume it will stay this way.
>>
>> The member declared in the source file is indeed a list of packages.
>> That said, based on my understanding of 294, the compiler would expand
>> the member packages to a list of classes in the artifact. I will clarify
>> it in the spec.
>>
>>> Version may be optional in a superpackage, but it is mandatory for a
>>> module, right? This should be clarified.
>>
>> "mandatory" would mean something that we can check and enforce. Since
>> version is declared using annotation in a superpackage, I don't think we
>> can enforce it at build time. That said, we can still enforce it at
>> deployment time if this is what you meant.
>
> Yes, the 277 spec should describe it as mandatory, and we should enforce
> it at runtime. If it becomes possible to enforce it a compile time, we
> would do so.
>
>>
>>> The example members list should be package names only.
>>>
>>> 2.7.3
>>>
>>> I like this addition.
>>
>> I'm glad to know.
>>
>>> 2.7.4
>>>
>>> There may well be cases in which a module wants to re-export a
>>> subset of
>>> imported classes/resources. We should consider supporting this case.
>>
>> Could you describe the actual use cases for this?
>
> Package a.b contains and exports classes C and D.
> Package x.y imports a.b, but only wants to re-export C.

I am not sure that this case is such a good idea. By allowing it,
wouldn't consumers of package x.y then potentially be able to see a D
from some other provider...this seems like a recipe for subtle bugs. You
mention the OSGi model below, but such subsetting of packages really
breaks the OSGi model of atomic packages.

>>> Refactoring in this way results in a perhaps unexpected runtime/memory
>>> overhead. A pure wrapper module that re-exports must have its own class
>>> loader, and, even though it won't define any classes, the VM *cache*
>>> will be updated as that loader is used.
>
> I think we need to think hard about this issue. The OSGi model of import
> by *package name* decouples the importer from any explicit binding to a
> bundle/module name. Refactoring under that model is *much* cleaner, and
> far more natural. As is the usage model. After all, Foo.java import
> statements contain package/class names, *not* module names. Programmers
> think in terms of classes and packages.
>
> Peter makes this point pretty strongly, and I have to say I agree
> wholeheartedly:
>
> http://www.aqute.biz/Blog/2006-04-29

Me too.

-> richard

>>> 4.1
>>>
>>> Since not everyone uses the Sun terms (FCS, GA), we might want to also
>>> define qualifier here as "beta", or "pre-release", or
>>> "release-candidate". And a "release" version must not have a qualifier.
>>
>> I will clarify it.
>>
>>> 5.2.2
>>>
>>>
>>> We should also make it clear that resources will also often be
>>> contained
>>> in "legacy" jars, for which no ClassesDirectoryPath is required.
>>
>> There is related to an open issue on how we want to support "legacy"
>> jars in the implementation. I will open up a new thread for the
>> discussion on this topic.
>>
>>> 5.6
>>>
>>> Might be a good idea to explicitly state that the Class-Path attribute
>>> is ignored.
>>
>> Right.
>>
>>> #3 This would appear to rule out OSGi's support of split packages. This
>>> spec should enable each ModuleSystem to control this behavior.
>>
>> The JAM file is the distribution format for the module system defined by
>> 277, and I don't think the treatment of JAR manifest in this section
>> applies to OSGi.
>
> Sure, for the manifest of a .jam file. But the statement:
>
> "All packages defined in a module definition are inherently sealed, and
> this entry is ignored by the module system."
>
> is pretty broad, and would seem to indicate that it applies to the
> definitions produced by any module system.
>
>
>>
>>> 6.1
>>>
>>> Third paragraph: Remove the leading "Besides, "
>>>
>>> 6.2.2
>>>
>>> Repository shutdown must define the semantics for any module instances
>>> from that repository.
>>>
>>> I still strongly believe we need a module shutdown method that
>>> optionally disables the loader.
>>>
>>> And this should also be used during repository shutdown. See my
>>> comments
>>> below for section E.5.
>>
>> This is on my radar, and is briefly mentioned in E.4 and E.5. We will
>> need to discuss what kind of lifecycle support we want to provide, and I
>> will open a new thread for the discussion soon.
>>
>>> 6.2.3/6.3
>>>
>>> For EE and other similar systems, it may be useful to have different
>>> VisibilityPolicy instances per Repository. We may want to have a
>>> getter/setter here, with the default implementation of get returning
>>> the
>>> default policy.
>>
>> Could you describe the use cases you had in mind for this?
>
> It creates a nice way to create wrapper repository instances that
> provide a customized view...
>
> EE systems are required to isolate applications from each other. And
> each may have very different external dependencies. If each repository
> instance can have its own VisibilityPolicy, then a wrapper Repository
> can be constructed for each application, using a different policy.
>
> Same goes for ImportOverridePolicy.
>
>>
>>> 6.2.6
>>>
>>> Local repository instances will "know" when any of these events occurs
>>> (via their API). Remote ones will not, so reload() is a reasonable
>>> method.
>>>
>>> Should reload be *required* before any repository returns new/modified
>>> instances?
>>
>> My expectation is that most repository implementations would want to
>> optimize their performance by caching most things in memory and not poll
>> the underlying storages unless they have to, so I think "reload" should
>> be required. That said, if you have use cases that show otherwise, I
>> would be interested to know about them.
>
> I'm just considering the simple case of deploying a new module to a
> LocalRepository. I think it will be a bit surprising if some special act
> is required to make it available. For example, this would fail:
>
>   localRepos.install(aModuleNamedSue);
>   ModuleDefinition sue = localRepos.find("sue");
>
> And it is pretty awkward to insert a call to reload() here. Given that
> the primary client of Repository is ModuleSystem, I guess the
> preparation logic can call reload() and re-try IFF a suitable definition
> cannot be found.
>
>>
>>> 6.5.1
>>>
>>> It isn't clear from this that each repository instance sharing an
>>> interchange dir must have a unique "expansion" directory.
>>>
>>> While some variant subclass could be created that uses appropriate
>>> locking to share the expansion dir, the provided LocalRepository does
>>> not.
>>
>> I think this will be up to each repository implementation to decide. No
>> matter what the implementation strategy is, it should not affect the
>> repository's semantic.
>
> Yes, but LocalRepository is a specific implementation, and one that
> requires an expansion directory for each instance, right? We should make
> that clear.
>
>>
>>> 6.5.3
>>>
>>> #5 Should be "shut down" not "shutted down".
>>>
>>> 7.1.1/7.1.2
>>>
>>> Should say that a system property may be used to control the type
>>> returned by ModuleSystem.getDefault().
>>
>> This method would be used to return the default module system which has
>> ties with the underlying JRE implementation. As we discussed, this is
>> not replaceable, so I don't think providing a system property for
>> override makes sense. ;)
>
> Thinking about this a bit more, the idea of a "default" module system is
> a bit odd. Certainly there will be one module system used by the JRE
> itself, and this is what you were thinking about here. And clearly
> LocalRepository and URLRepository are hard-wired to this same module
> system, so it makes some sense to be able to say in the javadoc for
> these classes that they use the "default" module (which needs to be
> added, btw). Do you have any other uses in mind? Perhaps we should be
> more explicit:
>
>    public static ModuleSystem getJREModuleSystem();
>
>
> Regardless, what I was really thinking about before is ModuleSystem
> initialization.
>
> ModuleDefinition has a getModuleSystem() method, but how is it
> implemented? Our model so far appears to assume that ModuleSystem
> instances will be shared, which is certainly reasonable, but... how? One
> simple model is that it is module system dependent, e.g. each module
> system implementation provides a singleton or equivalent. But this just
> pushes the problem up a layer, since the runtime type of
> ModuleDefinition will vary based on module system.
>
> I see that you added a ctor arg/getModuleSystem() method to Repository
> as well. In this model, the type problem is pushed up one more layer. It
> is the Repository implementation that must know the ModuleDefinition
> type, and therefore the ModuleSystem type.
>
> But we need to specify exactly how the initial repositories are
> configured/initialized, using the correct types, so that the JRE can
> instantiate them. (I took a cut at this in the class loading doc, if you
> recall.) This should be added to Appendix E--even if some of the details
> are JVM vendor specific, the requirements must at least be defined.
>
>
> But... didn't we decide long ago that a repository should not be
> restricted to a single module system? With a multi-repository search
> model, this is less of an issue, but why impose this limit? Composite
> implementations might have a hard time implementing getModuleSystem().
>
> Perhaps we should consider a model in which we:
>
> 1. Require ModuleSystem implementations to have a globally unique name.
> (There aren't likely to be hundreds of them, so this shouldn't be much
> of a hardship!)
>
> 2. Have a persistent configuration mechanism for ModuleSystems, like the
> one for the initial Repository instances. In addition to the runtime
> types for ModuleSystem subclasses, the instances themselves will likely
> need configuration, just like Repositories (logging, security,
> import/visibility policies, etc.)
>
> 3. During startup, the JRE initializes the registered ModuleSystems,
> then the registered Repositories.
>
> 4. Add to ModuleSystem:
>
>    public abstract String getName();
>
>    public static ModuleSystem getModuleSystem(String name);
>    public static List<ModuleSystem> getModuleSystems();
>
> Now repository implementations are not involved in *instantiating*
> ModuleSystems; they look them up by name.
>
> (and having a centralized lookup mechanism may enable other interesting
> behaviors)
>
>>
>>> I think we need more flexible mechanisms to control this. At the very
>>> least, there should be a way to define it in the local JRE in a
>>> persistent fashion.
>>>
>>> But we also may want a way for the launcher to choose the default
>>> module
>>> system based on some delegation model. Perhaps the available systems
>>> can
>>> be specified in a config file, each in a standard 277 module. And the
>>> launcher's search algorithm could iterate across the ModuleSystem
>>> instances and ask each to try loading the main module.
>>>
>>> Obviously the specifics need to be worked out, but you get the idea.
>>
>> This will depend on the implementation logic in the launcher in the JDK,
>> but the launcher is out of scope in the 277 spec. On the other hand, if
>> the launcher requires APIs from 277 in order to do its work, then we
>> will need to consider the requirements.
>>
>>> 7.3.1
>>>
>>> #4, bullet 2: loadClass() must not mask any thrown Error or
>>> RuntimeException by converting it to a ClassNotFoundException! This
>>> would make debugging the problem much more difficult, and would be a
>>> significant change in class loader behavior.
>>
>> I will make the logic more clear.
>>
>>> 7.3.2.2
>>>
>>> The search order for resources MUST be the same as that for classes. I
>>> can support this statement if you like.
>>
>> How to actually support the notion of exported resources is another open
>> issue, and I will open a new thread on this soon.
>>
>>> We should also say something about the protocol for resource URLs.
>
> Shouldn't we? Like whether there will be a new protocol for them, or not.
>
>>>
>>> E.5
>>>
>>> Again, module shutdown can only be performed within the scope of some
>>> larger construct, such as an EE application/container.
>>>
>>> Such an environment can and does have an explicit lifecycle model,
>>> including threading.
>>>
>>> Consider what can (and will!) happen after a module uninstall, if that
>>> module is left "alive"...
>>>
>>> If the uninstall removes the deployed module from the storage, then
>>> subsequent subsequent attempts to load classes/resources from that
>>> module can fail (depending on what is cached by the underlying
>>> ZipFile/file system/OS implementation).
>>>
>>> And it doesn't need to be a direct call to loadClass(). I have often
>>> seen this kind of failure happen with lazy dependency loading.
>>>
>>> So, the uninstall either must defer physically removing the deployed
>>> module until all instances are gone, or it must schedule them for
>>> removal on next startup, or whatever... crazy complexity.
>>>
>>> Can the storage of a shutdown repository be safely deleted? Not if any
>>> process is still using it.
>>>
>>> For all of these reasons, I strongly believe we need a module shutdown
>>> method. And yes, its use must be well documented!
>>
>> If I understand your requirements properly, I think what you are really
>> asking is a classloader disable/shutdown method, and such a method would
>> be called when a module is released (or shutdown) from the module system
>> in the context of EE servers.
>>
>>> API
>>> ---
>>
>> Since the APIs are still evolving significantly, I would like to defer
>> most of that discussions until the next revision of the spec and APIs
>> are available for the EG to review. That said, I will take your comments
>> into account when the APIs are refactored.
>>
>> - Stanley
>>
>>
>>> ModuleDefinition
>>>
>>> * The getModuleDefinitionContent() method must return a list of
>>> instances, since multiple jars/directories may be present. Might also
>>> make sense to shorten the name to getContents() since the return type
>>> makes it pretty clear what you are getting.
>>>
>>>
>>> ModuleDefinitionContent
>>>
>>> * The semantics of the open() method are fuzzy: who calls it, and when?
>>> Can it be safely called multiple times? What happens when the other
>>> methods are called and open() hasn't occurred?
>>>
>>> * Perhaps the open should be automatic on use of any accessor method if
>>> needed?
>>>
>>> * There should be an isOpen() method.
>>>
>>> * I think the name should be shortened to ModuleContent. It is not
>>> actually part of the definition.
>>>
>>>
>>> JamsModuleDefinition
>>>
>>> * Should be singular: JamModuleDefinition
>>>
>>>
>>> ImportPolicy
>>>
>>> * Should have a static getDefault() method.
>>>
>>>
>>> Version/VersionRange/VersionContstraint
>>>
>>> (See proposal in earlier email)
>>>
>>>
>>> PlatformBinding
>>>
>>> * Why not just call this "Platform"? It is no different than Version,
>>> just another attribute that can be used to filter during resolution.
>>>
>>>
>>> ModuleArchiveInfo
>>>
>>> * Need a way to get this from either a Module or a ModuleDefinition.
>>>
>>>
>>> Repository
>>>
>>> * Implementations of findModuleDefinition() will want to discover if
>>> the
>>> query contains a module name (equality test only!), so that the name
>>> can
>>> be used as a primary key. Either we should add a method to Query to
>>> test
>>> for this, or we should pass a name argument to this method. In the
>>> latter case, a null name must be allowed.
>>

From Stanley.Ho at sun.com  Tue May 22 12:55:46 2007
From: Stanley.Ho at sun.com (Stanley M. Ho)
Date: Tue, 22 May 2007 12:55:46 -0700
Subject: Another JSR-277 EDR comment
Message-ID: <46534AC2.2060907@sun.com>

Hi JSR 277 experts,

I have received a new EDR comment [1] late last week, and I've uploaded
the comment to the Confluence.

The comment in [1] is around simplification in using annotations for
declaring exported classes and exported resources. Since the syntax in
declaring exported classes is in the scope of JSR 294 but outside the
scope of JSR 277, I have forwarded them to the JSR 294 spec leads for
consideration. For declaring exported resources, it is within the scope
of JSR 277. However, after exchanging a few emails with the reviewer to
clarify what he suggested, it is clear that the example he mentioned
does not actually require resources to be exported in the first place,
and it does not yield any new requirement that we need to address. If
you disagree, please let me know.

- Stanley

[1] Early Draft Comment - 16
http://gee.cs.oswego.edu:8086/pages/viewpage.action?pageId=630

From bryan.atsatt at oracle.com  Tue May 22 14:42:17 2007
From: bryan.atsatt at oracle.com (Bryan Atsatt)
Date: Tue, 22 May 2007 14:42:17 -0700
Subject: Another reminder: Updated JSR-277 specification (04/19/2007)
In-Reply-To: <4652E4F0.3080200@ungoverned.org>
References: <463A28ED.8080302@sun.com> <463A6323.1050307@oracle.com>
	<463F7C11.8090601@sun.com> <46524588.6070203@oracle.com>
	<4652E4F0.3080200@ungoverned.org>
Message-ID: <465363B9.2010504@oracle.com>

Richard S. Hall wrote:
> Bryan Atsatt wrote:
>> Hey Stanley,
>>
>> More comments inline.
>>
>> // Bryan
>>
>> Stanley M. Ho wrote:
>>> Hi Bryan,
>>>
>>> Thanks for the inputs. See my comments inline.
>>>
>>> Bryan Atsatt wrote:
>>>> Stanley,
>>>>
>>>> Here are my comments on both the spec and the apis.
>>>>
>>>> // Bryan
>>>>
>>>> SPEC
>>>> ====
>>>>
>>>> 1.5
>>>>
>>>> You are assuming that module-name==superpackage-name, right? Otherwise,
>>>> if we add import statements to 294, then these would have to specify
>>>> module names, thus creating a circular dependency.
>>>
>>> Right. I will clarify it in the next revision of the spec.
>>>
>>>> 2.1
>>>>
>>>> "is properly understood as a mathematical abstraction"
>>>>
>>>> This phrase seems unnecessary, and comes across as a bit highbrow to
>>>> me.
>>>>
>>>> "A module archive is inherently sealed, and it does not reference any
>>>> resource externally"
>>>>
>>>> The term "sealed" here could be confused with the manifest attribute.
>>>> Perhaps a better term is "self-contained". And the second phrase is a
>>>> bit confusing also, since imports do reference external "resources".
>>>> Perhaps if you said "may not directly reference external classes or
>>>> resources"?
>>>
>>> I will look for better words to describe it.
>>>
>>>> 2.2
>>>>
>>>> Should state that module name must == superpackage name.
>>>>
>>>> 2.4
>>>>
>>>> The members definition should be a list of *packages*, not classes.
>>>> That
>>>> is all the 294 proposal supports (I actually can't see it at the moment
>>>> since my HD died, but this is my recollection!). I think it is
>>>> reasonable to assume it will stay this way.
>>>
>>> The member declared in the source file is indeed a list of packages.
>>> That said, based on my understanding of 294, the compiler would expand
>>> the member packages to a list of classes in the artifact. I will clarify
>>> it in the spec.
>>>
>>>> Version may be optional in a superpackage, but it is mandatory for a
>>>> module, right? This should be clarified.
>>>
>>> "mandatory" would mean something that we can check and enforce. Since
>>> version is declared using annotation in a superpackage, I don't think we
>>> can enforce it at build time. That said, we can still enforce it at
>>> deployment time if this is what you meant.
>>
>> Yes, the 277 spec should describe it as mandatory, and we should enforce
>> it at runtime. If it becomes possible to enforce it a compile time, we
>> would do so.
>>
>>>
>>>> The example members list should be package names only.
>>>>
>>>> 2.7.3
>>>>
>>>> I like this addition.
>>>
>>> I'm glad to know.
>>>
>>>> 2.7.4
>>>>
>>>> There may well be cases in which a module wants to re-export a
>>>> subset of
>>>> imported classes/resources. We should consider supporting this case.
>>>
>>> Could you describe the actual use cases for this?
>>
>> Package a.b contains and exports classes C and D.
>> Package x.y imports a.b, but only wants to re-export C.
>
> I am not sure that this case is such a good idea. By allowing it,
> wouldn't consumers of package x.y then potentially be able to see a D
> from some other provider...this seems like a recipe for subtle bugs. You
> mention the OSGi model below, but such subsetting of packages really
> breaks the OSGi model of atomic packages.

Right, I was thinking that we would enforce this during resolution,
but... It is certainly simpler to simply support re-export of entire
packages.

It is a little weird for a.b to re-export D if C doesn't refer to D, and
no classes in a.b refer to D, but this is perhaps too subtle.

>
>>>> Refactoring in this way results in a perhaps unexpected runtime/memory
>>>> overhead. A pure wrapper module that re-exports must have its own class
>>>> loader, and, even though it won't define any classes, the VM *cache*
>>>> will be updated as that loader is used.
>>
>> I think we need to think hard about this issue. The OSGi model of import
>> by *package name* decouples the importer from any explicit binding to a
>> bundle/module name. Refactoring under that model is *much* cleaner, and
>> far more natural. As is the usage model. After all, Foo.java import
>> statements contain package/class names, *not* module names. Programmers
>> think in terms of classes and packages.
>>
>> Peter makes this point pretty strongly, and I have to say I agree
>> wholeheartedly:
>>
>> http://www.aqute.biz/Blog/2006-04-29
>
> Me too.
>
> -> richard
>
>>>> 4.1
>>>>
>>>> Since not everyone uses the Sun terms (FCS, GA), we might want to also
>>>> define qualifier here as "beta", or "pre-release", or
>>>> "release-candidate". And a "release" version must not have a qualifier.
>>>
>>> I will clarify it.
>>>
>>>> 5.2.2
>>>>
>>>>
>>>> We should also make it clear that resources will also often be
>>>> contained
>>>> in "legacy" jars, for which no ClassesDirectoryPath is required.
>>>
>>> There is related to an open issue on how we want to support "legacy"
>>> jars in the implementation. I will open up a new thread for the
>>> discussion on this topic.
>>>
>>>> 5.6
>>>>
>>>> Might be a good idea to explicitly state that the Class-Path attribute
>>>> is ignored.
>>>
>>> Right.
>>>
>>>> #3 This would appear to rule out OSGi's support of split packages. This
>>>> spec should enable each ModuleSystem to control this behavior.
>>>
>>> The JAM file is the distribution format for the module system defined by
>>> 277, and I don't think the treatment of JAR manifest in this section
>>> applies to OSGi.
>>
>> Sure, for the manifest of a .jam file. But the statement:
>>
>> "All packages defined in a module definition are inherently sealed, and
>> this entry is ignored by the module system."
>>
>> is pretty broad, and would seem to indicate that it applies to the
>> definitions produced by any module system.
>>
>>
>>>
>>>> 6.1
>>>>
>>>> Third paragraph: Remove the leading "Besides, "
>>>>
>>>> 6.2.2
>>>>
>>>> Repository shutdown must define the semantics for any module instances
>>>> from that repository.
>>>>
>>>> I still strongly believe we need a module shutdown method that
>>>> optionally disables the loader.
>>>>
>>>> And this should also be used during repository shutdown. See my
>>>> comments
>>>> below for section E.5.
>>>
>>> This is on my radar, and is briefly mentioned in E.4 and E.5. We will
>>> need to discuss what kind of lifecycle support we want to provide, and I
>>> will open a new thread for the discussion soon.
>>>
>>>> 6.2.3/6.3
>>>>
>>>> For EE and other similar systems, it may be useful to have different
>>>> VisibilityPolicy instances per Repository. We may want to have a
>>>> getter/setter here, with the default implementation of get returning
>>>> the
>>>> default policy.
>>>
>>> Could you describe the use cases you had in mind for this?
>>
>> It creates a nice way to create wrapper repository instances that
>> provide a customized view...
>>
>> EE systems are required to isolate applications from each other. And
>> each may have very different external dependencies. If each repository
>> instance can have its own VisibilityPolicy, then a wrapper Repository
>> can be constructed for each application, using a different policy.
>>
>> Same goes for ImportOverridePolicy.
>>
>>>
>>>> 6.2.6
>>>>
>>>> Local repository instances will "know" when any of these events occurs
>>>> (via their API). Remote ones will not, so reload() is a reasonable
>>>> method.
>>>>
>>>> Should reload be *required* before any repository returns new/modified
>>>> instances?
>>>
>>> My expectation is that most repository implementations would want to
>>> optimize their performance by caching most things in memory and not poll
>>> the underlying storages unless they have to, so I think "reload" should
>>> be required. That said, if you have use cases that show otherwise, I
>>> would be interested to know about them.
>>
>> I'm just considering the simple case of deploying a new module to a
>> LocalRepository. I think it will be a bit surprising if some special act
>> is required to make it available. For example, this would fail:
>>
>>   localRepos.install(aModuleNamedSue);
>>   ModuleDefinition sue = localRepos.find("sue");
>>
>> And it is pretty awkward to insert a call to reload() here. Given that
>> the primary client of Repository is ModuleSystem, I guess the
>> preparation logic can call reload() and re-try IFF a suitable definition
>> cannot be found.
>>
>>>
>>>> 6.5.1
>>>>
>>>> It isn't clear from this that each repository instance sharing an
>>>> interchange dir must have a unique "expansion" directory.
>>>>
>>>> While some variant subclass could be created that uses appropriate
>>>> locking to share the expansion dir, the provided LocalRepository does
>>>> not.
>>>
>>> I think this will be up to each repository implementation to decide. No
>>> matter what the implementation strategy is, it should not affect the
>>> repository's semantic.
>>
>> Yes, but LocalRepository is a specific implementation, and one that