Hi Masayoshi,
Thank you for pointing that small miss. During testing phase, I had actually
renamed "Asia/Rangoon" to "Asia/Yangon" (Asia/Rangoon entry was deleted) in
TimeZoneNames*.java and this test case was failing along with other test cases,
hence the bug ID tag was added there. But after c
Hi David,
On 10/05/2016 04:27 AM, David Holmes wrote:
Hi Peter,
Without making any comment on what you have actually done, does this
account for private interface methods correctly?
In short, yes. Class.getMethods() and Class.getMethod() only ever return
public methods. The source of Metho
On 04/10/16 22:19, Martin Buchholz wrote:
> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?
Surely you have to start somewhere: deprecatio
Interesting.
How likely is it that there will be more than one tool of a given name
available? The method name findFirst() seems relatively odd for the
lookup operation.
I'd also note that the name string to pass in are "magic". There are
no constants defined for callers to use. Since there is no
Okay, that makes sense to me! Thank you for your explanations Claes and
Stuart.
Kind regards,
Jonathan
On 5 October 2016 at 01:57, Stuart Marks wrote:
> Right, the main point of the comment is to tell the reader the constructor
> isn't superfluous, to prevent it from being cleaned up and accide
On 05/10/2016 10:54, Stephen Colebourne wrote:
Interesting.
How likely is it that there will be more than one tool of a given name
available? The method name findFirst() seems relatively odd for the
lookup operation.
I'd also note that the name string to pass in are "magic". There are
no const
Very nice,
it will greatly help gradle, maven, etc.
in com/sun/tools/javac/main/Main.java,
the other constructor should delegate its initialization to the constructor you
just add,
public Main(String name, PrintWriter out) {
this(name, out, out);
}
I wonder if findFirst() in T
Looks Ok Mandy
> On Oct 4, 2016, at 10:52 PM, Mandy Chung wrote:
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8167014/webrev.00/index.html
>
> This fixes the missing key in the resource bundle and also include the
> exception message of the invalid entry. I verified with a JAR file with
On 05/10/2016 12:10, Remi Forax wrote:
Very nice,
it will greatly help gradle, maven, etc.
in com/sun/tools/javac/main/Main.java,
the other constructor should delegate its initialization to the constructor you
just add,
public Main(String name, PrintWriter out) {
this(name, ou
It seems to be a little to JDK centric to me.
Rémi
- Mail original -
> De: "Alan Bateman"
> À: "Remi Forax" , "Jonathan Gibbons"
>
> Cc: compiler-...@openjdk.java.net, "OpenJDK Dev list"
>
> Envoyé: Mercredi 5 Octobre 2016 13:39:02
> Objet: Re: RFR: 8159855
> On 05/10/2016 12:10, Re
On 05/10/2016 13:20, fo...@univ-mlv.fr wrote:
It seems to be a little to JDK centric to me.
It supports the common case, making the advanced cases possible. Also
it's consistent with the javax.tools API. So overall then I think Jon
has this right.
-Alan
Hi,
Please review http://cr.openjdk.java.net/~sdama/8055033/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8055033
When launching java and javac from shell script, ${TESTVMOPTS}, ${TESTJAVAOPTS}
and ${TESTTOOLVMOPTS}, ${TESTJAVACOPTS} should be
passed in respectively since jtreg sets
On 05/10/2016 05:19, Mandy Chung wrote:
:
ToolProvider::findFirst(String name) can find tool providers on classpath. I
think it needs to wrap the for-loop (specifically iterating on providers) with
doPrivileged due to the stack-based permission check.
Yes, that will be needed, otherwise the
Hi Martin,
On October 4, 2016 11:19:33 PM GMT+02:00, Martin Buchholz
wrote:
>VarHandle is a reasonable replacement for FieldUpdaters, but it's not
>yet
>complete (where is accumulateAndGet?),
Seems to be a feature for me :)
I've never liked the methods that takes a lambda in FieldUpdater. If y
Hi,
can I please have a review and sponsor for the following tiny
top-level build change required for building the OpenJDK on
Linux/s390:
http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166800/
https://bugs.openjdk.java.net/browse/JDK-8166800
All this change does is to add some s390-spec
Hi,
can somebody please review the following trivial change which simply
adds a new jvm.cfg file for Linux/s390x:
http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166801/
https://bugs.openjdk.java.net/browse/JDK-8166801
This is so far the only change we need in the jdk-repository for our
I'm sure I recall an email from the past few months which proposed that
*FieldUpdater are still going to be recommended in many cases over
VarHandle because the latter is probably too low-level for casual uses.
It was (IIRC) an argument in favor of more advanced fence methods or
something like
On 10/05/2016 04:43 PM, Volker Simonis wrote:
> can somebody please review the following trivial change which simply
> adds a new jvm.cfg file for Linux/s390x:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166801/
> https://bugs.openjdk.java.net/browse/JDK-8166801
This looks okay (a
Looks good to me.
/Erik
On 2016-10-05 16:43, Volker Simonis wrote:
Hi,
can somebody please review the following trivial change which simply
adds a new jvm.cfg file for Linux/s390x:
http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166801/
https://bugs.openjdk.java.net/browse/JDK-816680
Looks ok to me. I can sponsor this tomorrow.
/Erik
On 2016-10-05 16:43, Volker Simonis wrote:
Hi,
can I please have a review and sponsor for the following tiny
top-level build change required for building the OpenJDK on
Linux/s390:
http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/81668
On 10/5/16 3:34 AM, Alan Bateman wrote:
On 05/10/2016 10:54, Stephen Colebourne wrote:
Interesting.
How likely is it that there will be more than one tool of a given name
available? The method name findFirst() seems relatively odd for the
lookup operation.
I'd also note that the name string t
That would be really great!
Could you please do it in the jdk9/hs forest as that's the place where
we will need it first (i.e. when integrating the whole s390 hotspot
platform files).
Thanks,
Volker
On Wed, Oct 5, 2016 at 5:07 PM, Erik Joelsson wrote:
> Looks ok to me. I can sponsor this tomorr
On 05/10/16 15:39, Justin Sampson wrote:
> Deprecation is stronger than that -- it says "we're going to remove
> this, or we wish we could remove it because it's broken, so you'd
> better change your code a.s.a.p." -- e.g. Thread.stop().
We're moving Java to support some new ways of working, and
Hi
Please help review
issue: https://bugs.openjdk.java.net/browse/JDK-8166261
webre: http://cr.openjdk.java.net/~sherman/8166261/webrev
The radix sanity check are missing from
hasNextByte/Short/Int/Long/BigInteger().
The only method we are doing now is useRadix(). The proposed change here
i
Deprecation is stronger than that -- it says "we're going to remove this, or we
wish we could remove it because it's broken, so you'd better change your code
a.s.a.p." -- e.g. Thread.stop(). My interpretation of Martin's comment is that
using deprecation for things that aren't actually broken ju
Stuart, thank you very much for your continued review of this changeset,
and for finding those usages of CookieManager::get in Grepcode for me. I've
applied the comment you suggested for ModuleFinder and I've also fixed the
NetscapeCookieStore typo.
Stephen, thank you for getting back about DateTi
My interpretation of Martin's comment is that using deprecation for
things that aren't actually broken just means that people will live
with lots of deprecation warnings in their code for years to
come. This could be a perfect case for introducing a weaker
alternative to deprecation, saying "here'
On 05/10/16 17:55, Vladimir Ivanov wrote:
>>> My interpretation of Martin's comment is that using deprecation for
>>> things that aren't actually broken just means that people will live
>>> with lots of deprecation warnings in their code for years to
>>> come. This could be a perfect case for intro
Looks good to me.
The test case could use IntStream.rangeClosed(Character.MIN_RADIX,
Character.MAX_RADIX) for the good radixes, instead of hard coding ints.
Naoto
On 10/5/16 8:53 AM, Xueming Shen wrote:
Hi
Please help review
issue: https://bugs.openjdk.java.net/browse/JDK-8166261
webre: h
Hi Jonathan,
As soon you got all the changes together, we can go thru them and I will
recreate the webrev…
-Patrick
> Am 05.10.2016 um 18:07 schrieb Jonathan Bluett-Duncan
> :
>
> Stuart, thank you very much for your continued review of this changeset,
> and for finding those usages of Cookie
Hi Mandy
The code changes look good.
A couple of minor suggestions
This looks good. Only thought I had is
err.genmoduleinfo.unnamed.package={0} contains unnamed package; not a valid
module to generate module-info.java
perhaps change it to:
{0} contains an unnamed package that is not
On 05/10/2016 03:52, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8167014/webrev.00/index.html
This fixes the missing key in the resource bundle and also include the
exception message of the invalid entry. I verified with a JAR file with bad
entries.
This looks okay t
Lance,
Thanks for the review. jdeps.properties updated:
err.genmoduleinfo.not.jarfile={0} is a modular JAR file that cannot be
specified with the --generate-module-info option
err.genmoduleinfo.unnamed.package={0} contains an unnamed package that is not
allowed in a module
Mandy
> On Oct 5, 2
Hi,
Please review the following changeset that creates a replacement for the
TestVersionedStream test. The previous test occasionally failed on Linux
hotspot nightly testing due to jar tool sometimes changing the order of the
entries. The new test specifically sets the order of the entries an
On 5 October 2016 at 17:07, Jonathan Bluett-Duncan
wrote:
> Stephen, thank you for getting back about DateTimeFormatter. It's not clear
> to me what should be done with
> TCKDateTimeFormatter::test_resolverFields_listOfOneNull in this case. Do I
> delete it; or do I change it to test that a null T
Hi,
Please review my fix for 8151486, "Class.forName causes memory leak".
Bug:
https://bugs.openjdk.java.net/browse/JDK-8151486
Webrev:
http://cr.openjdk.java.net/~bchristi/8151486/webrev.00/
The test case reproduces the bug as such:
With a SecurityManager enabled, a class ("ClassForName") is
Hi Chris,
Some comments,
BTW, there is a newer version of Webrev that provides convenient next
and prev links...
* sun/rmi/server/Activation.java: 1973
- I'd stick to the normal set of values for a boolean system property:
use java.lang.Boolean.getProperty("sun.rmi").
* With so many
> On Oct 5, 2016, at 12:38 PM, Brent Christian
> wrote:
>
> Hi,
>
> Please review my fix for 8151486, "Class.forName causes memory leak".
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8151486
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8151486/webrev.00/
>
Since domains is not us
Stephen,
Thanks for the quick followup clarifications. I'm not entirely sure how you'd
like to proceed; see discussion below.
Jonathan, also see below.
On 10/5/16 9:07 AM, Jonathan Bluett-Duncan wrote:
Stuart, thank you very much for your continued review of this changeset, and for
finding
Hi,
I would leave the test and code as is for the purposes of 8133273
and leave it to later to resolve 8167222. There is no compelling need
to change it.
$.02, Roger
On 10/5/2016 4:45 PM, Stuart Marks wrote:
Stephen,
Thanks for the quick followup clarifications. I'm not entirely sure
how
Typo in ClassForNameLeak.java? At line 103, "change" -> "chance"?
Naoto
On 10/5/16 12:38 PM, Brent Christian wrote:
Hi,
Please review my fix for 8151486, "Class.forName causes memory leak".
Bug:
https://bugs.openjdk.java.net/browse/JDK-8151486
Webrev:
http://cr.openjdk.java.net/~bchristi/8151
On 6/10/2016 6:19 AM, Mandy Chung wrote:
On Oct 5, 2016, at 12:38 PM, Brent Christian wrote:
Hi,
Please review my fix for 8151486, "Class.forName causes memory leak".
Bug:
https://bugs.openjdk.java.net/browse/JDK-8151486
Webrev:
http://cr.openjdk.java.net/~bchristi/8151486/webrev.00/
Sin
Yes! Good catch, thanks.
-Brent
On 10/5/16 2:08 PM, Naoto Sato wrote:
Typo in ClassForNameLeak.java? At line 103, "change" -> "chance"?
Naoto
On 10/5/16 12:38 PM, Brent Christian wrote:
Hi,
Please review my fix for 8151486, "Class.forName causes memory leak".
Bug:
https://bugs.openjdk.java
> On Oct 5, 2016, at 2:26 PM, David Holmes wrote:
>
> On 6/10/2016 6:19 AM, Mandy Chung wrote:
>>
>>
>> Since domains is not used and not intended to keep PD alive and VM maintains
>> its own cache of these initiating PD for performance, removing domains field
>> looks good to me.
>
> What
On 6/10/2016 8:55 AM, Mandy Chung wrote:
On Oct 5, 2016, at 2:26 PM, David Holmes wrote:
On 6/10/2016 6:19 AM, Mandy Chung wrote:
Since domains is not used and not intended to keep PD alive and VM maintains
its own cache of these initiating PD for performance, removing domains field
look
On 10/5/16 12:32 PM, Stephen Colebourne wrote:
On 5 October 2016 at 17:07, Jonathan Bluett-Duncan
wrote:
Stephen, thank you for getting back about DateTimeFormatter. It's not clear
to me what should be done with
TCKDateTimeFormatter::test_resolverFields_listOfOneNull in this case. Do I
delete
> On Oct 5, 2016, at 4:02 PM, David Holmes wrote:
>
> On 6/10/2016 8:55 AM, Mandy Chung wrote:
>>
>>
>> Note that PD is the protection domain of an initiating class that resolves a
>> target type T. PD is kept in T’s class loader L. It’s not the protection
>> domains of the classes defined
Hi Lucy,
On Oct 4, 2016, at 5:35 PM, Lu, Yingqi wrote:
> Thank you very much for reviewing the patch and providing the detailed
> error/warning messages. They are very helpful!
You are welcome.
> We will look into the issues and solve them in the next version of the patch.
> Test cases for O
On 6/10/2016 9:19 AM, Mandy Chung wrote:
On Oct 5, 2016, at 4:02 PM, David Holmes wrote:
On 6/10/2016 8:55 AM, Mandy Chung wrote:
Note that PD is the protection domain of an initiating class that resolves a
target type T. PD is kept in T’s class loader L. It’s not the protection
domain
49 matches
Mail list logo
