Hi Stephen,
On 08/27/2018 11:51 PM, Stephen Colebourne wrote:
The specific code was written in Java 8 world to create a ClassLoader
containing the resource with a suitable parent (as a test case). The
resource was accessed using ClassLoader.getResources() from a shared
library. Under Java 9 I've
Please have a review for below change to refactor shell test
javax/naming/module/basic.sh to plain java, no test logic change, old shell
script is removed at same time, thanks
bug: https://bugs.openjdk.java.net/browse/JDK-8209773
webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/
Regar
Hi Volker,
On Aug 27, 2018, at 6:53 AM, Volker Simonis wrote:
> sorry, I'm a little late in the game. I've just looked at your change
> and in general it looks good!
Thanks: better late than never!
> There's one thing however I think you still have to fix. After
> changing 'stat64' to 'stat' i
The specific code was written in Java 8 world to create a ClassLoader
containing the resource with a suitable parent (as a test case). The
resource was accessed using ClassLoader.getResources() from a shared
library. Under Java 9 I've had to change ClassLoader.getResources() to
Class.getResource()
On 8/27/18 10:51 AM, Peter Levart wrote:
On 08/27/2018 04:47 PM, David Lloyd wrote:
On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman
wrote:
On 24/08/2018 18:27, David Lloyd wrote:
Why not go ahead and implement getResource as well? It's not *that*
big of a deal to add a URL handler, and it
On 27/08/2018 18:49, Jonathan Gibbons wrote:
Alan,
It looks like we don't even need to register a
URLStreamHandlerProvider, we can provide the URLStreamHandler when we
create the URL. :-)
This will only work for URL objects returned by getResource. If you
create the URL by other means, and w
- * @summary Checks that SwingLazyValue class correclty works
+ * @summary Checks that SwingLazyValue class correctly works
And "correctly works" should be "works correctly"
For test/jdk/sun/misc/URLClassPath/ClassnameCharTest.java
please add a comment that the class loader code was
copied from
On 08/27/2018 04:47 PM, David Lloyd wrote:
On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman wrote:
On 24/08/2018 18:27, David Lloyd wrote:
Why not go ahead and implement getResource as well? It's not *that*
big of a deal to add a URL handler, and it would be a fairly trivial
one.
Right, it wo
On 8/27/18 10:47 AM, Alan Bateman wrote:
On 27/08/2018 15:47, David Lloyd wrote:
:
AFAIK any code would expect that resources available as streams would
generally also be available as URLs. I'm not sure that distinguishing
between basic and advanced code really clarifies anything in terms of
On 27/08/2018 15:47, David Lloyd wrote:
:
AFAIK any code would expect that resources available as streams would
generally also be available as URLs. I'm not sure that distinguishing
between basic and advanced code really clarifies anything in terms of
the question.
I think you've mis-read my ma
This is now being tracked in JDK-8210009.
https://bugs.openjdk.java.net/browse/JDK-8210009
-- Jon
On 8/27/18 10:24 AM, seth lytle wrote:
david lloyd wrote:
AFAIK any code would expect that resources available as streams would generally
also be available as URLs
starting with java 9, the jav
david lloyd wrote:
> AFAIK any code would expect that resources available as streams would
> generally
also be available as URLs
starting with java 9, the javadocs for getResource (but not for
getResourceAsStream) specifically allow returning null if "a URL could not
be constructed to locate the
History: I was always a little disappointed that Console (understandably)
didn't support the things you could do with subprocesses in Emacs, like
implement shell buffers and otherwise have expect-style conversations with
subprocesses. But console dimensions was never on my radar - doesn't mean
muc
> On Aug 27, 2018, at 10:25 PM, Baesken, Matthias
> wrote:
>
> Hi Alan ,
>
>> Will sun.net.util.SocketExceptions be changed to use the supporting
>> class or is that a separate issue?
>>
>
> I think this is a separate issue .
>
>> In terms of approach then I think what you have is okay al
On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman wrote:
>
> On 24/08/2018 18:27, David Lloyd wrote:
> > Why not go ahead and implement getResource as well? It's not *that*
> > big of a deal to add a URL handler, and it would be a fairly trivial
> > one.
> Right, it wouldn't be too hard but it would r
On 24/08/2018 18:27, David Lloyd wrote:
Why not go ahead and implement getResource as well? It's not *that*
big of a deal to add a URL handler, and it would be a fairly trivial
one.
Right, it wouldn't be too hard but it would require a bit of plumbing to
have it backed by the Memory* classes in
Hi James,
What's the status of the project? Has it been abandoned?
-Pavel
> On 22 Mar 2018, at 00:09, James Roper wrote:
>
> Hi all,
>
> We've created a reference implementation. It's been done in such a way that
> implementation of new features (stages) is quite straight forward, there is
>
Hi Alan ,
> Will sun.net.util.SocketExceptions be changed to use the supporting
> class or is that a separate issue?
>
I think this is a separate issue .
> In terms of approach then I think what you have is okay although I think
> we should try to find a better name than "SecuritySystemProperty
As I was about to push this, I realize there was a minor nit with the
way in which build.xml files found some classes inside the generated
.idea folder - that is, the path to this folder was defined in a
relative way from the location of the script file.
A more robust way to get there is to se
Hi Brian,
sorry, I'm a little late in the game. I've just looked at your change
and in general it looks good!
There's one thing however I think you still have to fix. After
changing 'stat64' to 'stat' in UnixFileSystem_md.c you should define
'stat' to 'stat64' on AIX if you don't want to change t
On 24/08/2018 15:52, Baesken, Matthias wrote:
Hello, I created another webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
- use now jarPath instead of jarpath in the java security file
- moved the parsing of the property to a more general location (separate
class jdk/intern
On 23/08/2018 15:09, Claes Redestad wrote:
Hi,
it's a tiny startup improvement to rearrange code so that the
ExpiringCaches used in the FileSystem implementations aren't created
if they aren't going to be used:
Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/
Bug: https://bu
Hi Bernd,
It's in:
https://bugs.openjdk.java.net/browse/JDK-8209987
http://hg.openjdk.java.net/jdk/jdk/rev/5f40be158613
best regards,
-- daniel
On 23/08/2018 20:49, Bernd Eckenfels wrote:
Yes, Seeburger AG OCA should be on file (b.eckenf...@seeburger.de)
Thanks for following up
Did you had
On 24/08/2018 14:18, Langer, Christoph wrote:
Hi Rémi, Hi Peter,
thanks for your quick answers.
What you've suggested, Rémi, is perfectly right. I've updated my webrev. The
methods were copied from our old implementation (of a different class) where
they were provided as static.
I will also
24 matches
Mail list logo
