Hi Glyn,
Glyn Normington wrote:
...
A better approach would be for the Java 7 platform to provide first
class support for JSR 291. This boils down to standardising the
experimental class loader deadlock fix ([1]) and enabling JSR 291 to
exploit JSR 277's repositories and JSR 294's superpackages.
The features in JSR 277 which are already provided by JSR 291 could be
ditched (!) or could be retained for users wanting a module system "out
of the box" or for exploitation by the JRE itself as a properly
architected sequel to the consumer JRE. But if we retain these features,
it is essential we provide first-class interoperation with JSR 291 as we
have discussed many times in the past but which still looks pretty
challenging (see [2]).
Glyn
As we discussed before, the charter of JSR 277 is to develop a solution
for the next generation Java SE platform to address the problems as
described in the original JSR submission. What we want to provide in JSR
277 (and this EG also agreed) is first-class modularity, packaging, and
deployment support in the SE platform, with integration with language/VM
(through JSR 294), classes libraries and tools. This is the problem we
are solving, and we must provide all the features required to solve this
problem. Whether a feature already exists in other module systems is
orthogonal to whether it should be supported in JSR 277. That said, we
still want to learn from the experience of these existing systems as
much as possible, so we can design JSR 277 in the best possible way.
In terms of the relationship between JSR 277 and JSR 291, I think we all
agreed in the EG that JSR 277 will provide the necessary framework for
interoperation with other module systems, especially with JSR 291/OSGi.
Following up the original email about import package, I don't think we
should support it in JSR 277 for a different reason, and I will reply in
another email.
- Stanley
