RE: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Iris Clark]

Hi, Volker.

Sorry for the delay. 

> Ping - shouldn't we fix this issue before JDK 9 Feature Complete?

Ideally, yes.  I am hoping to get this resolved in the next few weeks. 

My first priority for Verona is JDK-8144062 which moves jdk.Version into a 
standard API (Alan mentioned this bugid earlier in this thread).  That 
absolutely must be completed before Feature Complete next month.

Thanks,
iris

-Original Message-
From: Volker Simonis [mailto:volker.simo...@gmail.com] 
Sent: Wednesday, April 27, 2016 1:28 AM
To: Iris Clark
Cc: Java Core Libs; verona-...@openjdk.java.net; Alex Buckley; Kumar 
Srinivasan; Marvin Ma
Subject: Re: RFR(XXS): 8149519: Investigate implementation of 
java.specification.version

Ping - shouldn't we fix this issue before JDK 9 Feature Complete?

Could you please also comment on my remarks regarding the relation of
java.lang.Package.getSpecificationVersion() to JEP and 223 and and my question 
why the Version class is not in a standard java package.

Thank you and best regards,
Volker


On Thu, Apr 7, 2016 at 12:11 PM, Volker Simonis  
wrote:
> On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark  wrote:
>> Hi, Volker.
>>
>> Sorry for the delay.  I agree that the old implementation isn't quite 
>> correct.  I can't see us potentially having a JCP MR for a security or patch 
>> release (9.0.0.X and 9.0.X respectively).
>>
>> I could see a MR for an very unusual minor release (9.X).  If we had an MR 
>> there's no guarantee that we'd need to change the java.specification.version 
>> system property.   However, in the event that we did need to change the 
>> java.specification.version, it should match that release's $MAJOR.$MINOR, 
>> even if it meant that we had a sequence of specification version numbers 
>> with gaps.
>>
>> As an example, let's say that JDK 9 is released via umbrella JSR with 
>> java.specification.value of "9".  The system property would remain at "9" 
>> for all releases regardless of type until we choose to have a MR.  Should 
>> that MR occur while we're working on minor release 9.3.X and there is a need 
>> to change the value of java.specification.value, it would become "9.3" and 
>> would remain so in every release until the next MR.
>>
>> While we haven't changed the system property recently, I think that we need 
>> to future-proof ourselves a little bit for MRs as described above.
>>
>> Assuming that we change the syntax of java.specification.version to 
>> $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need 
>> to make a similar change to the syntax of 
>> java.vm.specification.version.  [ Note that in the current 
>> implementation, I believe that the values of 
>> java.specification.version and java.vm.specification.version are tied 
>> to each other. ]
>>
>> Changing the syntax of java{.vm}?specification.version requires a CCC which 
>> I will file once we have agreement on the necessary changes.
>>
>
> Hi Iris,
>
> thanks for your comments. I don't think that using $MAJOR.$MINOR for 
> java.specification.version is a good solution. As far as I understand,  
> JEP 223 (i.e. the new version scheme) is an Oracle/OpenJDK 
> implementation detail. There is no JSR for this and it won't be 
> enforced trough a JCK/TCK test (please correct me if I'm wrong). The 
> new versioning schema references the JCP in that is says that the 
> $MAJOR number corresponds to the "Java SE Platform Specification"
> number as specified by the JCP in the corresponding JSR. But not vice 
> versa - i.e. there's no JSR referencing JEP 223.
>
> JEP 223 also says that the $MINOR number will be increased if this is 
> mandated by a Maintenance Release of the relevant Platform 
> Specification (by the JCP). But as you correctly noticed, in reality, 
> $MINOR is expected to be increased frequently compared to the number 
> of Java SE Maintenance Releases (if there will be any at all). So if 
> the JCP should decide to publish a Maintenance Release, why should it 
> name if after the then actual $MINOR update release number of the 
> Oracle/OpenJDK. I think a natural choice for such a MR would be "9.1", 
> no difference at which update release version Oracle/OpenJDK will be 
> at that time.
>
> So I think it would be best to decouple java.specification.version 
> from the Java versioning schema. We can start with 
> java.specification.version == $MAJOR. If there should be a MR 
> sometimes in the future, we can just set java.specification.version to 
> the version number of that MR, whatever that will be. That's exactly 
> what this change is about.
>
> Regarding the value of java.vm.specification.version I'm not sure what 
> it actually means at all. Until Java 1.6, 
> java.vm.specification.version has always been "1.0", while 
> java.specification.version has changed from 1.4, to 1.5 and 1.6 
> (notice that java.specification.version has never been changed to 
> 1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting with 
> Java 7, java.vm.specification.v

Re: RFR(m): 8140281 deprecate Optional.get()

[Stuart Marks]

On 4/27/16 1:39 AM, Dr Heinz M. Kabutz wrote:
thanks for these excellent examples of where Optional.get() is being used 
incorrectly in the JDK.  I would like to publish a Java Specialists' 
Newsletter about this topic and hopefully educate at least a part of the Java 
proletariat on how to do it correctly.  To my embarassment, this is the first 
time that I've /seen/ Optional.ifPresent(), so I include myself amongst the 
proles.  I think it was just too close to Optional.isPresent() and I just 
overlooked it.  However, the longer, clumsier name would not IMHO make any 
difference.  I would rather ask the IDE vendors to build in autofix mechanisms 
to transform the code in these examples to what it should look like.
You're welcome. I'm also a bit embarrassed at finding this code in the JDK. I 
guess we need to do some more internal education.


On the name, I'd be happy to find a less clumsy name that conveys the 
programmer's assertion that a value is always present. I also think it's 
reasonable, independently of any deprecation/renaming, for IDE vendors to add 
rule checkers that attempt to detect unsafe uses of Optional. I'm a bit 
skeptical of whether it's possible for there to be automatic fixes, but 
detection would be a good step forward.
Now a code style question.  Let's say that I get back an Optional 
and I currently do the following with it:


Optional prime =  ...
if (prime.isPresent()) {
  System.out.println("Prime is " + prime.get());
} else {
  System.out.println("Prime not found");
}
Assuming the Optional came from a method called findPrime(), I'd 
rewrite this code as follows:


System.out.println(findPrime().map(p -> "Prime is " + p)
  .orElse("Prime not found"));

Is there a better way of doing this?  We'd almost need a 
ifPresentElse(Consumer consumer, Runnable action) method I guess.

Close. In JDK 9 we added

ifPresentOrElse(Consumer action, Runnable emptyAction)

This is useful if you really need to perform separate actions in the different 
cases, instead of just substituting or transforming values.
Now, another question, do I have your permission to reference the examples of 
incorrect usage below and quote you on how it should be done in my newsletter?
Sure, I'd love to see your writeup on this. This is all open source and open 
email logs, so there aren't any secrets here. There are a couple caveats though:


1) There are places in the JDK code where special conditions apply. For example, 
early in startup, we avoid using lambdas because it drags in all the lambda 
support code prematurely. In such cases my suggested changes wouldn't be 
appropriate. I think this kind of issue doesn't apply to most applications and 
libraries, though.


2) I don't claim to have the final word on the "right" way to use Optional. It 
is, unfortunately, all too easy to find examples of poor usage of 
Optional.get(). I've suggested some fixes that I like, but others might prefer 
different approaches that are equally valid.


s'marks

Re: JEP 118 Parameter Names by default

[Michael Hixson]

I found this old email reply to someone who asked a similar question.
Maybe the same reasoning still applies:

http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000201.html

-Michael

On Wed, Apr 27, 2016 at 1:18 PM, Steven Schlansker
 wrote:
> Hi core-libs-dev,
>
> Apologies in advance if this is the wrong list, I was torn between this
> one and compiler-dev, but I'm already subscribed here so we'll try this first 
> :)
>
> I am trying to understand why the javac '-parameters' option is not enabled by
> default.
>
> Normally it would not be too onerous, but due to some limitations in e.g. 
> Maven
> it is surprisingly difficult to configure correctly in a world where you must
> build code that both targets e.g. 1.8 and 1.7 (and soon 1.9):
> http://mail-archives.apache.org/mod_mbox/maven-dev/201604.mbox/browser
>
> While I am happy to work with the Maven project to improve their support
> for sending compiler arguments more flexibly, I did wonder -- why is
> this feature not on by default?
>
> I did some brief searching and was unable to come up with any downside,
> but maybe I missed something obvious?  Can we turn it on by default for Java 
> 9?
>
> Thanks for humoring me,
> Steven
>
>

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[John Rose]

On Apr 27, 2016, at 4:20 PM, Paul Sandoz  wrote:
> 
> 
>> On 27 Apr 2016, at 15:26, John Rose  wrote:
>> 
>> Diction Note: Reified X means X wasn't real (in some sense) until now. As in 
>> non-reified types, which are not real at runtime because the static compiler 
>> discarded them.
>> 
> 
> I suggested reified because i thought it fit with the notion of making 
> something abstract more concrete, but perhaps this just confuses matters?

It's the real name, but since it already exists (because that's how it is 
stored) it isn't really reified, it's just revealed.

This API uses the term "real name" for an almost identical phenomenon (target 
of a sym-link in a file system):

https://docs.oracle.com/javase/8/docs/api/java/nio/file/Path.html#toRealPath-java.nio.file.LinkOption...-

In a versioned jar, the logical names are sometimes mapped to other names under 
which the elements are actually stored.
Thus, they behave like sym-links.  (But with a bit of control context thrown 
in, the active version.)

On old-fashioned file systems with real version numbers, the Common Lisp 
function TRUENAME does exactly what you are trying to do here.

http://www.mathcs.duq.edu/simon/Gcl/gcl_1141.html

