On 12/3/14 4:56 AM, Alan Bateman wrote:
On 02/12/2014 02:39, Chris Plummer wrote:
Sorry about the long delay in getting back to this. I ran into two
separate JPRT issues that were preventing me from testing these
changes, plus I was on vacation last week. Here's an updated webrev.
I'm not sure
On 12/04/2014 12:32 AM, Martin Buchholz wrote:
On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea wrote:
No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
java.util.secureRa
On 12/04/2014 09:20 AM, Peter Levart wrote:
P.S. Is anyone interested in generating truly random bytes?
http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
https://software.intel.com/en-us/tags/35970
Maybe not a good idea:
http://en.wikipedia.org/wiki/RdRand#Reception
Looks good to me.
/Erik
On 2014-12-04 04:16, David Holmes wrote:
Updated webrev:
http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/
Only changes are to profile-includes.txt.
Thanks,
David
On 2/12/2014 2:24 PM, David Holmes wrote:
Erik,
Many thanks for the makefile macro wizardry!
Hi David,
On 12/4/14 4:37 AM, David Holmes wrote:
Hi Daniel,
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of
Hi,
I think we may be over-rotating a little on this.
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those circumstances that cost is
acceptable (it may well be p
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class loader.
Then I switched to only parsing the bootmodules.jimage - because
I noticed that the res
Hi Daniel,
On 4/12/2014 7:05 PM, Daniel Fuchs wrote:
On 12/4/14 4:37 AM, David Holmes wrote:
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 & JDK 9
During the review of
JDK-8065552:
Hi Daniel,
On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class loader.
Then I switched to only parsing
On 04/12/14 13:06, David Holmes wrote:
Hi Daniel,
On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
Hi David,
In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under /lib/modules - which explain why I needed to
use the System class l
Thanks for driving efforts in this area Daniel. I think it's a very
useful test and is bound to help test code coverage. If it's currently
passing on all JPRT platforms, it's a good measure.
Eventually I think we can bulk up the tests that can be run on the
Iterable returned from your class se
Hi Nathan,
This list removes attachments.
Can the diff's be inlined in the email?
Thanks, Roger
On 12/4/2014 1:18 AM, Nathan Clement wrote:
Hi,
Here is my suggested fix for the FilterOuputStream issue in JDK-8054565. I
have been running this fix in my applications for several weeks (by addi
Hi,
Catching up on this.
This seems useful:
Stream Pattern.matchAsStream(...)
MatchResult stream elements need to be cloned via Matcher.toMatchResult.
The following is perhaps less useful though might be handy for some matcher
updates before handing off to a stream:
Stream Pattern.matc
Apologies if this has been raised in past. I've run into issues in the
past where bad user code (app server) has set the java.home system
property to a value other than the default. This has consequences for
apps/code that depend heavily on java.home returning the correct
location. The case I s
On 12/04/2014 09:42 AM, Seán Coffey wrote:
Apologies if this has been raised in past. I've run into issues in the
past where bad user code (app server) has set the java.home system
property to a value other than the default. This has consequences for
apps/code that depend heavily on java.home ret
On 04/12/2014 16:00, David M. Lloyd wrote:
On 12/04/2014 09:42 AM, Seán Coffey wrote:
Apologies if this has been raised in past. I've run into issues in the
past where bad user code (app server) has set the java.home system
property to a value other than the default. This has consequences for
a
Patrick, thanks a lot for doing this! I've had a look at these usages, and I
think it's safe to say that in the JDK it has never been required (yet) to
provide a copy method with custom byte array. So let's skip it for now.
I think more and more about your initial suggestion of introducing a 'cop
On 12/04/2014 10:21 AM, Seán Coffey wrote:
On 04/12/2014 16:00, David M. Lloyd wrote:
On 12/04/2014 09:42 AM, Seán Coffey wrote:
Apologies if this has been raised in past. I've run into issues in the
past where bad user code (app server) has set the java.home system
property to a value other t
Hello,
I am not sure this is a good idea, while I can understand a policy of "no
(new) lint warnings" and also activities to remove them (based on the
asumption that every warning is a potential bug or code smell) I absolutely
think supressing all remaining warnings without working to resolve them
On 04/12/14 14:02, Seán Coffey wrote:
Thanks for driving efforts in this area Daniel. I think it's a very
useful test and is bound to help test code coverage. If it's currently
passing on all JPRT platforms, it's a good measure.
It seems to :-)
Eventually I think we can bulk up the tests that
On 04/12/2014 15:42, Seán Coffey wrote:
Apologies if this has been raised in past. I've run into issues in the
past where bad user code (app server) has set the java.home system
property to a value other than the default. This has consequences for
apps/code that depend heavily on java.home retu
Greetings,
I was tempted to address this point my initial message, but since it has
been raised I will do so now.
Many of the warnings in the JDK have been there for years or even more
than a decade in some cases. Therefore, historically those of us who
have worked on the JDK apparently have
On 04/12/2014 08:12, Chris Plummer wrote:
Hi Alan,
While removing the java.io.File import, I also questioned why I had
java.io.IOException being imported. There were a couple of methods
that declared it thrown, and the main method therefore had to catch
it, but it turns out this was just copy
On 12/04/2014 10:40 AM, Paul Sandoz wrote:
Hi,
I think we may be over-rotating a little on this.
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those circumstanc
On 12/04/2014 09:20 AM, Peter Levart wrote:
So what we have here is two desires:
- we want a resource-friendly / with as little dependencies as
possible way to generate some unique seed, with implicit fall-back
which need not be secure
- we want a resource-friendly / with as little dependencies
Hi Pavel,
Patrick, thanks a lot for doing this! I've had a look at these usages, and I
think it's safe to say that in the JDK it has never been required (yet) to
provide a copy method with custom byte array. So let's skip it for now.
Welcome, unfortunately I did not manage it to check those o
On 12/4/14 9:30 AM, Alan Bateman wrote:
On 04/12/2014 08:12, Chris Plummer wrote:
Hi Alan,
While removing the java.io.File import, I also questioned why I had
java.io.IOException being imported. There were a couple of methods
that declared it thrown, and the main method therefore had to catch
Hi Joe,
The changes look fine.
Best,
Lance
On Dec 4, 2014, at 2:18 AM, joe darcy wrote:
> Hello,
>
> First some background, one of the JEPs targeted to JDK 9 is
>
>JEP 212: Resolve Lint and Doclint Warnings
>http://openjdk.java.net/jeps/212
>
> In the jdk repository, only the depreca
Hi,
My apologies - the page http://openjdk.java.net/contribute/ gave me the
impression that I could send the diff as an attachment. I've included it
inline below.
Regards,
Nathan
diff --git a/src/share/classes/java/io/FilterOutputStream.java
b/src/share/classes/java/io/FilterOutputStream.ja
Hello,
Please review these changes to address
JDK-8066632: Suppress deprecation warnings in java.rmi module
http://cr.openjdk.java.net/~darcy/8066632.0/
Patch inlined below.
Thanks,
-Joe
--- old/src/java.rmi/share/classes/java/rmi/server/RemoteObject.java
2014-12-04 14:43:37.8060863
Hi Joe,
Looks fine.
Roger
On 12/4/2014 5:46 PM, joe darcy wrote:
Hello,
Please review these changes to address
JDK-8066632: Suppress deprecation warnings in java.rmi module
http://cr.openjdk.java.net/~darcy/8066632.0/
Patch inlined below.
Thanks,
-Joe
--- old/src/java.rmi/share/c
Patrick,
> Should those methods also be on the FilterInput- and OutputStream?
I'm not sure I'm following you. j.i.FilterInputStream will get the base version
of InputStream.copyTo method for free as a child though it doesn't define it
itself. Every class down the hierarchy starting from the j.i.I
Hello,
also using a stream in a multi threaded way is quite unusual most of
the implementations I have seen use a atomic solution. This makes
sense considering the fact that especially the close() might be called
by a timeout/cleanup/finalizer/timer/shutdown thread. Using a
AtomicUpdater would red
Thanks Erik. Once 8u/dev is open for 8u60 I'll request push approval.
David
On 4/12/2014 6:53 PM, Erik Joelsson wrote:
Looks good to me.
/Erik
On 2014-12-04 04:16, David Holmes wrote:
Updated webrev:
http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/
Only changes are to profile-inc
Hi Daniel,
I still find your use of the classloader very confusing. You talk about
the defining loader but you never check the defining loader against
anything. In
146 static void checkFor(Class c, ClassLoader loader) {
the loader variable is never used. And if loader is simply the
Looks good to me too Chris - sorry for the delay getting back to you.
But at least Kumar spotted all the typos :)
David
On 4/12/2014 6:12 PM, Chris Plummer wrote:
On 12/3/14 4:56 AM, Alan Bateman wrote:
On 02/12/2014 02:39, Chris Plummer wrote:
Sorry about the long delay in getting back to t
> Hello,
>
> also using a stream in a multi threaded way is quite unusual most of
> the implementations I have seen use a atomic solution.
Bernd, as far as I understand we are not talking about concurrent-proof solution
for the j.i.FilterOutputStream as this class is sure not even thread-safe. Mo
On 12/04/2014 04:40 AM, Paul Sandoz wrote:
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those circumstances that cost is
acceptable (it may well be possible to re
It still looks good to me too. :)
Thanks,
Serguei
On 12/4/14 3:46 PM, David Holmes wrote:
Looks good to me too Chris - sorry for the delay getting back to you.
But at least Kumar spotted all the typos :)
David
On 4/12/2014 6:12 PM, Chris Plummer wrote:
On 12/3/14 4:56 AM, Alan Bateman wrote
Hi,
My problem is definitely not related to multi-threaded use. The test shows
basically the same code that we have in production that experienced the
problem. The stream is used from a single thread in a try-with-resources block.
I don't see that this change is any more risky than the change
Am Thu, 4 Dec 2014 23:54:10 +
schrieb Pavel Rappo :
> Bernd, as far as I understand we are not talking about
> concurrent-proof solution for the j.i.FilterOutputStream as this
> class is sure not even thread-safe.
It is used very much, also in concurrent context. As I explained the
close() op
A System.setFinalProperty() method that creates a new property with a final
value? Maybe also a System.isFinalProperty() method allowing people to detect
if a property is final.
--Max
Am Fri, 5 Dec 2014 11:49:26 +1100
schrieb Nathan Clement :
> Hi,
>
> My problem is definitely not related to multi-threaded use. The test
> shows basically the same code that we have in production that
> experienced the problem.
Of course it can be triggered single threaded. But this does not m
But where does it say that this class can be used in a concurrent context?
This class is documented as serving a base class role, yes, but it has
state. It's the user/subclass responsibility to provide threadsafety, as
far as I see. Attempting to make close() atomic just makes the next reader
con
Martin,
On 2/12/2014 6:46 AM, Martin Buchholz wrote:
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
Is this finalized then? You can only make one commit per CR.
I think the current webrev is simple progress with the exception of my
attempt to tran
On 2/12/2014 6:46 AM, Martin Buchholz wrote:
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
I think the current webrev is simple progress with the exception of my
attempt to translate volatiles into fences, which is marginal (but was
a good learning e
Hello,
Please review the small fix below for
JDK-8066641: Suppress deprecation warnings in jdk.naming module
Thanks,
-Joe
diff -r ab3ff449ba9a
src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java
---
a/src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry
+1
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On Dec 4, 2014, at 9:23 PM, joe darcy wrote:
>
> Hello,
>
> Please review the small fix below for
>
>JDK-80
Hi Alan,
I am not clear whether canonicalization cache enabled or disabled, however
I think even the cache is enable, it may not help much for the start up
stage especially if the app uses many different files.
The cache should speed up applications for common case especially after
start up and t
Hi Weijun,
The original init() methods invoked by FilePermission constructors and
readObject() for deserialization. The constructors will be invoked only
once for each FilePermission Object and the ObjectInputStream will create
new FilePermission for each deserialization so the old init() is fine
Hi Bernd,
> > My problem is definitely not related to multi-threaded use. The test
> > shows basically the same code that we have in production that
> > experienced the problem.
>
> Of course it can be triggered single threaded. But this does not mean
> you should not fix it for concurrent use a
Just updated the test to workaround a seemingly unrelated platform
specific issue. (that only manifests on older kernels)
http://cr.openjdk.java.net/~robm/8065238/webrev.02/
-Rob
On 03/12/14 16:21, Rob McKenna wrote:
Hi folks,
Looking to fix a regression caused by 8042857. Basically the
Hi Bernd,
I will update the patch for the underscores. As to security manager I think
in most cases, FilePermission is used with it together.
>From the spec:
Absolute path:is complete in that no other information is required in
order to locate the file that it denotes
Canonical Path: is bo
Hi All,
I have updated the patch[3] to reflect all of your suggestions.
[3] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.02/
Thanks a lot!
2014-12-05 10:39 GMT+08:00 deven you :
> Hi Alan,
>
> I am not clear whether canonicalization cache enabled or disabled, however
> I think even the
54 matches
Mail list logo
