Stephen,
I think the use-case can be pretty well defined.
There should be an enumeration/iterator/stream available that provides the
contents of a jar file as it would be seen/interpreted by the JVMs
classloader.So if the classloader is doing any processing to handle
versioned classes/resourc
Thanks for the clarification – I overstated the “any JarEntry”.
I didn’t look at VersionedStream so I now understand the limitations you
mention.
In my case, it’s necessary to look at all files in the jar file to do the
elimination of unneeded ordinary/inner classes so JarInputStream
getNex
Stephen,
It is not the case that the getName() always returns the path starting with
"META-INF/versions/". Specifically, if the entry is obtained from
getJarEntry() API (and not from the enumerator), then the name is that of
the unversioned file, but the metadata and contents obtained using the
ja
A versioned file name, JarEntry.getName(), starts with "META-INF/versions/".
The version is the following string up to the next "/".
The version can be parsed with Runtime.Version.parse().
If not a versioned class file name, then use Jarfile.baseVersion().
That should be sufficient to get the versi
Paul,
yeh... I guess I concede it's not JarFiles job... as much as that would
make things easier for containers to reach agreement:(
However, can we at least look at having a new default method on JarEntry to
query the version. Without that, containers don't have the information
available to perf
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187449/webrev.00/
jdeps throws InternalError if a JDK module is not an explicit module.
This check should only apply to JDK modules loaded from the system
image. This patch will relax the check for upgradeable modules that may
be an automatic
On Mon, Sep 18, 2017 at 10:52 AM, Kazunori Ogata wrote:
>
> Hi Peter,
>
> Peter Levart wrote on 2017/09/18 22:05:43:
>
> > On 09/18/2017 12:28 PM, Kazunori Ogata wrote:
> > > Hi Hans and Peter,
> > >
> > > Thank you for your comments.
> > >
> > > Regarding the code Hans showed, I don't yet unders
Hi Roger,
I think that this looks fine.
Thanks,
Brian
On Sep 18, 2017, at 12:28 PM, Roger Riggs wrote:
> Please review refactoring
> the handling of closing of files in FileInputStream, FileOutputStream,
> RandomAccessFile,
> and FileChannelImpl and related native code.
>
> The refactoring
In anticipation of the re-opening (not yet) of the JDK 10 repo please
review refactoring
the handling of closing of files in FileInputStream, FileOutputStream,
RandomAccessFile,
and FileChannelImpl and related native code.
The refactoring enables a future improvement to use the cleaner to close
Hi Peter,
Peter Levart wrote on 2017/09/18 22:05:43:
> From: Peter Levart
> To: Kazunori Ogata
> Cc: Hans Boehm , core-libs-dev
> Date: 2017/09/18 22:06
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
> Hi Ogata,
>
> On 09/18/2017 12:28
I agree with Alan here, we should not be pushing a semantic understanding of
inner classes into JarFile.
I do sympathise with the case of annotation class scanning, which has always
tunnelled through the class loader view to directly get at class file bytes
possibly dealing with various URI sc
Hi Ogata,
On 09/18/2017 12:28 PM, Kazunori Ogata wrote:
Hi Hans and Peter,
Thank you for your comments.
Regarding the code Hans showed, I don't yet understand what it the
problem. Since the load at 1204b is a speculative one, dereferencing
slots[17] should not raise any exception. If the con
Hi Hans and Peter,
Thank you for your comments.
Regarding the code Hans showed, I don't yet understand what it the
problem. Since the load at 1204b is a speculative one, dereferencing
slots[17] should not raise any exception. If the confirmation at 1204.5
succeeds, the value of tmp must also
13 matches
Mail list logo