(And in some way, we are sliding down the slope toward re-inventing those file 
systems, aren't we?)

The older pre-nio API for File calls it "getCanonicalPath", but I think "true 
name" is better than
"canonical name", since "canonical" means "follows the rules", rather than what 
we need in this case,
which is "where it really is stored".

http://docs.oracle.com/javase/8/docs/api/java/io/File.html#getCanonicalPath--

> 
>> In this case it appears you are simply exposing a translated name, not 
>> making it real for the first time.
>> 
>> If this is true, I think you want to say "true name" or "real name" or 
>> "translated name", not "reified name”.
> 
> or “versioned name" would work for me.

I'm just whinging about the term "reified" which doesn't seem to work, 
logically.

"Versioned name" would work for me too.  But "true name" has the two good 
precedents cited above.

— John

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[Paul Sandoz]

> On 27 Apr 2016, at 15:26, John Rose  wrote:
> 
> Diction Note: Reified X means X wasn't real (in some sense) until now. As in 
> non-reified types, which are not real at runtime because the static compiler 
> discarded them.
> 

I suggested reified because i thought it fit with the notion of making 
something abstract more concrete, but perhaps this just confuses matters?


> In this case it appears you are simply exposing a translated name, not making 
> it real for the first time.
> 
> If this is true, I think you want to say "true name" or "real name" or 
> "translated name", not "reified name”.

or “versioned name" would work for me.

Paul.

Re: RFR (JAXP) 8154220 : Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException

[huizhe wang]

Thanks!

Best,
Joe

On 4/27/2016 3:51 PM, Lance Andersen wrote:

Looks better joe

Best
Lance
On Apr 27, 2016, at 6:45 PM, huizhe wang > wrote:



On 4/27/2016 12:42 PM, Lance Andersen wrote:

Hi Joe,

Overall it is OK.

I might have considered using @Beforeclass vs a static block in the 
test.  Also, once you check the property, you could then set your 
offset and avoid the extra check and need for the isWindows boolean. 
 That is more of a style choice though.


Thanks Lance. Updated using @Beforeclass to set up a filepath field.

http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/



I am OK either way,  I just try to leverage the testng annotations 
when I can.


Yeah, make sense.

Best,
Joe



Best
Lance
On Apr 27, 2016, at 3:06 PM, huizhe wang > wrote:


Hi,

Please review the following issue and fix:

JBS: https://bugs.openjdk.java.net/browse/JDK-8154220
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/ 



Thanks,
Joe



 



Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 









Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR (JAXP) 8154220 : Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException

[Lance Andersen]

Looks better joe

Best
Lance
> On Apr 27, 2016, at 6:45 PM, huizhe wang  wrote:
> 
> 
> On 4/27/2016 12:42 PM, Lance Andersen wrote:
>> Hi Joe,
>> 
>> Overall it is OK.
>> 
>> I might have considered using @Beforeclass vs a static block in the test.  
>> Also, once you check the property, you could then set your offset and avoid 
>> the extra check and need for the isWindows boolean.  That is more of a style 
>> choice though.
> 
> Thanks Lance. Updated using @Beforeclass to set up a filepath field.
> 
> http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/ 
> 
> 
>> 
>> I am OK either way,  I just try to leverage the testng annotations when I 
>> can.
> 
> Yeah, make sense.
> 
> Best,
> Joe
> 
>> 
>> Best
>> Lance
>>> On Apr 27, 2016, at 3:06 PM, huizhe wang >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the following issue and fix:
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8154220 
>>> 
>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/ 
>>> 
>>> 
>>> Thanks,
>>> Joe
>>> 
>> 
>>  
>> 
>>   
>> 
>>  Lance Andersen| 
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
>> 
>> 
>> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR (JAXP) 8154220 : Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException

[huizhe wang]

On 4/27/2016 12:42 PM, Lance Andersen wrote:

Hi Joe,

Overall it is OK.

I might have considered using @Beforeclass vs a static block in the 
test.  Also, once you check the property, you could then set your 
offset and avoid the extra check and need for the isWindows boolean. 
 That is more of a style choice though.


Thanks Lance. Updated using @Beforeclass to set up a filepath field.

http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/



I am OK either way,  I just try to leverage the testng annotations 
when I can.


Yeah, make sense.

Best,
Joe



Best
Lance
On Apr 27, 2016, at 3:06 PM, huizhe wang > wrote:


Hi,

Please review the following issue and fix:

JBS: https://bugs.openjdk.java.net/browse/JDK-8154220
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/ 



Thanks,
Joe





Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[John Rose]

Diction Note: Reified X means X wasn't real (in some sense) until now. As in 
non-reified types, which are not real at runtime because the static compiler 
discarded them. 

In this case it appears you are simply exposing a translated name, not making 
it real for the first time. 

If this is true, I think you want to say "true name" or "real name" or 
"translated name", not "reified name".

– John

> On Apr 27, 2016, at 2:58 PM, Steve Drach  wrote:
> 
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 
> 
> 
> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ 
> 
> 
> This changeset causes the URL returned from a ClassLoader.getResource(name) 
> invocation to be reified, that is the URL is a direct pointer to either a 
> versioned or unversioned entry in the jar file. The patch also assures that 
> jar URL’s are always processed by the URLClassPath.JarLoader.  The 
> MultiReleaseJarURLConnection test was enhanced to demonstrate that reified 
> URLs are returned.  The SimpleHttpServer test helper class was moved into 
> it’s own file.

RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[Steve Drach]

Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 


Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ 


This changeset causes the URL returned from a ClassLoader.getResource(name) 
invocation to be reified, that is the URL is a direct pointer to either a 
versioned or unversioned entry in the jar file. The patch also assures that jar 
URL’s are always processed by the URLClassPath.JarLoader.  The 
MultiReleaseJarURLConnection test was enhanced to demonstrate that reified URLs 
are returned.  The SimpleHttpServer test helper class was moved into it’s own 
file.

Re: RFR [9] 8153737: Unsupported Module

[Chris Hegarty]

Hi Rio,


> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner 
> class
> 
> in jdk.unsupported module:
> 
> java.lang.NoClassDefFoundError: 
> sun/reflect/ReflectionFactory$GetReflectionFactoryAction
>at 
> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-internal/BuiltinClassLoader.java:366)
>at 
> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-internal/ClassLoaders.java:184)
>at 
> java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
>at 
> org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47)

GetReflectionFactoryAction is a convenience class for acquiring
the capability to instantiate reflective objects.  It’s code is:

As part of JEP 260, we retained the single getReflectionFactory 
accessor. You can replace your usage with the following:

 PrivilegedAction pa = new 
PrivilegedAction() {
   @Override
   public ReflectionFactory run() {
   return ReflectionFactory.getReflectionFactory();
   }
   };

-Chris.

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

[Peter Levart]

Hi Joe,


On 04/22/2016 07:47 PM, joe darcy wrote:

Hi Roger,

Per other discussion in the thread, no new method will be introduced.

The area owners will need to cleanup this usage of this method since 
it may involve restructuring of catch blocks, etc., since the 
recommended approach has different exception behavior.


The functionality of Class.newInstance() might have a logical 
replacement in existing API (getConstructor().newInstance()) but this 
replacement is not equivalent performance-wise.


As mentioned, Class.newInstance() has a special cache for constructor 
and caller that speeds up repeated invocations from the same caller by 
skipping access checks. Suppose there exist a public API like the following:


public  T instantiateAndSetup(Class clazz) { ... }

...that uses clazz.newInstance() inside the implementation to construct 
new instances of passed-in classes. Suppose such API is widely used and 
is performance sensitive. What is the maintainer of that API supposed to 
do when Class.newInstance() is deprecated and later removed with no 
replacement? He has the following choices:


- deprecate his API and provide a replacement taking a Constructor 
object instead of a Class object and leave the responsibility of 
Constructor(s) caching to the user of the API.
- maintain an internal cache of Class -> Constructor in his 
implementation of the API. Such cache is not trivial as it must weakly 
reference Class and Constructor objects or ClassLoader leaks are 
possible and it has its own overhead.


Wouldn't it be possible to just change the specification of the method 
to wrap checked exceptions with an unchecked exception (such as 
UdeclaredThrowableException)? I think this would have a minimal impact 
on existing code as constructors usually don't throw checked exceptions 
- in particular the no-argument constructors.


Is there any evidence that such no-argument constructors exist at all, 
let alone that they are invoked via Class.newInstance() ?


Regards, Peter




Thanks,

-Joe

On 4/22/2016 8:33 AM, Roger Riggs wrote:

Hi Joe,

Wouldn't it be less make work to introduce the new method, replace 
the current one where appropriate
and then deprecate the existing method?  As it is, you/someone is 
going to make a second pass

over all the same files.

Roger


On 4/21/2016 12:25 PM, joe darcy wrote:

Hello,

After a generally positive reception, please review the webrev to 
implement the deprecation of Class.newInstance and the suppression 
of the resulting warnings:


http://cr.openjdk.java.net/~darcy/6850612.0/

There are also some changes in the langtools repo; I'll send a 
separate review request for those changes to compiler-dev.


I'll also forward this review request to other areas with affected 
code.


Thanks,

-Joe

On 4/17/2016 10:31 AM, joe darcy wrote:

Hello,

With talk of deprecation in the air [1], I thought it would be a 
fine time to examine one of the bugs on my list


JDK-6850612: Deprecate Class.newInstance since it violates the 
checked exception language contract


As the title of the bug implies, The Class.newInstance method 
knowingly violates the checking exception contract. This has long 
been documented in its specification:


Note that this method propagates any exception thrown by the 
nullary constructor, including a checked exception. Use of this 
method effectively bypasses the compile-time exception checking 
that would otherwise be performed by the compiler. The 
Constructor.newInstance method avoids this problem by wrapping any 
exception thrown by the constructor in a (checked) 
InvocationTargetException.


Roughly, the fix would be to turn the text of this note into the 
@deprecated text and to add a @Deprecated(since="9") annotation to 
the method. There are a few dozen uses of the method in the JDK 
that would have to be @SuppressWarning-ed or otherwise updated.


