Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

[joe darcy]

Hi Brian,


On 12/16/2016 10:43 AM, Brian Burkhalter wrote:

Hi Joe,

This looks fine to me. I’ve just a few picayune items:

1. FdLibm

Line 649: I assume the weird “halF” (upper case F) is retained in 
order to match the original C code.


Corrected.



2. TEST.ROOT

Line 30: The jtreg required version is reverted.


Oops; I'll fix that before pushing.



3. ExpTests

Lines 65 and 69: The threshold values in comments could be static 
final constants as well as they are used at lines

66, 70, 109 and 112.


Yeah, I went back and forth on that point a bit while write the test. I 
changed the later usages to


double[] decisionPoints = {
// Near overflow threshold
EXP_OVERFLOW_THRESH - 512*Math.ulp(EXP_OVERFLOW_THRESH),

// Near underflow threshold
EXP_UNDERFLOW_THRESH - 512*Math.ulp(EXP_UNDERFLOW_THRESH),

Thanks,

-Joe

Re: Proposal: Add a type token class for representing generic types

[David Holmes]

Hi Gunnar,

On 17/12/2016 2:18 AM, Gunnar Morling wrote:

Hi,

I'd like to suggest the addition of a type token class to the Java
class library, to be used for representing generic types such as
List.


Sounds like something that falls within scope for the generic 
specialization work in Project Valhalla:


http://openjdk.java.net/projects/valhalla/

David
-


Actual class literals can only represent raw types. But often
libraries have the need to apply some sort of configuration to
specific generic types, link specific behaviour to them or expose
(meta) data related to them. The suggested type token class would
allow to implement such cases in a type-safe fashion.

# Example use cases

* The "type-safe heterogenous container" pattern from Joshua Bloch's
book "Effective Java" introduces a container which allows to safely
store and retrieve objects of different types. They are keyed by
Class, which means that one cannot have a value for a List
and another value for a List in such container. Also one
cannot obtain a List without casting from such container. Type
literals would allow this:

 void put(TypeLiteral type, T value);
 T get(TypeLiteral type);

TypeLiteral stringListType = ...;
List stringList = container.get( stringListType );

* JAX-RS allows to read response message entities into parameterized
types using its GenericType class:

List customers = response.readEntity( new
GenericType() {} );

* CDI allows to dynamically obtain beans of specific parameterized
types using its TypeLiteral class:

@Inject @Any Instance anyPaymentProcessor;

public PaymentProcessor getChequePaymentProcessor() {
PaymentProcessor pp = anyPaymentProcessor
.select( new TypeLiteral() {} ).get();
}

# Proposed solution

Type literals would be represented by a new type
java.lang.reflect.TypeLiteral. Instances would be created via
sub-classing, capturing the  parameter and baking it into the
sub-class:

TypeLiteral stringListType = new
TypeLiteral(){};

That'd allow to provide type-safe APIs around generic types as shown
in the examples above. The following methods should be defined on
TypeLiteral in order to make it useful for implementers of such APIs:

Type getType();
Class getRawType();
boolean equals(Object obj);
int hashCode();
String toString();

# Prior art

The idea of type tokens based on capturing a generic type in a
sub-class has been around for a long time. The first reference I've
found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1].
Examples in real-world APIs and libraries are TypeLiteral in CDI
[2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4]
and TypeToken in Guava [5].

# Alternatives and shortcomings

The obvious alternative would be reified generics, but I think it's
commonly agreed upon that these will not come to the Java language any
time soon. Without native support in the language itself the proposed
type literal class is the best way to support the mentioned use cases
as far as I can say.

Shortcomings are the creation of a sub-class per literal instantiation
(probably more an aesthetic problem, though) and failure of the
pattern when type variables are included anywhere in the represented
type [6]. Unfortunately, this can only be detected at runtime when
instantiating a literal but not by the compiler (although, I reckon it
technically could, by handling this case specifically).

# Conclusion

Lacking reified generics, the Java platform would benefit from the
addition of new type token class java.lang.reflect.TypeLiteral. The
pattern's presence in common APIs and libraries shows that there is a
wide-spread need for such mechanism and the community would benefit
very much from a standardized solution in the JDK itself. This will
allow for more unified API designs as well as foster integration of
different libraries.

I'm eager to learn about your feedback and the OpenJDK team's
assessment of this proposal.

--Gunnar

[1] http://gafter.blogspot.de/2006/12/super-type-tokens.html
[2] 
https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html
[3] 
https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html
[4] 
https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html
[5] 
https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html
[6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Uwe Schindler]

Hi Chris,

