Re: RFR:8055033: Shell tests for jrunscript don't pass through VM options

[Sundararajan Athijegannathan]

+1

-Sundar


On 10/5/2016 7:51 PM, Srinivas Dama wrote:
> 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 these environment variables.
>
> Regards,
> Srinivas
>

RFR: 8167237: Jar tool can not correctly find/process the --release option if it occurs before the file list

[Steve Drach]

Hi,

Please review the changeset that fixes the problem of not “seeing” the jar tool 
—release  option if it is not preceded by anything other than gnu-style 
options.  It’s a simple one line change to process —release the same way as -C.

issue: https://bugs.openjdk.java.net/browse/JDK-8167237 
webrev: 
http://cr.openjdk.java.net/~sdrach/8167237/webrev.00/ 


Thanks,
Steve

Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Stuart Marks]

On 10/5/16 10:04 AM, Andrew Haley wrote:

On 05/10/16 17:55, Vladimir Ivanov wrote:

On 10/5/16 7:39 AM, Justin Sampson 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 introducing a weaker
alternative to deprecation, saying "here's something better that you
should really be using for new code" -- e.g. ArrayList vs. Vector.

Doesn't enhanced deprecation [1] in 9 cover that?


I can't tell.  As far as I can see there is no annotation which
covers exactly our case:

the API is flawed and is impractical to fix,

usage of the API is likely to lead to errors,

the API has been superseded by another API,

the API is obsolete,

the API is experimental and is subject to incompatible changes,

or any combination of the above.

we'd perhaps need to add

this method over here is better in most cases

...which perhaps implies obsolescent rather than obsolete.



(Vladimir, thanks for mentioning JEP 277. [1])

Andrew, all,

The list of criteria from JEP 277 isn't intended to be restrictive. It turns out 
that the criteria for deprecating something are quite subjective, and it's 
really hard to boil them down to specific reasons or attributes or whatever.


To my eye, "has been superseded by" includes "this method over here is better in 
most cases" but I'm sure we could find differences if we went looking for them.


The main contribution of JEP 277 in this area is the addition of the boolean 
forRemoval element to the @Deprecated annotation. If true, it means there is a 
plan to remove the annotated API -- for the JDK, most likely in the next major 
release. If false, it means there are no plans to remove the API at present.


To get back to this specific case, if you're looking over the shoulder of 
someone who's using *FieldUpdater, and your reaction is "you should be using 
VarHandles instead" then that's an argument for deprecating the FieldUpdaters 
with forRemoval=false.


On the other hand, if there are still things you can do with FieldUpdaters that 
you cannot (yet) do with VarHandles or some other construct, that's an argument 
for *not* deprecating the FieldUpdaters (yet).


I'm not familiar enough with the current state of things in this area to make an 
informed recommendation here.


s'marks


[1] http://openjdk.java.net/jeps/277

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

[Alexandre (Shura) Iline]

Hi, Denis,

By an agreement, @modules should go before any action tag. You use it after 
@build.

Shura

> On Oct 6, 2016, at 9:37 AM, Denis Kononenko  
> wrote:
> 
> Hi,
> 
> Could someone please review these new tests for jimage utility.
> 
> There're 5 new files containing tests to cover use cases for 'info', 'list', 
> 'extract' and other options. No new tests for 'verify'.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
> WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/
> 
> 
> Thank you,
> Denis.

[9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

[Denis Kononenko]

Hi,

Could someone please review these new tests for jimage utility.

There're 5 new files containing tests to cover use cases for 'info', 
'list', 'extract' and other options. No new tests for 'verify'.


BUGURL: https://bugs.openjdk.java.net/browse/JDK-8167240
WEBREV: http://cr.openjdk.java.net/~dkononenko/8167240/webrev.00/


Thank you,
Denis.

Re: RFR: 8163984: Fix license and copyright headers in jdk9 under test/lib

[Stanislav Smirnov]

adding core-libs-dev mailing list, since my change affect some files for 
testing APIs in java.util.function

Best regards,
Stanislav Smirnov


> On 05 Oct 2016, at 19:44, Stanislav Smirnov  
> wrote:
> 
> Hi,
> 
> Please review this fix for JDK-8163984 
> .
> This one is similar to another one, I have sent earlier.
> Legal notices and Oracle copyrights were updated (white and blank space, 
> commas) in tests files under test/lib for uniformity to meet Oracle 
> requirements.
> 
> There are two files from test/lib/jdk do I need to include jdk9_dev mailing 
> list?
> 
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8163984 
> 
> Webrev: http://cr.openjdk.java.net/~stsmirno/8163984/webrev.00/ 
> 
> Best regards,
> Stanislav Smirnov
> 
> 
> 
> 
> 

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

[Stephen Colebourne]

On 6 October 2016 at 00:00, Stuart Marks  wrote:
>> I think you should perform no change to DateTimeFormatter (other than
>> a comment) as part of this changeset. The behaviour of that
>> DateTimeFormatter method is subtle, and I now suspect that what we
>> have there might be the best option.
>
> I had recommended removing the comment from DateTimeFormatter, but if
> Stephen wants the comment in, that's fine with me. In fact I'll defer to
> what Stephen (and Roger Riggs) want with this code, since they're the
> maintainers.

I think it makes sense to leave the new comment in. All further change
should be under 8167222.

Stephen