Thoughts on the appropriateness of deprecating this method at this 
time?


Comments on the bug have suggested that besides deprecating the 
method, a new method on Class could be introduced, 
newInstanceWithProperExceptionBehavior, that had the same signature 
but wrapped exceptions thrown by the constructor call in the same 
way Constructor.newInstance does.


Thanks,

-Joe

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html

Re: RFR [9] 8153737: Unsupported Module

[Richard Opalka]

We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction 
inner class


in jdk.unsupported module:

java.lang.NoClassDefFoundError: 
sun/reflect/ReflectionFactory$GetReflectionFactoryAction
at 
jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-internal/BuiltinClassLoader.java:366)
at 
jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-internal/ClassLoaders.java:184)
at 
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
at 
org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47)


Rio


On 04/08/2016 05:48 PM, Mandy Chung wrote:

On Apr 8, 2016, at 8:35 AM, Chris Hegarty  wrote:


I moved the tests from a directory named 'jdk.unsupported' to
unsupported', as other tests, in test/tools/jdeps/module, use
test/tools/jdeps as a test library, and the directory/test lib
name is conflicting with the module name. jtreg fails immediately.
The updates I made check that jdeps identifies both jdk.internal.misc
and sun.misc Unsafe as internal APIs.

Thanks for explaining why you did the rename.  Your change now makes sense to 
me.  I may reorganize the jdeps tests to avoid the module name you ran into in 
the future.

All looks good.

Mandy

JEP 118 Parameter Names by default

[Steven Schlansker]

Hi core-libs-dev,

Apologies in advance if this is the wrong list, I was torn between this
one and compiler-dev, but I'm already subscribed here so we'll try this first :)

I am trying to understand why the javac '-parameters' option is not enabled by
default.

Normally it would not be too onerous, but due to some limitations in e.g. Maven
it is surprisingly difficult to configure correctly in a world where you must
build code that both targets e.g. 1.8 and 1.7 (and soon 1.9):
http://mail-archives.apache.org/mod_mbox/maven-dev/201604.mbox/browser

While I am happy to work with the Maven project to improve their support
for sending compiler arguments more flexibly, I did wonder -- why is
this feature not on by default?

I did some brief searching and was unable to come up with any downside,
but maybe I missed something obvious?  Can we turn it on by default for Java 9?

Thanks for humoring me,
Steven

Re: RFR (JAXP) 8154220 : Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException

[Lance Andersen]

Hi Joe,

Overall it is OK.

I might have considered using @Beforeclass vs a static block in the test.  
Also, once you check the property, you could then set your offset and avoid the 
extra check and need for the isWindows boolean.  That is more of a style choice 
though.

I am OK either way,  I just try to leverage the testng annotations when I can.

Best
Lance
> On Apr 27, 2016, at 3:06 PM, huizhe wang  wrote:
> 
> Hi,
> 
> Please review the following issue and fix:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8154220
> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/
> 
> Thanks,
> Joe
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RFR (JAXP) 8154220 : Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException

[huizhe wang]

Hi,

Please review the following issue and fix:

JBS: https://bugs.openjdk.java.net/browse/JDK-8154220
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8154220/webrev/

Thanks,
Joe

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

[Mandy Chung]

Updated webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.01/index.html

I added a new StackFrame::getByteCodeIndex method to return bci and 
updatedgetFileName and getLineNumber to have the same returned type as in 
StackTraceElement.  From usage perspective, the caller has to prepare and 
handle the information is unavailable and I think it would typically log some 
token to represent the unavailable case and might well use null and negative 
value. This patch would save the creation of short-lived Optional object that 
might help logging filename/linenumber case.

I’m working on a new test to verify bci and line number to be included in the 
next revision.

Mandy

> On Apr 11, 2016, at 2:22 PM, Mandy Chung  wrote:
> 
> Webrev at:
>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html
> 
> StackFrame::getFileName and StackFrame::getLineNumber are originally proposed 
> with the view of any stack walking code can migrate to the StackWalker API 
> without the use of StackTraceElement. 
> 
> File name and line number are useful for debugging and troubleshooting 
> purpose. It has additional overhead to map from a method and BCI to look up 
> the file name and line number. 
> 
> StackFrame::toStackTraceElement method returns StackTraceElement that 
> includes the file name and line number. There is no particular benefit to 
> duplicate getFileName and getLineNumber methods in StackFrame. It is 
> equivalently convenient to call 
> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). 
> 
> This patch proposes to remove StackFrame::getFileName and 
> StackFrame::getLineNumber methods since such information can be obtained from 
> StackFrame.toStackTraceElement().
> 
> Mandy

Re: RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

[Chris Hegarty]

On 27 Apr 2016, at 11:33, Aleksey Shipilev  wrote:

> Hi,
> 
> Please review this tiny spec improvement that syncs up JLS and
> java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks
> down the implementation details for String concat (e.g. usage of
> StringBuilder):
>  http://cr.openjdk.java.net/~shade/8155215/webrev.00/

This looks good. Should is say “Java SE” API rather than “JDK API” ?

-Chris.

Re: RFR(m): 8140281 deprecate Optional.get()

[Mario Torre]

2016-04-27 19:43 GMT+02:00 Maurizio Cimadamore :
>
>
> On 27/04/16 09:31, Andrew Haley wrote:
>>
>> what they say makes
>> sense to me
>
> It makes sense to me to. Having an innocently-named get() method throwing an
> exception is not something you see everyday. And in this case it's doubly
> confusing because one could imagine also a different behavior (i.e. return
> null if no object is there). So I'm in favor for making things clearer by
> choosing a more explicit name (whether the proposed one or a better one).

This thread looks funny, so I chime in too.

+1 for the change overall, I really do like when methods are self
explanatory and I don't need to read the manual ;)

But please consider the getWhenPresent sounds to me like it's trying
to suggest that the method would block and returns *when* the value is
present, not sure if it's just me and the fact that I'm not native
english speaker though.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

RE: RFR(m): 8140281 deprecate Optional.get()

[Timo Kinnunen]

Hi, 

Looking at real problems is good, and in this case there’s quite a few layers 
of issues underlying issues indeed. First the problem of the “get” method 
underlain by the deprecation issue. As mentioned, the name “get” is a good, 
proper name for a method. There are no problems with the name itself. The 
problem is with the implementation backing this name not matching what it 
should obviously-from-just-reading-the-name be really doing. 

A misbehaving implementation is nothing new and is a relatively easy problem to 
fix. First, not throwing a previously thrown exception should not break too 
many consumers. Likewise returning a previously not returned value won’t 
deprive consumers of any values they are relying on getting. Still, some 
consumers might be broken. On balance, if the evidence presented earlier the 
thread holds true then many (perhaps quite a few more!) consumers -- currently 
silently broken -- would get silently mended.

As a bonus, returning null and not throwing a NSEE doesn’t disqualify Optional 
from becoming a value type in future nor prevent it from containing a future 
value type. The solution to how this is to be done is left as an exercise for 
the reader. 😊 But yeah, there is a solution.

Against this backdrop the suggestion to deprecate the get-method without 
changing its implementation in essence changes the thrown 
NoSuchElementException into a quasi-checked exception via creative (ab)use of 
the deprecation mechanism. That leaves the class with just as many methods with 
problems as there were in the beginning. If the get-method is then recreated 
under a different name with all the problems in the implementation left 
unfixed, Optional ends up with 1 more method with problems than what it started 
with. This way of “fixing” the problem seems to me like a workaround to deeper 
issues with the language.




-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10

From: Brian Goetz
Sent: Wednesday, April 27, 2016 16:49
To: Stuart Marks; Stephen Colebourne
Cc: core-libs-dev
Subject: Re: RFR(m): 8140281 deprecate Optional.get()

So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But 
let's talk about a real underlying issue instead, mkay?

While no one has actually said this (I guess everyone was too busy 
slinging rhetoric and raising strawman objections) there is at least one 
real issue here, which is:

  - I have a library
  - I want it to be free of deprecation warnings
  - I want it to compile cleanly on platform versions N...N+k, where 
something is deprecated with an alternative in M>N, and the alternative 
does not exist in N.

