On 06/09/2015 01:41 AM, Kim Barrett wrote:
On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. wrote:
If that's the case, the documentation needs to be more clear :-) It currently
says:
"Clears this reference object. Invoking this method will not cause this object to
be enqueued."
I interpre
On 09/06/2015 02:27, joe darcy wrote:
Hello,
As an addendum to the fix-the-warnings JEP, please review this change
which fixes some bad @throws references and the like over in corba:
8086029: Fix doclint reference warnings in org.omg.CORBA
http://cr.openjdk.java.net/~darcy/8086029.0
On 6/8/2015 6:00 PM, Joseph D. Darcy wrote:
Hello jaxp and core-libs teams,
FYI, I have some in-progress changes to add Makefile support for
tiered testing:
Thanks for the info.
Joe
JDK-8075571: Support tiered testing make targets
http://cr.openjdk.java.net/~darcy/8075571.0/
Thi
Hi Kim,
Thanks for taking a look at this code.
On 06/09/2015 04:03 AM, Kim Barrett wrote:
On May 31, 2015, at 3:32 PM, Peter Levart wrote:
So, for the curious, here's the improved prototype:
http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/
And here are the
On 9.6.2015 01:31, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
old L171: case "1.9":
new L171: case "9":
On May 31, 2015, at 3:32 PM, Peter Levart wrote:
>
> So, for the curious, here's the improved prototype:
>
>
> http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/
>
> And here are the improved benchmarks (with some results inline):
>
> http://cr.openjdk.java.n
+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 Jun 8, 2015, at 9:27 PM, joe darcy wrote:
>
> Hello,
>
> As an addendum to the fix-the-warnings JEP, please r
Hello,
As an addendum to the fix-the-warnings JEP, please review this change
which fixes some bad @throws references and the like over in corba:
8086029: Fix doclint reference warnings in org.omg.CORBA
http://cr.openjdk.java.net/~darcy/8086029.0/
Patch below.
Thanks,
-Joe
--- old/s
Hello jaxp and core-libs teams,
FYI, I have some in-progress changes to add Makefile support for tiered
testing:
JDK-8075571: Support tiered testing make targets
http://cr.openjdk.java.net/~darcy/8075571.0/
This involves adding some new TEST.group definitions in the jdk and jaxp
repo
On Jun 8, 2015, at 1:45 PM, Rezaei, Mohammad A. wrote:
>
> If that's the case, the documentation needs to be more clear :-) It currently
> says:
>
> "Clears this reference object. Invoking this method will not cause this
> object to be enqueued."
>
> I interpret that as meaning the reference
Hi Volker,
Your patch reminds me the question I have about loading zip library.
In JDK 9 (and earlier release), zip library is loaded by the VM during
startup (see ClassLoader::load_zip_library). I think loadLibrary("zip")
is no longer needed to be called from System::initializeSystemClass
m
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
General comment: Not all copyright years were updated.
General comment: It looks like support for the 'patch' value is not
completely
implemented through all the Makefiles. I didn't audit for this, but
it's
On Jun 8, 2015, at 4:20 PM, Peter Levart wrote:
>
>
>
> On 06/08/2015 09:47 PM, Kim Barrett wrote:
>> On Jun 6, 2015, at 11:02 AM, Peter Levart
>> wrote:
>>
>>> I understand that it would be desirable for a finalizable object to be made
>>> "untracked" as soon as it is manually cleaned-up.
Staffan,
(1) ByteArrayInputSteram is no longer needed in ZipFile
(2) You've changed the lock region in ZipFile.getInputSteram. Given we are not
doing ByteArrayInpusteram for this method, can we just not touch this
method
and the class ZipFileInputSteram()?
The concern is that we d
On 08/06/2015 13:37, Magnus Ihse Bursie wrote:
:
The API functions in Version.java and jvm.h are not finished. The specification
in the JEP talks about a java.util.Version, that I presume will replace the
sun.misc.Version, and that will fully implement an API to access the version
string and
On 06/08/2015 09:47 PM, Kim Barrett wrote:
On Jun 6, 2015, at 11:02 AM, Peter Levart wrote:
I understand that it would be desirable for a finalizable object to be made
"untracked" as soon as it is manually cleaned-up. This would most certainly
give a relief to GC as it could reclaim such un
On Jun 6, 2015, at 11:02 AM, Peter Levart wrote:
>
> I understand that it would be desirable for a finalizable object to be made
> "untracked" as soon as it is manually cleaned-up. This would most certainly
> give a relief to GC as it could reclaim such untracked objects immediately
> like nor
If that's the case, the documentation needs to be more clear :-) It currently
says:
"Clears this reference object. Invoking this method will not cause this object
to be enqueued."
I interpret that as meaning the reference will not be put on the queue as a
part of the clear() call.
The bit o
On 06/08/2015 06:53 PM, Rezaei, Mohammad A. wrote:
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q
Shouldn't we extend the same notion to other reference types? For Weak/Soft
references, the (rough) equivalent would be a method of the kind:
public void markUnqueueable() // suggestions for better method name most
welcome!
{
this.q = ReferenceQueue.NULL;
}
This is quite useful when the
Hello,
Please review distribution of some DTLS feature tests to TLS protocol.
Some DTLS tests may also be used to test the same functionality in TLS
protocol and its versions.
It is test only improvement.
bug: https://bugs.openjdk.java.net/browse/JDK-8085979
webrev: http://cr.openjdk.java.net/
Hi,
can I please get a review at least for the part of this fix which is
common for jdk8 and jdk9. It's only a few lines in
src/share/vm/prims/jni.cpp for the hotspot repository and one line
src/java.base/share/classes/java/lang/ClassLoader.java for the jdk
repository.
Thanks,
Volker
On Tue, Ju
+1 on Nashorn changes.
-Sundar
On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote:
8 jun 2015 kl. 11:34 skrev Alan Bateman :
On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
This review request covers the main part of the work for JEP-223, the new version string format
[1]. Basically,
Looks good to me too.
Regards,
Sean.
On 08/06/15 13:30, Mark Sheppard wrote:
Hi Rob,
looks fine to me
thanks for handling this issue
regards
Mark
On 05/06/2015 15:41, Rob McKenna wrote:
Added some cleanup code around the BufferedReaders & the leftover
test files:
http://cr.openjdk.jav
> 8 jun 2015 kl. 11:34 skrev Alan Bateman :
>
>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
>> This review request covers the main part of the work for JEP-223, the new
>> version string format [1]. Basically, we'll call this release Java "9",
>> instead of Java "1.9.0".
>>
>> This patch i
Hi Rob,
looks fine to me
thanks for handling this issue
regards
Mark
On 05/06/2015 15:41, Rob McKenna wrote:
Added some cleanup code around the BufferedReaders & the leftover test
files:
http://cr.openjdk.java.net/~robm/7130985/webrev.02/
-Rob
On 03/06/15 16:20, Rob McKenna wrote:
Thanks!
On 05.06.2015 21:32, Roger Riggs wrote:
Hi Alexander,
Looks good, thanks for the updates.
Roger
On 6/5/2015 1:33 PM, alexander stepanov wrote:
Hello Lance, Roger,
Thank you for the notes, please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8081517/webrev.01/index.ht
Staffan,
Could you review a CCC request.
http://ccc.us.oracle.com/8059036
-Dmitry
On 2015-06-05 15:24, Staffan Larsen wrote:
> Thanks - this version looks good to me.
>
> /Staffan
>
>> On 5 jun 2015, at 13:00, Dmitry Samersoff
>> wrote:
>>
>> Staffan,
>>
>> Thank you for review!
>>
>> Done.
On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
This review request covers the main part of the work for JEP-223, the
new version string format [1]. Basically, we'll call this release Java
"9", instead of Java "1.9.0".
This patch is a folding of all work that has been done so far in the
branch
Hello,
Looks pretty good. Found some typos:
jdk_util.c:
99: specia_update_version
jdk-version.m4:
31: assing
124, 132: --with--version-pre-base has a dash too many? I see this
pattern consistently used though, am I missing something?
/Erik
On 2015-06-05 16:07, Magnus Ihse Bursie wrote:
Thi
Hi,
On Sun, 2015-06-07 at 10:46 +0200, Peter Levart wrote:
> Hi,
>
> On 06/05/2015 11:11 PM, Jonathan Payne wrote:
> > My problem was that finalization was not being run at all with the G1
>>collector. Not at all. That would have been fine with me because none
>>of the existing objects in the Fin
31 matches
Mail list logo
