Alen et al,
here is a VersionedJarFile implementation that filters out inappropriate
inner classes:
https://gist.github.com/gregw/8f305e369d0b769e9c3fe791a0634b13
cheers
On 16 September 2017 at 07:58, Greg Wilkins wrote:
>
> Alan,
>
> I had a quick look at `jdk.internal.util.jar.VersionedStre
FWIW I tracked down the MR jar file that I was having trouble with. It's the
stand-alone JAXWS jar file com.sun.xml.ws.jaxws-rt.jar.
Focusing on the problem class, the jar contains
com/sun/xml/ws/util/xml/XmlCatalogUtil$1.class
com/sun/xml/ws/util/xml/XmlCatalogUtil.class
META-INF/versions/9/com/
Alan,
I had a quick look at `jdk.internal.util.jar.VersionedStream` and have the
following comments:
- The style of the API is fine - pass in a JarFile and get a
Stream.
- It might be better to have a Stream which includes
a method to query the actual version of each entry.
- I thi
> On 15 Sep 2017, at 15:17, Alexander Udalov
> wrote:
>
> Thank you, I've re-read JLS 7.7.2 and understand now that it behaves
> as expected. I'll continue exporting and opening every package then.
If you open *every* package, you could create an open module as well. Might be
less annoying, a
Thank you, I've re-read JLS 7.7.2 and understand now that it behaves
as expected. I'll continue exporting and opening every package then.
Alexander
On Fri, Sep 15, 2017 at 3:52 PM, Alan Bateman wrote:
> On 15/09/2017 13:14, Alexander Udalov wrote:
>>
>> It looks like exporting a package from a (
> On 15 Sep 2017, at 14:32, Stephen Felts wrote:
>
> "opens" is a superset of "exports".
Only when qualified with 'at run-time'.
Sander
On 15/09/2017 13:14, Alexander Udalov wrote:
It looks like exporting a package from a (non-open) module with an
"exports" directive is not enough to ensure that
Module.getResourceAsStream on that module would load resources from
the module. Surprisingly, adding an "opens" directive for the same
p
"opens" is a superset of "exports".
-Original Message-
From: Alexander Udalov [mailto:alexander.uda...@jetbrains.com]
Sent: Friday, September 15, 2017 8:14 AM
To: jigsaw-dev
Subject: "exports" directive does not open module's resources for dependent
modules
It looks like exporting a p
It looks like exporting a package from a (non-open) module with an
"exports" directive is not enough to ensure that
Module.getResourceAsStream on that module would load resources from
the module. Surprisingly, adding an "opens" directive for the same
package to the module declaration allows resourc
On 15/09/2017 08:40, Greg Wilkins wrote:
Alan & Christian,
thanks for that - I totally missed ResolvedModule.open().list()
So now a supplementary question... are ModuleReaders MR aware? Ie if
the jar of the module is MR, will the resolved module only contain
classes that are appropriate for
Alan & Christian,
thanks for that - I totally missed ResolvedModule.open().list()
So now a supplementary question... are ModuleReaders MR aware? Ie if the
jar of the module is MR, will the resolved module only contain classes that
are appropriate for the current Runtime?
thanks in advance.
che
On 15/09/2017 03:09, Greg Wilkins wrote:
Alan,
thanks for correcting me on the API of JarFile - I can see it kind of
works, but in a very bizarre way (it gives different content for
entries obtained via the enumerator vs the getJarEntry API, even
though both entries report the same name).
On 15/09/2017 05:01, Greg Wilkins wrote:
All,
another question on scanning, but more jigsaw related than my other
question.
App containers have to scan jars deployed in EARs, WARs etc. for
annotations, fragments, resources etc. However, many containers also offer
features to be able to optional
Hi Greg,
short disclaimer: I'm learning and testing the "--scan-module" magic at
the moment to implement a similar feature in JUnit 5. See [1] for details.
If I'm talking non-sense, please correct me jigsaw-devs.
To scan the contents of a module you'll need a ModuleReference[2] instance.
You may
14 matches
Mail list logo