That leaves the hypothetical library provider above (which I assume is 
Stephen's situation, though it was left unsaid) with some bad choices:
  - @SuppressWarnings the use everywhere
  - Compile without deprecation warnings
  - Have multiple sourcebases

I think the real issue is that @SuppressWarnings is too blunt a tool to 
be useful in this situation, so deprecation causes collateral pain for 
library developers.  If we can make the deprecation more painless for 
this class of developers (the ones disproportionately affeted), then I 
think much of the noise goes away.

On 4/27/2016 1:42 AM, Stuart Marks wrote:
> On 4/26/16 3:43 AM, Stephen Colebourne wrote:
>> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
>> would be painful and add no value.
>
> Hi Stephen,
>
> I just sent a reply [1] to Kevin B, wherein I clarified "rename."
>
> Briefly, it strictly isn't a rename. The old method would be 
> deprecated not-for-removal, and would be left in place indefinitely.
>
> Does this still create pain? If so, is there some way the proposal can 
> be modified to reduce it?
>
> s'marks

Re: RFR(m): 8140281 deprecate Optional.get()

[Maurizio Cimadamore]

On 27/04/16 09:31, Andrew Haley wrote:

what they say makes
sense to me
It makes sense to me to. Having an innocently-named get() method 
throwing an exception is not something you see everyday. And in this 
case it's doubly confusing because one could imagine also a different 
behavior (i.e. return null if no object is there). So I'm in favor for 
making things clearer by choosing a more explicit name (whether the 
proposed one or a better one).


Cheers
Maurizio

Re: RFR(m): 8140281 deprecate Optional.get()

[Andrew Haley]

On 04/27/2016 04:44 PM, Stephen Colebourne wrote:

> Better suppress warnings would be nice, and the problem statement
> below is reasonable, what concerns me more is the impact on clients
> of the Strata API. Strata uses Optional heavily - we have "done the
> right thing" and do not return null from any public methods. As
> such, a *lot* of methods return Optional. If this change happens,
> then everyone who adopts Strata today and codes against our API
> (legitimately using isPresent() followed by get() ) will suffer when
> Java 9 is released. I don't see how a better SuppressWarnings helps
> those clients.

Sure, but almost all of the uses of Optional.get() will be in the future.

This rather reminds me of the early UNIX bug report about make syntax.
The bug was that make(1) treated tab characters and spaces
differently.  This bug could have been fixed but there were about 20
users of make already, and they would have had to change their
makefiles.  And probably everyone reading this mail has suffered
because of that bug.

Andrew.

Re: RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

[Xueming Shen]

On 4/27/16 3:33 AM, Aleksey Shipilev wrote:

Hi,

Please review this tiny spec improvement that syncs up JLS and
java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks
down the implementation details for String concat (e.g. usage of
StringBuilder):
   http://cr.openjdk.java.net/~shade/8155215/webrev.00/

I'll submit CCC as soon as we agree on wording.

Thanks,
-Aleksey


looks good.

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

[joe darcy]

Hi Daniel,

Good catch! I've fixed that in my working copy of the changes.

Thanks for the careful review,

-Joe

On 4/27/2016 7:20 AM, Daniel Fuchs wrote:

Hi Joe,

Changes in java.util.logging and java.management look good.

I glanced at the rest and spotted one issue here:

http://cr.openjdk.java.net/~darcy/6850612.0/src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java.frames.html 



 615 Object o = 
Class.forName("javax.swing.text.html.parser.ParserDelegator");

 616 defaultParser = (Parser) o;

The call to newInstance() is missing at line 615

best regards,

-- daniel

On 21/04/16 18:25, joe darcy wrote:

Hello,

After a generally positive reception, please review the webrev to
implement the deprecation of Class.newInstance and the suppression of
the resulting warnings:

http://cr.openjdk.java.net/~darcy/6850612.0/

There are also some changes in the langtools repo; I'll send a separate
review request for those changes to compiler-dev.

I'll also forward this review request to other areas with affected code.

Thanks,

-Joe

On 4/17/2016 10:31 AM, joe darcy wrote:

Hello,

With talk of deprecation in the air [1], I thought it would be a fine
time to examine one of the bugs on my list

JDK-6850612: Deprecate Class.newInstance since it violates the
checked exception language contract

As the title of the bug implies, The Class.newInstance method
knowingly violates the checking exception contract. This has long been
documented in its specification:


Note that this method propagates any exception thrown by the nullary
constructor, including a checked exception. Use of this method
effectively bypasses the compile-time exception checking that would
otherwise be performed by the compiler. The Constructor.newInstance
method avoids this problem by wrapping any exception thrown by the
constructor in a (checked) InvocationTargetException.


Roughly, the fix would be to turn the text of this note into the
@deprecated text and to add a @Deprecated(since="9") annotation to the
method. There are a few dozen uses of the method in the JDK that would
have to be @SuppressWarning-ed or otherwise updated.

Thoughts on the appropriateness of deprecating this method at this 
time?


Comments on the bug have suggested that besides deprecating the
method, a new method on Class could be introduced,
newInstanceWithProperExceptionBehavior, that had the same signature
but wrapped exceptions thrown by the constructor call in the same way
Constructor.newInstance does.

Thanks,

-Joe

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html 

Re: RFR(m): 8140281 deprecate Optional.get()

[Stephen Colebourne]

Better suppress warnings would be nice, and the problem statement
below is reasonable, what concerns me more is the impact on clients of
the Strata API. Strata uses Optional heavily - we have "done the right
thing" and do not return null from any public methods. As such, a
*lot* of methods return Optional. If this change happens, then
everyone who adopts Strata today and codes against our API
(legitimately using isPresent() followed by get() ) will suffer when
Java 9 is released. I don't see how a better SuppressWarnings helps
those clients.

FWIW, I will have to consider migrating to Guava Optional if I can't
rely on a core API like JDK Optional remaining stable.


I propose that we deprecate List.get(int).
To compensate, we should add a new method getButPleaseCheckListSizeFirst(int)

The rationale is that lots of developers call get(int) without
correctly checking the list size. I estimate that 69.3724% of all
developers misuse the method.


If I thought the method needed renaming, I'd go along with this. I'm
am accepting the demise of Class.newInstance() for example, although I
think even that is a very marginal deprecation. If it seems to Kevin
that get() is the right name, and others like me agree, perhaps its
worth considering whether the change is actually appropriate?

FWIW, the best example in JSR-310 of a design mistake is
TemporalAmount.get(TemporalUnit):
http://stackoverflow.com/questions/24491243/why-cant-i-get-a-duration-in-minutes-or-hours-in-java-time/24500045#24500045
Renaming that method to unitValue(TemporalUnit) or similar would
actually be a useful change (as it is a framework method and almost
all uses of that method in application code are wrong).

Stephen


On 27 April 2016 at 15:48, Brian Goetz  wrote:
> So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But let's
> talk about a real underlying issue instead, mkay?
>
> While no one has actually said this (I guess everyone was too busy slinging
> rhetoric and raising strawman objections) there is at least one real issue
> here, which is:
>
>  - I have a library
>  - I want it to be free of deprecation warnings
>  - I want it to compile cleanly on platform versions N...N+k, where
> something is deprecated with an alternative in M>N, and the alternative does
> not exist in N.
>
> That leaves the hypothetical library provider above (which I assume is
> Stephen's situation, though it was left unsaid) with some bad choices:
>  - @SuppressWarnings the use everywhere
>  - Compile without deprecation warnings
>  - Have multiple sourcebases
>
> I think the real issue is that @SuppressWarnings is too blunt a tool to be
> useful in this situation, so deprecation causes collateral pain for library
> developers.  If we can make the deprecation more painless for this class of
> developers (the ones disproportionately affeted), then I think much of the
> noise goes away.
>
>
> On 4/27/2016 1:42 AM, Stuart Marks wrote:
>>
>> On 4/26/16 3:43 AM, Stephen Colebourne wrote:
>>>
>>> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
>>> would be painful and add no value.
>>
>>
>> Hi Stephen,
>>
>> I just sent a reply [1] to Kevin B, wherein I clarified "rename."
>>
>> Briefly, it strictly isn't a rename. The old method would be deprecated
>> not-for-removal, and would be left in place indefinitely.
>>
>> Does this still create pain? If so, is there some way the proposal can be
>> modified to reduce it?
>>
>> s'marks
>
>

Re: RFR(m): 8140281 deprecate Optional.get()

[Brian Goetz]

So far, this thread has been mostly "I DON'T LIKE THIS CHANGE." But 
let's talk about a real underlying issue instead, mkay?


While no one has actually said this (I guess everyone was too busy 
slinging rhetoric and raising strawman objections) there is at least one 
real issue here, which is:


 - I have a library
 - I want it to be free of deprecation warnings
 - I want it to compile cleanly on platform versions N...N+k, where 
something is deprecated with an alternative in M>N, and the alternative 
does not exist in N.


That leaves the hypothetical library provider above (which I assume is 
Stephen's situation, though it was left unsaid) with some bad choices:

 - @SuppressWarnings the use everywhere
 - Compile without deprecation warnings
 - Have multiple sourcebases

I think the real issue is that @SuppressWarnings is too blunt a tool to 
be useful in this situation, so deprecation causes collateral pain for 
library developers.  If we can make the deprecation more painless for 
this class of developers (the ones disproportionately affeted), then I 
think much of the noise goes away.


On 4/27/2016 1:42 AM, Stuart Marks wrote:

On 4/26/16 3:43 AM, Stephen Colebourne wrote:

In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
would be painful and add no value.


Hi Stephen,

I just sent a reply [1] to Kevin B, wherein I clarified "rename."

Briefly, it strictly isn't a rename. The old method would be 
deprecated not-for-removal, and would be left in place indefinitely.


Does this still create pain? If so, is there some way the proposal can 
be modified to reduce it?


s'marks

Re: JDK-8155102: Process.toString could include pid, isAlive, exitStatus

[Roger Riggs]

Hi Andrey,

Take a look at the OpenJDK processes, there are a few things you can read
about how to contribute [1] and the developers guide [2].

The changes would be localized to the ProcessImpl classes for unix and 
windows.


Roger


[1] http://openjdk.java.net/contribute/
[2] http://openjdk.java.net/guide/

On 4/26/2016 1:45 PM, Andrey Dyachkov wrote:

Hi,

I would like to familiarise myself with contributing process.
Can I take this bug to fix?

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

[Daniel Fuchs]

Hi Joe,

Changes in java.util.logging and java.management look good.

I glanced at the rest and spotted one issue here:

http://cr.openjdk.java.net/~darcy/6850612.0/src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java.frames.html

 615 Object o = 
Class.forName("javax.swing.text.html.parser.ParserDelegator");

 616 defaultParser = (Parser) o;

The call to newInstance() is missing at line 615

best regards,

-- daniel

On 21/04/16 18:25, joe darcy wrote:

Hello,

After a generally positive reception, please review the webrev to
implement the deprecation of Class.newInstance and the suppression of
the resulting warnings:

http://cr.openjdk.java.net/~darcy/6850612.0/

There are also some changes in the langtools repo; I'll send a separate
review request for those changes to compiler-dev.

I'll also forward this review request to other areas with affected code.

Thanks,

-Joe

On 4/17/2016 10:31 AM, joe darcy wrote:

Hello,

With talk of deprecation in the air [1], I thought it would be a fine
time to examine one of the bugs on my list

JDK-6850612: Deprecate Class.newInstance since it violates the
checked exception language contract

As the title of the bug implies, The Class.newInstance method
knowingly violates the checking exception contract. This has long been
documented in its specification:


Note that this method propagates any exception thrown by the nullary
constructor, including a checked exception. Use of this method
effectively bypasses the compile-time exception checking that would
otherwise be performed by the compiler. The Constructor.newInstance
method avoids this problem by wrapping any exception thrown by the
constructor in a (checked) InvocationTargetException.


Roughly, the fix would be to turn the text of this note into the
@deprecated text and to add a @Deprecated(since="9") annotation to the
method. There are a few dozen uses of the method in the JDK that would
have to be @SuppressWarning-ed or otherwise updated.

Thoughts on the appropriateness of deprecating this method at this time?

Comments on the bug have suggested that besides deprecating the
method, a new method on Class could be introduced,
newInstanceWithProperExceptionBehavior, that had the same signature
but wrapped exceptions thrown by the constructor call in the same way
Constructor.newInstance does.

Thanks,

-Joe

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html

Re: RFR(m): 8140281 deprecate Optional.get()

[Vitaly Davidovich]

I really don't know what to say -- "near 100% use error rate"? I don't know
that person nor whom he's representing when he says "our", but that's
appalling.  This has nothing to do with "ivory tower cranks", as he put
it.  Did you ask him why he thinks their use error rate is so high?

On Wed, Apr 27, 2016 at 9:42 AM, Brian Goetz  wrote:

> Not that you'll find an additional voice compelling, but here's some
> additional anecdotal evidence from another channel:
>https://twitter.com/jeffreymaxwell/status/725313986053427200
>
>
>
> On 4/26/2016 8:16 PM, Vitaly Davidovich wrote:
>
> I'm really grasping at straws here and asking for something quantitative
> to substantiate this deprecation plan.  As it stands, there is hearsay and
> some stackoverflow links - surely going through with this (and inflicting
> some level of pain on folks who don't care for this) deserves something a
> bit better? Brian mentioned that one criticism often heard is mistakes
> aren't corrected - I fully believe that's true.  But this may end up being
> one of those "they want to correct mistakes and THIS is what they chose??!"
> things.  I understand the appeal in "correcting" this given it's a
> relatively new addition, but I don't think it'll go over well.
>
> On Tuesday, April 26, 2016, Paul Benedict < 
> pbened...@apache.org> wrote:
>
>> Are you asking Brian to set up another survey monkey for the masses? I
>> expect a happy silent majority and a raucous minority just based on
>> past results. :-)
>> On Apr 26, 2016 6:38 PM, "Vitaly Davidovich"  wrote:
>>
>> I've yet to hear one supporter on this thread besides yourself and Stuart.
>> Is there some usability survey or something that actually indicates a
>> significant sample of people don't like the name? Guava Optional behaves
>> and is named the same way, and I've not heard anyone complain about that
>> (I
>> and many people I know used it for years).
>>
>> I think the conversation would be *maybe* different if picking a name for
>> a
>> new thing, but the deprecation churn here adds no value, IMO, and is going
>> to be viewed as an annoyance by a large swath of people.
>>
>> On Tuesday, April 26, 2016, Brian Goetz  wrote:
>>
>> > As the person who chose the original (terrible) name, let me weigh in...
>> >
>> > I think calling this method "get()" was our biggest API mistake in Java
>> > 8.  Now, one could argue that, if this is the biggest mistake we made,
>> then
>> > we did pretty darn good.  Which may be true, but ... make no mistake, it
>> > was the wrong name (mea culpa), and experience has borne out that it is
>> > widely misused.  Subjectively, about half the uses of .get() I see are
>> > wrong -- and wrong in the obvious, avoidable way -- they don't consider
>> the
>> > optional might be empty. So they've just traded an unexpected NPE for an
>> > unexpected NSEE.
>> >
>> > Its problem is, essentially: it looks harmless, but isn't, but it sure
>> > seems like the method you obviously want when you're browsing the
>> > autocomplete list / javadoc.  It's a hazard both to code writers (pick
>> the
>> > wrong method because the name is bad) and to code readers (deceptively
>> > harmless looking.)
>> >
>> > Methods like orElse or ifPresent look harmless, and are; methods like
>> > orElseThrow have potentially harmful side-effects but have names that
>> are
>> > transparent about what harm they could do.  But Optional.get() is
>> neither
>> > safe nor transparent -- and yet awfully tempting-looking -- and this
>> leads
>> > to frequent misuse.  Naming matters, and this one was wrong, and the
>> harm
>> > is observable.  I wish I'd caught it before 8 shipped.
>> >
>> > Stepping back a bit ... one of the most frequent complaints we get is
>> > "mistakes never get fixed".  So, we've decided to be more serious about
>> > deprecation -- Dr. Deprecator is suiting up!  But that means, for any
>> given
>> > item, some people are going to disagree about whether deprecation is
>> > suitable, and some will be inconvenienced by the deprecation -- this is
>> > unavoidable.
>> >
>> > Why prioritize this one?  In part, because it's a *new* mistake, and has
>> > had less time to become entrenched -- and this is the very first
>> > opportunity we have to fix it.  If we can't fix an API mistake at the
>> very
>> > first opportunity, the logical consequence is we can't ever fix
>> anything.
>> > And that doesn't seem to be the world we want to retreat to.
>> >
>> > Similarly, is this the worst mistake in all of Java?  Surely not. But
>> its
>> > also not reasonable to say "you can't fix X until you've fixed
>> everything
>> > worse than X" -- again, that's a recipe for never fixing anything.  So,
>> in
>> > the context of a deprecation effort, this seems an entirely reasonable
>> > candidate.
>> >
>> > I'd like to see it fixed, and the sooner the better.
>> >
>> >
>> > On 4/26/2016 6:43 AM, Stephen Colebourne wrote:
>> >
>> >> In OpenGamma Strata we have 546 uses of Optional.get(). Rena

Re: RFR(m): 8140281 deprecate Optional.get()

[Brian Goetz]

Not that you'll find an additional voice compelling, but here's some 
additional anecdotal evidence from another channel:

   https://twitter.com/jeffreymaxwell/status/725313986053427200



On 4/26/2016 8:16 PM, Vitaly Davidovich wrote:
I'm really grasping at straws here and asking for something 
quantitative to substantiate this deprecation plan.  As it stands, 
there is hearsay and some stackoverflow links - surely going through 
with this (and inflicting some level of pain on folks who don't care 
for this) deserves something a bit better? Brian mentioned that one 
criticism often heard is mistakes aren't corrected - I fully believe 
that's true.  But this may end up being one of those "they want to 
correct mistakes and THIS is what they chose??!" things.  I understand 
the appeal in "correcting" this given it's a relatively new addition, 
but I don't think it'll go over well.


On Tuesday, April 26, 2016, Paul Benedict > wrote:


Are you asking Brian to set up another survey monkey for the
masses? I expect a happy silent majority and a raucous
minority just based on past results. :-)

On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" > wrote:

I've yet to hear one supporter on this thread besides yourself
and Stuart.
Is there some usability survey or something that actually
indicates a
significant sample of people don't like the name? Guava
Optional behaves
and is named the same way, and I've not heard anyone complain
about that (I
and many people I know used it for years).

I think the conversation would be *maybe* different if picking
a name for a
new thing, but the deprecation churn here adds no value, IMO,
and is going
to be viewed as an annoyance by a large swath of people.

On Tuesday, April 26, 2016, Brian Goetz
> wrote:

> As the person who chose the original (terrible) name, let me
weigh in...
>
> I think calling this method "get()" was our biggest API
mistake in Java
> 8.  Now, one could argue that, if this is the biggest
mistake we made, then
> we did pretty darn good.  Which may be true, but ... make no
mistake, it
> was the wrong name (mea culpa), and experience has borne out
that it is
> widely misused.  Subjectively, about half the uses of .get()
I see are
> wrong -- and wrong in the obvious, avoidable way -- they
don't consider the
> optional might be empty. So they've just traded an
unexpected NPE for an
> unexpected NSEE.
>
> Its problem is, essentially: it looks harmless, but isn't,
but it sure
> seems like the method you obviously want when you're
browsing the
> autocomplete list / javadoc.  It's a hazard both to code
writers (pick the
> wrong method because the name is bad) and to code readers
(deceptively
> harmless looking.)
>
> Methods like orElse or ifPresent look harmless, and are;
methods like
> orElseThrow have potentially harmful side-effects but have
names that are
> transparent about what harm they could do.  But
Optional.get() is neither
> safe nor transparent -- and yet awfully tempting-looking --
and this leads
> to frequent misuse.  Naming matters, and this one was wrong,
and the harm
> is observable.  I wish I'd caught it before 8 shipped.
>
> Stepping back a bit ... one of the most frequent complaints
we get is
> "mistakes never get fixed".  So, we've decided to be more
serious about
> deprecation -- Dr. Deprecator is suiting up!  But that
means, for any given
> item, some people are going to disagree about whether
deprecation is
> suitable, and some will be inconvenienced by the deprecation
-- this is
> unavoidable.
>
> Why prioritize this one?  In part, because it's a *new*
mistake, and has
> had less time to become entrenched -- and this is the very first
> opportunity we have to fix it.  If we can't fix an API
mistake at the very
> first opportunity, the logical consequence is we can't ever
fix anything.
> And that doesn't seem to be the world we want to retreat to.
>
> Similarly, is this the worst mistake in all of Java?  Surely
not. But its
> also not reasonable to say "you can't fix X until you've
fixed everything
> worse than X" -- again, that's a recipe for never fixing
anything.  So, in
> the context of a deprecation effort, this seems an entirely
reasonable
> candidate.
>
> I'd like to see it fixed, and the soone

Re: RFR(XS): 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache

[Sundararajan Athijegannathan]

+1

-Sundar

On 4/27/2016 5:28 PM, Michael Haupt wrote:
> Dear all,
>
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8155214
> Webrev: http://cr.openjdk.java.net/~mhaupt/8155214/webrev.00/
>
> The failing test, unlike several other tests in the method handles area, was 
> not safeguarded against code cache overflows.
>
> Thanks,
>
> Michael
>

Re: RFR(S): 8155106: MHs.Lookup.findConstructor returns handles for array classes

[Sundararajan Athijegannathan]

+1

-Sundar


On 4/27/2016 6:08 PM, Michael Haupt wrote:
> Dear all,
>
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8155106
> Webrev: http://cr.openjdk.java.net/~mhaupt/8155106/webrev.00/
>
> Thanks,
>
> Michael
>

Re: RFR(S): 8155106: MHs.Lookup.findConstructor returns handles for array classes

[Aleksey Shipilev]

On 04/27/2016 03:38 PM, Michael Haupt wrote:
> Dear all,
> 
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8155106
> Webrev: http://cr.openjdk.java.net/~mhaupt/8155106/webrev.00/

Looks okay.

-Aleksey

RFR(S): 8155106: MHs.Lookup.findConstructor returns handles for array classes

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8155106
Webrev: http://cr.openjdk.java.net/~mhaupt/8155106/webrev.00/

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Volker Simonis]