thanks, works perfectly. I compiled a JDK with this commit and Lucene's 
unmapping works. Thanks.
https://github.com/apache/lucene-solr/compare/LUCENE-6989-v2

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Friday, December 16, 2016 6:39 PM
> To: Peter Levart ; Core-Libs-Dev  d...@openjdk.java.net>; jigsaw-dev ; Uwe
> Schindler 
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
> 
> Pushed to jdk9/dev. Should make b150.
> 
>   https://bugs.openjdk.java.net/browse/JDK-8171377
> 
> -Chris.
> 
> > On 14 Dec 2016, at 11:58, Chris Hegarty 
> wrote:
> >
> > Webrev updated in-place.
> >  http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> >
> > -Chris.
> >
> > On 13/12/16 21:18, Peter Levart wrote:
> >> I think this is OK.
> >>
> >> Just a couple of nits in test:
> >>
> >> 1. You create a static Path bob = Paths.get("bob") field, but then you
> >> don't use it in:
> >>
> >>  56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
> >> CREATE, WRITE)) {
> >>
> >> 2. badBuffers could include a duplicate and a slice of a direct buffer
> >> allocated with ByteBuffer.allocateDirect()
> >>
> >> 3. The comment in the test is referencing the old method name:
> >>
> >>  26  * @summary Basic test for Unsafe::deallocate
> >>
> >>
> >> Regards, Peter
> >>
> >> On 12/13/2016 08:47 PM, Chris Hegarty wrote:
> >>> Taking into account the feedback so far, and changing the method name
> ( since
> >>> it is an attractive nuisance ), here is where I think we ended up.
> >>>
> >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> >>>
> >>> If this is agreeable, I’ll file an issue in JIRA to track the code 
> >>> changes, and
> >>> update JEP 260.
> >>>
> >>> -Chris.
> >>

JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

[Brian Burkhalter]

Please review at your convenience.

Issue:  https://bugs.openjdk.java.net/browse/JDK-8148023
Patch:  http://cr.openjdk.java.net/~bpb/8148023/webrev.00/index.html

The method was not adhering to the specification [1] and was creating long file 
names which caused failures on all platforms. The pertinent portion of the 
specification is:

"To create the new file, the prefix and the suffix may first be adjusted to fit 
the limitations of the underlying platform. If the prefix is too long then it 
will be truncated, but its first three characters will always be preserved. If 
the suffix is too long then it too will be truncated, but if it begins with a 
period character ('.') then the period and the first three characters following 
it will always be preserved. Once these adjustments have been made the name of 
the new file will be generated by concatenating the prefix, five or more 
internally-generated characters, and the suffix."

The code was updated to truncate the filename (leaf) portion of the path name 
to meet the platform file name component length constraints. The IO regression 
tests passed with this change on all platforms.

Thanks,

Brian

[1] 
http://download.java.net/java/jdk9/docs/api/java/io/File.html#createTempFile-java.lang.String-java.lang.String-java.io.File-

Re: RFR: jsr166 jdk9 integration wave 13

[Paul Sandoz]

> On 16 Dec 2016, at 11:58, Martin Buchholz  wrote:
> 
> Thanks, Stefan!
> 
> The creation of these bridge classes seem like a misfeature/bug of javac.

It’s to work around the current access control rules enforced by the VM. The 
Java source world and the bytecode/VM world have different opinions.

IIUC we need a clearer notion of "nest mate" classes (something that Valhalla 
is looking into).

Paul.

> We should avoid them where possible.  Every unnecessary class file makes
> every single java program a little slower to start up.  We can discover
> such "bridge classes" heuristically by looking for "small" synthetic class
> files:
> 
> find build/classes/java.base/ -name '*$[0-9].class' -size -800c
> 
> I think adding the package-private constructor is slightly better software
> engineering than making the classes themselves package-private:
> 
> Index: PriorityQueue.java
> ===
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/PriorityQueue.java,v
> retrieving revision 1.115
> diff -u -r1.115 PriorityQueue.java
> --- PriorityQueue.java 2 Dec 2016 07:11:36 - 1.115
> +++ PriorityQueue.java 16 Dec 2016 19:54:22 -
> @@ -522,6 +522,8 @@
>  */
> private int expectedModCount = modCount;
> 
> +Itr() {}
> +
> public boolean hasNext() {
> return cursor < size ||
> (forgetMeNot != null && !forgetMeNot.isEmpty());
> Index: concurrent/ConcurrentLinkedDeque.java
> ===
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v
> retrieving revision 1.79
> diff -u -r1.79 ConcurrentLinkedDeque.java
> --- concurrent/ConcurrentLinkedDeque.java 8 Dec 2016 05:03:37 - 1.79
> +++ concurrent/ConcurrentLinkedDeque.java 16 Dec 2016 19:54:23 -
> @@ -1367,12 +1367,14 @@
> 
> /** Forward iterator */
> private class Itr extends AbstractItr {
> +Itr() {}
> Node startNode() { return first(); }
> Node nextNode(Node p) { return succ(p); }
> }
> 
> /** Descending iterator */
> private class DescendingItr extends AbstractItr {
> +DescendingItr() {}
> Node startNode() { return last(); }
> Node nextNode(Node p) { return pred(p); }
> }
> Index: concurrent/CyclicBarrier.java
> ===
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CyclicBarrier.java,v
> retrieving revision 1.57
> diff -u -r1.57 CyclicBarrier.java
> --- concurrent/CyclicBarrier.java 8 Oct 2016 20:37:20 - 1.57
> +++ concurrent/CyclicBarrier.java 16 Dec 2016 19:54:23 -
> @@ -120,6 +120,7 @@
>  * but no subsequent reset.
>  */
> private static class Generation {
> +Generation() {}
> boolean broken; // initially false
> }
> 
> Index: concurrent/LinkedBlockingDeque.java
> ===
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v
> retrieving revision 1.67
> diff -u -r1.67 LinkedBlockingDeque.java
> --- concurrent/LinkedBlockingDeque.java 13 Dec 2016 18:55:57 - 1.67
> +++ concurrent/LinkedBlockingDeque.java 16 Dec 2016 19:54:23 -
> @@ -1145,12 +1145,14 @@
> 
> /** Forward iterator */
> private class Itr extends AbstractItr {
> +Itr() {}
> Node firstNode() { return first; }
> Node nextNode(Node n) { return n.next; }
> }
> 
> /** Descending iterator */
> private class DescendingItr extends AbstractItr {
> +DescendingItr() {}
> Node firstNode() { return last; }
> Node nextNode(Node n) { return n.prev; }
> }
> Index: concurrent/SubmissionPublisher.java
> ===
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/SubmissionPublisher.java,v
> retrieving revision 1.67
> diff -u -r1.67 SubmissionPublisher.java
> --- concurrent/SubmissionPublisher.java 16 Dec 2016 13:11:50 - 1.67
> +++ concurrent/SubmissionPublisher.java 16 Dec 2016 19:54:23 -
> @@ -165,7 +165,8 @@
> ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();
> 
> /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */
> -static final class ThreadPerTaskExecutor implements Executor {
> +private static final class ThreadPerTaskExecutor implements Executor {
> +ThreadPerTaskExecutor() {}
> public void execute(Runnable r) { new Thread(r).start(); }
> }
> 
> 
> 
> On Fri, Dec 16, 2016 at 5:14 AM, Doug Lea  wrote:
> 
>> On 12/15/2016 01:17 PM, Stefan Zobel wrote:
>> 
>> I recently noticed that javac creates a synthetic class and a bridge
>>> constructor
>>> for 

Re: RFR: jsr166 jdk9 integration wave 13

[Martin Buchholz]

ThreadPerTaskExecutor() {}  // prevents bridge class creation

On Fri, Dec 16, 2016 at 12:21 PM, Stefan Zobel 
wrote:

>
> yes, I agree. It may be better to add a comment like in ArrayList.Itr:
>
> // prevent creating a synthetic constructor
>
> Otherwise someone might be tempted to drop these empty constructors.
>
> See also
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
> September/043803.html


Yeah, no one Just Fixed The Problem Once And For All !

Re: RFR: jsr166 jdk9 integration wave 13

[Stefan Zobel]

2016-12-16 20:58 GMT+01:00 Martin Buchholz :
> Thanks, Stefan!
>
> The creation of these bridge classes seem like a misfeature/bug of javac.
> We should avoid them where possible.  Every unnecessary class file makes
> every single java program a little slower to start up.  We can discover such
> "bridge classes" heuristically by looking for "small" synthetic class files:
>
> find build/classes/java.base/ -name '*$[0-9].class' -size -800c
>
> I think adding the package-private constructor is slightly better software
> engineering than making the classes themselves package-private:
>

Hi Martin,

yes, I agree. It may be better to add a comment like in ArrayList.Itr:

// prevent creating a synthetic constructor

Otherwise someone might be tempted to drop these empty constructors.

See also
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043803.html


Regards,
Stefan

Re: RFR: jsr166 jdk9 integration wave 13

[Martin Buchholz]

Thanks, Stefan!

The creation of these bridge classes seem like a misfeature/bug of javac.
We should avoid them where possible.  Every unnecessary class file makes
every single java program a little slower to start up.  We can discover
such "bridge classes" heuristically by looking for "small" synthetic class
files:

find build/classes/java.base/ -name '*$[0-9].class' -size -800c

I think adding the package-private constructor is slightly better software
engineering than making the classes themselves package-private:

Index: PriorityQueue.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/PriorityQueue.java,v
retrieving revision 1.115
diff -u -r1.115 PriorityQueue.java
--- PriorityQueue.java 2 Dec 2016 07:11:36 - 1.115
+++ PriorityQueue.java 16 Dec 2016 19:54:22 -
@@ -522,6 +522,8 @@
  */
 private int expectedModCount = modCount;

+Itr() {}
+
 public boolean hasNext() {
 return cursor < size ||
 (forgetMeNot != null && !forgetMeNot.isEmpty());
Index: concurrent/ConcurrentLinkedDeque.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v
retrieving revision 1.79
diff -u -r1.79 ConcurrentLinkedDeque.java
--- concurrent/ConcurrentLinkedDeque.java 8 Dec 2016 05:03:37 - 1.79
+++ concurrent/ConcurrentLinkedDeque.java 16 Dec 2016 19:54:23 -
@@ -1367,12 +1367,14 @@

 /** Forward iterator */
 private class Itr extends AbstractItr {
+Itr() {}
 Node startNode() { return first(); }
 Node nextNode(Node p) { return succ(p); }
 }

 /** Descending iterator */
 private class DescendingItr extends AbstractItr {
+DescendingItr() {}
 Node startNode() { return last(); }
 Node nextNode(Node p) { return pred(p); }
 }
Index: concurrent/CyclicBarrier.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CyclicBarrier.java,v
retrieving revision 1.57
diff -u -r1.57 CyclicBarrier.java
--- concurrent/CyclicBarrier.java 8 Oct 2016 20:37:20 - 1.57
+++ concurrent/CyclicBarrier.java 16 Dec 2016 19:54:23 -
@@ -120,6 +120,7 @@
  * but no subsequent reset.
  */
 private static class Generation {
+Generation() {}
 boolean broken; // initially false
 }

Index: concurrent/LinkedBlockingDeque.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v
retrieving revision 1.67
diff -u -r1.67 LinkedBlockingDeque.java
--- concurrent/LinkedBlockingDeque.java 13 Dec 2016 18:55:57 - 1.67
+++ concurrent/LinkedBlockingDeque.java 16 Dec 2016 19:54:23 -
@@ -1145,12 +1145,14 @@

 /** Forward iterator */
 private class Itr extends AbstractItr {
+Itr() {}
 Node firstNode() { return first; }
 Node nextNode(Node n) { return n.next; }
 }

 /** Descending iterator */
 private class DescendingItr extends AbstractItr {
+DescendingItr() {}
 Node firstNode() { return last; }
 Node nextNode(Node n) { return n.prev; }
 }
Index: concurrent/SubmissionPublisher.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/SubmissionPublisher.java,v
retrieving revision 1.67
diff -u -r1.67 SubmissionPublisher.java
--- concurrent/SubmissionPublisher.java 16 Dec 2016 13:11:50 - 1.67
+++ concurrent/SubmissionPublisher.java 16 Dec 2016 19:54:23 -
@@ -165,7 +165,8 @@
 ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();

 /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */
-static final class ThreadPerTaskExecutor implements Executor {
+private static final class ThreadPerTaskExecutor implements Executor {
+ThreadPerTaskExecutor() {}
 public void execute(Runnable r) { new Thread(r).start(); }
 }



On Fri, Dec 16, 2016 at 5:14 AM, Doug Lea  wrote:

> On 12/15/2016 01:17 PM, Stefan Zobel wrote:
>
> I recently noticed that javac creates a synthetic class and a bridge
>> constructor
>> for SubmissionPublisher.ThreadPerTaskExecutor because its generated
>> constructor
>> is private. I don't know if it really matters but that could be avoided by
>> declaring a package-private constructor that does nothing.
>>
>
> Or, more simply remove the unnecessary "private" qualifier for the
> nested ThreadPerTaskExecutor class, as we did in the similar usage in
> CompletableFuture, and should have remembered to do here.
> Done; thanks.
>
> -Doug
>
>
>
>
>
>>/** Fallback if ForkJoinPool.commonPool() cannot support parallelism */
>>>

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

[Brian Burkhalter]

Hi Joe,

This looks fine to me. I’ve just a few picayune items:

1. FdLibm

Line 649: I assume the weird “halF” (upper case F) is retained in order to 
match the original C code.

2. TEST.ROOT

Line 30: The jtreg required version is reverted.

3. ExpTests

Lines 65 and 69: The threshold values in comments could be static final 
constants as well as they are used at lines
66, 70, 109 and 112.

Thanks,

Brian

On Dec 15, 2016, at 12:25 PM, joe darcy  wrote:

> Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow (JDK-8134795) 
> and hypot (JDK-7130085) earlier in JDK 9 is exp:
> 
>JDK-8139688 Port fdlibm exp to Java
>http://cr.openjdk.java.net/~darcy/8139688.5/
> 
> Same methodology followed as when porting the earlier functions.

Re: Duration isPositive missing?

[Roger Riggs]

Hi Steven,

Yes, it does seem like an oversight.  There are some other alternatives 
that might be considered.
.toMillis() > 0// Might throw an exception for very large or 
small durations.


I create an issue: 8171382 java.time.Duration missing isPositive method 



To look at it for the next release.

Roger


On 12/16/2016 12:54 PM, Steven Schlansker wrote:

Hi core-libs-dev,

My coworker and I were just puzzling over the seemingly trivially missing
java.time.Duration#isPositive

There are already "isNegative" and "isZero" -- but for isPositive the best
we came up with were awful things like

!isZero() && !isNegative()
!.negate().isNegative()
.compareTo(Duration.ZERO) > 0

but all of these feel way worse than a simple isPositive method.
Can you shed some light as to why this is missing?

Thanks!
Steven

Duration isPositive missing?

[Steven Schlansker]

Hi core-libs-dev,

My coworker and I were just puzzling over the seemingly trivially missing
java.time.Duration#isPositive

There are already "isNegative" and "isZero" -- but for isPositive the best
we came up with were awful things like

!isZero() && !isNegative()
!.negate().isNegative()
.compareTo(Duration.ZERO) > 0

but all of these feel way worse than a simple isPositive method.
Can you shed some light as to why this is missing?

Thanks!
Steven

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Chris Hegarty]

Pushed to jdk9/dev. Should make b150.

  https://bugs.openjdk.java.net/browse/JDK-8171377

-Chris.

> On 14 Dec 2016, at 11:58, Chris Hegarty  wrote:
> 
> Webrev updated in-place.
>  http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> 
> -Chris.
> 
> On 13/12/16 21:18, Peter Levart wrote:
>> I think this is OK.
>> 
>> Just a couple of nits in test:
>> 
>> 1. You create a static Path bob = Paths.get("bob") field, but then you
>> don't use it in:
>> 
>>  56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
>> CREATE, WRITE)) {
>> 
>> 2. badBuffers could include a duplicate and a slice of a direct buffer
>> allocated with ByteBuffer.allocateDirect()
>> 
>> 3. The comment in the test is referencing the old method name:
>> 
>>  26  * @summary Basic test for Unsafe::deallocate
>> 
>> 
>> Regards, Peter
>> 
>> On 12/13/2016 08:47 PM, Chris Hegarty wrote:
>>> Taking into account the feedback so far, and changing the method name ( 
>>> since
>>> it is an attractive nuisance ), here is where I think we ended up.
>>> 
>>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>>> 
>>> If this is agreeable, I’ll file an issue in JIRA to track the code changes, 
>>> and
>>> update JEP 260.
>>> 
>>> -Chris.
>> 

Re: Proposal: Add a type token class for representing generic types

[Steven Schlansker]

> On Dec 16, 2016, at 8:18 AM, Gunnar Morling  wrote:
> 
> Hi,
> 
> I'd like to suggest the addition of a type token class to the Java
> class library, to be used for representing generic types such as
> List.

I don't have much clout on this list to throw around, but a huge
+1 from me!  I maintain a library that tries to be zero-dependency
and we found that we also had to introduce a type token.

If you try to avoid reusing existing names (as you mention, there are
like 5 different implementations in very common libraries) it is hard
to even come up with a unique class name at this point.

And it just feels wrong to have so many unique implementations of a simple 
concept...

Having this in the core libraries would be great for us.

> 
> Actual class literals can only represent raw types. But often
> libraries have the need to apply some sort of configuration to
> specific generic types, link specific behaviour to them or expose
> (meta) data related to them. The suggested type token class would
> allow to implement such cases in a type-safe fashion.
> 
> # Example use cases
> 
> * The "type-safe heterogenous container" pattern from Joshua Bloch's
> book "Effective Java" introduces a container which allows to safely
> store and retrieve objects of different types. They are keyed by
> Class, which means that one cannot have a value for a List
> and another value for a List in such container. Also one
> cannot obtain a List without casting from such container. Type
> literals would allow this:
> 
> void put(TypeLiteral type, T value);
> T get(TypeLiteral type);
> 
>TypeLiteral stringListType = ...;
>List stringList = container.get( stringListType );
> 
> * JAX-RS allows to read response message entities into parameterized
> types using its GenericType class:
> 
>List customers = response.readEntity( new
> GenericType() {} );
> 
> * CDI allows to dynamically obtain beans of specific parameterized
> types using its TypeLiteral class:
> 
>@Inject @Any Instance anyPaymentProcessor;
> 
>public PaymentProcessor getChequePaymentProcessor() {
>PaymentProcessor pp = anyPaymentProcessor
>.select( new TypeLiteral() {} ).get();
>}
> 
> # Proposed solution
> 
> Type literals would be represented by a new type
> java.lang.reflect.TypeLiteral. Instances would be created via
> sub-classing, capturing the  parameter and baking it into the
> sub-class:
> 
>TypeLiteral stringListType = new
> TypeLiteral(){};
> 
> That'd allow to provide type-safe APIs around generic types as shown
> in the examples above. The following methods should be defined on
> TypeLiteral in order to make it useful for implementers of such APIs:
> 
>Type getType();
>Class getRawType();
>boolean equals(Object obj);
>int hashCode();
>String toString();
> 
> # Prior art
> 
> The idea of type tokens based on capturing a generic type in a
> sub-class has been around for a long time. The first reference I've
> found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1].
> Examples in real-world APIs and libraries are TypeLiteral in CDI
> [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4]
> and TypeToken in Guava [5].
> 
> # Alternatives and shortcomings
> 
> The obvious alternative would be reified generics, but I think it's
> commonly agreed upon that these will not come to the Java language any
> time soon. Without native support in the language itself the proposed
> type literal class is the best way to support the mentioned use cases
> as far as I can say.
> 
> Shortcomings are the creation of a sub-class per literal instantiation
> (probably more an aesthetic problem, though) and failure of the
> pattern when type variables are included anywhere in the represented
> type [6]. Unfortunately, this can only be detected at runtime when
> instantiating a literal but not by the compiler (although, I reckon it
> technically could, by handling this case specifically).
> 
> # Conclusion
> 
> Lacking reified generics, the Java platform would benefit from the
> addition of new type token class java.lang.reflect.TypeLiteral. The
> pattern's presence in common APIs and libraries shows that there is a
> wide-spread need for such mechanism and the community would benefit
> very much from a standardized solution in the JDK itself. This will
> allow for more unified API designs as well as foster integration of
> different libraries.
> 
> I'm eager to learn about your feedback and the OpenJDK team's
> assessment of this proposal.
> 
> --Gunnar
> 
> [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html
> [2] 
> https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html
> [3] 
> https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html
> [4] 
> https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html
> [5] 

Proposal: Add a type token class for representing generic types

[Gunnar Morling]

Hi,

I'd like to suggest the addition of a type token class to the Java
class library, to be used for representing generic types such as
List.

Actual class literals can only represent raw types. But often
libraries have the need to apply some sort of configuration to
specific generic types, link specific behaviour to them or expose
(meta) data related to them. The suggested type token class would
allow to implement such cases in a type-safe fashion.

# Example use cases

* The "type-safe heterogenous container" pattern from Joshua Bloch's
book "Effective Java" introduces a container which allows to safely
store and retrieve objects of different types. They are keyed by
Class, which means that one cannot have a value for a List
and another value for a List in such container. Also one
cannot obtain a List without casting from such container. Type
literals would allow this:

 void put(TypeLiteral type, T value);
 T get(TypeLiteral type);

TypeLiteral stringListType = ...;
List stringList = container.get( stringListType );

* JAX-RS allows to read response message entities into parameterized
types using its GenericType class:

List customers = response.readEntity( new
GenericType() {} );

* CDI allows to dynamically obtain beans of specific parameterized
types using its TypeLiteral class:

@Inject @Any Instance anyPaymentProcessor;

public PaymentProcessor getChequePaymentProcessor() {
PaymentProcessor pp = anyPaymentProcessor
.select( new TypeLiteral() {} ).get();
}

# Proposed solution

Type literals would be represented by a new type
java.lang.reflect.TypeLiteral. Instances would be created via
sub-classing, capturing the  parameter and baking it into the
sub-class:

TypeLiteral stringListType = new
TypeLiteral(){};

That'd allow to provide type-safe APIs around generic types as shown
in the examples above. The following methods should be defined on
TypeLiteral in order to make it useful for implementers of such APIs:

Type getType();
Class getRawType();
boolean equals(Object obj);
int hashCode();
String toString();

# Prior art

The idea of type tokens based on capturing a generic type in a
sub-class has been around for a long time. The first reference I've
found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1].
Examples in real-world APIs and libraries are TypeLiteral in CDI
[2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4]
and TypeToken in Guava [5].

# Alternatives and shortcomings

The obvious alternative would be reified generics, but I think it's
commonly agreed upon that these will not come to the Java language any
time soon. Without native support in the language itself the proposed
type literal class is the best way to support the mentioned use cases
as far as I can say.

Shortcomings are the creation of a sub-class per literal instantiation
(probably more an aesthetic problem, though) and failure of the
pattern when type variables are included anywhere in the represented
type [6]. Unfortunately, this can only be detected at runtime when
instantiating a literal but not by the compiler (although, I reckon it
technically could, by handling this case specifically).

# Conclusion

Lacking reified generics, the Java platform would benefit from the
addition of new type token class java.lang.reflect.TypeLiteral. The
pattern's presence in common APIs and libraries shows that there is a
wide-spread need for such mechanism and the community would benefit
very much from a standardized solution in the JDK itself. This will
allow for more unified API designs as well as foster integration of
different libraries.

I'm eager to learn about your feedback and the OpenJDK team's
assessment of this proposal.

--Gunnar

[1] http://gafter.blogspot.de/2006/12/super-type-tokens.html
[2] 
https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html
[3] 
https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html
[4] 
https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html
[5] 
https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html
[6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

[Roger Riggs]

Hi,

Sorry, I meant DateTimeFormatterBuilder.

Roger


On 12/16/2016 9:28 AM, Roger Riggs wrote:

Hi Abhijit,

Please also fix the same error in DateTimeFormatter; line 300.

I would use '24' as the example of the hour of day.
It would emphasize that the range is 1-24.

Roger


On 12/16/2016 6:19 AM, Abhijit Roy wrote:

Hi all,


Please review the java doc fix for the below bug:

Bug: https://bugs.openjdk.java.net/browse/JDK-8171348

Description: Incorrect documentation for DateTimeFormatter letter 'k'

Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/


I have just rectified and modified those errors. And moving forward 
it for review.



Regards,

Abhijit



P.S.  It will be merged with RFR: JDK-8164923, JDK-8170566, 
JDK-8169482, JDK-8170653

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

[Roger Riggs]

Hi Abhijit,

Please also fix the same error in DateTimeFormatter; line 300.

I would use '24' as the example of the hour of day.
It would emphasize that the range is 1-24.

Roger


On 12/16/2016 6:19 AM, Abhijit Roy wrote:

Hi all,

  


Please review the java doc fix for the below bug:

Bug: https://bugs.openjdk.java.net/browse/JDK-8171348

Description: Incorrect documentation for DateTimeFormatter letter 'k'

Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/

  


I have just rectified and modified those errors. And moving forward it for 
review.

  


Regards,

Abhijit

  

  


P.S.  It will be merged with RFR: JDK-8164923, JDK-8170566, JDK-8169482, 
JDK-8170653

Re: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

[Roger Riggs]

Hi Hamlin,

Yes, the logic would be clearer;  and I would also remove the (now) 
redundant checking.


Roger


On 12/15/2016 9:42 PM, Hamlin Li wrote:

Hi Roger, Daniel,

Thank you for reviewing.

On 2016/12/15 22:45, Roger Riggs wrote:

Hi Hamlin,

If this is supposed to fix the call from line 68: then doesn't the 
test for reg != null

at line 70 already have the same effect?
Please consider the situation: LocateRegistry.createRegistry(port) in 
createReg(true, port) does not throw exception but just return null 
when remoteOk is true. this case is missed by current test. Although 
we know that should not happen by checking the product code, but the 
test should not assume how it is implemented.
And I think the patch will make logic more clear, maybe we could 
remove the check of reg != null at the same time after modify the code 
in createReg(...).


Thank you
-Hamlin


Roger


On 12/14/2016 10:19 PM, Hamlin Li wrote:

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8171133
webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/

java/rmi/registry/reexport/Reexport.java, there is a missing case 
check in createReg(..): if LocateRegistry.createRegistry(port) 
return null when port is in use.


Thank you
-Hamlin
 


diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java
--- a/test/java/rmi/registry/reexport/Reexport.javaTue Dec 13 
18:47:23 2016 -0800
+++ b/test/java/rmi/registry/reexport/Reexport.javaWed Dec 14 
19:06:40 2016 -0800

@@ -105,6 +105,9 @@

 try {
 reg = LocateRegistry.createRegistry(port);
+if (remoteOk) {
+TestLibrary.bomb("Remote registry is up, an 
Exception is expected!");

+}
 } catch (Throwable e) {
 if (remoteOk) {
 System.err.println("EXPECTING PORT IN USE 
EXCEPTION:");

Re: RFR of JDK-8171298: ProblemList java/rmi/registry/readTest/readTest.sh due to JDK-7146543

[Roger Riggs]

Hi Hamlin,

Looks fine.

(Using a subtask for this kind of problem listing works well too; then 
it is clearly related to the original bug.

And isn't an independent issue.  Yes, task bugid can be used for commits).

Thanks, Roger


On 12/16/2016 12:04 AM, Hamlin Li wrote:

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8171298


diff -r 63e82d0eb4f6 test/ProblemList.txt
--- a/test/ProblemList.txtWed Dec 14 19:23:08 2016 -0800
+++ b/test/ProblemList.txtThu Dec 15 21:01:34 2016 -0800
@@ -205,6 +205,8 @@

 java/rmi/transport/dgcDeadLock/DGCDeadLock.java 8029360 macosx-all

+java/rmi/registry/readTest/readTest.sh 7146543 generic-all
+
  



 # jdk_security


Thank you
-Hamlin

Re: RFR: jsr166 jdk9 integration wave 13

[Doug Lea]

On 12/15/2016 01:17 PM, Stefan Zobel wrote:


I recently noticed that javac creates a synthetic class and a bridge constructor
for SubmissionPublisher.ThreadPerTaskExecutor because its generated constructor
is private. I don't know if it really matters but that could be avoided by
declaring a package-private constructor that does nothing.


Or, more simply remove the unnecessary "private" qualifier for the
nested ThreadPerTaskExecutor class, as we did in the similar usage in
CompletableFuture, and should have remembered to do here.
Done; thanks.

-Doug






   /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */
   private static final class ThreadPerTaskExecutor implements Executor {
   // avoid creation of synthetic class and bridge constructor
   ThreadPerTaskExecutor() {}
   public void execute(Runnable r) { new Thread(r).start(); }
   }



Regards,
Stefan

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Jochen Theodorou]

Hi,

I strongly hope Paul and Cedric will be able to start the release 
process next week, if not we will have to do it the old way I think.


what would help us a lot would be you testing the GROOVY_2_4_X branch 
with your build system to see if it really does solve your problem. Even 
if it is only locally on your computer


bye Jochen

On 16.12.2016 10:58, Uwe Schindler wrote:

Hi Jochen,

thank you for the information! Is there any plan about a release? I also found 
no JIRA issue about this issue to link it against our JIRA: 
https://issues.apache.org/jira/browse/LUCENE-7596

The problem makes our build system unusable, so it would be very important to 
have a fix quite soon! As our Ant/Ivy-based build relies on Maven Central, it 
would be good to have the bugfix release available there, which requires a 
release. I think the same applies for Gradle users (Elasticsearch).

As a temporary workaround we might be able to use the Apache Snapshot 
repository, but this is not allowed if we do a release of Lucene.

Uwe

-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/


-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org]
Sent: Saturday, December 10, 2016 9:23 AM
To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
Core-Libs-Dev 
Subject: Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch

On 09.12.2016 23:32, Uwe Schindler wrote:

Hi,

I updated our Jenkins server for the JDK 9 preview testing to use build 148.

Previously we had build 140 and build 147, which both worked without any
issues. But after the update the following stuff goes wrong:


(1) Unmapping of direct buffers no longer works, although this API was

marked as critical because there is no replacement up to now, so code can
unmap memory mapped files, which is one of the most important things
Apache Lucene needs to use to access huge random access files while
reading the index. Without memory mapping, the slowdown for Lucene
users will be huge


This is caused by the recent Jigsaw changes, published in build 148.

Unfortunately we did not test the Jigsaw builds, so we would have noticed
that earlier. Basically the following peace of code fails now (with or without
doPrivileged and with/without security manager):


   final Class directBufferClass =

Class.forName("java.nio.DirectByteBuffer");


   final Method m = directBufferClass.getMethod("cleaner");
   m.setAccessible(true);
   MethodHandle directBufferCleanerMethod = lookup.unreflect(m);
   Class cleanerClass =

directBufferCleanerMethod.type().returnType();

   // build method handle for unmapping, full code is here:

https://goo.gl/TfQWl6

I guess that is the effect of #AwkwardStrongEncapsulation. I would
advise doing regular checks against the jigsaw builds to know about such
problems in the future earlier... but seeing your code break without an
obvious good solution sure is stressful. I feel with you.

[...]

(2) A second thing  we noticed is that Groovy no longer works and dies with

strange error messages.

That is because versions including Groovy 2.4.7 are using
setAccessible(AccessibleObject[] array, true), and the array will also
include private methods or fields. This worked till
#AwkwardStrongEncapsulation because will then a class was either
exported and its method can all be made accessible or not. For example
on GAE or earlier versions of the module system. Now an exported class
may break this, since its private methods can no longer be made
accessible using setAccessible.

A fix for this is already committed, we are only waiting for release of
Groovy 2.4.8. Of course even with the fix Groovy code can possibly
break... for example if you did the direct buffer access in Groovy.

Btw, do not hesitate to ask about such problems on groovy-user, please.

bye Jochen

RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

[Abhijit Roy]

Hi all,

 

Please review the java doc fix for the below bug:

Bug: https://bugs.openjdk.java.net/browse/JDK-8171348

Description: Incorrect documentation for DateTimeFormatter letter 'k'

Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/

 

I have just rectified and modified those errors. And moving forward it for 
review.

 

Regards,

Abhijit

 

 

P.S.  It will be merged with RFR: JDK-8164923, JDK-8170566, JDK-8169482, 
JDK-8170653

Re: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

[Daniel Fuchs]

Hi Rob,

Looks good to me too now.

-- daniel

On 16/12/16 03:21, Vyom Tewari wrote:

Hi Rob,

Code changes looks good to me.

Thanks,

Vyom


On Thursday 15 December 2016 08:27 PM, Rob McKenna wrote:

Gah, thanks Daniel. I originally worked this fix on 8u and neglected to
remove synchronized when forward porting.

I've been having a few discussions on altering how we do locking in this
code in general and CoWArrayList is a nice idea. I'd like to leave this
change until I get to that work though. Thanks for the suggestion.

Updated webrev at: http://cr.openjdk.java.net/~robm/8169465/webrev.02/

 -Rob

On 14/12/16 04:58, Daniel Fuchs wrote:

Hi Rob,

The expire(long) method is already synchronized, so there's no
need to call synchronized(this) inside, unless you forgot to
to remove synchronized from the method declaration?

I wonder if 'conns' could be created as a CopyOnWriteArrayList.
Then maybe no synchronization would be needed? It's the first time
I'm looking at this file - so please accept this as a suggestion
for a simpler (and possibly insufficient) alternative ...

best regards,

-- daniel

On 14/12/16 15:59, Rob McKenna wrote:

Hi folks,

Looking for a review of this change:

http://cr.openjdk.java.net/~robm/8169465/webrev.01/

This is necessary to fix a potential problem where recursive ldap calls
can potentially cause a deadlock with the PoolCleaner thread.

See: https://bugs.openjdk.java.net/browse/JDK-8169465

-Rob

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

[Uwe Schindler]

Hi Jochen,

thank you for the information! Is there any plan about a release? I also found 
no JIRA issue about this issue to link it against our JIRA: 
https://issues.apache.org/jira/browse/LUCENE-7596

The problem makes our build system unusable, so it would be very important to 
have a fix quite soon! As our Ant/Ivy-based build relies on Maven Central, it 
would be good to have the bugfix release available there, which requires a 
release. I think the same applies for Gradle users (Elasticsearch).

As a temporary workaround we might be able to use the Apache Snapshot 
repository, but this is not allowed if we do a release of Lucene.

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: Jochen Theodorou [mailto:blackd...@gmx.org]
> Sent: Saturday, December 10, 2016 9:23 AM
> To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev 
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
> 
> On 09.12.2016 23:32, Uwe Schindler wrote:
> > Hi,
> >
> > I updated our Jenkins server for the JDK 9 preview testing to use build 148.
> Previously we had build 140 and build 147, which both worked without any
> issues. But after the update the following stuff goes wrong:
> >
> > (1) Unmapping of direct buffers no longer works, although this API was
> marked as critical because there is no replacement up to now, so code can
> unmap memory mapped files, which is one of the most important things
> Apache Lucene needs to use to access huge random access files while
> reading the index. Without memory mapping, the slowdown for Lucene
> users will be huge
> >
> > This is caused by the recent Jigsaw changes, published in build 148.
> Unfortunately we did not test the Jigsaw builds, so we would have noticed
> that earlier. Basically the following peace of code fails now (with or without
> doPrivileged and with/without security manager):
> >
> >final Class directBufferClass =
> Class.forName("java.nio.DirectByteBuffer");
> >
> >final Method m = directBufferClass.getMethod("cleaner");
> >m.setAccessible(true);
> >MethodHandle directBufferCleanerMethod = lookup.unreflect(m);
> >Class cleanerClass =
> directBufferCleanerMethod.type().returnType();
> >// build method handle for unmapping, full code is here:
> https://goo.gl/TfQWl6
> 
> I guess that is the effect of #AwkwardStrongEncapsulation. I would
> advise doing regular checks against the jigsaw builds to know about such
> problems in the future earlier... but seeing your code break without an
> obvious good solution sure is stressful. I feel with you.
> 
> [...]
> > (2) A second thing  we noticed is that Groovy no longer works and dies with
> strange error messages.
> 
> That is because versions including Groovy 2.4.7 are using
> setAccessible(AccessibleObject[] array, true), and the array will also
> include private methods or fields. This worked till
> #AwkwardStrongEncapsulation because will then a class was either
> exported and its method can all be made accessible or not. For example
> on GAE or earlier versions of the module system. Now an exported class
> may break this, since its private methods can no longer be made
> accessible using setAccessible.
> 
> A fix for this is already committed, we are only waiting for release of
> Groovy 2.4.8. Of course even with the fix Groovy code can possibly
> break... for example if you did the direct buffer access in Groovy.
> 
> Btw, do not hesitate to ask about such problems on groovy-user, please.
> 
> bye Jochen

Re: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac

[Chris Hegarty]

On 16/12/16 03:43, Wang Weijun wrote:

Please take a review at

   http://cr.openjdk.java.net/~weijun/8171340/webrev.00/

All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)".


Thank you Max. Reviewed.

-Chris.