Yes, this was the version I've looked to as well. Thanks for pointing this out.

On Wed, Apr 27, 2016 at 1:26 PM, Martin Buchholz  wrote:
> I think the jdk9 docs have moved (again, g - I complain about this
> sort of thing every release) and so a google search for "package class
> se 9" only finds the old one +104 at
> http://download.java.net/jdk9/docs/api/java/lang/Package.html
> Why can't there be a redirect instead of leaving the old docs in place?
>
> On Wed, Apr 27, 2016 at 3:01 AM, Alan Bateman  wrote:
>> On 27/04/2016 10:54, Volker Simonis wrote:
>>>
>>> :
>>> Thanks for the clarification. As far as I can see, this updated
>>> javadoc is still only in the jigsaw repo so I didn't read it before.
>>>
>> It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs [1]
>> and it's there.
>>
>> -Alan
>>
>> [1] http://download.java.net/java/jdk9/docs/api/index.html

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Alan Bateman]

On 27/04/2016 12:26, Martin Buchholz wrote:

I think the jdk9 docs have moved (again, g - I complain about this
sort of thing every release) and so a google search for "package class
se 9" only finds the old one +104 at
http://download.java.net/jdk9/docs/api/java/lang/Package.html
Why can't there be a redirect instead of leaving the old docs in place?

Yeah, a number of us noticed that recently too. Chasing the folks that 
publish these builds to get this fixed ...


-Alan

RFR(XS): 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8155214
Webrev: http://cr.openjdk.java.net/~mhaupt/8155214/webrev.00/

The failing test, unlike several other tests in the method handles area, was 
not safeguarded against code cache overflows.

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: String.equalsIgnoreCase(...) optimization

[Aleksey Shipilev]

Hi Andrey,

On 04/27/2016 12:57 PM, Andrey wrote:
> I publish my JMH benchmark at github 
> https://github.com/volodin-aa/openjdk-benchmark

Please note that you really should compete with JDK 9 String, not with
JDK 8. String.equalsIgnoreCase is different in JDK 9, and the obvious
improvement one can do there is:

diff -r 5a6df35b0f97 src/java.base/share/classes/java/lang/StringLatin1.java
--- a/src/java.base/share/classes/java/lang/StringLatin1.java   Wed Apr 27
09:13:51 2016 +0200
+++ b/src/java.base/share/classes/java/lang/StringLatin1.java   Wed Apr 27
14:16:14 2016 +0300
@@ -315,11 +315,14 @@
   byte[] other, int ooffset,
int len) {
 int last = toffset + len;
 while (toffset < last) {
-char c1 = (char)(value[toffset++] & 0xff);
-char c2 = (char)(other[ooffset++] & 0xff);
-if (c1 == c2) {
+byte b1 = value[toffset++];
+byte b2 = other[ooffset++];
+if (b1 == b2) {
 continue;
 }
+char c1 = (char)(b1 & 0xff);
+char c2 = (char)(b2 & 0xff);
+
 char u1 = Character.toUpperCase(c1);
 char u2 = Character.toUpperCase(c2);
 if (u1 == u2) {

...which improves performance even on short Strings. Maybe specializing
Character.toUpperCase for Latin1 strings would pay off more. Maybe
specializing regionMatches for complete Strings would worth the
increased complexity too, but that should be tried on JDK code first.

To make a good justification for the change, the benchmark should really
test:
 a) Different lengths;
 b) Different starting mismatch offset;
 c) Different Latin1/UTF16 pairs.

Note well: these optimizations would require studying the generated code
looking for the compiler quirks, and as such would require much more
time than anyone thinks it would take (even after taking Hofstadter's
Law into account).

Thanks,
-Aleksey

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Martin Buchholz]

I think the jdk9 docs have moved (again, g - I complain about this
sort of thing every release) and so a google search for "package class
se 9" only finds the old one +104 at
http://download.java.net/jdk9/docs/api/java/lang/Package.html
Why can't there be a redirect instead of leaving the old docs in place?

On Wed, Apr 27, 2016 at 3:01 AM, Alan Bateman  wrote:
> On 27/04/2016 10:54, Volker Simonis wrote:
>>
>> :
>> Thanks for the clarification. As far as I can see, this updated
>> javadoc is still only in the jigsaw repo so I didn't read it before.
>>
> It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs [1]
> and it's there.
>
> -Alan
>
> [1] http://download.java.net/java/jdk9/docs/api/index.html

Re: RFR(m): 8140281 deprecate Optional.get()

[Vitaly Davidovich]

On Wednesday, April 27, 2016, Andrew Haley  wrote:

> On 27/04/16 11:51, Vitaly Davidovich wrote:
> > On Wednesday, April 27, 2016, Andrew Haley  > wrote:
> >
> >> On 27/04/16 00:38, Vitaly Davidovich wrote:
> >>> I've yet to hear one supporter on this thread besides yourself and
> >> Stuart.
> >>
> >> Do you really want to turn this discussion into even more of a
> >> bikeshed discussion?
> >
> > Not at all.  Simply saying I find this proposal odd, and I didn't get the
> > feeling I'm alone by reading the other responses here.
>
> You're not alone, but not everyone should chime in.  Now that I'm
> here I have to say that deprecating bad names is an excellent
> thing to do, and what enhanced deprecation should be doing.

Sure, but there's no agreement it's a bad name to begin with.  It's a fine
name, with precedent, and avoids visual noise when used as
intended.  Optional has something like a dozen methods with very simple
javadoc - if a developer misused it, they'll learn and move on.  There's
really no issue here at all, as far as I'm concerned.  I understand Brian
and Stuart's thinking, but it's not addressing any real issue, IMO.

>
> Andrew.
>
>

-- 
Sent from my phone

Re: RFR(m): 8140281 deprecate Optional.get()

[Stephen Colebourne]

On 26 April 2016 at 22:55, Brian Goetz  wrote:
> As the person who chose the original (terrible) name, let me weigh in...

We start from a different premise - I do not think that get() is a
terrible name. Nor was it the biggest API mistake in Java 8 (I've come
to believe parallelStream() was that).

FWIW, if I agreed that it was a terrible name, I would be in favour of
the rename at the earliest opportunity. How about Duration.getNano(
which should have been getNanos() ?

Kevin has already outlined the key reason for the name get() - that
Guava uses it and has done for many years. It is therefore the
accepted name for the method. More broadly, it is used in association
with isPresent() and as such seeing "getWhenPresent" repeats "present"
and is far too much in your face.

Ultimately, Optional is a class that requires a degree of learning.
That learning is not hard and will happen with time. Where things went
wrong IMO was adding Optional without tackling null-management in the
language, but thats a separate debate.

My experience is certainly not that 50% of users use it wrong. I do
accept that many will not use orElse() or map() when they should, but
that is fine - so long as they use isPresent() before get(), the rest
can come later.

To be clear, a lot of the claimed justification for this from Stuart's
earlier message is that people are using get() instead of orElse(),
orElseThrow(), filter(), map() etc. _but I don't care about that at
all_. Overuse of isPresent() is rife but fine. The only case that
matters is use of get() without any check.

On 27 April 2016 at 06:42, Stuart Marks  wrote:
> Briefly, it strictly isn't a rename. The old method would be deprecated
> not-for-removal, and would be left in place indefinitely.
> Does this still create pain? If so, is there some way the proposal can be
> modified to reduce it?

We keep our code free of all deprecations. As such, this will require
change when we adopt Java 9. So, this is a rename in practical terms.
The replacement being significantly longer will also cause line-length
issues and reformatting in places.

TLDR, we view Optoinal as a new core API added in Java 8 that was have
relied on and used widely. It is fine as is, and does not need any
alteration.

Stephen



> I think calling this method "get()" was our biggest API mistake in Java 8.
> Now, one could argue that, if this is the biggest mistake we made, then we
> did pretty darn good.  Which may be true, but ... make no mistake, it was
> the wrong name (mea culpa), and experience has borne out that it is widely
> misused.  Subjectively, about half the uses of .get() I see are wrong -- and
> wrong in the obvious, avoidable way -- they don't consider the optional
> might be empty. So they've just traded an unexpected NPE for an unexpected
> NSEE.
>
> Its problem is, essentially: it looks harmless, but isn't, but it sure seems
> like the method you obviously want when you're browsing the autocomplete
> list / javadoc.  It's a hazard both to code writers (pick the wrong method
> because the name is bad) and to code readers (deceptively harmless looking.)
>
> Methods like orElse or ifPresent look harmless, and are; methods like
> orElseThrow have potentially harmful side-effects but have names that are
> transparent about what harm they could do.  But Optional.get() is neither
> safe nor transparent -- and yet awfully tempting-looking -- and this leads
> to frequent misuse.  Naming matters, and this one was wrong, and the harm is
> observable.  I wish I'd caught it before 8 shipped.
>
> Stepping back a bit ... one of the most frequent complaints we get is
> "mistakes never get fixed".  So, we've decided to be more serious about
> deprecation -- Dr. Deprecator is suiting up!  But that means, for any given
> item, some people are going to disagree about whether deprecation is
> suitable, and some will be inconvenienced by the deprecation -- this is
> unavoidable.
>
> Why prioritize this one?  In part, because it's a *new* mistake, and has had
> less time to become entrenched -- and this is the very first opportunity we
> have to fix it.  If we can't fix an API mistake at the very first
> opportunity, the logical consequence is we can't ever fix anything.  And
> that doesn't seem to be the world we want to retreat to.
>
> Similarly, is this the worst mistake in all of Java?  Surely not. But its
> also not reasonable to say "you can't fix X until you've fixed everything
> worse than X" -- again, that's a recipe for never fixing anything.  So, in
> the context of a deprecation effort, this seems an entirely reasonable
> candidate.
>
> I'd like to see it fixed, and the sooner the better.
>

Re: RFR(m): 8140281 deprecate Optional.get()

[Andrew Haley]

On 27/04/16 11:51, Vitaly Davidovich wrote:
> On Wednesday, April 27, 2016, Andrew Haley  wrote:
> 
>> On 27/04/16 00:38, Vitaly Davidovich wrote:
>>> I've yet to hear one supporter on this thread besides yourself and
>> Stuart.
>>
>> Do you really want to turn this discussion into even more of a
>> bikeshed discussion?
> 
> Not at all.  Simply saying I find this proposal odd, and I didn't get the
> feeling I'm alone by reading the other responses here.

You're not alone, but not everyone should chime in.  Now that I'm
here I have to say that deprecating bad names is an excellent
thing to do, and what enhanced deprecation should be doing.

Andrew.

Re: RFR(m): 8140281 deprecate Optional.get()

[Vitaly Davidovich]

On Wednesday, April 27, 2016, Andrew Haley  wrote:

> On 27/04/16 00:38, Vitaly Davidovich wrote:
> > I've yet to hear one supporter on this thread besides yourself and
> Stuart.
>
> Do you really want to turn this discussion into even more of a
> bikeshed discussion?

Not at all.  Simply saying I find this proposal odd, and I didn't get the
feeling I'm alone by reading the other responses here.

>  Count me in as in favour of deprecation,
> but let's not get into +1s and -1s.  I'm perfectly happy to
> let Stuart and Brian explain themselves — what they say makes
> sense to me.
>
> Andrew.
>
>

-- 
Sent from my phone

Re: String.equalsIgnoreCase(...) optimization

[Andrey]

Results for long strings

private static final String _STRING = "This test needs to be better. Always 
comparing String and string doesn't tell us much. These strings are extremely 
short, and a few more cases would be useful. Please change your units to 
something more sensible. I suggest nanoseconds. Thanks, Andrew.";
private static final String STRING = "THIS TEST NEEDS TO BE BETTER. ALWAYS 
COMPARING STRING AND STRING DOESN'T TELL US MUCH. THESE STRINGS ARE EXTREMELY 
SHORT, AND A FEW MORE CASES WOULD BE USEFUL. PLEASE CHANGE YOUR UNITS TO 
SOMETHING MORE SENSIBLE. I SUGGEST NANOSECONDS. THANKS, ANDREW.";


# Run complete. Total time: 00:04:01

Benchmark Mode Cnt Score Error Units
StringBenchmark.constConstthrpt 20   931938,920 ± 1703,527 ops/s
StringBenchmark.constConstFast thrpt 20 1290645,530 ± 10855,059 ops/s
StringBenchmark.newNewthrpt 20 604461,665 ± 17613,802 ops/s
StringBenchmark.newNewFast thrpt 20 962488,540 ± 15299,433 ops/s
StringBenchmark.varVar   thrpt 20   849925,016 ± 1933,533 ops/s
StringBenchmark.varVarFastthrpt 20 1306144,917 ± 15554,201 ops/s

For not equal strings algorithm has performance as standard 
String.equalsIgnoreCase(...) .

27.04.2016, 13:17, "Andrew Haley" :
>  On 27/04/16 10:57, Andrey wrote:
>
>>   I publish my JMH benchmark at github
>>   https://github.com/volodin-aa/openjdk-benchmark
>
>  This test needs to be better. Always comparing "String" and "string"
>  doesn't tell us much. These strings are extremely short, and a few
>  more cases would be useful.
>
>  Please change your units to something more sensible. I suggest
>  nanoseconds.
>
>  Thanks,
>
>  Andrew.

RFR (XS) 8155215: java.lang.String concatenation spec is unnecessarily strong

[Aleksey Shipilev]

Hi,

Please review this tiny spec improvement that syncs up JLS and
java.lang.String Javadoc. java.lang.String Javadoc unnecessarily locks
down the implementation details for String concat (e.g. usage of
StringBuilder):
  http://cr.openjdk.java.net/~shade/8155215/webrev.00/

I'll submit CCC as soon as we agree on wording.

Thanks,
-Aleksey

Re: String.equalsIgnoreCase(...) optimization

[Andrew Haley]

On 27/04/16 10:57, Andrey wrote:

> I publish my JMH benchmark at github
> https://github.com/volodin-aa/openjdk-benchmark

This test needs to be better.  Always comparing "String" and "string"
doesn't tell us much.  These strings are extremely short, and a few
more cases would be useful.

Please change your units to something more sensible.  I suggest
nanoseconds.

Thanks,

Andrew.

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Alan Bateman]

On 27/04/2016 10:54, Volker Simonis wrote:

:
Thanks for the clarification. As far as I can see, this updated
javadoc is still only in the jigsaw repo so I didn't read it before.

It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs 
[1] and it's there.


-Alan

[1] http://download.java.net/java/jdk9/docs/api/index.html

Re: String.equalsIgnoreCase(...) optimization

[Andrey]

I publish my JMH benchmark at github 
https://github.com/volodin-aa/openjdk-benchmark

27.04.2016, 01:23, "Andrey" :
> I create simple benchmark (attached). Optimized version more faster:
>
> # JMH 1.12 (released 26 days ago)
> # VM version: JDK 1.8.0_91, VM 25.91-b14
> ..
> # Run complete. Total time: 00:04:02
>
> Benchmark Mode Cnt Score Error Units
> StringBenchmark.constConst thrpt 20 37935470,179 ▒ 158354,736 ops/s
> StringBenchmark.constConstFast thrpt 20 70342038,623 ▒ 727831,951 ops/s
> StringBenchmark.newNew thrpt 20 30033885,754 ▒ 374524,932 ops/s
> StringBenchmark.newNewFast thrpt 20 69567918,934 ▒ 196494,474 ops/s
> StringBenchmark.varVar thrpt 20 36102111,956 ▒ 364861,774 ops/s
> StringBenchmark.varVarFast thrpt 20 66743826,698 ▒ 124162,725 ops/s
>
> How I can publish my version equalsIgnoreCase(...) or OpenJDK team check 
> results separately?
>
> 26.04.2016, 18:18, "Andrew Haley" :
>>   On 04/26/2016 03:25 PM, Andrey wrote:
>>>    May be can create optimized regionMatches(...) for use in 
>>> equalsIgnoreCase(...)?
>>
>>   When the HotSpot JVM's just-in-time compiler optimizes this code it
>>   inlines all of these tests, realizes that they are constant values,
>>   and generates no code for them. All the generated code does is check
>>   that the strings have the same coder and are the same length, then it
>>   goes into an unrolled loop checking that the characters are the same

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Volker Simonis]

On Wed, Apr 27, 2016 at 11:15 AM, Alan Bateman  wrote:
>
> On 27/04/2016 09:28, Volker Simonis wrote:
>>
>> Ping - shouldn't we fix this issue before JDK 9 Feature Complete?
>>
>> Could you please also comment on my remarks regarding the relation of
>> java.lang.Package.getSpecificationVersion() to JEP and 223 and and my
>> question why the Version class is not in a standard java package.
>>
> One thing to be aware of is that specification for legacy java.lang.Package
> has been significantly overhauled as part of updating the platform to
> support modules. The javadoc to read is the updated class description where
> it specifies the properties of Packages automatically created for types in
> named modules, also the API note in the 8-parameter
> ClassLoader.definePackage method. The TL;DR summary is that
> getSpecificationVersion() will return null when invoking on Package objects
> for any types in any of the system module (or any of the modules on the
> module path too). So I don't think JEP 223 needs to be concerned with it.
>

Thanks for the clarification. As far as I can see, this updated
javadoc is still only in the jigsaw repo so I didn't read it before.

> JDK-8144062 is tracking the replacement of jdk.Version with a standard API.
>

Thanks for providing the link. I wasn't aware of it. Yet another bug
to follow on JBS :)

Volker

> -Alan.

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Alan Bateman]

On 27/04/2016 09:28, Volker Simonis wrote:

Ping - shouldn't we fix this issue before JDK 9 Feature Complete?

Could you please also comment on my remarks regarding the relation of
java.lang.Package.getSpecificationVersion() to JEP and 223 and and my
question why the Version class is not in a standard java package.

One thing to be aware of is that specification for legacy 
java.lang.Package has been significantly overhauled as part of updating 
the platform to support modules. The javadoc to read is the updated 
class description where it specifies the properties of Packages 
automatically created for types in named modules, also the API note in 
the 8-parameter ClassLoader.definePackage method. The TL;DR summary is 
that getSpecificationVersion() will return null when invoking on Package 
objects for any types in any of the system module (or any of the modules 
on the module path too). So I don't think JEP 223 needs to be concerned 
with it.


JDK-8144062 is tracking the replacement of jdk.Version with a standard API.

-Alan.

Re: [jmm-dev] RFR 8154755: Add a VarHandle weakCompareAndSet with volatile semantics

[Aleksey Shipilev]

On 04/21/2016 07:21 PM, Paul Sandoz wrote:
> Please review:
> 
>   
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154755-weak-cas-volatile/webrev/

Looks okay to me.

-Aleksey

Re: RFR(m): 8140281 deprecate Optional.get()

[Andrew Haley]

On 27/04/16 00:38, Vitaly Davidovich wrote:
> I've yet to hear one supporter on this thread besides yourself and Stuart.

Do you really want to turn this discussion into even more of a
bikeshed discussion?  Count me in as in favour of deprecation,
but let's not get into +1s and -1s.  I'm perfectly happy to
let Stuart and Brian explain themselves — what they say makes
sense to me.

Andrew.

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Volker Simonis]

Ping - shouldn't we fix this issue before JDK 9 Feature Complete?

Could you please also comment on my remarks regarding the relation of
java.lang.Package.getSpecificationVersion() to JEP and 223 and and my
question why the Version class is not in a standard java package.

Thank you and best regards,
Volker


On Thu, Apr 7, 2016 at 12:11 PM, Volker Simonis
 wrote:
> On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark  wrote:
>> Hi, Volker.
>>
>> Sorry for the delay.  I agree that the old implementation isn't quite 
>> correct.  I can't see us potentially having a JCP MR for a security or patch 
>> release (9.0.0.X and 9.0.X respectively).
>>
>> I could see a MR for an very unusual minor release (9.X).  If we had an MR 
>> there's no guarantee that we'd need to change the java.specification.version 
>> system property.   However, in the event that we did need to change the 
>> java.specification.version, it should match that release's $MAJOR.$MINOR, 
>> even if it meant that we had a sequence of specification version numbers 
>> with gaps.
>>
>> As an example, let's say that JDK 9 is released via umbrella JSR with 
>> java.specification.value of "9".  The system property would remain at "9" 
>> for all releases regardless of type until we choose to have a MR.  Should 
>> that MR occur while we're working on minor release 9.3.X and there is a need 
>> to change the value of java.specification.value, it would become "9.3" and 
>> would remain so in every release until the next MR.
>>
>> While we haven't changed the system property recently, I think that we need 
>> to future-proof ourselves a little bit for MRs as described above.
>>
>> Assuming that we change the syntax of java.specification.version to 
>> $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make 
>> a similar change to the syntax of java.vm.specification.version.  [ Note 
>> that in the current implementation, I believe that the values of 
>> java.specification.version and java.vm.specification.version are tied to 
>> each other. ]
>>
>> Changing the syntax of java{.vm}?specification.version requires a CCC which 
>> I will file once we have agreement on the necessary changes.
>>
>
> Hi Iris,
>
> thanks for your comments. I don't think that using $MAJOR.$MINOR for
> java.specification.version is a good solution. As far as I understand,
>  JEP 223 (i.e. the new version scheme) is an Oracle/OpenJDK
> implementation detail. There is no JSR for this and it won't be
> enforced trough a JCK/TCK test (please correct me if I'm wrong). The
> new versioning schema references the JCP in that is says that the
> $MAJOR number corresponds to the "Java SE Platform Specification"
> number as specified by the JCP in the corresponding JSR. But not vice
> versa - i.e. there's no JSR referencing JEP 223.
>
> JEP 223 also says that the $MINOR number will be increased if this is
> mandated by a Maintenance Release of the relevant Platform
> Specification (by the JCP). But as you correctly noticed, in reality,
> $MINOR is expected to be increased frequently compared to the number
> of Java SE Maintenance Releases (if there will be any at all). So if
> the JCP should decide to publish a Maintenance Release, why should it
> name if after the then actual $MINOR update release number of the
> Oracle/OpenJDK. I think a natural choice for such a MR would be "9.1",
> no difference at which update release version Oracle/OpenJDK will be
> at that time.
>
> So I think it would be best to decouple java.specification.version
> from the Java versioning schema. We can start with
> java.specification.version == $MAJOR. If there should be a MR
> sometimes in the future, we can just set java.specification.version to
> the version number of that MR, whatever that will be. That's exactly
> what this change is about.
>
> Regarding the value of java.vm.specification.version I'm not sure what
> it actually means at all. Until Java 1.6,
> java.vm.specification.version has always been "1.0", while
> java.specification.version has changed from 1.4, to 1.5 and 1.6
> (notice that java.specification.version has never been changed to
> 1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting with
> Java 7, java.vm.specification.version is the same like
> java.specification.version (i.e. 1.7 and 1.8) but I'm not sure if that
> is mandated by JCP and if it will be possible that these numbers will
> diverge for a Java release. I.e. will it be possible to have a new
> Java version (say Java 10) where the VM specification (and thus
> java.vm.specification.version) will remain unchanged (say "9")? From
> my understanding, that should be possible. Especially for a MR, it
> seems highly probable to me that the java.specification.version will
> be increased, but the VM specification (and thus
> java.vm.specification.version) will remain unchanged.
>
> So again, I think we shouldn't tie java.vm.specification.version to
> java.specification.version and simply start with
> java.vm.speci

Re: RFR(m): 8140281 deprecate Optional.get()

[ecki]

Hello,

I agree, using the isPresent()/get() is fine, especially for code which 
interfaces between Optional-using APIs and null/default using APIs. Especially 
if you do not want/should use streams or lambda. And as I recall the "do not 
use Optional everywhere" motto is repeatet from Oracle as well, so those 
Interfaces are to be expected.

Optional<> res = calculateOptionalResult();
If (res.isPresent())
  doSomething(res.get());  // at this location 'orThrow' would be highly 
disturbing the reading flow
// else
//doSomething();

So the major problem with that is, it makes it obvious it has not much 
advantage over null (and the language needs a ?. Operator ,)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-Original Message-
From: Kevin Bourrillion 
To: Vitaly Davidovich 
Cc: core-libs-dev 
Sent: Mi., 27 Apr. 2016 7:51
Subject: Re: RFR(m): 8140281 deprecate Optional.get()

Guava owner here, and yes, I've never heard such a complaint about our
Optional.get() method. This class has about a quarter of a million usages
inside Google alone (I'm not kidding), and people seem quite happy with it.

We have been planning to migrate these usages from our Optional class to
yours (sounds crazy, but this is how we roll). Threads like this one -- and
the threat of changing Optional in-place incompatibly to become a value
type as part of Valhalla -- are making us, for the first time, seriously
question whether that is such a good idea.

Please don't rename this method.




On Tue, Apr 26, 2016 at 4:38 PM, Vitaly Davidovich 
wrote:

> I've yet to hear one supporter on this thread besides yourself and Stuart.
> Is there some usability survey or something that actually indicates a
> significant sample of people don't like the name? Guava Optional behaves
> and is named the same way, and I've not heard anyone complain about that (I
> and many people I know used it for years).
>
> I think the conversation would be *maybe* different if picking a name for a
> new thing, but the deprecation churn here adds no value, IMO, and is going
> to be viewed as an annoyance by a large swath of people.
>
> On Tuesday, April 26, 2016, Brian Goetz  wrote:
>
> > As the person who chose the original (terrible) name, let me weigh in...
> >
> > I think calling this method "get()" was our biggest API mistake in Java
> > 8.  Now, one could argue that, if this is the biggest mistake we made,
> then
> > we did pretty darn good.  Which may be true, but ... make no mistake, it
> > was the wrong name (mea culpa), and experience has borne out that it is
> > widely misused.  Subjectively, about half the uses of .get() I see are
> > wrong -- and wrong in the obvious, avoidable way -- they don't consider
> the
> > optional might be empty. So they've just traded an unexpected NPE for an
> > unexpected NSEE.
> >
> > Its problem is, essentially: it looks harmless, but isn't, but it sure
> > seems like the method you obviously want when you're browsing the
> > autocomplete list / javadoc.  It's a hazard both to code writers (pick
> the
> > wrong method because the name is bad) and to code readers (deceptively
> > harmless looking.)
> >
> > Methods like orElse or ifPresent look harmless, and are; methods like
> > orElseThrow have potentially harmful side-effects but have names that are
> > transparent about what harm they could do.  But Optional.get() is neither
> > safe nor transparent -- and yet awfully tempting-looking -- and this
> leads
> > to frequent misuse.  Naming matters, and this one was wrong, and the harm
> > is observable.  I wish I'd caught it before 8 shipped.
> >
> > Stepping back a bit ... one of the most frequent complaints we get is
> > "mistakes never get fixed".  So, we've decided to be more serious about
> > deprecation -- Dr. Deprecator is suiting up!  But that means, for any
> given
> > item, some people are going to disagree about whether deprecation is
> > suitable, and some will be inconvenienced by the deprecation -- this is
> > unavoidable.
> >
> > Why prioritize this one?  In part, because it's a *new* mistake, and has
> > had less time to become entrenched -- and this is the very first
> > opportunity we have to fix it.  If we can't fix an API mistake at the
> very
> > first opportunity, the logical consequence is we can't ever fix anything.
> > And that doesn't seem to be the world we want to retreat to.
> >
> > Similarly, is this the worst mistake in all of Java?  Surely not. But its
> > also not reasonable to say "you can't fix X until you've fixed everything
> > worse than X" -- again, that's a recipe for never fixing anything.  So,
> in
> > the context of a deprecation effort, this seems an entirely reasonable
> > candidate.
> >
> > I'd like to see it fixed, and the sooner the better.
> >
> >
> > On 4/26/2016 6:43 AM, Stephen Colebourne wrote:
> >
> >> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this
> >> would be painful and add no value.
> >>
> >> While I understand the pain from some devel