From maurizio.cimadamore at oracle.com Thu Nov 1 02:12:56 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 01 Nov 2012 09:12:56 +0000 Subject: hg: lambda/lambda/langtools: Fixes to 269 support for intersection types: Message-ID: <20121101091302.14ABE476E8@hg.openjdk.java.net> Changeset: 7ffcc63f2b3d Author: mcimadamore Date: 2012-11-01 09:11 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7ffcc63f2b3d Fixes to 269 support for intersection types: *) typo in IntersectionType interface javadoc *) getEnclosedElements should return empty list when invoked on an intersection type-element ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/type/IntersectionType.java ! test/tools/javac/cast/intersection/model/ModelChecker.java From peter.levart at gmail.com Thu Nov 1 02:13:55 2012 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 01 Nov 2012 10:13:55 +0100 Subject: inference of throws type parameters in SAMs In-Reply-To: <50919CA4.3080802@oracle.com> References: <508FFDCE.9020700@gmail.com> <76AFF182-B17E-44EE-A93A-E83F9B7E3B94@oracle.com> <50915A01.3080506@univ-mlv.fr> <50915DC1.2070401@oracle.com> <509161BF.7000109@univ-mlv.fr> <50916476.30908@oracle.com> <50918F52.6060405@gmail.com> <50919CA4.3080802@oracle.com> Message-ID: <50923D53.9000306@gmail.com> On 10/31/2012 10:48 PM, Maurizio Cimadamore wrote: > On 31/10/12 20:51, Peter Levart wrote: >> On 10/31/2012 06:48 PM, Maurizio Cimadamore wrote: >>> On 31/10/12 17:37, Remi Forax wrote: >>>> On 10/31/2012 06:20 PM, Maurizio Cimadamore wrote: >>>>> On 31/10/12 17:04, Remi Forax wrote: >>>>>> On 10/31/2012 03:53 PM, Dan Smith wrote: >>>>>>> This is on the radar for inference. As you suggest, we would >>>>>>> probably just choose RuntimeException in certain scenarios rather >>>>>>> than using the upper bound. >>>>>>> >>>>>>> We have toyed with some more ambitious ideas for handling >>>>>>> exceptions in lambda bodies, but those won't be part of Java 8. >>>>>>> >>>>>>> ?Dan >>>>>> yes, and my fear is that if we choose something different than >>>>>> Object >>>>>> now (like RuntimeException) >>>>>> we will not be able to change the inference algorithm in Java 9. >>>>>> At least with Object as default, we know that currently the >>>>>> inference >>>>>> fails so >>>>>> we can provide a better one without creating incompatibilities. >>>>> I think Object is never a problem - for this kind of issues to show >>>>> up, the inference variable must appear in the throws clause, which >>>>> means it should be at least <: Throwable. >>>> yes, sorry, >>>> s/Object/Throwable >>>> >>>> Choosing the bound of the unconstrained variable if the variable is >>>> used in a throws in not the better choice, >>>> but before we came with a better algorithm, it's a better choice than >>>> RuntimeException because it doesn't >>>> hamper the use of a better algorithm in the future. >>> Yeah - I think that's kinda the choice ahead of us - on the one >>> hand, if >>> we add exception transparency support in the future, it seems like this >>> case should be handle as a result of that work; on the other hand, >>> inferring RuntimeException could be a reasonable compromise, esp. given >>> that the number of incompatibilities that will occur as a result of an >>> inference upgrade would be pretty low (though it's true that when >>> lambdas are available inference variables in the throws clause might >>> become more common...). >>> >>> Maurizio >> Can we elaborate about incompatibilities that will occur as a result >> of later inference upgrade? >> >> If I understood correctly, you are talking about inference upgrade >> that will happen after JDK8 and which will contain exception >> transparency support. >> >> So, unconstrained variable that is used in functional interface and >> appears only in throws declaration of the sole interface method. What >> incompatibilities can it cause if it is inferred now as >> RuntimeException as opposed to upper bound and in a later release as >> something more appropriate like Nothing? Can we imagine an example? > > An example would be along the following lines (admittedly convoluted): > > interface SAM { > void m() throws X; > } > > List m(SAM s) { ... } > > g(List l) { } //1 > g(Object o) { } //2 > > g(m(()->{})); //resolves to (1) in JDK 8, resolves to (2) in JDK x+1, > x >= 8 ;-) > That would be the case if JDK 8 inferred RuntimeException in certain unconstrained scenarios rather that upper bound. That's true, but so is true that a modified example would suffer form the same incompatibility if JDK8 inferred upper bound in such scenarios (Throwable in this example): g(List l) { } //1 g(Object o) { } //2 g(m(()->{})); //resolves to (1) in JDK 8, resolves to (2) in JDK x+1, x >= 8 This example is bad API. More correctly written API would use: g(List l) { } //1 g(Object o) { } //2 Which is less likely to suffer from an incompatibility - for example if inference upgrade ever used say type Nothing and inferred List in such cases. Regards, Peter > Maurizio > >> >> Regards, Peter >> >>>>> Maurizio >>>> R?mi >>>> >>>>>> R?mi >>>>>> >>>>>>> On Oct 30, 2012, at 10:18 AM, Peter Levart >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I know this has been discussed before, but a long time has >>>>>>>> passed and >>>>>>>> various inference algorithms have been tried in the meanwhile. >>>>>>>> So I >>>>>>>> would like to ask whether current state is final. For example if I >>>>>>>> have >>>>>>>> a functional interface like the following: >>>>>>>> >>>>>>>> public interface ThrowingFactory { >>>>>>>> T make() throws E; >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> And a "hypothetical" method: >>>>>>>> >>>>>>>> public interface Stream { >>>>>>>> T >>>>>>>> findFirstOrElse(ThrowingFactory >>>>>>>> other) throws E; >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Then the following program compiles OK: >>>>>>>> >>>>>>>> public static void main(String... args) throws IOException >>>>>>>> { >>>>>>>> Stream stream = null; >>>>>>>> >>>>>>>> String first = stream.findFirstOrElse(() -> {throw new >>>>>>>> IOException();}); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Which indicates that the inference algorithm does it's job >>>>>>>> correctly. >>>>>>>> But the following program: >>>>>>>> >>>>>>>> public static void main(String... args) >>>>>>>> { >>>>>>>> MyStream stream = null; >>>>>>>> >>>>>>>> String first = stream.findFirstOrElse(() -> "NO >>>>>>>> VALUE"); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Triggers the compilation failure: >>>>>>>> >>>>>>>> error: unreported exception Throwable; must be caught or declared >>>>>>>> to be >>>>>>>> thrown >>>>>>>> String first = stream.findFirstOrElse(() -> "NO >>>>>>>> VALUE"); >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> P.S. If this worked, the controversial TypeThatMustNotBeNamed >>>>>>>> which >>>>>>>> is used as return type of 3 Stream methods could be replaced with >>>>>>>> 3*3=9 >>>>>>>> Stream methods that would more or less fit the main purpose of >>>>>>>> being >>>>>>>> fluent. For example, current Stream.findFirst() would expand to: >>>>>>>> >>>>>>>> public interface Stream { >>>>>>>> T findFirst() throws NoSuchElementException; >>>>>>>> T findFirstOrElse(T other); >>>>>>>> T >>>>>>>> findFirstOrElse(ThrowingFactory >>>>>>>> other) throws E; >>>>>>>> } >>>>>>>> >>>>>>>> Is this to much methods? >>>>>>>> >>>>>>>> >>>>>>>> >>> >> > From david.holmes at oracle.com Thu Nov 1 02:43:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 19:43:42 +1000 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <5092444E.2030708@oracle.com> Hi Mike, A few small comments: BinaryOperator: Typo: the the --- Block: * @param t an input object -> the input object --- typeBinaryOperator * Combines two {@code type} operands of the same type As opposed to two type operands of different type? :) typeMapper explicitly says it is the type specialization of Mapper, but typeBinaryOperator doesn't say the same thing about BinaryOperator. Ditto for UnaryOperator. We need a consistent approach here. --- DoubleUnaryOperator IntUnaryOperator: @param operand The operand value. The -> the General consistency note: sometimes the @param descriptive text starts with a capital and sometimes not. ---- Mapper: "A mapper may variously provide a mapping between types, object instances or keys and values or any other form of transformation upon the input." I can't parse this sentence and I'm not sure it is adding value beyond what is already said in the first sentence. --- UnaryOperator: * @param the type of input objects to {@code operate} and of the result. objects -> object and perhaps "the type of ^the^ input object ..." --- package-info.java * Functional interfaces provide typing for lambda methods. lambda methods? Do you mean lambda expressions? "non-defaulted" is a horrible term. Isn't it simply abstract? Seems to me that "abstract default" should not be permitted and that default wipes out any implicit abstract. That way a default method is not an abstract method, while an abstract method is what it always has been: a method signature with no implementation. + *

All functional interface implementations are expected to: The above lead in does not read correctly with the subsequent bullet points Cheers, David On 1/11/2012 6:16 AM, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. > > The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome. > > Elements of this naming scheme include: > - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. > - The argument lists are structured so that specializations act on the first argument(s), so IntMapper is a specialization of Mapper, and IntBinaryOperator is a specialization of BinaryOperator. > > In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: > > - We are time-boxed at one week. (until Nov. 7th) > > - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. > > - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ From jim.gish at oracle.com Thu Nov 1 07:49:15 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 01 Nov 2012 10:49:15 -0400 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <50928BEB.6050702@oracle.com> Hi Mike, Just a few minor javadoc suggestions. Otherwise, the "meat" looks good. Thanks, Jim ----------------------------------------------------------------------------------- Copyrights - - why do some of the copyrights say 2010, 2011, 2012 ? Is this the correct format? DoubleBinaryOperater.java (and others) just have 2012 java/util/BinaryOperator.java - why is extends Combiner commented out on the interface decl? Is this part of the phase-in of these changes? - for the javadoc for operate(T,T), I'd say "Returns the result of some /binary /operation upon the operands." java/util/DoubleBinaryOperator.java - for the javadoc for operate(double,double), I'd say "Returns the result of some /binary /operation upon the operands." java/util/DoubleMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code double) value" java/util/DoubleUnaryOperator.java - "Returns a {@code double} value computed from the double operand." Should the second "double" also be "{@code double}"? java/util/functions/Factory.java - "Returns an object. The returned object may be an existing object or a newly created object." This might be better: "Returns an object which may have been created previously or is newly created." - for make() - "Returns an object" --> "Creates and returns an object or returns one previously created" java/util/functions/IntBinaryOperator.java - " Combines two {@code int} operands of the same type producing an {@code int} result" -- I'd insert a comma between "type" and "producing" - "some operation" -> "some /binary/ operation" java/util/IntMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code int) value" java/util/functions/LongBinaryOperator.java - "some operation" -> "some /binary/ operation" java/util/LongMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code long) value" java/util/Mapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate output object" java.util/functions/Predicate.java - I think "condition" might be better than "criteria" java/util/functions/UnaryOperator.java - "@param the type of input objects to {@code operate} and of the result" is hard to parse. Perhaps this would be better: "@param the operand and result type of the {@code operate} method" - why is "extends Map" commented out? java/util/functions/package-info.html - this seems a little awkward: 35 *

All functional interface implementations are expected to: 36 *

    37 *
  • When used for aggregate operations upon many elements it should not be 38 * assumed that the operation will be called upon elements in any specific order. 39 *
  • 40 *
It appears you were/are expecting additional things to be added to the list of expectations. Maybe it would be best to reserve the list structure of the comment for the time where additional conditions are added. Until then a simpler sentence would be cleaner: "When used for aggregate operations upon many elements, no functional interface implementation should assume that the operation will be called upon elements in any specific order. As Porky would say, That's all folks! :-) On 10/31/2012 04:16 PM, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. > > The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome. > > Elements of this naming scheme include: > - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. > - The argument lists are structured so that specializations act on the first argument(s), so IntMapper is a specialization of Mapper, and IntBinaryOperator is a specialization of BinaryOperator. > > In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: > > - We are time-boxed at one week. (until Nov. 7th) > > - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. > > - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From brian.goetz at oracle.com Thu Nov 1 09:19:24 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 01 Nov 2012 16:19:24 +0000 Subject: hg: lambda/lambda/jdk: Add Iterator.forEach; add Atomic{Reference, Int, Loference, Int, Long}FieldUpdater.{getAndUpdate, updateAndGet} Message-ID: <20121101162027.31675476EF@hg.openjdk.java.net> Changeset: 0afeaddee9cf Author: briangoetz Date: 2012-11-01 12:19 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0afeaddee9cf Add Iterator.forEach; add Atomic{Reference,Int,Loference,Int,Long}FieldUpdater.{getAndUpdate,updateAndGet} ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/streams/Spliterator.java ! src/share/classes/java/util/streams/StreamAccessor.java ! src/share/classes/java/util/streams/Streams.java ! src/share/classes/java/util/streams/ops/Nodes.java From marc at petit-huguenin.org Thu Nov 1 11:23:58 2012 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Thu, 01 Nov 2012 11:23:58 -0700 Subject: Javadoc with new build [was Re: Build error on OSX] In-Reply-To: <508C7F71.30301@oracle.com> References: <462FB1E3-E6A4-4017-AEDC-CDB449EE9F1D@oracle.com> <506738EF.3020204@petit-huguenin.org> <7A5EC587-308D-4A3C-9A55-C33BEAB2AA89@oracle.com> <508C5CC0.4020805@petit-huguenin.org> <508C7F71.30301@oracle.com> Message-ID: <5092BE3E.4070806@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/27/2012 05:42 PM, Brian Goetz wrote: >> That come too late for me - as now that MapStream is no longer in the >> API, JDK 1.8 becomes useless for my projects - but hopefully this will >> help someone else. > > Are you sure? One of the reasons that we dropped MapStream is that a > significant majority of its use cases are served by: > > map.entrySet().stream() Not even talking about other MapStream sources (I yet have to use Map for anything else than testing my algorithms), that forces to create new instances of Map.SimpleImmutableEntry in each map step, making my code as ugly (and probably inefficient) as it was with iteration 1. I can live with that, but that becomes too difficult for other people who will have to maintain it, and that's why I have to abandon jdk 1.8 for these projects. I'll still use jdk 1.8 for prototyping though. > > or by Stream.reduceBy. If you've got use cases which think can't be > handled, post 'em here and let us see. > - -- Marc Petit-Huguenin Email: marc at petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQkr49AAoJECnERZXWan7EfNkQANDw3QUnVmLl6Kkn3oYc0xcZ bNYWF6fVnuV8z1tJjqBQPjM3cQEvYoASFqiTveTUS9U9iVdgD9n29OyRQ8zC23CA NKBDZr8yCwqIR6Xubx84motNmFGb5GciCGu6jDFEhXAoKIWBUuHpibi5lmU4edGo ZRP8pBOAySandvxaOD8TowfYeyA6zh1/f8xbq05+OHpWBIIKCn61QBqZNcC8usm4 mVxRFZhxRXPKRmTeVeAPlC9XizGL/xxrbPTwjOYcJL4QPaoVswBLkA7see8eN/ut Hpl87zVSMfwsc5gxxQWtwJko3pIQ8ptUlIvz9xZ0c1B5ckn0KSr51qiEkjaSBi8v FjOO953ZOSaQgNOQpWc51jYGN/4L8HhQYo2sn5xcxyBLqLbPSb5jfkwf93CJHMaE glLX3bOmLSKnBQ2uEW77rN5r88A9BvuILBNW+p5eVvFsr6mC3PxUPmlx4M3KO3Hl nGxUGKAQE2Dy6ZVtIqOlRR/hOvyQcODjDOgM3fB2F0Kz5VB6ajabN5TfRdp/4tvq K8Nhk2o0D1E6GNPzEIXErXJfWedMqAy/YWrF3Z6iPLTVcwDGCGGmNkl40kI+wigW DJsg7YW0gcHdkV4BAgeHwwBI2Kb5Cg/8EtymqH3MEWmEUkwiuCaZxJjZRkjKexwz Ykc1Y3cBZwjAK0Qac4yR =+T4Y -----END PGP SIGNATURE----- From brian.goetz at oracle.com Thu Nov 1 12:38:11 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 01 Nov 2012 19:38:11 +0000 Subject: hg: lambda/lambda/jdk: Garbage-collect unneeded stream building abstractions; generics and duplication cleanup in ArrayList Message-ID: <20121101193843.1C6E3476F5@hg.openjdk.java.net> Changeset: 0f187cdcacb3 Author: briangoetz Date: 2012-11-01 15:37 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0f187cdcacb3 Garbage-collect unneeded stream building abstractions; generics and duplication cleanup in ArrayList ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/streams/Streams.java From paul.sandoz at oracle.com Fri Nov 2 01:44:48 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 02 Nov 2012 08:44:48 +0000 Subject: hg: lambda/lambda/jdk: clarify docs Message-ID: <20121102084534.9E8C947729@hg.openjdk.java.net> Changeset: 0fe3dad5e617 Author: psandoz Date: 2012-11-02 09:35 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0fe3dad5e617 clarify docs ! src/share/classes/java/util/Iterator.java From paul.sandoz at oracle.com Fri Nov 2 03:40:37 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 02 Nov 2012 10:40:37 +0000 Subject: hg: lambda/lambda/jdk: - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] Message-ID: <20121102104145.2FA4B4772A@hg.openjdk.java.net> Changeset: a894d11817f6 Author: psandoz Date: 2012-11-02 11:36 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a894d11817f6 - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] - Change stream.sequential() to use a stateful collection operation that is a no-op for sequential evaluation. For parallel evaluation the intermediate node that is produced from collection will ensure the rest of the pipeline will be evaluated sequentially. - Expanded the flag op tests to test setting, clearing and preservation of flags sequential and parallel evaluation. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/StreamOpFlags.java ! src/share/classes/java/util/streams/ValuePipeline.java - src/share/classes/java/util/streams/ops/CollectorOp.java + src/share/classes/java/util/streams/ops/CollectorOps.java ! src/share/classes/java/util/streams/ops/Node.java ! src/share/classes/java/util/streams/ops/Nodes.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java From georgiy.rakov at oracle.com Fri Nov 2 04:45:42 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 02 Nov 2012 15:45:42 +0400 Subject: User control over splitting granularity while parallel processing Message-ID: <5093B266.2030806@oracle.com> Hello, current public API seems to have no means allowing user to control the granularity of splitting sequences while parallel processing. It seems to be useful because the computational complexity of supplied functors (predicates, blocks, ... , etc) is known by nobody but user who's created it. I wonder whether such means are going to be introduced. And if they are not why? Thank you, Georgiy. From maurizio.cimadamore at oracle.com Fri Nov 2 04:46:11 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 02 Nov 2012 11:46:11 +0000 Subject: hg: lambda/lambda/langtools: Add temporary workaround to support intersection-type targets on lambdas method references. Message-ID: <20121102114622.99ECD4772C@hg.openjdk.java.net> Changeset: c9a4b3c92810 Author: mcimadamore Date: 2012-11-02 11:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c9a4b3c92810 Add temporary workaround to support intersection-type targets on lambdas method references. Type-checking code will now use the _first_ interface bound of an intersection type as the target type for lambdas/method refs. This allows code using patterns such as: (Predicate & Serializable)x->false To compile and behave exactly like before: additional interface bounds are simply ignored. ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out From aleksey.shipilev at oracle.com Fri Nov 2 04:59:18 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 02 Nov 2012 15:59:18 +0400 Subject: User control over splitting granularity while parallel processing In-Reply-To: <5093B266.2030806@oracle.com> References: <5093B266.2030806@oracle.com> Message-ID: <5093B596.2000100@oracle.com> Hi Georgiy, On 11/02/2012 03:45 PM, Georgiy Rakov wrote: > It seems to be useful because the computational complexity of supplied > functors (predicates, blocks, ... , etc) is known by nobody but user > who's created it. Exactly. There is some freedom for automatic optimization though. > I wonder whether such means are going to be introduced. And if they are > not why? It is being discussed. If you have the concrete suggestions about the API you would see useful, please shoot them here. -Aleksey. From pbenedict at apache.org Fri Nov 2 07:27:15 2012 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 2 Nov 2012 09:27:15 -0500 Subject: hg: lambda/lambda/jdk: - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] In-Reply-To: <20121102104145.2FA4B4772A@hg.openjdk.java.net> References: <20121102104145.2FA4B4772A@hg.openjdk.java.net> Message-ID: The "Evaluation works in two modes" comment doesn't need to be a javadoc comment. It's just a comment since it doesn't describe any field/method. However, with a description that good, I am surprised it isn't part of the class' javadoc. Paul On Fri, Nov 2, 2012 at 5:40 AM, wrote: > Changeset: a894d11817f6 > Author: psandoz > Date: 2012-11-02 11:36 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a894d11817f6 > > - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] > - Change stream.sequential() to use a stateful collection operation that is > a no-op for sequential evaluation. For parallel evaluation the > intermediate > node that is produced from collection will ensure the rest of the > pipeline > will be evaluated sequentially. > - Expanded the flag op tests to test setting, clearing and preservation of > flags sequential and parallel evaluation. > > ! src/share/classes/java/util/streams/AbstractPipeline.java > ! src/share/classes/java/util/streams/StreamOpFlags.java > ! src/share/classes/java/util/streams/ValuePipeline.java > - src/share/classes/java/util/streams/ops/CollectorOp.java > + src/share/classes/java/util/streams/ops/CollectorOps.java > ! src/share/classes/java/util/streams/ops/Node.java > ! src/share/classes/java/util/streams/ops/Nodes.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java > > > From paul.sandoz at oracle.com Fri Nov 2 07:41:28 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Nov 2012 15:41:28 +0100 Subject: hg: lambda/lambda/jdk: - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] In-Reply-To: References: <20121102104145.2FA4B4772A@hg.openjdk.java.net> Message-ID: <4B1CEADD-DF3D-426E-9E4A-F0AF037373B0@oracle.com> On Nov 2, 2012, at 3:27 PM, Paul Benedict wrote: > The "Evaluation works in two modes" comment doesn't need to be a javadoc comment. It's just a comment since it doesn't describe any field/method. However, with a description that good, I am surprised it isn't part of the class' javadoc. > Thanks, i will push it up. FWIW i did not intend it to be a JavaDoc comment, just i am so used to writing JavaDoc comments :-) Paul. > Paul > > On Fri, Nov 2, 2012 at 5:40 AM, wrote: > Changeset: a894d11817f6 > Author: psandoz > Date: 2012-11-02 11:36 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a894d11817f6 > > - Revert evaluation to use IntermediateOp[] rather than AbstractPipeline[] > - Change stream.sequential() to use a stateful collection operation that is > a no-op for sequential evaluation. For parallel evaluation the intermediate > node that is produced from collection will ensure the rest of the pipeline > will be evaluated sequentially. > - Expanded the flag op tests to test setting, clearing and preservation of > flags sequential and parallel evaluation. > > ! src/share/classes/java/util/streams/AbstractPipeline.java > ! src/share/classes/java/util/streams/StreamOpFlags.java > ! src/share/classes/java/util/streams/ValuePipeline.java > - src/share/classes/java/util/streams/ops/CollectorOp.java > + src/share/classes/java/util/streams/ops/CollectorOps.java > ! src/share/classes/java/util/streams/ops/Node.java > ! src/share/classes/java/util/streams/ops/Nodes.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java > > > From maurizio.cimadamore at oracle.com Sat Nov 3 08:01:46 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 03 Nov 2012 15:01:46 +0000 Subject: hg: lambda/lambda/langtools: Misc cleanups: Message-ID: <20121103150155.41FC34775A@hg.openjdk.java.net> Changeset: 39145a667f8a Author: mcimadamore Date: 2012-11-03 15:00 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/39145a667f8a Misc cleanups: *) Remove fixup of speculative cache *) Remove 'hack' to make recovery attribution of speculative types work *) Fixed use of static field Warner.noWarnings causing spurious unchecked warnings during test runs *) Refactored code for Attr.checkId ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/GraphInfer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/lambda/BadRecovery.out ! test/tools/javac/lambda/Intersection01.java From paul.sandoz at oracle.com Sat Nov 3 12:23:04 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Sat, 03 Nov 2012 19:23:04 +0000 Subject: hg: lambda/lambda/jdk: - removed StreamAccessor Message-ID: <20121103192358.1AFE54775D@hg.openjdk.java.net> Changeset: ecf2a2d21af8 Author: psandoz Date: 2012-11-03 20:12 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ecf2a2d21af8 - removed StreamAccessor - AbstractPipeline now operates on a Spliterator and flags - the StreamOfFlags.PARALLEL defines whether sequential or parallel evaluation is performed - Simplify static methods on Streams to create a Stream for Iterable Iterator, Spliterator and arrays. (ArrayProxy support is commented out and needs to be revisisted) - Fixed issues with Spliterator of SpinedList returning incorrect known size - Increase test coverage for Node and NodeBuilder instances. ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/Spliterator.java - src/share/classes/java/util/streams/StreamAccessor.java ! src/share/classes/java/util/streams/StreamOpFlags.java ! src/share/classes/java/util/streams/Streams.java ! src/share/classes/java/util/streams/ValuePipeline.java ! src/share/classes/java/util/streams/ops/CollectorOps.java ! src/share/classes/java/util/streams/ops/Node.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java From paul.sandoz at oracle.com Mon Nov 5 05:36:42 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 05 Nov 2012 13:36:42 +0000 Subject: hg: lambda/lambda/jdk: Move Spliterator.shouldNotSplit to ParallelPipelineHelper.suggestSplit Message-ID: <20121105133730.3223F47787@hg.openjdk.java.net> Changeset: cb5a68c2e6cf Author: psandoz Date: 2012-11-05 14:28 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb5a68c2e6cf Move Spliterator.shouldNotSplit to ParallelPipelineHelper.suggestSplit ensuring that Spliterator is only about splitting and element access. ParallelPipelineHelper is in a better position to centralize the suggestion that a split should be peformed given information on spliterator and properties both static and dynamic of the F/J pool and platform. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/ParallelPipelineHelper.java ! src/share/classes/java/util/streams/Spliterator.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/CumulateOp.java ! src/share/classes/java/util/streams/ops/TreeUtils.java From paul.sandoz at oracle.com Mon Nov 5 06:14:35 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 05 Nov 2012 14:14:35 +0000 Subject: hg: lambda/lambda/jdk: JavaDoc for abstract pipeline. Message-ID: <20121105141500.A229F47788@hg.openjdk.java.net> Changeset: 33e0259f7495 Author: psandoz Date: 2012-11-05 15:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/33e0259f7495 JavaDoc for abstract pipeline. ! src/share/classes/java/util/streams/AbstractPipeline.java From boaznahum at gmail.com Mon Nov 5 06:41:04 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 5 Nov 2012 16:41:04 +0200 Subject: Will JDK 8 support SAM that is Abstract Class ? Message-ID: I can't find what the spec is saying, but I remember that Abstract class with one abstract method is also SAM. Currently in b63 I got java: incompatible types: the target type must be a functional interface Will it be supported in the future ? Thanks Boaz From paul.sandoz at oracle.com Mon Nov 5 06:43:11 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 05 Nov 2012 14:43:11 +0000 Subject: hg: lambda/lambda/jdk: The type parameter declarations of nominal function types (SAMs in j.u.functions) Message-ID: <20121105144332.DDAAF47789@hg.openjdk.java.net> Changeset: e60b1819b652 Author: psandoz Date: 2012-11-05 15:21 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 The type parameter declarations of nominal function types (SAMs in j.u.functions) that return a value are re-ordered so that the return type parameter is declared first (e.g. Mapper and FlatMapper). ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/functions/BiMapper.java ! src/share/classes/java/util/functions/BinaryOperator.java ! src/share/classes/java/util/functions/Combiner.java ! src/share/classes/java/util/functions/FlatMapper.java ! src/share/classes/java/util/functions/Mapper.java ! src/share/classes/java/util/functions/Mappers.java ! src/share/classes/java/util/functions/Predicates.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/ValuePipeline.java ! src/share/classes/java/util/streams/ops/FlatMapOp.java ! src/share/classes/java/util/streams/ops/FoldOp.java ! src/share/classes/java/util/streams/ops/GroupByOp.java ! src/share/classes/java/util/streams/ops/MapOp.java ! src/share/classes/java/util/streams/ops/MatchOp.java ! src/share/classes/java/util/streams/ops/ReduceByOp.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java From reinier at zwitserloot.com Mon Nov 5 07:00:32 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 5 Nov 2012 16:00:32 +0100 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: Message-ID: It was part of the original plan, but I believe non-interface SAMs have been dropped. I'm guessing because it was difficult to handle the peculiars of working with MethodHandles and not actually making a new instance of the SAM type. --Reinier Zwitserloot On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: > I can't find what the spec is saying, but I remember that Abstract class > with one abstract method is also SAM. > > Currently in b63 I got java: incompatible types: the target type must be a > functional interface > > Will it be supported in the future ? > > Thanks > Boaz > > From boaznahum at gmail.com Mon Nov 5 07:08:11 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 5 Nov 2012 17:08:11 +0200 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: Message-ID: Does it mean that all 'old' inner classes extending adapters cant be converted to lambda(assuming converting the adapter to SAM)? Please say no: ( Thanks Boaz On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" wrote: > It was part of the original plan, but I believe non-interface SAMs have > been dropped. I'm guessing because it was difficult to handle the peculiars > of working with MethodHandles and not actually making a new instance of the > SAM type. > > --Reinier Zwitserloot > > > > On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: > >> I can't find what the spec is saying, but I remember that Abstract class >> with one abstract method is also SAM. >> >> Currently in b63 I got java: incompatible types: the target type must be a >> functional interface >> >> Will it be supported in the future ? >> >> Thanks >> Boaz >> >> > From paul.sandoz at oracle.com Mon Nov 5 07:49:36 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Nov 2012 16:49:36 +0100 Subject: Stream.unordered() Message-ID: <96901DC8-35A6-421D-A661-204BF53EB418@oracle.com> HI, See attached for a patch that adds Stream.unordered(). This method will clear the encounter order flag. When this flag is cleared certain downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order. Such algorithms may be more efficient than order preserving algorithms, although i would say that one should not presume this to be a general assumption and has to be taken on a case by case basis. One such example is obtaining unique elements. When encounter order is to be preserved it might be required to merge the linked hash sets produced at the leaves of the computation tree. That merging has a cost, i suspect it is rather tricky to write a parallel set merge algorithm, so a naive implementation would just take the set on the left hand side of a tree and merge with set on the right hand side using Set.addAll. When encounter order need not be preserved one can stuff elements as and when they are produced into a shared ConcurrentHashMap. Paul. -------------- next part -------------- From forax at univ-mlv.fr Mon Nov 5 09:13:51 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 05 Nov 2012 18:13:51 +0100 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: Message-ID: <5097F3CF.2030601@univ-mlv.fr> On 11/05/2012 04:08 PM, Boaz Nahum wrote: > Does it mean that all 'old' inner classes extending adapters cant be > converted to lambda(assuming converting the adapter to SAM)? > Please say no: ( We drop that support because an abstract class has a constructor (at least one) that can observe the creation of the lambda so it defeat most of the optimizations that the VM can do. The other problem was to deal with abstract class with a constructor that may throw an exception because again, the construction of the lambda is observable. You can still retrofit your code to use lambda using delegation instead of inheritance. By example: abstract class Foo { Foo() { // some side effects } public abstract void m(T element); } Foo foo = new Foo() { public void m(String s) { // lambda code } }; can be retrofitted to: class Foo { private final Block block; Foo(Block block) { this.block = block; // some side effects } public void m(T element) { block.apply(element); } } Foo foo = new Foo((String s) -> { // lambda code }); > > Thanks > Boaz Cheers, R?mi > On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" > wrote: > >> It was part of the original plan, but I believe non-interface SAMs have >> been dropped. I'm guessing because it was difficult to handle the peculiars >> of working with MethodHandles and not actually making a new instance of the >> SAM type. >> >> --Reinier Zwitserloot >> >> >> >> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: >> >>> I can't find what the spec is saying, but I remember that Abstract class >>> with one abstract method is also SAM. >>> >>> Currently in b63 I got java: incompatible types: the target type must be a >>> functional interface >>> >>> Will it be supported in the future ? >>> >>> Thanks >>> Boaz >>> >>> From paul.sandoz at oracle.com Mon Nov 5 08:22:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Nov 2012 17:22:39 +0100 Subject: Stream.unordered() In-Reply-To: <96901DC8-35A6-421D-A661-204BF53EB418@oracle.com> References: <96901DC8-35A6-421D-A661-204BF53EB418@oracle.com> Message-ID: Grrr. attachments (even just textual attachments of a reasonable size) are removed... Paul. On Nov 5, 2012, at 4:49 PM, Paul Sandoz wrote: > HI, > > See attached for a patch that adds Stream.unordered(). > > This method will clear the encounter order flag. When this flag is cleared certain downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order. > > Such algorithms may be more efficient than order preserving algorithms, although i would say that one should not presume this to be a general assumption and has to be taken on a case by case basis. > > One such example is obtaining unique elements. > > When encounter order is to be preserved it might be required to merge the linked hash sets produced at the leaves of the computation tree. That merging has a cost, i suspect it is rather tricky to write a parallel set merge algorithm, so a naive implementation would just take the set on the left hand side of a tree and merge with set on the right hand side using Set.addAll. > > When encounter order need not be preserved one can stuff elements as and when they are produced into a shared ConcurrentHashMap. > > Paul. > > > > diff -r e60b1819b652 src/share/classes/java/util/streams/Stream.java --- a/src/share/classes/java/util/streams/Stream.java Mon Nov 05 15:21:49 2012 +0100 +++ b/src/share/classes/java/util/streams/Stream.java Mon Nov 05 16:24:46 2012 +0100 @@ -113,8 +113,21 @@ Optional findAny(); + /** + * Convert this stream, if a parallel stream, to a sequential stream. + * + * @return a sequential stream. + */ Stream sequential(); + /** + * Convert this stream to a stream that has no encounter order. + *

Parallel evaluation of downstream operations are free process input elements and produce output elements + * in any order.

+ * + * @return a stream whose output elements have no encounter order. + */ + Stream unordered(); /** * An aggregate that supports an {@code addAll(Stream)} operation. diff -r e60b1819b652 src/share/classes/java/util/streams/ValuePipeline.java --- a/src/share/classes/java/util/streams/ValuePipeline.java Mon Nov 05 15:21:49 2012 +0100 +++ b/src/share/classes/java/util/streams/ValuePipeline.java Mon Nov 05 16:24:46 2012 +0100 @@ -163,6 +163,11 @@ } @Override + public Stream unordered() { + return chainValue(new FlagDeclaringOp(StreamOpFlags.NOT_ORDERED)); + } + + @Override public U reduce(final U seed, final BinaryOperator op) { return pipeline(new FoldOp<>(seed, op, op)); } diff -r e60b1819b652 test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java Mon Nov 05 16:24:46 2012 +0100 @@ -0,0 +1,54 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ +package org.openjdk.tests.java.util.streams.ops; + +import org.testng.annotations.Test; + +import java.util.Arrays; +import java.util.EnumSet; +import java.util.streams.*; + + at Test +public class UnorderedStreamTest { + + public void testUnordered() { + testUnordered(Arrays.asList(1, 2, 3).stream()); + testUnordered(Arrays.asList(1, 2, 3).parallel()); + } + + void testUnordered(Stream s) { + s = s.unordered(); + + @SuppressWarnings("unchecked") + Stream st = new ValuePipeline( + (AbstractPipeline)s, + new FlagOpTest.TestFlagExpectedOp<>(0, + EnumSet.noneOf(StreamOpFlags.class), + EnumSet.noneOf(StreamOpFlags.class), + EnumSet.of(StreamOpFlags.ORDERED))); + st.toArray(); + } + +} From eric.caspole at amd.com Mon Nov 5 08:33:14 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 5 Nov 2012 11:33:14 -0500 Subject: Build seems to refer to non-existant classes? Message-ID: <5097EA4A.1020706@amd.com> Hi everybody, I am having trouble building the lambda jdk fresh checkout this morning, but I made a change shown below to get it to succeed. Is something wrong with my build setup or are the build files actually out of sync with the java source? Thanks, Eric I am using Ubuntu 12.04 here. hg clone http://hg.openjdk.java.net/lambda/lambda/ ./get_source.sh make ARCH_DATA_MODEL=64 I am not sure if I can build lambda against JDK 7 but everything seems more or less OK, and make sanity works. I have: ALT_JDK_IMPORT_PATH=/opt/jdk1.7.0_09/ LANG=C ALT_BOOTDIR=/opt/jdk1.7.0_09/ Thanks, Eric The error I was getting is: NAWK="/usr/bin/gawk" SED="/bin/sed" SORT="/usr/bin/sort" \ /bin/sh localegen.sh "FormatData CollationData TimeZoneNames LocaleNames CurrencyNames CalendarData" /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.euro \ /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.noneuro ../../../src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java make[4]: *** No rule to make target `/home/ecaspole/views/lambda/lambda/build/linux-amd64/classes/java/util/streams/ops/CollectorOp.class', needed by `/home/ecaspole/views/lambda/lambda/build/linux-amd64/tmp/java/java.lang/java/.classes.list'. Stop. make[4]: Leaving directory `/home/ecaspole/views/lambda/lambda/jdk/make/java/java' make[3]: *** [all] Error 1 make[3]: Leaving directory `/home/ecaspole/views/lambda/lambda/jdk/make/java' make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/ecaspole/views/lambda/lambda/jdk/make' make[1]: *** [jdk-build] Error 2 make[1]: Leaving directory `/home/ecaspole/views/lambda/lambda' make: *** [build_product_image] Error 2 ecaspole at ecaspole-desktop:~/views/lambda/lambda$ I made this change to erase references to non-existant files: ecaspole at ecaspole-desktop:~/views/lambda/lambda/jdk$ hg diff make/java/java/FILES_java.gmk diff -r e60b1819b652 make/java/java/FILES_java.gmk --- a/make/java/java/FILES_java.gmk Mon Nov 05 15:21:49 2012 +0100 +++ b/make/java/java/FILES_java.gmk Mon Nov 05 11:25:09 2012 -0500 @@ -422,7 +422,7 @@ java/util/streams/AbstractPipeline.java \ java/util/streams/BaseStream.java \ java/util/streams/ops/AbstractTask.java \ - java/util/streams/ops/CollectorOp.java \ + java/util/streams/ops/CollectorOps.java \ java/util/streams/ops/ConcatOp.java \ java/util/streams/ops/CumulateOp.java \ java/util/streams/ops/FilterOp.java \ @@ -457,7 +457,6 @@ java/util/streams/Sink.java \ java/util/streams/Spliterator.java \ java/util/streams/Streamable.java \ - java/util/streams/StreamAccessor.java \ java/util/streams/Stream.java \ java/util/streams/StreamOpFlags.java \ java/util/streams/StreamShape.java \ From kevinb at google.com Mon Nov 5 08:41:39 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 5 Nov 2012 08:41:39 -0800 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: <5097F3CF.2030601@univ-mlv.fr> References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: I was initially pro-abstract-class-support, but after taking a hard look at just how often such a feature is really needed I changed my mind. If abstract classes were supported, there would be a magical hidden invocation of user code here: SomeType x = () -> 1; ... namely, the SomeType constructor. That constructor could do anything, including throw checked exceptions -- this is pretty surprising and goes against the "feel" of lambda expressions. And note there'd be no way to invoke a constructor that had parameters anyway. When we really must extend a SAM abstract class, we'll just have to continue to use an anonymous class, and that's fine. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From paul.sandoz at oracle.com Mon Nov 5 09:04:30 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 05 Nov 2012 17:04:30 +0000 Subject: hg: lambda/lambda/jdk: Sync old build system. Message-ID: <20121105170452.4287F47790@hg.openjdk.java.net> Changeset: 685d2eb9aa05 Author: psandoz Date: 2012-11-05 18:03 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/685d2eb9aa05 Sync old build system. ! make/java/java/FILES_java.gmk From paul.sandoz at oracle.com Mon Nov 5 09:08:43 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Nov 2012 18:08:43 +0100 Subject: Build seems to refer to non-existant classes? In-Reply-To: <5097EA4A.1020706@amd.com> References: <5097EA4A.1020706@amd.com> Message-ID: Hi Eric, We generally use the new build system [1] and tend not to update the current build system unless someone shouts out or a formal build is required. I pushed an update according to your change, thanks for that: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/685d2eb9aa05 Paul. [1] http://openjdk.java.net/projects/build-infra/guide.html On Nov 5, 2012, at 5:33 PM, Eric Caspole wrote: > Hi everybody, > I am having trouble building the lambda jdk fresh checkout this morning, > but I made a change shown below to get it to succeed. Is something wrong > with my build setup or are the build files actually out of sync with the > java source? > > Thanks, > Eric > > > I am using Ubuntu 12.04 here. > > hg clone http://hg.openjdk.java.net/lambda/lambda/ > ./get_source.sh > make ARCH_DATA_MODEL=64 > > I am not sure if I can build lambda against JDK 7 but everything seems > more or less OK, and make sanity works. I have: > ALT_JDK_IMPORT_PATH=/opt/jdk1.7.0_09/ > LANG=C > ALT_BOOTDIR=/opt/jdk1.7.0_09/ > > Thanks, > Eric > > > The error I was getting is: > > > NAWK="/usr/bin/gawk" SED="/bin/sed" SORT="/usr/bin/sort" \ > /bin/sh localegen.sh "FormatData CollationData TimeZoneNames > LocaleNames CurrencyNames CalendarData" > /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.euro > \ > > /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.noneuro > ../../../src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template > /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java > make[4]: *** No rule to make target > `/home/ecaspole/views/lambda/lambda/build/linux-amd64/classes/java/util/streams/ops/CollectorOp.class', > needed by > `/home/ecaspole/views/lambda/lambda/build/linux-amd64/tmp/java/java.lang/java/.classes.list'. > Stop. > make[4]: Leaving directory > `/home/ecaspole/views/lambda/lambda/jdk/make/java/java' > make[3]: *** [all] Error 1 > make[3]: Leaving directory > `/home/ecaspole/views/lambda/lambda/jdk/make/java' > make[2]: *** [all] Error 1 > make[2]: Leaving directory `/home/ecaspole/views/lambda/lambda/jdk/make' > make[1]: *** [jdk-build] Error 2 > make[1]: Leaving directory `/home/ecaspole/views/lambda/lambda' > make: *** [build_product_image] Error 2 > ecaspole at ecaspole-desktop:~/views/lambda/lambda$ > > > > I made this change to erase references to non-existant files: > > ecaspole at ecaspole-desktop:~/views/lambda/lambda/jdk$ hg diff > make/java/java/FILES_java.gmk > diff -r e60b1819b652 make/java/java/FILES_java.gmk > --- a/make/java/java/FILES_java.gmk Mon Nov 05 15:21:49 2012 +0100 > +++ b/make/java/java/FILES_java.gmk Mon Nov 05 11:25:09 2012 -0500 > @@ -422,7 +422,7 @@ > java/util/streams/AbstractPipeline.java \ > java/util/streams/BaseStream.java \ > java/util/streams/ops/AbstractTask.java \ > - java/util/streams/ops/CollectorOp.java \ > + java/util/streams/ops/CollectorOps.java \ > java/util/streams/ops/ConcatOp.java \ > java/util/streams/ops/CumulateOp.java \ > java/util/streams/ops/FilterOp.java \ > @@ -457,7 +457,6 @@ > java/util/streams/Sink.java \ > java/util/streams/Spliterator.java \ > java/util/streams/Streamable.java \ > - java/util/streams/StreamAccessor.java \ > java/util/streams/Stream.java \ > java/util/streams/StreamOpFlags.java \ > java/util/streams/StreamShape.java \ > > > > > From eric.caspole at amd.com Mon Nov 5 09:14:16 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 5 Nov 2012 12:14:16 -0500 Subject: Build seems to refer to non-existant classes? In-Reply-To: References: <5097EA4A.1020706@amd.com> Message-ID: <5097F3E8.3060405@amd.com> OK, thanks. I will try the new build system from now on. I was aware of it out there somewhere but have not really run into it yet. Eric On 11/05/2012 12:08 PM, Paul Sandoz wrote: > Hi Eric, > > We generally use the new build system [1] and tend not to update the > current build system unless someone shouts out or a formal build is > required. > > I pushed an update according to your change, thanks for that: > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/685d2eb9aa05 > > Paul. > > [1] http://openjdk.java.net/projects/build-infra/guide.html > > > On Nov 5, 2012, at 5:33 PM, Eric Caspole > wrote: > >> Hi everybody, >> I am having trouble building the lambda jdk fresh checkout this morning, >> but I made a change shown below to get it to succeed. Is something wrong >> with my build setup or are the build files actually out of sync with the >> java source? >> >> Thanks, >> Eric >> >> >> I am using Ubuntu 12.04 here. >> >> hg clone http://hg.openjdk.java.net/lambda/lambda/ >> ./get_source.sh >> make ARCH_DATA_MODEL=64 >> >> I am not sure if I can build lambda against JDK 7 but everything seems >> more or less OK, and make sanity works. I have: >> ALT_JDK_IMPORT_PATH=/opt/jdk1.7.0_09/ >> LANG=C >> ALT_BOOTDIR=/opt/jdk1.7.0_09/ >> >> Thanks, >> Eric >> >> >> The error I was getting is: >> >> >> NAWK="/usr/bin/gawk" SED="/bin/sed" SORT="/usr/bin/sort" \ >> /bin/sh localegen.sh "FormatData CollationData TimeZoneNames >> LocaleNames CurrencyNames CalendarData" >> /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.euro >> >> \ >> >> /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java.tmp.noneuro >> >> ../../../src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template >> >> /home/ecaspole/views/lambda/lambda/build/linux-amd64/gensrc/sun/util/locale/provider/LocaleDataMetaInfo.java >> make[4]: *** No rule to make target >> `/home/ecaspole/views/lambda/lambda/build/linux-amd64/classes/java/util/streams/ops/CollectorOp.class', >> >> needed by >> `/home/ecaspole/views/lambda/lambda/build/linux-amd64/tmp/java/java.lang/java/.classes.list'. >> >> Stop. >> make[4]: Leaving directory >> `/home/ecaspole/views/lambda/lambda/jdk/make/java/java' >> make[3]: *** [all] Error 1 >> make[3]: Leaving directory >> `/home/ecaspole/views/lambda/lambda/jdk/make/java' >> make[2]: *** [all] Error 1 >> make[2]: Leaving directory `/home/ecaspole/views/lambda/lambda/jdk/make' >> make[1]: *** [jdk-build] Error 2 >> make[1]: Leaving directory `/home/ecaspole/views/lambda/lambda' >> make: *** [build_product_image] Error 2 >> ecaspole at ecaspole-desktop:~/views/lambda/lambda$ >> >> >> >> I made this change to erase references to non-existant files: >> >> ecaspole at ecaspole-desktop:~/views/lambda/lambda/jdk$ hg diff >> make/java/java/FILES_java.gmk >> diff -r e60b1819b652 make/java/java/FILES_java.gmk >> --- a/make/java/java/FILES_java.gmkMon Nov 05 15:21:49 2012 +0100 >> +++ b/make/java/java/FILES_java.gmkMon Nov 05 11:25:09 2012 -0500 >> @@ -422,7 +422,7 @@ >> java/util/streams/AbstractPipeline.java \ >> java/util/streams/BaseStream.java \ >> java/util/streams/ops/AbstractTask.java \ >> - java/util/streams/ops/CollectorOp.java \ >> + java/util/streams/ops/CollectorOps.java \ >> java/util/streams/ops/ConcatOp.java \ >> java/util/streams/ops/CumulateOp.java \ >> java/util/streams/ops/FilterOp.java \ >> @@ -457,7 +457,6 @@ >> java/util/streams/Sink.java \ >> java/util/streams/Spliterator.java \ >> java/util/streams/Streamable.java \ >> - java/util/streams/StreamAccessor.java \ >> java/util/streams/Stream.java \ >> java/util/streams/StreamOpFlags.java \ >> java/util/streams/StreamShape.java \ >> >> >> >> >> > From mike.duigou at oracle.com Mon Nov 5 09:17:19 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 Nov 2012 09:17:19 -0800 Subject: Stream.unordered() In-Reply-To: References: <96901DC8-35A6-421D-A661-204BF53EB418@oracle.com> Message-ID: <5B8A43C4-1F69-4E16-AE12-043654988F79@oracle.com> >

Parallel evaluation of downstream operations I would remove "Parallel". Not because I have specific examples of where a sequential implementation might do something out of order but because it seems like over specification. Mike On Nov 5 2012, at 08:22 , Paul Sandoz wrote: > Grrr. attachments (even just textual attachments of a reasonable size) are removed... > > Paul. > > On Nov 5, 2012, at 4:49 PM, Paul Sandoz wrote: > >> HI, >> >> See attached for a patch that adds Stream.unordered(). >> >> This method will clear the encounter order flag. When this flag is cleared certain downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order. >> >> Such algorithms may be more efficient than order preserving algorithms, although i would say that one should not presume this to be a general assumption and has to be taken on a case by case basis. >> >> One such example is obtaining unique elements. >> >> When encounter order is to be preserved it might be required to merge the linked hash sets produced at the leaves of the computation tree. That merging has a cost, i suspect it is rather tricky to write a parallel set merge algorithm, so a naive implementation would just take the set on the left hand side of a tree and merge with set on the right hand side using Set.addAll. >> >> When encounter order need not be preserved one can stuff elements as and when they are produced into a shared ConcurrentHashMap. >> >> Paul. From brian.goetz at oracle.com Mon Nov 5 09:31:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 5 Nov 2012 12:31:57 -0500 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: <6CB3810E-5426-4038-8BAA-020B08502B18@oracle.com> And, many otherwise-SAM abstract classes could add constructors/factory methods that take a SAM interface, as we did for ThreadLocal: class ThreadLocal { public ThreadLocal(Factory factory) { ... } } So you can say ThreadLocal tl = new ThreadLocal(() -> new Bazooka(....)); On Nov 5, 2012, at 11:41 AM, Kevin Bourrillion wrote: > I was initially pro-abstract-class-support, but after taking a hard look at > just how often such a feature is really needed I changed my mind. > > If abstract classes were supported, there would be a magical hidden > invocation of user code here: > > SomeType x = () -> 1; > > ... namely, the SomeType constructor. That constructor could do anything, > including throw checked exceptions -- this is pretty surprising and goes > against the "feel" of lambda expressions. And note there'd be no way to > invoke a constructor that had parameters anyway. > > When we really must extend a SAM abstract class, we'll just have to > continue to use an anonymous class, and that's fine. > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > From paul.sandoz at oracle.com Mon Nov 5 09:37:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Nov 2012 18:37:27 +0100 Subject: Stream.unordered() In-Reply-To: <5B8A43C4-1F69-4E16-AE12-043654988F79@oracle.com> References: <96901DC8-35A6-421D-A661-204BF53EB418@oracle.com> <5B8A43C4-1F69-4E16-AE12-043654988F79@oracle.com> Message-ID: On Nov 5, 2012, at 6:17 PM, Mike Duigou wrote: >>

Parallel evaluation of downstream operations > > I would remove "Parallel". Not because I have specific examples of where a sequential implementation might do something out of order but because it seems like over specification. > Thanks, i removed the paragraph, since at some point will have to describe for each stateful operation what it does for parallel evaluation when encounter order is set or cleared and those can reference unordered() and may be it becomes more obvious what to say on unordered when we do that. Paul. > Mike > > On Nov 5 2012, at 08:22 , Paul Sandoz wrote: > >> Grrr. attachments (even just textual attachments of a reasonable size) are removed... >> >> Paul. >> >> On Nov 5, 2012, at 4:49 PM, Paul Sandoz wrote: >> >>> HI, >>> >>> See attached for a patch that adds Stream.unordered(). >>> >>> This method will clear the encounter order flag. When this flag is cleared certain downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order. >>> >>> Such algorithms may be more efficient than order preserving algorithms, although i would say that one should not presume this to be a general assumption and has to be taken on a case by case basis. >>> >>> One such example is obtaining unique elements. >>> >>> When encounter order is to be preserved it might be required to merge the linked hash sets produced at the leaves of the computation tree. That merging has a cost, i suspect it is rather tricky to write a parallel set merge algorithm, so a naive implementation would just take the set on the left hand side of a tree and merge with set on the right hand side using Set.addAll. >>> >>> When encounter order need not be preserved one can stuff elements as and when they are produced into a shared ConcurrentHashMap. >>> >>> Paul. > From boaznahum at gmail.com Mon Nov 5 09:52:42 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 5 Nov 2012 19:52:42 +0200 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: <5097F3CF.2030601@univ-mlv.fr> References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: Do you think converting adapter class class TransitionHandler { String getName() { return null; } abstract void noTransition(); } to interface: interface TransitionHandler { String getName() default { return null; } void noTransition(); } abuse the "Defender Methods" idea ? Do you see any problem with this ? And why can't the compiler deduce that no ctor is involved ? (I hope no one plans to add ctor to Object ?) Thanks Boaz On Mon, Nov 5, 2012 at 7:13 PM, Remi Forax wrote: > On 11/05/2012 04:08 PM, Boaz Nahum wrote: > > Does it mean that all 'old' inner classes extending adapters cant be > > converted to lambda(assuming converting the adapter to SAM)? > > Please say no: ( > > We drop that support because an abstract class has a constructor (at > least one) > that can observe the creation of the lambda so it defeat most of the > optimizations > that the VM can do. > > The other problem was to deal with abstract class with a constructor > that may throw an exception > because again, the construction of the lambda is observable. > > You can still retrofit your code to use lambda using delegation instead > of inheritance. > By example: > > abstract class Foo { > Foo() { > // some side effects > } > public abstract void m(T element); > } > > Foo foo = new Foo() { > public void m(String s) { > // lambda code > } > }; > > can be retrofitted to: > > class Foo { > private final Block block; > Foo(Block block) { > this.block = block; > // some side effects > } > public void m(T element) { > block.apply(element); > } > } > > Foo foo = new Foo((String s) -> { > // lambda code > }); > > > > > > Thanks > > Boaz > > Cheers, > R?mi > > > On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" > > wrote: > > > >> It was part of the original plan, but I believe non-interface SAMs have > >> been dropped. I'm guessing because it was difficult to handle the > peculiars > >> of working with MethodHandles and not actually making a new instance of > the > >> SAM type. > >> > >> --Reinier Zwitserloot > >> > >> > >> > >> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: > >> > >>> I can't find what the spec is saying, but I remember that Abstract > class > >>> with one abstract method is also SAM. > >>> > >>> Currently in b63 I got java: incompatible types: the target type must > be a > >>> functional interface > >>> > >>> Will it be supported in the future ? > >>> > >>> Thanks > >>> Boaz > >>> > >>> > > > From ricky.clarkson at gmail.com Mon Nov 5 10:00:10 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Mon, 5 Nov 2012 15:00:10 -0300 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: That's exactly what I'm doing to Functional Java. Only static methods cause a problem (are static defenders on the radar?). Final methods becoming defender methods is a little concerning because they can then be overridden. All classes, including Object, have a constructor. Object's just doesn't do anything. On Mon, Nov 5, 2012 at 2:52 PM, Boaz Nahum wrote: > Do you think converting adapter class > > class TransitionHandler { > > String getName() { return null; } > > abstract void noTransition(); > } > > to interface: > interface TransitionHandler { > > String getName() default { return null; } > > void noTransition(); > } > > abuse the "Defender Methods" idea ? Do you see any problem with this ? > > And why can't the compiler deduce that no ctor is involved ? (I hope no one > plans to add ctor to Object ?) > > Thanks > Boaz > > > > > > > On Mon, Nov 5, 2012 at 7:13 PM, Remi Forax wrote: > >> On 11/05/2012 04:08 PM, Boaz Nahum wrote: >> > Does it mean that all 'old' inner classes extending adapters cant be >> > converted to lambda(assuming converting the adapter to SAM)? >> > Please say no: ( >> >> We drop that support because an abstract class has a constructor (at >> least one) >> that can observe the creation of the lambda so it defeat most of the >> optimizations >> that the VM can do. >> >> The other problem was to deal with abstract class with a constructor >> that may throw an exception >> because again, the construction of the lambda is observable. >> >> You can still retrofit your code to use lambda using delegation instead >> of inheritance. >> By example: >> >> abstract class Foo { >> Foo() { >> // some side effects >> } >> public abstract void m(T element); >> } >> >> Foo foo = new Foo() { >> public void m(String s) { >> // lambda code >> } >> }; >> >> can be retrofitted to: >> >> class Foo { >> private final Block block; >> Foo(Block block) { >> this.block = block; >> // some side effects >> } >> public void m(T element) { >> block.apply(element); >> } >> } >> >> Foo foo = new Foo((String s) -> { >> // lambda code >> }); >> >> >> > >> > Thanks >> > Boaz >> >> Cheers, >> R?mi >> >> > On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" >> > wrote: >> > >> >> It was part of the original plan, but I believe non-interface SAMs have >> >> been dropped. I'm guessing because it was difficult to handle the >> peculiars >> >> of working with MethodHandles and not actually making a new instance of >> the >> >> SAM type. >> >> >> >> --Reinier Zwitserloot >> >> >> >> >> >> >> >> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: >> >> >> >>> I can't find what the spec is saying, but I remember that Abstract >> class >> >>> with one abstract method is also SAM. >> >>> >> >>> Currently in b63 I got java: incompatible types: the target type must >> be a >> >>> functional interface >> >>> >> >>> Will it be supported in the future ? >> >>> >> >>> Thanks >> >>> Boaz >> >>> >> >>> >> >> >> > From boaznahum at gmail.com Mon Nov 5 10:13:56 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 5 Nov 2012 20:13:56 +0200 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: Sorry for nagging That what I', trying to say. Object has a constructor that does nothing. So it has no side effect. Does is still "defeat most of the optimizations that the VM can do" ? On Mon, Nov 5, 2012 at 8:00 PM, Ricky Clarkson wrote: > That's exactly what I'm doing to Functional Java. Only static methods > cause a problem (are static defenders on the radar?). Final methods > becoming defender methods is a little concerning because they can then > be overridden. > > All classes, including Object, have a constructor. Object's just > doesn't do anything. > > On Mon, Nov 5, 2012 at 2:52 PM, Boaz Nahum wrote: > > Do you think converting adapter class > > > > class TransitionHandler { > > > > String getName() { return null; } > > > > abstract void noTransition(); > > } > > > > to interface: > > interface TransitionHandler { > > > > String getName() default { return null; } > > > > void noTransition(); > > } > > > > abuse the "Defender Methods" idea ? Do you see any problem with this ? > > > > And why can't the compiler deduce that no ctor is involved ? (I hope no > one > > plans to add ctor to Object ?) > > > > Thanks > > Boaz > > > > > > > > > > > > > > On Mon, Nov 5, 2012 at 7:13 PM, Remi Forax wrote: > > > >> On 11/05/2012 04:08 PM, Boaz Nahum wrote: > >> > Does it mean that all 'old' inner classes extending adapters cant be > >> > converted to lambda(assuming converting the adapter to SAM)? > >> > Please say no: ( > >> > >> We drop that support because an abstract class has a constructor (at > >> least one) > >> that can observe the creation of the lambda so it defeat most of the > >> optimizations > >> that the VM can do. > >> > >> The other problem was to deal with abstract class with a constructor > >> that may throw an exception > >> because again, the construction of the lambda is observable. > >> > >> You can still retrofit your code to use lambda using delegation instead > >> of inheritance. > >> By example: > >> > >> abstract class Foo { > >> Foo() { > >> // some side effects > >> } > >> public abstract void m(T element); > >> } > >> > >> Foo foo = new Foo() { > >> public void m(String s) { > >> // lambda code > >> } > >> }; > >> > >> can be retrofitted to: > >> > >> class Foo { > >> private final Block block; > >> Foo(Block block) { > >> this.block = block; > >> // some side effects > >> } > >> public void m(T element) { > >> block.apply(element); > >> } > >> } > >> > >> Foo foo = new Foo((String s) -> { > >> // lambda code > >> }); > >> > >> > >> > > >> > Thanks > >> > Boaz > >> > >> Cheers, > >> R?mi > >> > >> > On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" < > reinier at zwitserloot.com> > >> > wrote: > >> > > >> >> It was part of the original plan, but I believe non-interface SAMs > have > >> >> been dropped. I'm guessing because it was difficult to handle the > >> peculiars > >> >> of working with MethodHandles and not actually making a new instance > of > >> the > >> >> SAM type. > >> >> > >> >> --Reinier Zwitserloot > >> >> > >> >> > >> >> > >> >> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum > wrote: > >> >> > >> >>> I can't find what the spec is saying, but I remember that Abstract > >> class > >> >>> with one abstract method is also SAM. > >> >>> > >> >>> Currently in b63 I got java: incompatible types: the target type > must > >> be a > >> >>> functional interface > >> >>> > >> >>> Will it be supported in the future ? > >> >>> > >> >>> Thanks > >> >>> Boaz > >> >>> > >> >>> > >> > >> > >> > > > From brian.goetz at oracle.com Mon Nov 5 11:35:56 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 5 Nov 2012 14:35:56 -0500 Subject: Will JDK 8 support SAM that is Abstract Class ? In-Reply-To: References: <5097F3CF.2030601@univ-mlv.fr> Message-ID: > That's exactly what I'm doing to Functional Java. Only static methods > cause a problem (are static defenders on the radar?). Final methods > becoming defender methods is a little concerning because they can then > be overridden. Static *methods* are on the radar -- but they're not "default methods", since they can't be overridden. But, yes. Though likely not to make the cut for 8. > All classes, including Object, have a constructor. Object's just > doesn't do anything. > > On Mon, Nov 5, 2012 at 2:52 PM, Boaz Nahum wrote: >> Do you think converting adapter class >> >> class TransitionHandler { >> >> String getName() { return null; } >> >> abstract void noTransition(); >> } >> >> to interface: >> interface TransitionHandler { >> >> String getName() default { return null; } >> >> void noTransition(); >> } >> >> abuse the "Defender Methods" idea ? Do you see any problem with this ? >> >> And why can't the compiler deduce that no ctor is involved ? (I hope no one >> plans to add ctor to Object ?) >> >> Thanks >> Boaz >> >> >> >> >> >> >> On Mon, Nov 5, 2012 at 7:13 PM, Remi Forax wrote: >> >>> On 11/05/2012 04:08 PM, Boaz Nahum wrote: >>>> Does it mean that all 'old' inner classes extending adapters cant be >>>> converted to lambda(assuming converting the adapter to SAM)? >>>> Please say no: ( >>> >>> We drop that support because an abstract class has a constructor (at >>> least one) >>> that can observe the creation of the lambda so it defeat most of the >>> optimizations >>> that the VM can do. >>> >>> The other problem was to deal with abstract class with a constructor >>> that may throw an exception >>> because again, the construction of the lambda is observable. >>> >>> You can still retrofit your code to use lambda using delegation instead >>> of inheritance. >>> By example: >>> >>> abstract class Foo { >>> Foo() { >>> // some side effects >>> } >>> public abstract void m(T element); >>> } >>> >>> Foo foo = new Foo() { >>> public void m(String s) { >>> // lambda code >>> } >>> }; >>> >>> can be retrofitted to: >>> >>> class Foo { >>> private final Block block; >>> Foo(Block block) { >>> this.block = block; >>> // some side effects >>> } >>> public void m(T element) { >>> block.apply(element); >>> } >>> } >>> >>> Foo foo = new Foo((String s) -> { >>> // lambda code >>> }); >>> >>> >>>> >>>> Thanks >>>> Boaz >>> >>> Cheers, >>> R?mi >>> >>>> On Nov 5, 2012 5:01 PM, "Reinier Zwitserloot" >>>> wrote: >>>> >>>>> It was part of the original plan, but I believe non-interface SAMs have >>>>> been dropped. I'm guessing because it was difficult to handle the >>> peculiars >>>>> of working with MethodHandles and not actually making a new instance of >>> the >>>>> SAM type. >>>>> >>>>> --Reinier Zwitserloot >>>>> >>>>> >>>>> >>>>> On Mon, Nov 5, 2012 at 3:41 PM, Boaz Nahum wrote: >>>>> >>>>>> I can't find what the spec is saying, but I remember that Abstract >>> class >>>>>> with one abstract method is also SAM. >>>>>> >>>>>> Currently in b63 I got java: incompatible types: the target type must >>> be a >>>>>> functional interface >>>>>> >>>>>> Will it be supported in the future ? >>>>>> >>>>>> Thanks >>>>>> Boaz >>>>>> >>>>>> >>> >>> >>> >> > From paul.sandoz at oracle.com Mon Nov 5 12:22:53 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 05 Nov 2012 20:22:53 +0000 Subject: hg: lambda/lambda/jdk: Add Stream.unordered() that clears the encounter order flag such Message-ID: <20121105202314.65F0747799@hg.openjdk.java.net> Changeset: 0cf151046f3e Author: psandoz Date: 2012-11-05 21:22 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0cf151046f3e Add Stream.unordered() that clears the encounter order flag such that any downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order. Such algorithms might be more efficient than the order preserving algorithms. ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/ValuePipeline.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java From mike.duigou at oracle.com Mon Nov 5 14:12:41 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 05 Nov 2012 22:12:41 +0000 Subject: hg: lambda/lambda/jdk: Additional utils and javadoc Message-ID: <20121105221316.9145F4779E@hg.openjdk.java.net> Changeset: 197bf7b0507d Author: henryjen Date: 2012-11-05 14:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/197bf7b0507d Additional utils and javadoc Reviwed-by: bgoetz, mduigou ! src/share/classes/java/util/Comparators.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java From mike.duigou at oracle.com Mon Nov 5 16:10:24 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 06 Nov 2012 00:10:24 +0000 Subject: hg: lambda/lambda/jdk: Doc clarifications. Message-ID: <20121106001049.CBD16477A1@hg.openjdk.java.net> Changeset: 425d175eca55 Author: mduigou Date: 2012-11-05 16:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/425d175eca55 Doc clarifications. ! src/share/classes/java/util/Sized.java From forax at univ-mlv.fr Tue Nov 6 00:50:57 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 06 Nov 2012 09:50:57 +0100 Subject: lambda and dynamic JVM languages interropt In-Reply-To: <2126EC06-1EC9-4D57-8E0B-880FA7F82BB4@oracle.com> References: <2126EC06-1EC9-4D57-8E0B-880FA7F82BB4@oracle.com> Message-ID: <5098CF71.8010005@univ-mlv.fr> There is a blog post from Jim Connors about a dynamic language developed by GE and ported to the JVM (see the message below). One of the item of the blog post is that JVM languages can benefit from the Java integration and leverage features like lambdas. Thinking a bit about that, the current lambda metafactory API is not totally aligned with this goal. The current API offers only single entry point (two in fact with serialization) so there is no way for JVM language developers to choose which representation of lambdas is most suited for their language (dynamic generation of inner-classes or method handle proxy). I think we should provide 3 entry points (6 with serialization), the one Java uses which select the best implementation and delegates to one of the lambda implementation entrypoints, and 2 for the two ways to represent a lambda. cheers, R?mi -------- Original Message -------- Subject: nice blog post on Majik Date: Mon, 5 Nov 2012 16:44:30 -0800 From: John Rose Reply-To: Da Vinci Machine Project To: Da Vinci Machine Project Some of you may remember reading posts from Duncan MacGregor or seeing the talk on GE's Majik system at this year's JVM Language Summit. There's a new Oracle blog entry on their work here: https://blogs.oracle.com/jtc/entry/sprinkle_some_magik_on_that It includes a rehearsal of business reasons to move from a proprietary VM to the JVM. Enjoy! ? John _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From blackdrag at gmx.org Tue Nov 6 05:03:35 2012 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 06 Nov 2012 14:03:35 +0100 Subject: lambda and dynamic JVM languages interropt In-Reply-To: <5098CF71.8010005@univ-mlv.fr> References: <2126EC06-1EC9-4D57-8E0B-880FA7F82BB4@oracle.com> <5098CF71.8010005@univ-mlv.fr> Message-ID: <50990AA7.7030806@gmx.org> Am 06.11.2012 09:50, schrieb Remi Forax:[...] > Thinking a bit about that, the current lambda metafactory API is not > totally aligned with this goal. > The current API offers only single entry point (two in fact with > serialization) so there is no way for > JVM language developers to choose which representation of lambdas is > most suited for their language > (dynamic generation of inner-classes or method handle proxy). > I think we should provide 3 entry points (6 with serialization), the one > Java uses which select the best implementation > and delegates to one of the lambda implementation entrypoints, and 2 for > the two ways to represent a lambda. I am following the list only from time to time and I think there is a detail I am missing here. So afaik we generate for the lambda a method and we will have an invokedynamic based call site that is given the handle of that method as well as the "target". The conversion is then done by the metafactory API, which means either directly with MethodHandles or with an inner class, which is generated at runtime. I hope I am right so far. Now you suggest that I can force one or the other way, instead of going though the generic path. My question now is... why should I not want the generic way and force one? bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From forax at univ-mlv.fr Tue Nov 6 05:48:56 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 06 Nov 2012 14:48:56 +0100 Subject: lambda and dynamic JVM languages interropt In-Reply-To: <50990AA7.7030806@gmx.org> References: <2126EC06-1EC9-4D57-8E0B-880FA7F82BB4@oracle.com> <5098CF71.8010005@univ-mlv.fr> <50990AA7.7030806@gmx.org> Message-ID: <50991548.9080705@univ-mlv.fr> On 11/06/2012 02:03 PM, Jochen Theodorou wrote: > Am 06.11.2012 09:50, schrieb Remi Forax:[...] >> Thinking a bit about that, the current lambda metafactory API is not >> totally aligned with this goal. >> The current API offers only single entry point (two in fact with >> serialization) so there is no way for >> JVM language developers to choose which representation of lambdas is >> most suited for their language >> (dynamic generation of inner-classes or method handle proxy). >> I think we should provide 3 entry points (6 with serialization), the one >> Java uses which select the best implementation >> and delegates to one of the lambda implementation entrypoints, and 2 for >> the two ways to represent a lambda. > > I am following the list only from time to time and I think there is a > detail I am missing here. So afaik we generate for the lambda a method > and we will have an invokedynamic based call site that is given the > handle of that method as well as the "target". The conversion is then > done by the metafactory API, which means either directly with > MethodHandles or with an inner class, which is generated at runtime. I > hope I am right so far. > > Now you suggest that I can force one or the other way, instead of > going though the generic path. My question now is... why should I not > want the generic way and force one? Because you want back and forth interropt. Being able to convert a method handle to a Java lambda is one side of the story, the other side is to be able to take a Java lambda and convert it back to your language. If your language uses an interfaces like Function0, Function1, etc then it's easy if Java lambdas are represented as inner classes. If your language uses method handles, it's easier if you can extract the method handle from the proxy. > > bye Jochen > cheers, R?mi From paul.sandoz at oracle.com Tue Nov 6 07:42:14 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Nov 2012 16:42:14 +0100 Subject: Heads up: Mapper -> Mapper Message-ID: Hi, To align better with EG discussions some nominal function types, such as Mapper/FlatMapper, were modified such that the type parameter for the return type is declared first rather than last. This is unlikely to affect code using such function types implicitly, i.e. lambda expressions, but will definitely affect code that explicitly depends on such types. I will endeavour to communicate such changes more quickly in the future. Paul. http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 From pbenedict at apache.org Tue Nov 6 07:49:57 2012 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Nov 2012 09:49:57 -0600 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: Community question: Why aren't the EG discussions public yet? I thought the latest JCP brings transparency to the expert list. Is it because lambda is not running under the latest JCP transparency rules yet? Paul On Tue, Nov 6, 2012 at 9:42 AM, Paul Sandoz wrote: > Hi, > > To align better with EG discussions some nominal function types, such as > Mapper/FlatMapper, were modified such that the type parameter for the > return type is declared first rather than last. > > This is unlikely to affect code using such function types implicitly, i.e. > lambda expressions, but will definitely affect code that explicitly depends > on such types. > > I will endeavour to communicate such changes more quickly in the future. > > Paul. > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 > > From aleksey.shipilev at oracle.com Tue Nov 6 07:51:03 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 06 Nov 2012 10:51:03 -0500 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: <509931E7.6080800@oracle.com> On 11/06/2012 10:42 AM, Paul Sandoz wrote: > To align better with EG discussions some nominal function types, such > as Mapper/FlatMapper, were modified such that the type parameter for > the return type is declared first rather than last. And the rationale for Combiner -> Combiner in the reduceBy is the same? Thanks, Aleksey From forax at univ-mlv.fr Tue Nov 6 07:50:50 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 06 Nov 2012 16:50:50 +0100 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: <509931DA.5050102@univ-mlv.fr> On 11/06/2012 04:42 PM, Paul Sandoz wrote: > Hi, > > To align better with EG discussions some nominal function types, such as Mapper/FlatMapper, were modified such that the type parameter for the return type is declared first rather than last. > > This is unlikely to affect code using such function types implicitly, i.e. lambda expressions, but will definitely affect code that explicitly depends on such types. > > I will endeavour to communicate such changes more quickly in the future. > > Paul. > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 > Hi Paul, and to be coherent, all methods that declares a type parameter used as first parameter of a functional type should also be declared first. cheers, R?mi From brian.goetz at oracle.com Tue Nov 6 07:53:22 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Nov 2012 10:53:22 -0500 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: I think you missed the memo. They've been public for quite a while. On Nov 6, 2012, at 10:49 AM, Paul Benedict wrote: > Community question: Why aren't the EG discussions public yet? I thought the > latest JCP brings transparency to the expert list. Is it because lambda is > not running under the latest JCP transparency rules yet? > > Paul > > On Tue, Nov 6, 2012 at 9:42 AM, Paul Sandoz wrote: > >> Hi, >> >> To align better with EG discussions some nominal function types, such as >> Mapper/FlatMapper, were modified such that the type parameter for the >> return type is declared first rather than last. >> >> This is unlikely to affect code using such function types implicitly, i.e. >> lambda expressions, but will definitely affect code that explicitly depends >> on such types. >> >> I will endeavour to communicate such changes more quickly in the future. >> >> Paul. >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 >> >> > From pbenedict at apache.org Tue Nov 6 08:00:57 2012 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Nov 2012 10:00:57 -0600 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: Touch?! On Tue, Nov 6, 2012 at 9:53 AM, Brian Goetz wrote: > I think you missed the memo. They've been public for quite a while. > > On Nov 6, 2012, at 10:49 AM, Paul Benedict wrote: > > > Community question: Why aren't the EG discussions public yet? I thought > the > > latest JCP brings transparency to the expert list. Is it because lambda > is > > not running under the latest JCP transparency rules yet? > > > > Paul > > > > On Tue, Nov 6, 2012 at 9:42 AM, Paul Sandoz > wrote: > > > >> Hi, > >> > >> To align better with EG discussions some nominal function types, such as > >> Mapper/FlatMapper, were modified such that the type parameter for the > >> return type is declared first rather than last. > >> > >> This is unlikely to affect code using such function types implicitly, > i.e. > >> lambda expressions, but will definitely affect code that explicitly > depends > >> on such types. > >> > >> I will endeavour to communicate such changes more quickly in the future. > >> > >> Paul. > >> > >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 > >> > >> > > > > From scolebourne at joda.org Tue Nov 6 08:08:37 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 6 Nov 2012 16:08:37 +0000 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: On 6 November 2012 15:42, Paul Sandoz wrote: > To align better with EG discussions some nominal function types, such as Mapper/FlatMapper, were modified such that the type parameter for the return type is declared first rather than last. This feels like a step back. Mapper I read that as "maps from T to U". More generally, I would normally put the inputs in order first, then the return type, then any exceptions (not applicable here). Can you indicate why or link to the thread about this? thanks Stephen From paul.sandoz at oracle.com Tue Nov 6 08:10:28 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Nov 2012 17:10:28 +0100 Subject: Heads up: Mapper -> Mapper In-Reply-To: <509931E7.6080800@oracle.com> References: <509931E7.6080800@oracle.com> Message-ID: On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev wrote: > On 11/06/2012 10:42 AM, Paul Sandoz wrote: >> To align better with EG discussions some nominal function types, such >> as Mapper/FlatMapper, were modified such that the type parameter for >> the return type is declared first rather than last. > > And the rationale for Combiner -> Combiner in the > reduceBy is the same? > Yes, that change is the result of refactoring the type parameter order on Combiner: http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java i.e. the last type parameter, W that is the result type, is shuffled up to become the first. Paul. From mike.duigou at oracle.com Tue Nov 6 08:10:27 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Nov 2012 08:10:27 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: The discussions are completely public. What Paul (Sandoz) is referring to is the review of the initial set of functional interfaces which includes this change. The currently ongoing review is being conducted on both the lambda-libs-spec-experts list and lambda-dev lists simultaneously. http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/ http://mail.openjdk.java.net/pipermail/lambda-dev/ The discussion begins with: http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006406.html http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-October/000236.html Paul Sandoz's patch just makes the lambda workspace consistent with the currently being reviewed material by re-ordering the type parameters. Mike On Nov 6 2012, at 07:49 , Paul Benedict wrote: > Community question: Why aren't the EG discussions public yet? I thought the > latest JCP brings transparency to the expert list. Is it because lambda is > not running under the latest JCP transparency rules yet? > > Paul > > On Tue, Nov 6, 2012 at 9:42 AM, Paul Sandoz wrote: > >> Hi, >> >> To align better with EG discussions some nominal function types, such as >> Mapper/FlatMapper, were modified such that the type parameter for the >> return type is declared first rather than last. >> >> This is unlikely to affect code using such function types implicitly, i.e. >> lambda expressions, but will definitely affect code that explicitly depends >> on such types. >> >> I will endeavour to communicate such changes more quickly in the future. >> >> Paul. >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e60b1819b652 >> >> > From keith.mcguigan at oracle.com Tue Nov 6 08:25:22 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 6 Nov 2012 11:25:22 -0500 Subject: default methods committed to jdk8 hotspot Message-ID: FYI: The default method implementation has finally made it into a jdk8 hotspot repo: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4735d2c84362 From here it will trickle up first to hsx/hotspot-main, and then to jdk8/hotspot as the gatekeepers make their pushes. -- - Keith From blackdrag at gmx.org Tue Nov 6 08:53:27 2012 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 06 Nov 2012 17:53:27 +0100 Subject: lambda and dynamic JVM languages interropt In-Reply-To: <50991548.9080705@univ-mlv.fr> References: <2126EC06-1EC9-4D57-8E0B-880FA7F82BB4@oracle.com> <5098CF71.8010005@univ-mlv.fr> <50990AA7.7030806@gmx.org> <50991548.9080705@univ-mlv.fr> Message-ID: <50994087.5070902@gmx.org> Am 06.11.2012 14:48, schrieb Remi Forax: [...] > Because you want back and forth interropt. > Being able to convert a method handle to a Java lambda is one side of > the story, > the other side is to be able to take a Java lambda and convert it back > to your language. > > If your language uses an interfaces like Function0, Function1, etc then > it's easy if > Java lambdas are represented as inner classes. If your language uses > method handles, > it's easier if you can extract the method handle from the proxy. I think I still don't follow 100%. There is Java lambda to my language... either I make a call from Java with some SAM to my runtime, so that I get the right thing already, or I have the ready object. Assuming I am using internally MethodHandles and want the handle from the proxy, I first need to know it is a lambda (for example a marker interface) and then means to extract the handle from the Java lambda. In this direction nailing the ways used in meta factory could help, if for example for the inner class case a certain layout is guaranteed. But the call site doing that is in Java code and not under my control, or am I wrong here? I mean I doubt there has been thought to a way to give an alternative bootstrap method, or to let the bootstrap method delegate to another method, defined at runtime. So what is essentially missing here is to extract the method handle from the ready object. And the other way is me calling Java and converting my lambdas to Java lambdas. Assuming I have ways to get the MethodHandle from the code I control this should be no problem. Then when is that not the case? Maybe if I don't generate bytecode... Is that what you wanted to say? bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From sam at sampullara.com Tue Nov 6 09:20:18 2012 From: sam at sampullara.com (Sam Pullara) Date: Tue, 6 Nov 2012 09:20:18 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: <509931E7.6080800@oracle.com> Message-ID: Neither Scala nor Guava makes this ordering choice. Let's not be innovative where it doesn't matter and will only cause confusion. http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html http://www.scala-lang.org/api/current/scala/Function1.html Sam On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz wrote: > > On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev > wrote: > > > On 11/06/2012 10:42 AM, Paul Sandoz wrote: > >> To align better with EG discussions some nominal function types, such > >> as Mapper/FlatMapper, were modified such that the type parameter for > >> the return type is declared first rather than last. > > > > And the rationale for Combiner -> Combiner in the > > reduceBy is the same? > > > > Yes, that change is the result of refactoring the type parameter order on > Combiner: > > > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java > > i.e. the last type parameter, W that is the result type, is shuffled up to > become the first. > > Paul. > > From fsarradin at xebia.fr Mon Nov 5 21:51:30 2012 From: fsarradin at xebia.fr (=?ISO-8859-1?Q?Fran=E7ois_Sarradin?=) Date: Tue, 6 Nov 2012 06:51:30 +0100 Subject: =?UTF-8?Q?Report=3A_Will_Java_8=E2=80=B2s_Lambda_Change_The_Face_of_Th?= =?UTF-8?Q?e_World=3F?= Message-ID: Hi, I know that you are looking for feedback. So during October, I organized a presentation around the JSR335 at my company: Xebia France. More precisely, it was an interactive session with a presentation, some live coding and debates around the code, and a retrospective. The audience was asked the impact of the Lambda Project on the Java community and Java projects would probably be. I have reported what has been said during my presentation on the blog of my company: http://blog.xebia.com/2012/11/05/report-will-java-8s-lambda-change-the-face-of-the-world/ Regards, Fran?ois Sarradin Xebia IT Architects http://www.xebia.fr http://blog.xebia.fr From forax at univ-mlv.fr Tue Nov 6 10:36:19 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 06 Nov 2012 19:36:19 +0100 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: <509931E7.6080800@oracle.com> Message-ID: <509958A3.2090406@univ-mlv.fr> On 11/06/2012 06:20 PM, Sam Pullara wrote: > Neither Scala nor Guava makes this ordering choice. Let's not be innovative > where it doesn't matter and will only cause confusion. > > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html > http://www.scala-lang.org/api/current/scala/Function1.html > > Sam I don't care about the order we choose if it's the same everywhere :) For the record, C# uses the same order too. http://msdn.microsoft.com/en-us/library/bb397687.aspx R?mi > > On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz wrote: > >> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev >> wrote: >> >>> On 11/06/2012 10:42 AM, Paul Sandoz wrote: >>>> To align better with EG discussions some nominal function types, such >>>> as Mapper/FlatMapper, were modified such that the type parameter for >>>> the return type is declared first rather than last. >>> And the rationale for Combiner -> Combiner in the >>> reduceBy is the same? >>> >> Yes, that change is the result of refactoring the type parameter order on >> Combiner: >> >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java >> >> i.e. the last type parameter, W that is the result type, is shuffled up to >> become the first. >> >> Paul. >> >> From jonathan.gibbons at oracle.com Tue Nov 6 10:59:32 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 Nov 2012 10:59:32 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: <509958A3.2090406@univ-mlv.fr> References: <509931E7.6080800@oracle.com> <509958A3.2090406@univ-mlv.fr> Message-ID: <50995E14.9050208@oracle.com> Can I suggest that we at least try and establish some naming convention as well, so that we are not just relying on positional conventions. There are already some JDK APIs with "result first, then parameter", using the convention Name R for Result, P for Parameter -- Jon On 11/06/2012 10:36 AM, Remi Forax wrote: > On 11/06/2012 06:20 PM, Sam Pullara wrote: >> Neither Scala nor Guava makes this ordering choice. Let's not be innovative >> where it doesn't matter and will only cause confusion. >> >> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html >> http://www.scala-lang.org/api/current/scala/Function1.html >> >> Sam > I don't care about the order we choose if it's the same everywhere :) > For the record, C# uses the same order too. > > http://msdn.microsoft.com/en-us/library/bb397687.aspx > > R?mi > >> On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz wrote: >> >>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev >>> wrote: >>> >>>> On 11/06/2012 10:42 AM, Paul Sandoz wrote: >>>>> To align better with EG discussions some nominal function types, such >>>>> as Mapper/FlatMapper, were modified such that the type parameter for >>>>> the return type is declared first rather than last. >>>> And the rationale for Combiner -> Combiner in the >>>> reduceBy is the same? >>>> >>> Yes, that change is the result of refactoring the type parameter order on >>> Combiner: >>> >>> >>> http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java >>> >>> i.e. the last type parameter, W that is the result type, is shuffled up to >>> become the first. >>> >>> Paul. >>> >>> > From mike.duigou at oracle.com Tue Nov 6 11:02:57 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 06 Nov 2012 19:02:57 +0000 Subject: hg: lambda/lambda/jdk: - StreamShape is now an interface. Message-ID: <20121106190336.4237C477BE@hg.openjdk.java.net> Changeset: fdf914a9f584 Author: psandoz Date: 2012-11-06 11:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fdf914a9f584 - StreamShape is now an interface. - StreamShapeFactory is responsible for creating default implementations. This is the place where we could switch on plugability using ServiceLoader (and then we have to starting thinking about class loaders :-( ). - Two StreamShapes instances are considered the same if their stream types are the same. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/BaseStream.java + src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/StreamShape.java + src/share/classes/java/util/streams/StreamShapeFactory.java ! src/share/classes/java/util/streams/Streams.java - src/share/classes/java/util/streams/ValuePipeline.java ! src/share/classes/java/util/streams/ops/ForEachOp.java ! src/share/classes/java/util/streams/ops/IntermediateOp.java ! src/share/classes/java/util/streams/ops/MatchOp.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! src/share/classes/java/util/streams/ops/StatefulOp.java ! src/share/classes/java/util/streams/ops/StreamOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java From pbenedict at apache.org Tue Nov 6 11:06:03 2012 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 Nov 2012 13:06:03 -0600 Subject: Heads up: Mapper -> Mapper In-Reply-To: <50995E14.9050208@oracle.com> References: <509931E7.6080800@oracle.com> <509958A3.2090406@univ-mlv.fr> <50995E14.9050208@oracle.com> Message-ID: Is R and P better than I and O? I don't think I could guess R and P without reading the javadoc. I and O, I can (no pun). On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Can I suggest that we at least try and establish some naming convention > as well, so that we are not just relying on positional conventions. > > There are already some JDK APIs with "result first, then parameter", > using the convention Name R for Result, P for Parameter > > -- Jon > > > > On 11/06/2012 10:36 AM, Remi Forax wrote: > > On 11/06/2012 06:20 PM, Sam Pullara wrote: > >> Neither Scala nor Guava makes this ordering choice. Let's not be > innovative > >> where it doesn't matter and will only cause confusion. > >> > >> > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html > >> http://www.scala-lang.org/api/current/scala/Function1.html > >> > >> Sam > > I don't care about the order we choose if it's the same everywhere :) > > For the record, C# uses the same order too. > > > > http://msdn.microsoft.com/en-us/library/bb397687.aspx > > > > R?mi > > > >> On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz > wrote: > >> > >>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev < > aleksey.shipilev at oracle.com> > >>> wrote: > >>> > >>>> On 11/06/2012 10:42 AM, Paul Sandoz wrote: > >>>>> To align better with EG discussions some nominal function types, such > >>>>> as Mapper/FlatMapper, were modified such that the type parameter for > >>>>> the return type is declared first rather than last. > >>>> And the rationale for Combiner -> Combiner in the > >>>> reduceBy is the same? > >>>> > >>> Yes, that change is the result of refactoring the type parameter order > on > >>> Combiner: > >>> > >>> > >>> > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java > >>> > >>> i.e. the last type parameter, W that is the result type, is shuffled > up to > >>> become the first. > >>> > >>> Paul. > >>> > >>> > > > > > From mike.duigou at oracle.com Tue Nov 6 12:13:27 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 06 Nov 2012 20:13:27 +0000 Subject: hg: lambda/lambda/jdk: Both SortedOp and UniqOp now take into account whether the source is sorted/distinct in the sequential case and sorted/distinct/ordered in the parallel case. Message-ID: <20121106201339.BDCED477C1@hg.openjdk.java.net> Changeset: e045cd5ee294 Author: psandoz Date: 2012-11-06 12:12 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e045cd5ee294 Both SortedOp and UniqOp now take into account whether the source is sorted/distinct in the sequential case and sorted/distinct/ordered in the parallel case. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/ops/CollectorOps.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! src/share/classes/java/util/streams/ops/UniqOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SortedOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java From jonathan.gibbons at oracle.com Tue Nov 6 13:03:51 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 06 Nov 2012 13:03:51 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: <509931E7.6080800@oracle.com> <509958A3.2090406@univ-mlv.fr> <50995E14.9050208@oracle.com> Message-ID: <50997B37.7080305@oracle.com> I and O would be OK, I was just afraid we were headed for T, U, V, W. -- Jon On 11/06/2012 11:06 AM, Paul Benedict wrote: > Is R and P better than I and O? I don't think I could guess R and P > without reading the javadoc. I and O, I can (no pun). > > On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons > > wrote: > > Can I suggest that we at least try and establish some naming > convention > as well, so that we are not just relying on positional conventions. > > There are already some JDK APIs with "result first, then parameter", > using the convention Name R for Result, P for Parameter > > -- Jon > > > > On 11/06/2012 10:36 AM, Remi Forax wrote: > > On 11/06/2012 06:20 PM, Sam Pullara wrote: > >> Neither Scala nor Guava makes this ordering choice. Let's not > be innovative > >> where it doesn't matter and will only cause confusion. > >> > >> > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html > >> http://www.scala-lang.org/api/current/scala/Function1.html > >> > >> Sam > > I don't care about the order we choose if it's the same > everywhere :) > > For the record, C# uses the same order too. > > > > http://msdn.microsoft.com/en-us/library/bb397687.aspx > > > > R?mi > > > >> On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz > > wrote: > >> > >>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev > > > >>> wrote: > >>> > >>>> On 11/06/2012 10:42 AM, Paul Sandoz wrote: > >>>>> To align better with EG discussions some nominal function > types, such > >>>>> as Mapper/FlatMapper, were modified such that the type > parameter for > >>>>> the return type is declared first rather than last. > >>>> And the rationale for Combiner -> Combiner > in the > >>>> reduceBy is the same? > >>>> > >>> Yes, that change is the result of refactoring the type > parameter order on > >>> Combiner: > >>> > >>> > >>> > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java > >>> > >>> i.e. the last type parameter, W that is the result type, is > shuffled up to > >>> become the first. > >>> > >>> Paul. > >>> > >>> > > > > > From sam at sampullara.com Tue Nov 6 13:42:32 2012 From: sam at sampullara.com (Sam Pullara) Date: Tue, 6 Nov 2012 13:42:32 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: <50997B37.7080305@oracle.com> References: <509931E7.6080800@oracle.com> <509958A3.2090406@univ-mlv.fr> <50995E14.9050208@oracle.com> <50997B37.7080305@oracle.com> Message-ID: What do people think about using more semantic names for these? I realize that it has been pretty standard to use single letters but I would find Mapper to be much more palatable. Sam On Tue, Nov 6, 2012 at 1:03 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I and O would be OK, I was just afraid we were headed for T, U, V, W. > > -- Jon > > > On 11/06/2012 11:06 AM, Paul Benedict wrote: > > Is R and P better than I and O? I don't think I could guess R and P > > without reading the javadoc. I and O, I can (no pun). > > > > On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons > > > > wrote: > > > > Can I suggest that we at least try and establish some naming > > convention > > as well, so that we are not just relying on positional conventions. > > > > There are already some JDK APIs with "result first, then parameter", > > using the convention Name R for Result, P for Parameter > > > > -- Jon > > > > > > > > On 11/06/2012 10:36 AM, Remi Forax wrote: > > > On 11/06/2012 06:20 PM, Sam Pullara wrote: > > >> Neither Scala nor Guava makes this ordering choice. Let's not > > be innovative > > >> where it doesn't matter and will only cause confusion. > > >> > > >> > > > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html > > >> http://www.scala-lang.org/api/current/scala/Function1.html > > >> > > >> Sam > > > I don't care about the order we choose if it's the same > > everywhere :) > > > For the record, C# uses the same order too. > > > > > > http://msdn.microsoft.com/en-us/library/bb397687.aspx > > > > > > R?mi > > > > > >> On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz > > > wrote: > > >> > > >>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev > > > > > >>> wrote: > > >>> > > >>>> On 11/06/2012 10:42 AM, Paul Sandoz wrote: > > >>>>> To align better with EG discussions some nominal function > > types, such > > >>>>> as Mapper/FlatMapper, were modified such that the type > > parameter for > > >>>>> the return type is declared first rather than last. > > >>>> And the rationale for Combiner -> Combiner > > in the > > >>>> reduceBy is the same? > > >>>> > > >>> Yes, that change is the result of refactoring the type > > parameter order on > > >>> Combiner: > > >>> > > >>> > > >>> > > > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java > > >>> > > >>> i.e. the last type parameter, W that is the result type, is > > shuffled up to > > >>> become the first. > > >>> > > >>> Paul. > > >>> > > >>> > > > > > > > > > > > > From mike.duigou at oracle.com Tue Nov 6 10:26:47 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Nov 2012 10:26:47 -0800 Subject: Default Methods Syntax Flag Day Message-ID: <24B3480F-E0D7-4E12-8E7E-4E13A11220B2@oracle.com> Hello Lambdoners! The day has finally come. Today I will be attempting to convert the lambda JDK repo to use the latest EDR syntax. public void method() default { foo(); } becomes public default void method() { foo(); } I expect to commit the change around Wednesday noon PST Mike From mike.duigou at oracle.com Tue Nov 6 15:40:13 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 06 Nov 2012 23:40:13 +0000 Subject: hg: lambda/lambda/jdk: Adapt source to EDR default method syntax: Message-ID: <20121106234027.08C68477CE@hg.openjdk.java.net> Changeset: 15de60ed9497 Author: mduigou Date: 2012-11-06 15:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/15de60ed9497 Adapt source to EDR default method syntax: public void method() default { foo(); } becomes public default void method() { foo(); } Other than implementing the syntax change this patch contains changes to two files java/util/streams/Streams.java tests/java/util/LambdaTestHelpers.java The additional changes work around an apparent temporary compiler problem. In both cases the compiler fails to recognize an interface is a valid functional interface. ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/Sized.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/functions/BiBlock.java ! src/share/classes/java/util/functions/BiMapper.java ! src/share/classes/java/util/functions/BiPredicate.java ! src/share/classes/java/util/functions/BinaryOperator.java ! src/share/classes/java/util/functions/Block.java ! src/share/classes/java/util/functions/Mapper.java ! src/share/classes/java/util/functions/Predicate.java ! src/share/classes/java/util/streams/Sink.java ! src/share/classes/java/util/streams/Spliterator.java ! src/share/classes/java/util/streams/Streamable.java ! src/share/classes/java/util/streams/Streams.java ! src/share/classes/java/util/streams/TerminalSink.java ! src/share/classes/java/util/streams/ops/IntermediateOp.java ! src/share/classes/java/util/streams/ops/Node.java ! src/share/classes/java/util/streams/ops/StatefulOp.java ! src/share/classes/java/util/streams/ops/StreamOp.java ! src/share/classes/java/util/streams/ops/TerminalOp.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationInInterface.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInnerDefault.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestSuperDefault.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestVarArgsSuperDefault.java ! test-ng/tests/org/openjdk/tests/separate/SourceModel.java ! test-ng/tests/org/openjdk/tests/shapegen/Hierarchy.java ! test-ng/tests/org/openjdk/tests/vm/DefaultMethodRegressionTests.java ! test-ng/tests/org/openjdk/tests/vm/DefaultMethodsTest.java ! test-ng/tests/org/openjdk/tests/vm/StrictfpDefault.java ! test-ng/tests/org/openjdk/tests/vm/SynchronizedDefault.java From mike.duigou at oracle.com Tue Nov 6 15:40:35 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 06 Nov 2012 23:40:35 +0000 Subject: hg: lambda/lambda/langtools: Switch default method syntax to EDR syntax (default as attribute) Message-ID: <20121106234037.BA789477CF@hg.openjdk.java.net> Changeset: b38937b3090e Author: mcimadamore Date: 2012-11-06 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b38937b3090e Switch default method syntax to EDR syntax (default as attribute) ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/defender/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defender/ClassReaderTest/pkg/Foo.java ! test/tools/javac/defender/Neg01.java ! test/tools/javac/defender/Neg01.out ! test/tools/javac/defender/Neg02.java ! test/tools/javac/defender/Neg02.out ! test/tools/javac/defender/Neg03.java ! test/tools/javac/defender/Neg03.out ! test/tools/javac/defender/Neg04.java ! test/tools/javac/defender/Neg04.out ! test/tools/javac/defender/Neg05.java ! test/tools/javac/defender/Neg05.out ! test/tools/javac/defender/Neg06.java ! test/tools/javac/defender/Neg06.out ! test/tools/javac/defender/Neg07.java ! test/tools/javac/defender/Neg07.out ! test/tools/javac/defender/Neg08.java ! test/tools/javac/defender/Neg08.out ! test/tools/javac/defender/Neg09.java ! test/tools/javac/defender/Neg09.out ! test/tools/javac/defender/Neg10.java ! test/tools/javac/defender/Neg10.out ! test/tools/javac/defender/Neg11.java ! test/tools/javac/defender/Neg11.out ! test/tools/javac/defender/Neg12.java ! test/tools/javac/defender/Neg12.out ! test/tools/javac/defender/Neg13.java ! test/tools/javac/defender/Neg13.out + test/tools/javac/defender/Neg14.java + test/tools/javac/defender/Neg14.out ! test/tools/javac/defender/Pos01.java ! test/tools/javac/defender/Pos02.java ! test/tools/javac/defender/Pos04.java ! test/tools/javac/defender/Pos05.java ! test/tools/javac/defender/Pos06.java ! test/tools/javac/defender/Pos07.java ! test/tools/javac/defender/Pos08.java ! test/tools/javac/defender/Pos09.java ! test/tools/javac/defender/Pos10.java ! test/tools/javac/defender/Pos11.java ! test/tools/javac/defender/Pos12.java ! test/tools/javac/defender/Pos13.java ! test/tools/javac/defender/Pos14.java + test/tools/javac/defender/Pos15.java + test/tools/javac/defender/Pos16.java ! test/tools/javac/defender/TestInlinedDefenderBody.java ! test/tools/javac/defender/TestNoBridgeOnDefenders.java ! test/tools/javac/defender/fd/FDTest.java ! test/tools/javac/defender/fd/shapegen/Hierarchy.java ! test/tools/javac/defender/pkg1/A.java ! test/tools/javac/defender/super/TestDefenderSuperCall.java + test/tools/javac/defender/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/defender/syntax/TestDefenderModifiers.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/lambda/Defender01.java ! test/tools/javac/lambda/LambdaExpr20.java ! test/tools/javac/lambda/SourceLevelTest.java ! test/tools/javac/lambda/SourceLevelTest.out From mike.duigou at oracle.com Tue Nov 6 15:45:27 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 6 Nov 2012 15:45:27 -0800 Subject: Default Methods Syntax Flag Day In-Reply-To: <24B3480F-E0D7-4E12-8E7E-4E13A11220B2@oracle.com> References: <24B3480F-E0D7-4E12-8E7E-4E13A11220B2@oracle.com> Message-ID: <426596E3-D563-4BF0-B3C3-E5E7CA42D82B@oracle.com> The changes have been pushed to both langtools and jdk repos so the syntax conversion is now complete. Two issues to be aware of: - A compiler issue was encountered where, in a small number of cases, functional interfaces were not recognized and disallowed assignment of method references or lambdas. This bug will likely be fixed shortly (if you even run into it at all). - IDEs such as NetBeans and IntelliJ don't yet support the new syntax. We expect that both will soon offer updated versions that convert to the new syntax. Unless you are planning to submit patches to the lambda/jdk repo it might be best to wait a few days for everything to stabilize. Mike On Nov 6 2012, at 10:26 , Mike Duigou wrote: > Hello Lambdoners! > > The day has finally come. Today I will be attempting to convert the lambda JDK repo to use the latest EDR syntax. > > public void method() default { foo(); } > > becomes > > public default void method() { foo(); } > > I expect to commit the change around Wednesday noon PST > > Mike > From pablogrisafi1975 at gmail.com Tue Nov 6 15:53:04 2012 From: pablogrisafi1975 at gmail.com (Pablo Grisafi) Date: Tue, 6 Nov 2012 20:53:04 -0300 Subject: Heads up: Mapper -> Mapper Message-ID: Can we please abandon the horrible misleading one-letter-for-types convention? Looks like we are in programming in BASIC again Let's use good intention revealing names, please Name or Name or even Name are way better than Name For one type argument classes, like List, it is not that important, but even in that case, List is better Sorry if my English is not good enough. Sometimes I think I'm the only average Java programmer reading this list. Am I missing some clever reason why we are using the one-letter convention? Pablo Grisafi pablogrisafi1975 at gmail.com > ---------- Forwarded message ---------- > From: Paul Benedict > To: Jonathan Gibbons > Cc: lambda-dev at openjdk.java.net > Date: Tue, 6 Nov 2012 13:06:03 -0600 > Subject: Re: Heads up: Mapper -> Mapper > Is R and P better than I and O? I don't think I could guess R and P > without > reading the javadoc. I and O, I can (no pun). > > On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > > > Can I suggest that we at least try and establish some naming convention > > as well, so that we are not just relying on positional conventions. > > > > There are already some JDK APIs with "result first, then parameter", > > using the convention Name R for Result, P for Parameter > > > > -- Jon From brian.goetz at oracle.com Tue Nov 6 16:14:47 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Nov 2012 19:14:47 -0500 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: Message-ID: <8B889F61-BE3B-4CFA-AAEC-5EFE0760823E@oracle.com> These are the java naming conventions (unless we change them). However, were not going to have that discussion here. Discussions about naming conventions is completely off topic for this list. Sent from my iPhone On Nov 6, 2012, at 6:53 PM, Pablo Grisafi wrote: > Can we please abandon the horrible misleading one-letter-for-types convention? > Looks like we are in programming in BASIC again > Let's use good intention revealing names, please > Name or Name or even Name TOutput> are way better than Name > For one type argument classes, like List, it is not that important, > but even in that case, List is better > Sorry if my English is not good enough. Sometimes I think I'm the only > average Java programmer reading this list. > Am I missing some clever reason why we are using the one-letter convention? > > Pablo Grisafi > pablogrisafi1975 at gmail.com > >> ---------- Forwarded message ---------- >> From: Paul Benedict >> To: Jonathan Gibbons >> Cc: lambda-dev at openjdk.java.net >> Date: Tue, 6 Nov 2012 13:06:03 -0600 >> Subject: Re: Heads up: Mapper -> Mapper >> Is R and P better than I and O? I don't think I could guess R and P >> without >> reading the javadoc. I and O, I can (no pun). >> >> On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> Can I suggest that we at least try and establish some naming convention >>> as well, so that we are not just relying on positional conventions. >>> >>> There are already some JDK APIs with "result first, then parameter", >>> using the convention Name R for Result, P for Parameter >>> >>> -- Jon > From henry.jen at oracle.com Tue Nov 6 17:11:24 2012 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 6 Nov 2012 17:11:24 -0800 Subject: Heads up: Mapper -> Mapper In-Reply-To: <8B889F61-BE3B-4CFA-AAEC-5EFE0760823E@oracle.com> References: <8B889F61-BE3B-4CFA-AAEC-5EFE0760823E@oracle.com> Message-ID: Agree the naming convention is off-topic, the positional convention is what's more controversial here as developer still need to declare Mapper with type sometimes, and it's counter-intuitive to be result first. Sure enough we can get used to Yoda-style, but in general I would think of operate(required input, output, optional?) not the other way around. No matter what EG decided, I +1 Remi on following statement, > all methods that declares a type parameter used as first parameter of a > functional type should also be declared first. For example, Comparators.comparing(Mapper) should be changed. Cheers, Henry On Nov 6, 2012, at 4:14 PM, Brian Goetz wrote: > These are the java naming conventions (unless we change them). > > However, were not going to have that discussion here. Discussions about naming conventions is completely off topic for this list. > > Sent from my iPhone > > On Nov 6, 2012, at 6:53 PM, Pablo Grisafi wrote: > >> Can we please abandon the horrible misleading one-letter-for-types convention? >> Looks like we are in programming in BASIC again >> Let's use good intention revealing names, please >> Name or Name or even Name> TOutput> are way better than Name >> For one type argument classes, like List, it is not that important, >> but even in that case, List is better >> Sorry if my English is not good enough. Sometimes I think I'm the only >> average Java programmer reading this list. >> Am I missing some clever reason why we are using the one-letter convention? >> >> Pablo Grisafi >> pablogrisafi1975 at gmail.com >> >>> ---------- Forwarded message ---------- >>> From: Paul Benedict >>> To: Jonathan Gibbons >>> Cc: lambda-dev at openjdk.java.net >>> Date: Tue, 6 Nov 2012 13:06:03 -0600 >>> Subject: Re: Heads up: Mapper -> Mapper >>> Is R and P better than I and O? I don't think I could guess R and P >>> without >>> reading the javadoc. I and O, I can (no pun). >>> >>> On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>>> Can I suggest that we at least try and establish some naming convention >>>> as well, so that we are not just relying on positional conventions. >>>> >>>> There are already some JDK APIs with "result first, then parameter", >>>> using the convention Name R for Result, P for Parameter >>>> >>>> -- Jon >> > From oleksander.demura at gmail.com Tue Nov 6 23:57:21 2012 From: oleksander.demura at gmail.com (Olexandr Demura) Date: Wed, 7 Nov 2012 09:57:21 +0200 Subject: =?UTF-8?Q?Re=3A_Report=3A_Will_Java_8=E2=80=B2s_Lambda_Change_The_Face_o?= =?UTF-8?Q?f_The_World=3F?= In-Reply-To: References: Message-ID: On the "The new syntax is nice, but not for everyone" part. 1. `map` and `reduce` can be combined into one `fold`, but your code example shows it would be clumsier. Streams.stream(myCollection) .map(product -> product.getUnitPrice() * product.getQuantity()) .reduce(0.0, (subTotal, price) -> subTotal + price) vs products.stream().fold( () -> 0.0, (subTotal, product) -> subTotal + product.getUnitPrice() * product.getQuantity(), (subTotal1, subTotal2) -> subTotal1 + subTotal2 /* not used if sequential */); 2. Current documentation suggests stream methods should not be on collection interfaces to not bloat them since there is no single stream implementation. e.g. products.stream() vs products.parallel() 3. May be they need not implicit parameters but primitive operation references? 3.1. java is explicit language (except `+` for String). `java` in IPA close to 'explicit' in several Slavic languages :) 3.2. when parameter is not needed method references `::` can be used. 2012/11/6 Fran?ois Sarradin > Hi, > > I know that you are looking for feedback. So during October, I > organized a presentation around the JSR335 at my company: Xebia > France. More precisely, it was an interactive session with a > presentation, some live coding and debates around the code, and a > retrospective. The audience was asked the impact of the Lambda Project > on the Java community and Java projects would probably be. I have > reported what has been said during my presentation on the blog of my > company: > http://blog.xebia.com/2012/11/05/report-will-java-8s-lambda-change-the-face-of-the-world/ > > Regards, > > Fran?ois Sarradin > Xebia IT Architects > http://www.xebia.fr > http://blog.xebia.fr > > From paul.sandoz at oracle.com Wed Nov 7 01:48:07 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Nov 2012 10:48:07 +0100 Subject: ValuePipline -> ReferencePipeline Message-ID: <9157C774-6A0B-4283-A3B6-B81A2A3C4CE7@oracle.com> Hi, A change has been committed (thanks Mike) that may affect testers. ValuePipeline has been renamed to ReferencePipeline. StreamShape has been converted from an enum to an interface. The motivation for this change is two fold: 1) a smoother integration for primitive streams; and 2) the potential for extensibility of stream types. The methods of Stream implemented by ReferencePipeline now defer to the output shape of the intermediate operation to add a new tail to the pipeline. Same goes for the testing framework. The key point here is that when we add a method to Stream say: IntStream mapToInt(IntMapper mapper) Then the ReferencePipeline implementing mapToInt does not need to refer to the implementation of IntStream, it only needs to refer to the appropriate operation. Paul. From paul.sandoz at oracle.com Wed Nov 7 01:58:10 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Nov 2012 10:58:10 +0100 Subject: Comparators.comparing(Mapper) Re: Heads up: Mapper -> Mapper In-Reply-To: References: <8B889F61-BE3B-4CFA-AAEC-5EFE0760823E@oracle.com> Message-ID: <14F42774-5698-4537-A90C-BE8B55C33E77@oracle.com> On Nov 7, 2012, at 2:11 AM, Henry Jen wrote: > >> all methods that declares a type parameter used as first parameter of a >> functional type should also be declared first. > > For example, Comparators.comparing(Mapper) should be changed. > You mean this one: public static > Comparator comparing(Mapper mapper) { I did not forget this :-) I deliberately left that as is because T is used as a parameter of the return type. Paul. From paul.sandoz at oracle.com Wed Nov 7 02:02:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Nov 2012 11:02:27 +0100 Subject: Heads up: Mapper -> Mapper In-Reply-To: References: <509931E7.6080800@oracle.com> Message-ID: <97446088-FF00-42E8-AA85-2DBE3C4456B1@oracle.com> Hi Sam, Can you voice your concerns on the EG list? I think you raise an important point. Paul. On Nov 6, 2012, at 6:20 PM, Sam Pullara wrote: > Neither Scala nor Guava makes this ordering choice. Let's not be innovative where it doesn't matter and will only cause confusion. > > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html > http://www.scala-lang.org/api/current/scala/Function1.html > From paul.sandoz at oracle.com Wed Nov 7 02:12:37 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 07 Nov 2012 10:12:37 +0000 Subject: hg: lambda/lambda/jdk: Removed doc for unused type parameter. Message-ID: <20121107101348.E7D62477EC@hg.openjdk.java.net> Changeset: 943163d2acab Author: psandoz Date: 2012-11-07 11:12 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/943163d2acab Removed doc for unused type parameter. ! src/share/classes/java/util/streams/BaseStream.java From georgiy.rakov at oracle.com Wed Nov 7 02:22:09 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 07 Nov 2012 14:22:09 +0400 Subject: Sorting streams containing nulls Message-ID: <509A3651.8020602@oracle.com> Hello. When we make sorted(...).iterator() on Stream instance containing one ore more nulls we receive NPE. The example of stack trace is below: java.lang.NullPointerException at java.util.PriorityQueue.offer(PriorityQueue.java:320) at java.util.PriorityQueue.add(PriorityQueue.java:306) at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) at java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) ... Could you please tell if it is considered as expected behavior or it's going to be fixed somehow. Georgiy. From maurizio.cimadamore at oracle.com Wed Nov 7 03:39:55 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 07 Nov 2012 11:39:55 +0000 Subject: hg: lambda/lambda/langtools: Bug fixes: Message-ID: <20121107114005.16CCB477EE@hg.openjdk.java.net> Changeset: d18de0997cba Author: mcimadamore Date: 2012-11-07 11:39 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d18de0997cba Bug fixes: *) Spurious functional interface conversion error when target type inherits default methods *) 269 visitor should accept 'implicit' intersection types ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/TargetType47.java From maurizio.cimadamore at oracle.com Wed Nov 7 03:43:28 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 07 Nov 2012 11:43:28 +0000 Subject: hg: lambda/lambda/jdk: Changes: Message-ID: <20121107114452.AD3D7477EF@hg.openjdk.java.net> Changeset: a5509d6347cf Author: mcimadamore Date: 2012-11-07 11:42 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a5509d6347cf Changes: *) Revert temporary workarounds to javac issue with spurious functional interface errors *) Fix tests in jdk/combo-tests to use new default method syntax ! combo-tests/tests/tools/javac/lambda/DefaultMethodAddTest.java ! combo-tests/tests/tools/javac/lambda/DefaultMethodRemoveTest.java ! combo-tests/tests/tools/javac/lambda/SourceTargetVersionTest.java ! src/share/classes/java/util/streams/Streams.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java From paul.sandoz at oracle.com Wed Nov 7 04:27:31 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 07 Nov 2012 12:27:31 +0000 Subject: hg: lambda/lambda/jdk: - ensure PARALLEL flag is cleared if sequential evaluation is performed Message-ID: <20121107122742.91F7D477F0@hg.openjdk.java.net> Changeset: b734873a4c79 Author: psandoz Date: 2012-11-07 13:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b734873a4c79 - ensure PARALLEL flag is cleared if sequential evaluation is performed because the stream is pulled. - Flag tests need to use test data that supports parallel streams (ArrayList temporarily does not currently support parallel streams). - Added flag test that explicit tests that SIZED and ORDERED are preserved for stateful operations when evaluated in parallel. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/StreamOpFlags.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java From brian.goetz at oracle.com Wed Nov 7 05:30:03 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 7 Nov 2012 08:30:03 -0500 Subject: Sorting streams containing nulls In-Reply-To: <509A3651.8020602@oracle.com> References: <509A3651.8020602@oracle.com> Message-ID: The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: > Hello. > > When we make sorted(...).iterator() on Stream instance containing one > ore more nulls we receive NPE. The example of stack trace is below: > > java.lang.NullPointerException > at java.util.PriorityQueue.offer(PriorityQueue.java:320) > at java.util.PriorityQueue.add(PriorityQueue.java:306) > at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) > at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) > at > java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) > ... > > Could you please tell if it is considered as expected behavior or it's > going to be fixed somehow. > > Georgiy. > From forax at univ-mlv.fr Wed Nov 7 05:43:38 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 07 Nov 2012 14:43:38 +0100 Subject: Sorting streams containing nulls In-Reply-To: References: <509A3651.8020602@oracle.com> Message-ID: <509A658A.2040206@univ-mlv.fr> On 11/07/2012 02:30 PM, Brian Goetz wrote: > The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. so it's an implementation bug ? All Queue don't accept null so either null need to be masked/unmasked or the implementation has to be changed. R?mi > > > > On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: > >> Hello. >> >> When we make sorted(...).iterator() on Stream instance containing one >> ore more nulls we receive NPE. The example of stack trace is below: >> >> java.lang.NullPointerException >> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >> at java.util.PriorityQueue.add(PriorityQueue.java:306) >> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >> at >> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >> ... >> >> Could you please tell if it is considered as expected behavior or it's >> going to be fixed somehow. >> >> Georgiy. >> > From sergey.kuksenko at oracle.com Wed Nov 7 06:08:25 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 07 Nov 2012 18:08:25 +0400 Subject: Sorting streams containing nulls In-Reply-To: <509A658A.2040206@univ-mlv.fr> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> Message-ID: <509A6B59.7040307@oracle.com> But it is sorted stream. How should we compare null with other values? On 11/07/2012 05:43 PM, Remi Forax wrote: > On 11/07/2012 02:30 PM, Brian Goetz wrote: >> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. > > so it's an implementation bug ? > All Queue don't accept null so either null need to be masked/unmasked or > the implementation has to be changed. > > R?mi > >> >> >> >> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >> >>> Hello. >>> >>> When we make sorted(...).iterator() on Stream instance containing one >>> ore more nulls we receive NPE. The example of stack trace is below: >>> >>> java.lang.NullPointerException >>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>> at >>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>> ... >>> >>> Could you please tell if it is considered as expected behavior or it's >>> going to be fixed somehow. >>> >>> Georgiy. >>> >> > > -- Best regards, Sergey Kuksenko From scolebourne at joda.org Wed Nov 7 06:44:11 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 7 Nov 2012 14:44:11 +0000 Subject: Trying binary drop Message-ID: Version lambda-8-b63-windows-x64-30_oct_2012 One possible issue: 1) Error trace uses the older # syntax for error messages: [javac] C:\dev\threeten\threeten\src-standard\test\java\javax\time\Examples. java:134: error: method query in class DefaultInterfaceDateTimeAccessor cannot b e applied to given types; [javac] System.out.println("Test: " + dt2.query(MonthDay::of)); [javac] ^ [javac] required: Query [javac] found: MonthDay#of Stephen From maurizio.cimadamore at oracle.com Wed Nov 7 07:23:05 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 07 Nov 2012 15:23:05 +0000 Subject: Trying binary drop In-Reply-To: References: Message-ID: <509A7CD9.5020305@oracle.com> On 07/11/12 14:44, Stephen Colebourne wrote: > Version lambda-8-b63-windows-x64-30_oct_2012 > One possible issue: > > 1) Error trace uses the older # syntax for error messages: > > [javac] C:\dev\threeten\threeten\src-standard\test\java\javax\time\Examples. > java:134: error: method query in class DefaultInterfaceDateTimeAccessor cannot b > e applied to given types; > [javac] System.out.println("Test: " + dt2.query(MonthDay::of)); > [javac] ^ > [javac] required: Query > [javac] found: MonthDay#of > > Stephen > Whoops! Thanks - I will fix this. Maurizio From henry.jen at oracle.com Wed Nov 7 07:34:32 2012 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 7 Nov 2012 07:34:32 -0800 Subject: Comparators.comparing(Mapper) Re: Heads up: Mapper -> Mapper In-Reply-To: <14F42774-5698-4537-A90C-BE8B55C33E77@oracle.com> References: <8B889F61-BE3B-4CFA-AAEC-5EFE0760823E@oracle.com> <14F42774-5698-4537-A90C-BE8B55C33E77@oracle.com> Message-ID: Uh, you are right, it's indeed the return type. Cheers, Henry On Nov 7, 2012, at 1:58 AM, Paul Sandoz wrote: > On Nov 7, 2012, at 2:11 AM, Henry Jen wrote: >> >>> all methods that declares a type parameter used as first parameter of a >>> functional type should also be declared first. >> >> For example, Comparators.comparing(Mapper) should be changed. >> > > You mean this one: > > public static > Comparator comparing(Mapper mapper) { > > I did not forget this :-) I deliberately left that as is because T is used as a parameter of the return type. > > Paul. > From bitterfoxc at gmail.com Wed Nov 7 23:45:10 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 8 Nov 2012 16:45:10 +0900 Subject: Different behavior between (F) and (Object & F) Message-ID: Hi, There is a different behavior in the same semantics: public class Main { interface F { void m(); default void clone() throws CloneNotSupportedException {} } public static void main(String[] args) { Object o; // implicit Object o = (F) () -> {}; // pass compiler check // explicit Object o = (Object & F) () -> {}; // compile time error } } Compiler rejects "(Object & F) () -> {}", but it accepts "(F) () -> {}". Is this the correct behavior? This is the compile error by "(Object & F) () -> {}": Main.java:18: error: clone() in Object cannot implement clone() in F o = (Object & F) () -> {}; // compile time error ^ attempting to assign weaker access privileges; was public 1 error Regards, bitter_fox From paul.sandoz at oracle.com Thu Nov 8 00:41:44 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Nov 2012 09:41:44 +0100 Subject: Sorting streams containing nulls In-Reply-To: <509A3651.8020602@oracle.com> References: <509A3651.8020602@oracle.com> Message-ID: <8B3D572B-B217-43D8-8615-9CF418682A6B@oracle.com> Hi Georgiy, You may also run into issue with uniqueElements and groupBy. For parallel evaluation of both cases when encounter order does not need to be preserved a ConcurrentHashMap is used. For uniqueElements: - when the upstream is already sorted a different algorithm is used that currently uses null as a sentinel for the last seen value (which could be easily fixed) - when pulling (using Iterator) a null as a sentinel for the cached value is used. So expect more NPEs :-) This also raises the point that it is important to test various combinations of operations for sequential push/pull and parallel because depending on how the stream is accessed and the state of the upstream the current stream may employ a different algorithm. Paul. On Nov 7, 2012, at 11:22 AM, Georgiy Rakov wrote: > Hello. > > When we make sorted(...).iterator() on Stream instance containing one > ore more nulls we receive NPE. The example of stack trace is below: > > java.lang.NullPointerException > at java.util.PriorityQueue.offer(PriorityQueue.java:320) > at java.util.PriorityQueue.add(PriorityQueue.java:306) > at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) > at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) > at > java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) > ... > > Could you please tell if it is considered as expected behavior or it's > going to be fixed somehow. > > Georgiy. > From georgiy.rakov at oracle.com Thu Nov 8 01:51:44 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 08 Nov 2012 13:51:44 +0400 Subject: Sorting streams containing nulls In-Reply-To: References: <509A3651.8020602@oracle.com> Message-ID: <509B80B0.2090403@oracle.com> I could suppose that NPE is thrown because of the sorted() implementation - see stack trace. It uses PriorityQueue for internal purpose; PriorityQueue doesn't support nulls that's why NPE is thrown. If I understand you correctly this is supposed to be fixed, could you please tell if it's really so. Georgiy. On 07.11.2012 17:30, Brian Goetz wrote: > The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. > > > > On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: > >> Hello. >> >> When we make sorted(...).iterator() on Stream instance containing one >> ore more nulls we receive NPE. The example of stack trace is below: >> >> java.lang.NullPointerException >> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >> at java.util.PriorityQueue.add(PriorityQueue.java:306) >> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >> at >> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >> ... >> >> Could you please tell if it is considered as expected behavior or it's >> going to be fixed somehow. >> >> Georgiy. >> From paul.sandoz at oracle.com Thu Nov 8 02:42:35 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Nov 2012 11:42:35 +0100 Subject: Issue with compiler recognising a functional interface? Message-ID: Hi, I am running into an issue with the compiler with latest code. See end of email for all relevant interfaces. The compiler fails for: IntInfiniteIterator iterator = () -> t; [javac] /Users/sandoz/Projects/jdk8/lambda/jdk/src/share/classes/java/util/streams/primitives/Primitives.java:282: error: incompatible types: the target type must be a functional interface [javac] IntInfiniteIterator iterator = () -> t; But works for: InfiniteIterator iterator = () -> t; I would of expected the former to work since there is just one non-default method. Paul. interface Iterator { boolean hasNext(); E next(); default void remove() { throw new UnsupportedOperationException("remove"); } default void forEach(Block block) { while (hasNext()) block.apply(next()); } } interface InfiniteIterator extends Iterator { @Override public default boolean hasNext() { return true; } } interface IntIterator extends Iterator { // Iterator @Override default Integer next() { Logger.getLogger(getClass().getName()).log(Level.WARNING, "{0} using boxed int", getClass().getName()); return nextInt(); } @Override default void forEach(Block sink) { if (sink instanceof IntBlock) { forEach((IntBlock) sink); } else { Iterator.super.forEach(sink); } } // int nextInt(); default void forEach(IntBlock sink) { while (hasNext()) { sink.applyInt(nextInt()); } } } interface IntInfiniteIterator extends IntIterator { @Override default boolean hasNext() { return true; } } From david.holmes at oracle.com Thu Nov 8 02:58:11 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Nov 2012 20:58:11 +1000 Subject: Issue with compiler recognising a functional interface? In-Reply-To: References: Message-ID: <509B9043.9080204@oracle.com> On 8/11/2012 8:42 PM, Paul Sandoz wrote: > Hi, > > I am running into an issue with the compiler with latest code. Is this the bug Mike referred to here: http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006485.html David ----- > See end of email for all relevant interfaces. > > The compiler fails for: > > IntInfiniteIterator iterator = () -> t; > > [javac] /Users/sandoz/Projects/jdk8/lambda/jdk/src/share/classes/java/util/streams/primitives/Primitives.java:282: error: incompatible types: the target type must be a functional interface > [javac] IntInfiniteIterator iterator = () -> t; > > But works for: > > InfiniteIterator iterator = () -> t; > > I would of expected the former to work since there is just one non-default method. > > Paul. > > interface Iterator { > boolean hasNext(); > > E next(); > > default void remove() { > throw new UnsupportedOperationException("remove"); > } > > default void forEach(Block block) { > while (hasNext()) > block.apply(next()); > } > } > > interface InfiniteIterator extends Iterator { > @Override > public default boolean hasNext() { > return true; > } > } > > interface IntIterator extends Iterator { > > // Iterator > > @Override > default Integer next() { > Logger.getLogger(getClass().getName()).log(Level.WARNING, "{0} using boxed int", getClass().getName()); > return nextInt(); > } > > > @Override > default void forEach(Block sink) { > if (sink instanceof IntBlock) { > forEach((IntBlock) sink); > } > else { > Iterator.super.forEach(sink); > } > } > > // > > int nextInt(); > > default void forEach(IntBlock sink) { > while (hasNext()) { > sink.applyInt(nextInt()); > } > } > } > > interface IntInfiniteIterator extends IntIterator { > @Override > default boolean hasNext() { > return true; > } > } > > From paul.sandoz at oracle.com Thu Nov 8 03:05:22 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Nov 2012 12:05:22 +0100 Subject: Issue with compiler recognising a functional interface? In-Reply-To: <509B9043.9080204@oracle.com> References: <509B9043.9080204@oracle.com> Message-ID: <4A6A846B-54BC-4A9F-AC92-AC6A2001BED1@oracle.com> On Nov 8, 2012, at 11:58 AM, David Holmes wrote: > On 8/11/2012 8:42 PM, Paul Sandoz wrote: >> Hi, >> >> I am running into an issue with the compiler with latest code. > > Is this the bug Mike referred to here: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006485.html > It could be, but i thought Maurizio fixed it: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a78999ebabfc http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d18de0997cba Paul. From oleksander.demura at gmail.com Thu Nov 8 05:32:57 2012 From: oleksander.demura at gmail.com (Olexandr Demura) Date: Thu, 8 Nov 2012 15:32:57 +0200 Subject: invalid functional descriptor - method is generic Message-ID: Could you please explain motivation behind restriction on generic methods yo not being able to use define functional interface as SAM? I tried to expose java.util.Mapping as functional interface thru CPS, but it happened to not work - errors on both `Both` definitions. java: incompatible types: invalid functional descriptor: method fold(lamb.da.data.bi.Combiner) in interface lamb.da.data.bi.Both is generic. public interface Both extends Mapping, BiFunctee { U fold(Combiner c); @Override K getKey() default { return fold((k, v) -> k); } @Override V getValue() default { return fold((k, v) -> v); } @Override Both map( Mapper m, Mapper n ) default { Both this0 = this; return c -> this0.fold(c.precombine(m, n)); } @Override Both swap() default { final Both this0 = this; return (m) -> this0.fold((K k, V v) -> m.combine(v, k)); } } openjdk version "1.8.0-ea" OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1669-20121030-b63-b00) OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) Note, I code that for fun, not for highly loaded production system; none of which supports lambdas anyway since java8 is a toy yet. From maurizio.cimadamore at oracle.com Thu Nov 8 05:39:43 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 13:39:43 +0000 Subject: Different behavior between (F) and (Object & F) In-Reply-To: References: Message-ID: <509BB61F.3080701@oracle.com> This glitch is due to the fact that translation code for lambdas whose target is an intersection type is not there yet. So, as a short-time hack, we adopted the view that the first type of an intersection types dictates how lambda conversion should work. This is all temporary and will be removed. Maurizio On 08/11/12 07:45, bitter_fox wrote: > Hi, > There is a different behavior in the same semantics: > > public class Main > { > interface F > { > void m(); > default void clone() throws CloneNotSupportedException {} > } > > public static void main(String[] args) > { > Object o; > > // implicit Object > o = (F) () -> {}; // pass compiler check > > // explicit Object > o = (Object & F) () -> {}; // compile time error > } > } > > Compiler rejects "(Object & F) () -> {}", but it accepts "(F) () -> {}". > Is this the correct behavior? > > This is the compile error by "(Object & F) () -> {}": > > Main.java:18: error: clone() in Object cannot implement clone() in F > o = (Object & F) () -> {}; // compile time error > ^ > attempting to assign weaker access privileges; was public > 1 error > > Regards, > bitter_fox > From maurizio.cimadamore at oracle.com Thu Nov 8 05:40:48 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 13:40:48 +0000 Subject: invalid functional descriptor - method is generic In-Reply-To: References: Message-ID: <509BB660.3000500@oracle.com> This is a restriction that has been removed - the code needs to be updated and reflect that. Maurizio On 08/11/12 13:32, Olexandr Demura wrote: > Could you please explain motivation behind restriction on generic methods > yo not being able to use define functional interface as SAM? > > I tried to expose java.util.Mapping as functional interface thru CPS, > but it happened to not work - errors on both `Both` definitions. > > java: incompatible types: invalid functional descriptor: method > fold(lamb.da.data.bi.Combiner) in interface lamb.da.data.bi.Both > is generic. > > public interface Both extends Mapping, BiFunctee { > U fold(Combiner c); > > @Override > K getKey() default { return fold((k, v) -> k); } > > @Override > V getValue() default { return fold((k, v) -> v); } > > @Override > Both map( > Mapper m, > Mapper n > ) default { > Both this0 = this; > return c -> this0.fold(c.precombine(m, n)); > } > > @Override > Both swap() default { > final Both this0 = this; > return (m) -> this0.fold((K k, V v) -> m.combine(v, k)); > } > > } > > openjdk version "1.8.0-ea" > OpenJDK Runtime Environment (build > 1.8.0-ea-lambda-nightly-h1669-20121030-b63-b00) > OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) > > Note, I code that for fun, not for highly loaded production system; > none of which supports lambdas anyway since java8 is a toy yet. > From brian.goetz at oracle.com Thu Nov 8 05:45:46 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 08 Nov 2012 08:45:46 -0500 Subject: Different behavior between (F) and (Object & F) In-Reply-To: References: Message-ID: <509BB78A.5030904@oracle.com> Casting a lambda/method ref to (T & U) requires that - T be a functional interface - U be a marker (ZAM) interface So, the compiler behavior is correct. However, the error message could probably be clearer. On 11/8/2012 2:45 AM, bitter_fox wrote: > Hi, > There is a different behavior in the same semantics: > > public class Main > { > interface F > { > void m(); > default void clone() throws CloneNotSupportedException {} > } > > public static void main(String[] args) > { > Object o; > > // implicit Object > o = (F) () -> {}; // pass compiler check > > // explicit Object > o = (Object & F) () -> {}; // compile time error > } > } > > Compiler rejects "(Object & F) () -> {}", but it accepts "(F) () -> {}". > Is this the correct behavior? > > This is the compile error by "(Object & F) () -> {}": > > Main.java:18: error: clone() in Object cannot implement clone() in F > o = (Object & F) () -> {}; // compile time error > ^ > attempting to assign weaker access privileges; was public > 1 error > > Regards, > bitter_fox > From brian.goetz at oracle.com Thu Nov 8 05:47:38 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 08 Nov 2012 08:47:38 -0500 Subject: Sorting streams containing nulls In-Reply-To: <509B80B0.2090403@oracle.com> References: <509A3651.8020602@oracle.com> <509B80B0.2090403@oracle.com> Message-ID: <509BB7FA.2060104@oracle.com> This implementation may be changed, but I find it hard to imagine that in the general case, sorting streams with nulls will not throw NPE somewhere. (For example, most comparators do not check for null.) On 11/8/2012 4:51 AM, Georgiy Rakov wrote: > I could suppose that NPE is thrown because of the sorted() > implementation - see stack trace. It uses PriorityQueue for internal > purpose; PriorityQueue doesn't support nulls that's why NPE is thrown. > If I understand you correctly this is supposed to be fixed, could you > please tell if it's really so. > > Georgiy. > > On 07.11.2012 17:30, Brian Goetz wrote: >> The exact specification is not yet written, but we are not expecting >> stream implementations or operations to do anything special with >> nulls. This means nulls may be passed to lambdas or inserted into >> collections that do not support them, resulting in NPE. >> >> >> >> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >> >>> Hello. >>> >>> When we make sorted(...).iterator() on Stream instance containing one >>> ore more nulls we receive NPE. The example of stack trace is below: >>> >>> java.lang.NullPointerException >>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>> at >>> java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>> at >>> >>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>> ... >>> >>> Could you please tell if it is considered as expected behavior or it's >>> going to be fixed somehow. >>> >>> Georgiy. >>> From brian.goetz at oracle.com Thu Nov 8 05:52:47 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 08 Nov 2012 08:52:47 -0500 Subject: invalid functional descriptor - method is generic In-Reply-To: References: Message-ID: <509BB92F.3080908@oracle.com> Functional interfaces may be generic. The problem is, there is no syntax for introducing a type parameter into a lambda, and it was deemed not to be a significant enough concern to introduce yet more syntax. (There would need to be something as part of the lambda to hold the introduction of the type parameters .) We felt that the syntactic intrusion for Java 8 was big enough that introducing additional new syntax for corner cases like this was not warranted. Generic methods can be converted to generic functional interfaces as method refs: GenericFunctionalIntf g = SomeClass::someGenericMethod; On 11/8/2012 8:32 AM, Olexandr Demura wrote: > Could you please explain motivation behind restriction on generic methods > yo not being able to use define functional interface as SAM? > > I tried to expose java.util.Mapping as functional interface thru CPS, > but it happened to not work - errors on both `Both` definitions. > > java: incompatible types: invalid functional descriptor: method > fold(lamb.da.data.bi.Combiner) in interface lamb.da.data.bi.Both > is generic. > > public interface Both extends Mapping, BiFunctee { > U fold(Combiner c); > > @Override > K getKey() default { return fold((k, v) -> k); } > > @Override > V getValue() default { return fold((k, v) -> v); } > > @Override > Both map( > Mapper m, > Mapper n > ) default { > Both this0 = this; > return c -> this0.fold(c.precombine(m, n)); > } > > @Override > Both swap() default { > final Both this0 = this; > return (m) -> this0.fold((K k, V v) -> m.combine(v, k)); > } > > } > > openjdk version "1.8.0-ea" > OpenJDK Runtime Environment (build > 1.8.0-ea-lambda-nightly-h1669-20121030-b63-b00) > OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) > > Note, I code that for fun, not for highly loaded production system; > none of which supports lambdas anyway since java8 is a toy yet. > From fsarradin at xebia.fr Thu Nov 8 05:06:44 2012 From: fsarradin at xebia.fr (=?ISO-8859-1?Q?Fran=E7ois_Sarradin?=) Date: Thu, 8 Nov 2012 14:06:44 +0100 Subject: =?UTF-8?Q?Re=3A_Report=3A_Will_Java_8=E2=80=B2s_Lambda_Change_The_Face_o?= =?UTF-8?Q?f_The_World=3F?= In-Reply-To: References: Message-ID: 2012/11/7 Olexandr Demura : > On the "The new syntax is nice, but not for everyone" part. > 1. `map` and `reduce` can be combined into one `fold`, but your code example > shows it would be clumsier. > > Streams.stream(myCollection) > .map(product -> product.getUnitPrice() * product.getQuantity()) > .reduce(0.0, (subTotal, price) -> subTotal + price) > > vs > > products.stream().fold( > () -> 0.0, > (subTotal, product) -> subTotal + product.getUnitPrice() * > product.getQuantity(), > (subTotal1, subTotal2) -> subTotal1 + subTotal2 /* not used if > sequential */); Before fold, there was a mapReduce method, with almost the same signature. I have presented this method. But it has not convinced the audience. That fact is that the map part and the reduce are separated. The audience has not understood why they are separated. > 2. Current documentation suggests stream methods should not be on collection > interfaces to not bloat them since there is no single stream implementation. > > e.g. products.stream() vs products.parallel() I understand this. But the result is that we have to use an intermediary method call that looks like noise addition in the method chaining for the audience. This is not really intuitive. > 3. May be they need not implicit parameters but primitive operation > references? > > 3.1. java is explicit language (except `+` for String). `java` in IPA close > to 'explicit' in several Slavic languages :) > > 3.2. when parameter is not needed method references `::` can be used. I have explained the notion of method reference and the notation '::'. It seems this was not sufficient :/ Thank for your feedback! Fran?ois- > 2012/11/6 Fran?ois Sarradin >> >> Hi, >> >> I know that you are looking for feedback. So during October, I >> organized a presentation around the JSR335 at my company: Xebia >> France. More precisely, it was an interactive session with a >> presentation, some live coding and debates around the code, and a >> retrospective. The audience was asked the impact of the Lambda Project >> on the Java community and Java projects would probably be. I have >> reported what has been said during my presentation on the blog of my >> company: >> http://blog.xebia.com/2012/11/05/report-will-java-8s-lambda-change-the-face-of-the-world/ >> >> Regards, >> >> Fran?ois Sarradin >> Xebia IT Architects >> http://www.xebia.fr >> http://blog.xebia.fr >> > From sergey.kuksenko at oracle.com Thu Nov 8 06:09:47 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Thu, 08 Nov 2012 18:09:47 +0400 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BB78A.5030904@oracle.com> References: <509BB78A.5030904@oracle.com> Message-ID: <509BBD2B.2000803@oracle.com> Why just not to make all lambdas serializable and forget about that? Allowing to mark lambda with ZAM will cause a huge usage of ZAM marking interfaces in user's code. They get new feature -> they will use it in all possible ways. But you may check marking with ZAM only by instanceof that is not a good style. On 11/08/2012 05:45 PM, Brian Goetz wrote: > Casting a lambda/method ref to (T & U) requires that > - T be a functional interface > - U be a marker (ZAM) interface > > So, the compiler behavior is correct. However, the error message could > probably be clearer. > > On 11/8/2012 2:45 AM, bitter_fox wrote: >> Hi, >> There is a different behavior in the same semantics: >> >> public class Main >> { >> interface F >> { >> void m(); >> default void clone() throws CloneNotSupportedException {} >> } >> >> public static void main(String[] args) >> { >> Object o; >> >> // implicit Object >> o = (F) () -> {}; // pass compiler check >> >> // explicit Object >> o = (Object & F) () -> {}; // compile time error >> } >> } >> >> Compiler rejects "(Object & F) () -> {}", but it accepts "(F) () -> {}". >> Is this the correct behavior? >> >> This is the compile error by "(Object & F) () -> {}": >> >> Main.java:18: error: clone() in Object cannot implement clone() in F >> o = (Object & F) () -> {}; // compile time error >> ^ >> attempting to assign weaker access privileges; was public >> 1 error >> >> Regards, >> bitter_fox >> > -- Best regards, Sergey Kuksenko From maurizio.cimadamore at oracle.com Thu Nov 8 06:18:23 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 14:18:23 +0000 Subject: Issue with compiler recognising a functional interface? In-Reply-To: <4A6A846B-54BC-4A9F-AC92-AC6A2001BED1@oracle.com> References: <509B9043.9080204@oracle.com> <4A6A846B-54BC-4A9F-AC92-AC6A2001BED1@oracle.com> Message-ID: <509BBF2F.1020404@oracle.com> On 08/11/12 11:05, Paul Sandoz wrote: > On Nov 8, 2012, at 11:58 AM, David Holmes wrote: > >> On 8/11/2012 8:42 PM, Paul Sandoz wrote: >>> Hi, >>> >>> I am running into an issue with the compiler with latest code. >> Is this the bug Mike referred to here: >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006485.html >> > It could be, but i thought Maurizio fixed it: > > http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a78999ebabfc > http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d18de0997cba > > Paul. > I'm working on a follow up fix (it seems yesterday fix didn't address the issue in its entirety). Will push it soon. Maurizio From bitterfoxc at gmail.com Thu Nov 8 06:40:27 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 8 Nov 2012 23:40:27 +0900 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BB61F.3080701@oracle.com> References: <509BB61F.3080701@oracle.com> Message-ID: Hi, Sorry for your confusing by my insufficient explanation. I think accepting is not a correct behavior because it seems the compiler doesn't check override of clone of Object. Object has a protected clone method and F has a public clone method. The compiler makes "class $$lambda$n implements F"(implicitly it extends Object). In this case the Object's protected clone will win. So the $$lambda$n has a protected clone. This is illegal by JLS[8.4.8.3][1]. JLS[8.4.8.3] Requirements in Overriding and Hiding " If the overridden or hidden method is public, then the overriding or hiding method must be public; otherwise, a compile-time error occurs." In this case, the overridden method is F#clone and this is public, and the overriding method is Object#clone and this is not public. This would be compile-time error. [1]: http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.8.3 Regards, bitter_fox 2012/11/8 Maurizio Cimadamore > This glitch is due to the fact that translation code for lambdas whose > target is an intersection type is not there yet. So, as a short-time hack, > we adopted the view that the first type of an intersection types dictates > how lambda conversion should work. This is all temporary and will be > removed. > > Maurizio > > > On 08/11/12 07:45, bitter_fox wrote: > >> Hi, >> There is a different behavior in the same semantics: >> >> public class Main >> { >> interface F >> { >> void m(); >> default void clone() throws CloneNotSupportedException {} >> } >> >> public static void main(String[] args) >> { >> Object o; >> >> // implicit Object >> o = (F) () -> {}; // pass compiler check >> >> // explicit Object >> o = (Object & F) () -> {}; // compile time error >> } >> } >> >> Compiler rejects "(Object & F) () -> {}", but it accepts "(F) () -> {}". >> Is this the correct behavior? >> >> This is the compile error by "(Object & F) () -> {}": >> >> Main.java:18: error: clone() in Object cannot implement clone() in F >> o = (Object & F) () -> {}; // compile time error >> ^ >> attempting to assign weaker access privileges; was public >> 1 error >> >> Regards, >> bitter_fox >> >> > From maurizio.cimadamore at oracle.com Thu Nov 8 06:49:21 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 14:49:21 +0000 Subject: Different behavior between (F) and (Object & F) In-Reply-To: References: <509BB61F.3080701@oracle.com> Message-ID: <509BC671.7090008@oracle.com> On 08/11/12 14:40, bitter_fox wrote: > In this case, the overridden method is F#clone and this is public, and > the overriding method is Object#clone and this is not public. This > would be compile-time error. Strictly speaking this is all true. Javac (and other compilers too) has a tendency to defer this kind of checks. For instance, even w/o lambdas, it is possible to write code like: class Foo { } Now, should this be illegal? The current view is that we let the type-witness to provide a public overrider for Object's clone. So the well-formedness check for intersection types has been historically loose in this respect; right now, javac is re-using the same well-formedness check regardless of whether the intersection type appears as a type-variable bound or as a cast target; this seems reasonable, however it leaves out few cases as you correctly point out. It is very likely that some additional restrictions on intersection types will come out when they are used as a target of a functional expression. Maurizio From brian.goetz at oracle.com Thu Nov 8 06:51:36 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 08 Nov 2012 09:51:36 -0500 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BBD2B.2000803@oracle.com> References: <509BB78A.5030904@oracle.com> <509BBD2B.2000803@oracle.com> Message-ID: <509BC6F8.4030800@oracle.com> > Why just not to make all lambdas serializable and forget about that? Several reasons, including: - Performance. Because of our translation strategy, there's a performance cost to making all lambdas serializable: - Extra static footprint in the capturing class - Extra dynamic footprint under some translation schemes (since lambda would have to reify all the indy call information present at the capture site, including static and dynamic arguments) - Some translation schemes can't handle it at all, and this would take these off the table, limiting the range of implementation choices - Security. Serializable lambdas effectively get desugared to public methods; this means snippets of logic that were implementation details of a computation become publicly addressable. Making this true by default increases the attack surface by probably 5 orders of magnitude. > Allowing to mark lambda with ZAM will cause a huge usage of ZAM marking > interfaces in user's code. They get new feature -> they will use it in > all possible ways. But you may check marking with ZAM only by instanceof > that is not a good style. I am not sure it will show up that often. The primary use case is 'defensive combinators', like Predicate.and(p1, p2), where you want the result to be serializable if the input predicates are. But this is locked in library code. The secondary use case is comparators passed to the constructor of TreeMap and the like. But, we did some analysis of existing uses of serializable and concluded that the syntactic intrusion would not be very widespread -- but of course we could be wrong. The choice of syntax for serialization opt-in was one of the hardest decisions the EG had to make. We considered at least a dozen candidates, all of which sucked so badly we gave up and had to come back to it -- twice. In the end we chose (IMO) the least objectionable. From brian.goetz at oracle.com Thu Nov 8 06:59:04 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 08 Nov 2012 09:59:04 -0500 Subject: Report: Will Java =?UTF-8?B?OOKAsnMgTGFtYmRhIENoYW5nZSBUaGUg?= =?UTF-8?B?RmFjZSBvZiBUaGUgV29ybGQ/?= In-Reply-To: References: Message-ID: <509BC8B8.8040405@oracle.com> > Before fold, there was a mapReduce method, with almost the same > signature. I have presented this method. But it has not convinced the > audience. That fact is that the map part and the reduce are separated. > The audience has not understood why they are separated. With the existing API, it is possible to "fold" the mapping into the combiner if you want -- have your reducing function be (sum, elt) -> sum + map(elt). But a single method with two lambdas is not going to be more usable -- people will have to reason about which lambda does what based on position. The current configuation of reduce and fold methods is scheduled to be revisited. But I don't see much merit in a fused mapReduce(Mapper, Reducer), other than the ability to do the computation in the primitive domain rather than the boxed domain -- and we have another approach for that. >> 2. Current documentation suggests stream methods should not be on collection >> interfaces to not bloat them since there is no single stream implementation. >> >> e.g. products.stream() vs products.parallel() > > I understand this. But the result is that we have to use an > intermediary method call that looks like noise addition in the method > chaining for the audience. This is not really intuitive. Understood. This was a difficult trade-off. In fact, I resisted this for a long time. But in the end, it was clearly the right choice. When you are retrofitting functionality onto existing libraries, sometimes you must choose the lesser of evils. From maurizio.cimadamore at oracle.com Thu Nov 8 07:06:52 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 15:06:52 +0000 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BC671.7090008@oracle.com> References: <509BB61F.3080701@oracle.com> <509BC671.7090008@oracle.com> Message-ID: <509BCA8C.1070408@oracle.com> Forget my previous email - I know realize what your email is about - should this code work? interface F { Object clone(); } F f = ()->null; I think it should - the metafactory will ggenerate a _public_ implementation for the clone method - i.e. class $$$lambdaClass$$$ implements F { public Object clone() { return null; } } Which is legal... Maurizio On 08/11/12 14:49, Maurizio Cimadamore wrote: > On 08/11/12 14:40, bitter_fox wrote: >> In this case, the overridden method is F#clone and this is public, and >> the overriding method is Object#clone and this is not public. This >> would be compile-time error. > Strictly speaking this is all true. Javac (and other compilers too) has > a tendency to defer this kind of checks. For instance, even w/o lambdas, > it is possible to write code like: > > class Foo { } > > Now, should this be illegal? The current view is that we let the > type-witness to provide a public overrider for Object's clone. > > So the well-formedness check for intersection types has been > historically loose in this respect; right now, javac is re-using the > same well-formedness check regardless of whether the intersection type > appears as a type-variable bound or as a cast target; this seems > reasonable, however it leaves out few cases as you correctly point out. > It is very likely that some additional restrictions on intersection > types will come out when they are used as a target of a functional > expression. > > Maurizio > From bitterfoxc at gmail.com Thu Nov 8 07:17:49 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Fri, 9 Nov 2012 00:17:49 +0900 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BCA8C.1070408@oracle.com> References: <509BB61F.3080701@oracle.com> <509BC671.7090008@oracle.com> <509BCA8C.1070408@oracle.com> Message-ID: F#clone was provided default implementation. My case is: interface F { default Object clone() {} void m(); } F f = () -> {}; And it now passes compiler and it makes: class $$lambda$n implements F { public void m() { Enclosing.lambdan(); } // override protected Object clone() } I think () -> {} shouldn't pass compiler Regards, bitter_fox 2012/11/9 Maurizio Cimadamore > Forget my previous email - I know realize what your email is about - > should this code work? > > interface F { > Object clone(); > } > > F f = ()->null; > > I think it should - the metafactory will ggenerate a _public_ > implementation for the clone method - i.e. > > class $$$lambdaClass$$$ implements F { > public Object clone() { > return null; > } > } > > Which is legal... > > Maurizio > > On 08/11/12 14:49, Maurizio Cimadamore wrote: > >> On 08/11/12 14:40, bitter_fox wrote: >> >>> In this case, the overridden method is F#clone and this is public, and >>> the overriding method is Object#clone and this is not public. This >>> would be compile-time error. >>> >> Strictly speaking this is all true. Javac (and other compilers too) has >> a tendency to defer this kind of checks. For instance, even w/o lambdas, >> it is possible to write code like: >> >> class Foo { } >> >> Now, should this be illegal? The current view is that we let the >> type-witness to provide a public overrider for Object's clone. >> >> So the well-formedness check for intersection types has been >> historically loose in this respect; right now, javac is re-using the >> same well-formedness check regardless of whether the intersection type >> appears as a type-variable bound or as a cast target; this seems >> reasonable, however it leaves out few cases as you correctly point out. >> It is very likely that some additional restrictions on intersection >> types will come out when they are used as a target of a functional >> expression. >> >> Maurizio >> >> > From forax at univ-mlv.fr Thu Nov 8 08:09:22 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 08 Nov 2012 17:09:22 +0100 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BC6F8.4030800@oracle.com> References: <509BB78A.5030904@oracle.com> <509BBD2B.2000803@oracle.com> <509BC6F8.4030800@oracle.com> Message-ID: <509BD932.902@univ-mlv.fr> Hi Sergey, the security issue is very real, given that we want to use lambda to implement things like doPrivileged block, being able to serialize the lambda will leak all the captured values. R?mi On 11/08/2012 03:51 PM, Brian Goetz wrote: >> Why just not to make all lambdas serializable and forget about that? > Several reasons, including: > - Performance. Because of our translation strategy, there's a > performance cost to making all lambdas serializable: > - Extra static footprint in the capturing class > - Extra dynamic footprint under some translation schemes (since > lambda would have to reify all the indy call information present at the > capture site, including static and dynamic arguments) > - Some translation schemes can't handle it at all, and this would > take these off the table, limiting the range of implementation choices > > - Security. Serializable lambdas effectively get desugared to public > methods; this means snippets of logic that were implementation details > of a computation become publicly addressable. Making this true by > default increases the attack surface by probably 5 orders of magnitude. > >> Allowing to mark lambda with ZAM will cause a huge usage of ZAM marking >> interfaces in user's code. They get new feature -> they will use it in >> all possible ways. But you may check marking with ZAM only by instanceof >> that is not a good style. > I am not sure it will show up that often. The primary use case is > 'defensive combinators', like Predicate.and(p1, p2), where you want the > result to be serializable if the input predicates are. But this is > locked in library code. The secondary use case is comparators passed to > the constructor of TreeMap and the like. But, we did some analysis of > existing uses of serializable and concluded that the syntactic intrusion > would not be very widespread -- but of course we could be wrong. > > The choice of syntax for serialization opt-in was one of the hardest > decisions the EG had to make. We considered at least a dozen > candidates, all of which sucked so badly we gave up and had to come back > to it -- twice. In the end we chose (IMO) the least objectionable. > From maurizio.cimadamore at oracle.com Thu Nov 8 08:29:55 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 16:29:55 +0000 Subject: Different behavior between (F) and (Object & F) In-Reply-To: References: <509BB61F.3080701@oracle.com> <509BC671.7090008@oracle.com> <509BCA8C.1070408@oracle.com> Message-ID: <509BDE03.8020707@oracle.com> Ah right - this gives IllegalAccessErro... this has been on the todo list for a while; I think I will take a stab at it since I'm at it. Thanks Maurizio On 08/11/12 15:17, bitter_fox wrote: > F#clone was provided default implementation. > My case is: > > interface F > { > default Object clone() {} > > void m(); > } > > F f = () -> {}; > > And it now passes compiler and it makes: > > class $$lambda$n implements F > { > public void m() > { > Enclosing.lambdan(); > } > > // override protected Object clone() > } > > I think () -> {} shouldn't pass compiler > > Regards, > bitter_fox > > 2012/11/9 Maurizio Cimadamore > > > Forget my previous email - I know realize what your email is about > - should this code work? > > interface F { > Object clone(); > } > > F f = ()->null; > > I think it should - the metafactory will ggenerate a _public_ > implementation for the clone method - i.e. > > class $$$lambdaClass$$$ implements F { > public Object clone() { > return null; > } > } > > Which is legal... > > Maurizio > > On 08/11/12 14:49, Maurizio Cimadamore wrote: > > On 08/11/12 14:40, bitter_fox wrote: > > In this case, the overridden method is F#clone and this is > public, and > the overriding method is Object#clone and this is not > public. This > would be compile-time error. > > Strictly speaking this is all true. Javac (and other compilers > too) has > a tendency to defer this kind of checks. For instance, even > w/o lambdas, > it is possible to write code like: > > class Foo { } > > Now, should this be illegal? The current view is that we let the > type-witness to provide a public overrider for Object's clone. > > So the well-formedness check for intersection types has been > historically loose in this respect; right now, javac is > re-using the > same well-formedness check regardless of whether the > intersection type > appears as a type-variable bound or as a cast target; this seems > reasonable, however it leaves out few cases as you correctly > point out. > It is very likely that some additional restrictions on > intersection > types will come out when they are used as a target of a functional > expression. > > Maurizio > > > From sergey.kuksenko at oracle.com Thu Nov 8 08:34:53 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Thu, 08 Nov 2012 20:34:53 +0400 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BD932.902@univ-mlv.fr> References: <509BB78A.5030904@oracle.com> <509BBD2B.2000803@oracle.com> <509BC6F8.4030800@oracle.com> <509BD932.902@univ-mlv.fr> Message-ID: <509BDF2D.8020006@oracle.com> I see. The security is the answer which I need. Having the security issue Brian may not mention performance. :) On 11/08/2012 08:09 PM, Remi Forax wrote: > Hi Sergey, > the security issue is very real, given that we want to use lambda to > implement things like > doPrivileged block, being able to serialize the lambda will leak all the > captured values. > > R?mi > > On 11/08/2012 03:51 PM, Brian Goetz wrote: >>> Why just not to make all lambdas serializable and forget about that? >> Several reasons, including: >> - Performance. Because of our translation strategy, there's a >> performance cost to making all lambdas serializable: >> - Extra static footprint in the capturing class >> - Extra dynamic footprint under some translation schemes (since >> lambda would have to reify all the indy call information present at the >> capture site, including static and dynamic arguments) >> - Some translation schemes can't handle it at all, and this would >> take these off the table, limiting the range of implementation choices >> >> - Security. Serializable lambdas effectively get desugared to public >> methods; this means snippets of logic that were implementation details >> of a computation become publicly addressable. Making this true by >> default increases the attack surface by probably 5 orders of magnitude. >> >>> Allowing to mark lambda with ZAM will cause a huge usage of ZAM marking >>> interfaces in user's code. They get new feature -> they will use it in >>> all possible ways. But you may check marking with ZAM only by instanceof >>> that is not a good style. >> I am not sure it will show up that often. The primary use case is >> 'defensive combinators', like Predicate.and(p1, p2), where you want the >> result to be serializable if the input predicates are. But this is >> locked in library code. The secondary use case is comparators passed to >> the constructor of TreeMap and the like. But, we did some analysis of >> existing uses of serializable and concluded that the syntactic intrusion >> would not be very widespread -- but of course we could be wrong. >> >> The choice of syntax for serialization opt-in was one of the hardest >> decisions the EG had to make. We considered at least a dozen >> candidates, all of which sucked so badly we gave up and had to come back >> to it -- twice. In the end we chose (IMO) the least objectionable. >> > > -- Best regards, Sergey Kuksenko From maurizio.cimadamore at oracle.com Thu Nov 8 09:17:27 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 08 Nov 2012 17:17:27 +0000 Subject: hg: lambda/lambda/langtools: Bug fixes: Message-ID: <20121108171732.2953E4785B@hg.openjdk.java.net> Changeset: dc6dec36396b Author: mcimadamore Date: 2012-11-08 17:17 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dc6dec36396b Bug fixes: *) Spurious functional interface conversion error when target type inherits default methods (part two) *) target-type of lambda/method reference should be well-formed w.r.t. Object overrides ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/TargetType48.java + test/tools/javac/lambda/TargetType49.java + test/tools/javac/lambda/TargetType49.out From maurizio.cimadamore at oracle.com Thu Nov 8 09:53:46 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 17:53:46 +0000 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BDE03.8020707@oracle.com> References: <509BB61F.3080701@oracle.com> <509BC671.7090008@oracle.com> <509BCA8C.1070408@oracle.com> <509BDE03.8020707@oracle.com> Message-ID: <509BF1AA.6040206@oracle.com> On 08/11/12 16:29, Maurizio Cimadamore wrote: > Ah right - this gives IllegalAccessErro... this has been on the todo > list for a while; I think I will take a stab at it since I'm at it. Fixed now - the compiler now applies the same check in both cases. Maurizio > Thanks > Maurizio > > > On 08/11/12 15:17, bitter_fox wrote: >> F#clone was provided default implementation. >> My case is: >> >> interface F >> { >> default Object clone() {} >> >> void m(); >> } >> >> F f = () -> {}; >> >> And it now passes compiler and it makes: >> >> class $$lambda$n implements F >> { >> public void m() >> { >> Enclosing.lambdan(); >> } >> >> // override protected Object clone() >> } >> >> I think () -> {} shouldn't pass compiler >> >> Regards, >> bitter_fox >> >> 2012/11/9 Maurizio Cimadamore > > >> >> Forget my previous email - I know realize what your email is about >> - should this code work? >> >> interface F { >> Object clone(); >> } >> >> F f = ()->null; >> >> I think it should - the metafactory will ggenerate a _public_ >> implementation for the clone method - i.e. >> >> class $$$lambdaClass$$$ implements F { >> public Object clone() { >> return null; >> } >> } >> >> Which is legal... >> >> Maurizio >> >> On 08/11/12 14:49, Maurizio Cimadamore wrote: >> >> On 08/11/12 14:40, bitter_fox wrote: >> >> In this case, the overridden method is F#clone and this is >> public, and >> the overriding method is Object#clone and this is not >> public. This >> would be compile-time error. >> >> Strictly speaking this is all true. Javac (and other compilers >> too) has >> a tendency to defer this kind of checks. For instance, even >> w/o lambdas, >> it is possible to write code like: >> >> class Foo { } >> >> Now, should this be illegal? The current view is that we let the >> type-witness to provide a public overrider for Object's clone. >> >> So the well-formedness check for intersection types has been >> historically loose in this respect; right now, javac is >> re-using the >> same well-formedness check regardless of whether the >> intersection type >> appears as a type-variable bound or as a cast target; this seems >> reasonable, however it leaves out few cases as you correctly >> point out. >> It is very likely that some additional restrictions on >> intersection >> types will come out when they are used as a target of a functional >> expression. >> >> Maurizio >> >> >> > From maurizio.cimadamore at oracle.com Thu Nov 8 09:54:07 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 08 Nov 2012 17:54:07 +0000 Subject: Issue with compiler recognising a functional interface? In-Reply-To: <509BBF2F.1020404@oracle.com> References: <509B9043.9080204@oracle.com> <4A6A846B-54BC-4A9F-AC92-AC6A2001BED1@oracle.com> <509BBF2F.1020404@oracle.com> Message-ID: <509BF1BF.7020905@oracle.com> Fixed Maurizio On 08/11/12 14:18, Maurizio Cimadamore wrote: > On 08/11/12 11:05, Paul Sandoz wrote: >> On Nov 8, 2012, at 11:58 AM, David Holmes wrote: >> >>> On 8/11/2012 8:42 PM, Paul Sandoz wrote: >>>> Hi, >>>> >>>> I am running into an issue with the compiler with latest code. >>> Is this the bug Mike referred to here: >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006485.html >>> >> It could be, but i thought Maurizio fixed it: >> >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a78999ebabfc >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d18de0997cba >> >> Paul. >> > I'm working on a follow up fix (it seems yesterday fix didn't address > the issue in its entirety). Will push it soon. > > Maurizio > From brian.goetz at oracle.com Thu Nov 8 16:10:11 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 09 Nov 2012 00:10:11 +0000 Subject: hg: lambda/lambda/jdk: Convert AbstractTask to compute down the left spine instead of right spine; this avoids a data race from previous version and offers better behavior for findFirst/limit/skip. Message-ID: <20121109001041.770D647866@hg.openjdk.java.net> Changeset: 9de13de7fc77 Author: briangoetz Date: 2012-11-08 19:09 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9de13de7fc77 Convert AbstractTask to compute down the left spine instead of right spine; this avoids a data race from previous version and offers better behavior for findFirst/limit/skip. ! src/share/classes/java/util/streams/ops/AbstractTask.java From bitterfoxc at gmail.com Thu Nov 8 16:19:28 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Fri, 9 Nov 2012 09:19:28 +0900 Subject: Different behavior between (F) and (Object & F) In-Reply-To: <509BF1AA.6040206@oracle.com> References: <509BB61F.3080701@oracle.com> <509BC671.7090008@oracle.com> <509BCA8C.1070408@oracle.com> <509BDE03.8020707@oracle.com> <509BF1AA.6040206@oracle.com> Message-ID: Thank you for your fix. Regards, bitter_fox 2012/11/9 Maurizio Cimadamore > On 08/11/12 16:29, Maurizio Cimadamore wrote: > >> Ah right - this gives IllegalAccessErro... this has been on the todo >> list for a while; I think I will take a stab at it since I'm at it. >> > Fixed now - the compiler now applies the same check in both cases. > > Maurizio > >> Thanks >> Maurizio >> >> >> On 08/11/12 15:17, bitter_fox wrote: >> >>> F#clone was provided default implementation. >>> My case is: >>> >>> interface F >>> { >>> default Object clone() {} >>> >>> void m(); >>> } >>> >>> F f = () -> {}; >>> >>> And it now passes compiler and it makes: >>> >>> class $$lambda$n implements F >>> { >>> public void m() >>> { >>> Enclosing.lambdan(); >>> } >>> >>> // override protected Object clone() >>> } >>> >>> I think () -> {} shouldn't pass compiler >>> >>> Regards, >>> bitter_fox >>> >>> 2012/11/9 Maurizio Cimadamore >>> >>> >> >>> >>> >>> Forget my previous email - I know realize what your email is about >>> - should this code work? >>> >>> interface F { >>> Object clone(); >>> } >>> >>> F f = ()->null; >>> >>> I think it should - the metafactory will ggenerate a _public_ >>> implementation for the clone method - i.e. >>> >>> class $$$lambdaClass$$$ implements F { >>> public Object clone() { >>> return null; >>> } >>> } >>> >>> Which is legal... >>> >>> Maurizio >>> >>> On 08/11/12 14:49, Maurizio Cimadamore wrote: >>> >>> On 08/11/12 14:40, bitter_fox wrote: >>> >>> In this case, the overridden method is F#clone and this is >>> public, and >>> the overriding method is Object#clone and this is not >>> public. This >>> would be compile-time error. >>> >>> Strictly speaking this is all true. Javac (and other compilers >>> too) has >>> a tendency to defer this kind of checks. For instance, even >>> w/o lambdas, >>> it is possible to write code like: >>> >>> class Foo { } >>> >>> Now, should this be illegal? The current view is that we let the >>> type-witness to provide a public overrider for Object's clone. >>> >>> So the well-formedness check for intersection types has been >>> historically loose in this respect; right now, javac is >>> re-using the >>> same well-formedness check regardless of whether the >>> intersection type >>> appears as a type-variable bound or as a cast target; this seems >>> reasonable, however it leaves out few cases as you correctly >>> point out. >>> It is very likely that some additional restrictions on >>> intersection >>> types will come out when they are used as a target of a >>> functional >>> expression. >>> >>> Maurizio >>> >>> >>> >>> >> > From brian.goetz at oracle.com Thu Nov 8 16:47:07 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 09 Nov 2012 00:47:07 +0000 Subject: hg: lambda/lambda/jdk: Add parallel version of findAny Message-ID: <20121109004719.0A69447869@hg.openjdk.java.net> Changeset: 887edbc2572b Author: briangoetz Date: 2012-11-08 19:12 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/887edbc2572b Add parallel version of findAny ! src/share/classes/java/util/streams/ops/FindAnyOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java From paul.sandoz at oracle.com Fri Nov 9 02:45:24 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Nov 2012 11:45:24 +0100 Subject: Issue with compiler recognising a functional interface? In-Reply-To: <509BF1BF.7020905@oracle.com> References: <509B9043.9080204@oracle.com> <4A6A846B-54BC-4A9F-AC92-AC6A2001BED1@oracle.com> <509BBF2F.1020404@oracle.com> <509BF1BF.7020905@oracle.com> Message-ID: On Nov 8, 2012, at 6:54 PM, Maurizio Cimadamore wrote: > Fixed > Many thanks, verified, Paul. From maurizio.cimadamore at oracle.com Fri Nov 9 06:18:24 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 09 Nov 2012 14:18:24 +0000 Subject: hg: lambda/lambda/langtools: Bug fixes: Message-ID: <20121109141832.8C85F478A9@hg.openjdk.java.net> Changeset: 5b858be3d094 Author: mcimadamore Date: 2012-11-09 14:17 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5b858be3d094 Bug fixes: *) method call with bad qualifier generates NPE if argument is a method reference *) bad stuck check for method reference leads to javac crash ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/MethodReference54.java + test/tools/javac/lambda/MethodReference54.out + test/tools/javac/lambda/TargetType50.java + test/tools/javac/lambda/TargetType50.out From brian.goetz at oracle.com Fri Nov 9 09:47:55 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 09 Nov 2012 17:47:55 +0000 Subject: hg: lambda/lambda/jdk: Add parallel version of FindFirst Message-ID: <20121109174847.A7263478B0@hg.openjdk.java.net> Changeset: 1fca62c40fb7 Author: briangoetz Date: 2012-11-09 12:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1fca62c40fb7 Add parallel version of FindFirst ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/FindFirstOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceTest.java From mike.duigou at oracle.com Fri Nov 9 13:33:05 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 09 Nov 2012 21:33:05 +0000 Subject: hg: lambda/lambda/jdk: Summary: Adds jtreg config file for test-ng tests. Message-ID: <20121109213356.614F4478B9@hg.openjdk.java.net> Changeset: b904c63a9e03 Author: mduigou Date: 2012-11-09 13:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b904c63a9e03 Summary: Adds jtreg config file for test-ng tests. Contributed-by: Akhil Arora + test-ng/TEST.ROOT From brian.goetz at oracle.com Sun Nov 11 14:50:54 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sun, 11 Nov 2012 22:50:54 +0000 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines Message-ID: <20121111225138.A9EB0478DD@hg.openjdk.java.net> Changeset: 94d64473e8e6 Author: briangoetz Date: 2012-11-11 17:44 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 Add BufferedReader.lines ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/Reader.java + src/share/classes/java/io/UncheckedIOException.java From forax at univ-mlv.fr Sun Nov 11 14:58:01 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 11 Nov 2012 23:58:01 +0100 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <20121111225138.A9EB0478DD@hg.openjdk.java.net> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> Message-ID: <50A02D79.9070401@univ-mlv.fr> On 11/11/2012 11:50 PM, brian.goetz at oracle.com wrote: > Changeset: 94d64473e8e6 > Author: briangoetz > Date: 2012-11-11 17:44 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 > > Add BufferedReader.lines > > ! src/share/classes/java/io/BufferedReader.java > ! src/share/classes/java/io/Reader.java > + src/share/classes/java/io/UncheckedIOException.java > > Brian, UncheckedIOException already exists, it's IOError. cheers, R?mi From brian.goetz at oracle.com Sun Nov 11 15:11:58 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 11 Nov 2012 18:11:58 -0500 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A02D79.9070401@univ-mlv.fr> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> Message-ID: <50A030BE.7080900@oracle.com> > Brian, > UncheckedIOException already exists, it's IOError. That exists, but is something different. IOError implements Error, which is intended to indicate an error situation from which the VM cannot recover. It was added to support Console, for which using Error is arguably OK. But here, an IOException is clearly NOT an Error. Our choices where creating this class or wrapping it in an ordinary RuntimeException. Because we anticipated other cases with IO-backed streams, we thought we'd get additional mileage out of this class. From forax at univ-mlv.fr Sun Nov 11 15:17:23 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 Nov 2012 00:17:23 +0100 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A030BE.7080900@oracle.com> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> Message-ID: <50A03203.3080808@univ-mlv.fr> On 11/12/2012 12:11 AM, Brian Goetz wrote: >> Brian, >> UncheckedIOException already exists, it's IOError. > > That exists, but is something different. > > IOError implements Error, which is intended to indicate an error > situation from which the VM cannot recover. It was added to support > Console, for which using Error is arguably OK. But here, an > IOException is clearly NOT an Error. > > Our choices where creating this class or wrapping it in an ordinary > RuntimeException. Because we anticipated other cases with IO-backed > streams, we thought we'd get additional mileage out of this class. by example, java.nio.file.Files.newDirectoryStream uses IOError exactly for that. I agree that a runtime exception is better than an Error, but given that some classes of the JDK already uses IOError exactly for the same purpose, I don't think it's a good idea to have two classes for the very same thing. R?mi From v.a.ammodytes at googlemail.com Sun Nov 11 15:24:15 2012 From: v.a.ammodytes at googlemail.com (Arne Siegel) Date: Mon, 12 Nov 2012 00:24:15 +0100 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <20121111225138.A9EB0478DD@hg.openjdk.java.net> Message-ID: <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Hi Brian, nice utility function, though I don't think you got the if statement in next() right. @Override public String next() { if (nextLine == null || hasNext()) { try { return nextLine; ... Better keep it simple: ... if (hasNext()) { ... Arne Siegel On 11 Nov 2012 at 22:50, brian.goetz at oracle.com wrote: > Changeset: 94d64473e8e6 > Author: briangoetz > Date: 2012-11-11 17:44 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 > > Add BufferedReader.lines > > ! src/share/classes/java/io/BufferedReader.java > ! src/share/classes/java/io/Reader.java > + src/share/classes/java/io/UncheckedIOException.java > > From brian.goetz at oracle.com Sun Nov 11 15:30:31 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 11 Nov 2012 18:30:31 -0500 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> References: <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Message-ID: <50A03517.8020706@oracle.com> Yeah, Henry already pointed that out to me :( But yes, this illustrates our strategy for library lambdafication, which might better be called streamification. We're adding stream-bearing methods in lots of places -- String.chars(), Reader.lines(), etc. Originally we had thought to have methods like eachLine(Block), but providing a Stream view is far more flexible -- you can bring the full power of the Stream API to bear. For methods that already return an aggregate (e.g., Class.getMethods()), no additional work is needed to access streams, since there will be easy ways to convert an array, collection, Iterator, or Enumeration to a Stream. Happy to get additional suggestions about where else in the JDK we can replace existing one-at-a-time constructs with Streams, if you've got. On 11/11/2012 6:24 PM, Arne Siegel wrote: > Hi Brian, > > nice utility function, though I don't think you got the if statement in next() right. > > @Override > public String next() { > if (nextLine == null || hasNext()) { > try { > return nextLine; > ... > > Better keep it simple: > ... > if (hasNext()) { > ... > > Arne Siegel > > > On 11 Nov 2012 at 22:50, brian.goetz at oracle.com wrote: > >> Changeset: 94d64473e8e6 >> Author: briangoetz >> Date: 2012-11-11 17:44 -0500 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 >> >> Add BufferedReader.lines >> >> ! src/share/classes/java/io/BufferedReader.java >> ! src/share/classes/java/io/Reader.java >> + src/share/classes/java/io/UncheckedIOException.java >> >> > > From ricky.clarkson at gmail.com Sun Nov 11 15:35:35 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Sun, 11 Nov 2012 20:35:35 -0300 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Message-ID: BufferedReader.lines() seems like the kind of method likely to cause resource leaks; if I use it and create a Stream and then return that to my caller, I can't close the BufferedReader in the same place I create it, and my caller cannot close the BufferedReader either. On Sun, Nov 11, 2012 at 8:24 PM, Arne Siegel wrote: > Hi Brian, > > nice utility function, though I don't think you got the if statement in > next() right. > > @Override > public String next() { > if (nextLine == null || hasNext()) { > try { > return nextLine; > ... > > Better keep it simple: > ... > if (hasNext()) { > ... > > Arne Siegel > > > On 11 Nov 2012 at 22:50, brian.goetz at oracle.com wrote: > > > Changeset: 94d64473e8e6 > > Author: briangoetz > > Date: 2012-11-11 17:44 -0500 > > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 > > > > Add BufferedReader.lines > > > > ! src/share/classes/java/io/BufferedReader.java > > ! src/share/classes/java/io/Reader.java > > + src/share/classes/java/io/UncheckedIOException.java > > > > > > > > From brian.goetz at oracle.com Sun Nov 11 15:39:58 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 11 Nov 2012 18:39:58 -0500 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Message-ID: <50A0374E.8040105@oracle.com> I'm not really sure what to do with your comment. Are you arguing that, because someone could use it in a leaky way, we should not add it to the JDK? Here's a totally safe idiom where it adds a lot of value: try (reader = new BR(new FR(file))) { reader.lines() .filter(e -> !startsWith("#")) .map(e -> e.toUpperCase()) .forEach(...); } It would be a shame to take it away from everyone just because it can be misused. What are you suggesting? On 11/11/2012 6:35 PM, Ricky Clarkson wrote: > BufferedReader.lines() seems like the kind of method likely to cause > resource leaks; if I use it and create a Stream and then return > that to my caller, I can't close the BufferedReader in the same place I > create it, and my caller cannot close the BufferedReader either. > > > On Sun, Nov 11, 2012 at 8:24 PM, Arne Siegel > > wrote: > > Hi Brian, > > nice utility function, though I don't think you got the if statement > in next() right. > > @Override > public String next() { > if (nextLine == null || hasNext()) { > try { > return nextLine; > ... > > Better keep it simple: > ... > if (hasNext()) { > ... > > Arne Siegel > > > On 11 Nov 2012 at 22:50, brian.goetz at oracle.com > wrote: > > > Changeset: 94d64473e8e6 > > Author: briangoetz > > Date: 2012-11-11 17:44 -0500 > > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 > > > > Add BufferedReader.lines > > > > ! src/share/classes/java/io/BufferedReader.java > > ! src/share/classes/java/io/Reader.java > > + src/share/classes/java/io/UncheckedIOException.java > > > > > > > > From david.holmes at oracle.com Sun Nov 11 15:45:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Nov 2012 09:45:42 +1000 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A03203.3080808@univ-mlv.fr> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> <50A03203.3080808@univ-mlv.fr> Message-ID: <50A038A6.5000602@oracle.com> On 12/11/2012 9:17 AM, Remi Forax wrote: > On 11/12/2012 12:11 AM, Brian Goetz wrote: >>> Brian, >>> UncheckedIOException already exists, it's IOError. >> >> That exists, but is something different. >> >> IOError implements Error, which is intended to indicate an error >> situation from which the VM cannot recover. It was added to support >> Console, for which using Error is arguably OK. But here, an >> IOException is clearly NOT an Error. >> >> Our choices where creating this class or wrapping it in an ordinary >> RuntimeException. Because we anticipated other cases with IO-backed >> streams, we thought we'd get additional mileage out of this class. > > by example, java.nio.file.Files.newDirectoryStream uses IOError exactly > for that. It does? The only use of IOError I can see in java.nio.file.* is in the Path interface. newDirectoryStream throws IOException. > I agree that a runtime exception is better than an Error, but given that > some classes of the JDK already uses IOError exactly for the same > purpose, I don't think it's a good idea to have two classes for the very > same thing. Error subclasses should be reserved for unrecoverable errors. Even if this is misused somewhere we should not perpetuate the misuse. David > R?mi > > From david.holmes at oracle.com Sun Nov 11 15:52:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Nov 2012 09:52:24 +1000 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Message-ID: <50A03A38.6020905@oracle.com> On 12/11/2012 9:35 AM, Ricky Clarkson wrote: > BufferedReader.lines() seems like the kind of method likely to cause > resource leaks; if I use it and create a Stream and then return > that to my caller, I can't close the BufferedReader in the same place I > create it, and my caller cannot close the BufferedReader either. What usage scenario are you considering here? For me all these streams operations are pipelined at the same level at which I have the source and sink, so I have control over the lifecycle. David > > > On Sun, Nov 11, 2012 at 8:24 PM, Arne Siegel > wrote: > >> Hi Brian, >> >> nice utility function, though I don't think you got the if statement in >> next() right. >> >> @Override >> public String next() { >> if (nextLine == null || hasNext()) { >> try { >> return nextLine; >> ... >> >> Better keep it simple: >> ... >> if (hasNext()) { >> ... >> >> Arne Siegel >> >> >> On 11 Nov 2012 at 22:50, brian.goetz at oracle.com wrote: >> >>> Changeset: 94d64473e8e6 >>> Author: briangoetz >>> Date: 2012-11-11 17:44 -0500 >>> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 >>> >>> Add BufferedReader.lines >>> >>> ! src/share/classes/java/io/BufferedReader.java >>> ! src/share/classes/java/io/Reader.java >>> + src/share/classes/java/io/UncheckedIOException.java >>> >>> >> >> >> >> > From zhong.j.yu at gmail.com Sun Nov 11 19:23:44 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Sun, 11 Nov 2012 21:23:44 -0600 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A041AF.12189.A4F0756D@v.a.ammodytes.googlemail.com> Message-ID: On Sun, Nov 11, 2012 at 5:35 PM, Ricky Clarkson wrote: > BufferedReader.lines() seems like the kind of method likely to cause > resource leaks; if I use it and create a Stream and then return > that to my caller, I can't close the BufferedReader in the same place I > create it, and my caller cannot close the BufferedReader either. Maybe you can return a stream + a postmortem action which the caller must invoke after it's absolutely sure that the stream is no longer used. public ToClose> foo(){ .... } public interface ToClose extends AutoCloseable T value(); void close(); It sucks, of course. > > On Sun, Nov 11, 2012 at 8:24 PM, Arne Siegel > wrote: > >> Hi Brian, >> >> nice utility function, though I don't think you got the if statement in >> next() right. >> >> @Override >> public String next() { >> if (nextLine == null || hasNext()) { >> try { >> return nextLine; >> ... >> >> Better keep it simple: >> ... >> if (hasNext()) { >> ... >> >> Arne Siegel >> >> >> On 11 Nov 2012 at 22:50, brian.goetz at oracle.com wrote: >> >> > Changeset: 94d64473e8e6 >> > Author: briangoetz >> > Date: 2012-11-11 17:44 -0500 >> > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94d64473e8e6 >> > >> > Add BufferedReader.lines >> > >> > ! src/share/classes/java/io/BufferedReader.java >> > ! src/share/classes/java/io/Reader.java >> > + src/share/classes/java/io/UncheckedIOException.java >> > >> > >> >> >> >> > From zhong.j.yu at gmail.com Sun Nov 11 19:37:24 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Sun, 11 Nov 2012 21:37:24 -0600 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A030BE.7080900@oracle.com> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> Message-ID: On Sun, Nov 11, 2012 at 5:11 PM, Brian Goetz wrote: >> Brian, >> UncheckedIOException already exists, it's IOError. > > That exists, but is something different. > > IOError implements Error, which is intended to indicate an error > situation from which the VM cannot recover. It was added to support > Console, for which using Error is arguably OK. But here, an IOException > is clearly NOT an Error. > > Our choices where creating this class or wrapping it in an ordinary > RuntimeException. Because we anticipated other cases with IO-backed > streams, we thought we'd get additional mileage out of this class. UncheckedIOException would also be useful in many applications where IO exceptions aren't expected to occur, and it would have been better if they are unchecked. Now programmers can use UncheckedIOException to convert IO exceptions to uncheck exceptions. However, why not have a general UncheckedException, so that we don't need to invent UncheckSQLException, UncheckedReflectionException etc. We can use RuntimeException as the wrapper now, but a dedicated UncheckedException can be more clear that this is just a wrapper of the actual exception. Zhong Yu From oleksander.demura at gmail.com Mon Nov 12 01:01:47 2012 From: oleksander.demura at gmail.com (Olexandr Demura) Date: Mon, 12 Nov 2012 11:01:47 +0200 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> Message-ID: Exceptional streams looks to me simply like one more StreamShape, dual to Mapping stream shape - some analogue to `Either A B`. If concept of Map Stream is viable yet, of course. BTW, java implicitly have that `shape` for years (: Callable ~= () -> (T | Exception) e.g. what if Optional doesn't exist. T reduce(T base, BinaryOperator op); Optional reduce(BinaryOperator op); -> T reduce(BinaryOperator op, Factory otherwise) throws X; Optional findFirst(); Optional findAny(); -> T findFirst(Factory otherwise) throws X; T findAny(Factory otherwise) throws X; 2012/11/12 Zhong Yu > > UncheckedIOException would also be useful in many applications where > IO exceptions aren't expected to occur, and it would have been better > if they are unchecked. Now programmers can use UncheckedIOException to > convert IO exceptions to uncheck exceptions. > > However, why not have a general UncheckedException, so that we don't > need to invent UncheckSQLException, UncheckedReflectionException etc. > We can use RuntimeException as the wrapper now, but a dedicated > UncheckedException can be more clear that this is just a wrapper of > the actual exception. > > Zhong Yu > > From paul.sandoz at oracle.com Mon Nov 12 02:01:26 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 12 Nov 2012 10:01:26 +0000 Subject: hg: lambda/lambda/jdk: Remove java.util.Mapping and revert back to Map.Entry. Message-ID: <20121112100214.96037478E7@hg.openjdk.java.net> Changeset: 62f516761797 Author: henryjen Date: 2012-11-12 10:55 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/62f516761797 Remove java.util.Mapping and revert back to Map.Entry. Reviewed-by: briangoetz, psandoz ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java - src/share/classes/java/util/Mapping.java ! src/share/classes/java/util/streams/Sink.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java From david.holmes at oracle.com Mon Nov 12 03:30:37 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Nov 2012 21:30:37 +1000 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> Message-ID: <50A0DDDD.80201@oracle.com> RuntimeException _is_ the unchecked Exception. David On 12/11/2012 1:37 PM, Zhong Yu wrote: > On Sun, Nov 11, 2012 at 5:11 PM, Brian Goetz wrote: >>> Brian, >>> UncheckedIOException already exists, it's IOError. >> >> That exists, but is something different. >> >> IOError implements Error, which is intended to indicate an error >> situation from which the VM cannot recover. It was added to support >> Console, for which using Error is arguably OK. But here, an IOException >> is clearly NOT an Error. >> >> Our choices where creating this class or wrapping it in an ordinary >> RuntimeException. Because we anticipated other cases with IO-backed >> streams, we thought we'd get additional mileage out of this class. > > UncheckedIOException would also be useful in many applications where > IO exceptions aren't expected to occur, and it would have been better > if they are unchecked. Now programmers can use UncheckedIOException to > convert IO exceptions to uncheck exceptions. > > However, why not have a general UncheckedException, so that we don't > need to invent UncheckSQLException, UncheckedReflectionException etc. > We can use RuntimeException as the wrapper now, but a dedicated > UncheckedException can be more clear that this is just a wrapper of > the actual exception. > > Zhong Yu > From forax at univ-mlv.fr Mon Nov 12 07:59:58 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 Nov 2012 16:59:58 +0100 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: <50A038A6.5000602@oracle.com> References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> <50A03203.3080808@univ-mlv.fr> <50A038A6.5000602@oracle.com> Message-ID: <50A11CFE.8020501@univ-mlv.fr> On 11/12/2012 12:45 AM, David Holmes wrote: > On 12/11/2012 9:17 AM, Remi Forax wrote: >> On 11/12/2012 12:11 AM, Brian Goetz wrote: >>>> Brian, >>>> UncheckedIOException already exists, it's IOError. >>> >>> That exists, but is something different. >>> >>> IOError implements Error, which is intended to indicate an error >>> situation from which the VM cannot recover. It was added to support >>> Console, for which using Error is arguably OK. But here, an >>> IOException is clearly NOT an Error. >>> >>> Our choices where creating this class or wrapping it in an ordinary >>> RuntimeException. Because we anticipated other cases with IO-backed >>> streams, we thought we'd get additional mileage out of this class. >> >> by example, java.nio.file.Files.newDirectoryStream uses IOError exactly >> for that. > > It does? The only use of IOError I can see in java.nio.file.* is in > the Path interface. newDirectoryStream throws IOException. My bad, the implementation was changed at the end of the development of jdk7 and I forget to update my brain accordingly. DirectoryStream now uses a DirectoryIteratorException which wraps an IOException and extends ConcurrentModificationException. So I supose that UncheckedIOException should be renamed to IOIteratorException, should extend ConcurrentModificationException and be the new supertype of DirectoryIteratorException. > > David R?mi From brian.goetz at oracle.com Mon Nov 12 10:25:47 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 12 Nov 2012 18:25:47 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121112182620.5682A478F2@hg.openjdk.java.net> Changeset: 969458b5ee9d Author: briangoetz Date: 2012-11-12 12:45 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/969458b5ee9d Garbage-collect dead Iterators methods; move filter/map methods from {Filter,Map}Op to Iterators; add Iterators.asEnumeration ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/concurrent/ForkJoinUtils.java ! src/share/classes/java/util/streams/ops/FilterOp.java ! src/share/classes/java/util/streams/ops/MapOp.java - test-ng/tests/org/openjdk/tests/java/util/IteratorsNullTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java Changeset: e8517ea52d33 Author: briangoetz Date: 2012-11-12 13:25 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e8517ea52d33 Improved short-circuiting in Find{Any,First}Op, MatchOp ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/streams/ops/FindAnyOp.java ! src/share/classes/java/util/streams/ops/FindFirstOp.java ! src/share/classes/java/util/streams/ops/MatchOp.java From brian.goetz at oracle.com Mon Nov 12 10:56:55 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Nov 2012 13:56:55 -0500 Subject: hg: lambda/lambda/jdk: Add BufferedReader.lines In-Reply-To: References: <20121111225138.A9EB0478DD@hg.openjdk.java.net> <50A02D79.9070401@univ-mlv.fr> <50A030BE.7080900@oracle.com> Message-ID: <50A14677.6000108@oracle.com> Some background... There were many ways to approach the issue of exceptions in lambdas. The approach we took in the end -- which is largely "ignore them" for the most part, making some small concessions for IOException -- is a pragmatic choice that covers most of the interesting use cases while minimizing intrusion and accidental complexity. Without any sort of exception transparency, we'd have to have both exception-bearing and non-exception-bearing versions of all the functional interfaces (and the methods that take them). As if this weren't bad enough, if you look at the dimensions of specialization for functional interfaces, it explodes: - basic kind (Predicate, Function, etc) - arity specializations (e.g., two-arg predicate) - primitive specializations (e.g., IntPredicate) - exceptions or not - serializable or not This rapidly spirals out of control. Pruning the exception and serialization dimensions from this restores things to the "barely manageable" level. We explored multiple options for exception transparency and found none of them to offer the right balance of power and complexity, especially with respect to compatibly evolving existing constructs like Iterator. We have some interesting ideas in this category that we may come back to in a future round. When we looked at the use cases where exceptions really intruded into streams, they were *all* IOException thrown in situations where any sort of fine-grained recovery was dubious. So the pragmatic solution for the current round was "do something simple for IOException", and focus the remainder of our limited time on higher-value things. On 11/12/2012 4:01 AM, Olexandr Demura wrote: > Exceptional streams looks to me simply like one more StreamShape, > dual to Mapping stream shape - some analogue to `Either A B`. > If concept of Map Stream is viable yet, of course. > > BTW, java implicitly have that `shape` for years (: > Callable ~= () -> (T | Exception) > > e.g. what if Optional doesn't exist. > > T reduce(T base, BinaryOperator op); > Optional reduce(BinaryOperator op); > -> > T reduce(BinaryOperator op, Factory otherwise) throws X; > > Optional findFirst(); > Optional findAny(); > -> > T findFirst(Factory otherwise) throws X; > T findAny(Factory otherwise) throws X; > > 2012/11/12 Zhong Yu > > > > UncheckedIOException would also be useful in many applications where > IO exceptions aren't expected to occur, and it would have been better > if they are unchecked. Now programmers can use UncheckedIOException to > convert IO exceptions to uncheck exceptions. > > However, why not have a general UncheckedException, so that we don't > need to invent UncheckSQLException, UncheckedReflectionException etc. > We can use RuntimeException as the wrapper now, but a dedicated > UncheckedException can be more clear that this is just a wrapper of > the actual exception. > > Zhong Yu > > From boaznahum at gmail.com Mon Nov 12 11:45:29 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 12 Nov 2012 21:45:29 +0200 Subject: Lambda and intersection types Message-ID: The follwing simple code ... ==================================== interface I1 {void f();} interface I2 { void printMe()default { System.out.println("I2");} void f(); } public static void main(String[] args) { I2 i2 = (I1 & I2) () -> {}; System.out.println( "i2 is I2=" + (i2 instanceof I2)); i2.printMe(); } ================================= Output is: ------------------------------------- i2 is I2=false Exception in thread "main" java.lang.IncompatibleClassChangeError: Class question.lambda_intersection_types.Q$$Lambda$2 does not implement the requested interface question.lambda_intersection_types.I2 ------------------------------------- What is the correct behavior ? From brian.goetz at oracle.com Mon Nov 12 11:55:43 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Nov 2012 14:55:43 -0500 Subject: Lambda and intersection types In-Reply-To: References: Message-ID: <50A1543F.2010104@oracle.com> The back-end work for intersection-typed lambdas is not implemented yet...only the compiler front-end work. On 11/12/2012 2:45 PM, Boaz Nahum wrote: > The follwing simple code ... > > ==================================== > interface I1 {void f();} > > interface I2 { > > void printMe()default { System.out.println("I2");} > > void f(); > } > > public static void main(String[] args) { > > I2 i2 = (I1 & I2) () -> {}; > > System.out.println( "i2 is I2=" + (i2 instanceof I2)); > > i2.printMe(); > } > ================================= > Output is: > > ------------------------------------- > i2 is I2=false > Exception in thread "main" java.lang.IncompatibleClassChangeError: Class > question.lambda_intersection_types.Q$$Lambda$2 does not implement the > requested interface question.lambda_intersection_types.I2 > ------------------------------------- > > What is the correct behavior ? > From boaznahum at gmail.com Mon Nov 12 12:01:41 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 12 Nov 2012 22:01:41 +0200 Subject: Lambda and intersection types In-Reply-To: <50A1543F.2010104@oracle.com> References: <50A1543F.2010104@oracle.com> Message-ID: Yes, but should it be valid code ? If yes, I2 implements both I1 & I2 or just I2 ? Thanks Boaz On Mon, Nov 12, 2012 at 9:55 PM, Brian Goetz wrote: > The back-end work for intersection-typed lambdas is not implemented > yet...only the compiler front-end work. > > > On 11/12/2012 2:45 PM, Boaz Nahum wrote: > >> The follwing simple code ... >> >> ==============================**====== >> interface I1 {void f();} >> >> interface I2 { >> >> void printMe()default { System.out.println("I2");} >> >> void f(); >> } >> >> public static void main(String[] args) { >> >> I2 i2 = (I1 & I2) () -> {}; >> >> System.out.println( "i2 is I2=" + (i2 instanceof I2)); >> >> i2.printMe(); >> } >> ==============================**=== >> Output is: >> >> ------------------------------**------- >> i2 is I2=false >> Exception in thread "main" java.lang.**IncompatibleClassChangeError: >> Class >> question.lambda_intersection_**types.Q$$Lambda$2 does not implement the >> requested interface question.lambda_intersection_**types.I2 >> ------------------------------**------- >> >> What is the correct behavior ? >> >> From brian.goetz at oracle.com Mon Nov 12 12:06:11 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Nov 2012 15:06:11 -0500 Subject: Lambda and intersection types In-Reply-To: References: <50A1543F.2010104@oracle.com> Message-ID: <50A156B3.4050107@oracle.com> Yes. i2 should be an instance of both I1 and I2. On 11/12/2012 3:01 PM, Boaz Nahum wrote: > Yes, but should it be valid code ? > > If yes, I2 implements both I1 & I2 or just I2 ? > > Thanks > Boaz > > > > On Mon, Nov 12, 2012 at 9:55 PM, Brian Goetz > wrote: > > The back-end work for intersection-typed lambdas is not implemented > yet...only the compiler front-end work. > > > On 11/12/2012 2:45 PM, Boaz Nahum wrote: > > The follwing simple code ... > > ==============================__====== > interface I1 {void f();} > > interface I2 { > > void printMe()default { System.out.println("I2");} > > void f(); > } > > public static void main(String[] args) { > > I2 i2 = (I1 & I2) () -> {}; > > System.out.println( "i2 is I2=" + (i2 instanceof I2)); > > i2.printMe(); > } > ==============================__=== > Output is: > > ------------------------------__------- > i2 is I2=false > Exception in thread "main" > java.lang.__IncompatibleClassChangeError: Class > question.lambda_intersection___types.Q$$Lambda$2 does not > implement the > requested interface question.lambda_intersection___types.I2 > ------------------------------__------- > > What is the correct behavior ? > > From brian.goetz at oracle.com Mon Nov 12 12:09:18 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 12 Nov 2012 15:09:18 -0500 Subject: Lambda and intersection types In-Reply-To: References: <50A1543F.2010104@oracle.com> Message-ID: <50A1576E.6020103@oracle.com> So, I was focusing too narrowly on the question the first time I answered. IF the code compiles, THEN i2 will, at runtime, be an instance of both I1 and I2. But, this code may not compile. The likely restriction when applied to a lambda/method ref conversion, at least initially, is that: - I1 be a SAM - I2..In be a "ZAM" (zero abstract method) - The intersection I1&I2&.. also be a SAM While the example you post meets the last criteria, it does not meet the first two. On 11/12/2012 3:01 PM, Boaz Nahum wrote: > Yes, but should it be valid code ? > > If yes, I2 implements both I1 & I2 or just I2 ? > > Thanks > Boaz > > > > On Mon, Nov 12, 2012 at 9:55 PM, Brian Goetz > wrote: > > The back-end work for intersection-typed lambdas is not implemented > yet...only the compiler front-end work. > > > On 11/12/2012 2:45 PM, Boaz Nahum wrote: > > The follwing simple code ... > > ==============================__====== > interface I1 {void f();} > > interface I2 { > > void printMe()default { System.out.println("I2");} > > void f(); > } > > public static void main(String[] args) { > > I2 i2 = (I1 & I2) () -> {}; > > System.out.println( "i2 is I2=" + (i2 instanceof I2)); > > i2.printMe(); > } > ==============================__=== > Output is: > > ------------------------------__------- > i2 is I2=false > Exception in thread "main" > java.lang.__IncompatibleClassChangeError: Class > question.lambda_intersection___types.Q$$Lambda$2 does not > implement the > requested interface question.lambda_intersection___types.I2 > ------------------------------__------- > > What is the correct behavior ? > > From brian.goetz at oracle.com Mon Nov 12 14:07:43 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 12 Nov 2012 22:07:43 +0000 Subject: hg: lambda/lambda/jdk: More garbage-collection of dead tests Message-ID: <20121112220756.88DBA478F7@hg.openjdk.java.net> Changeset: b3fc2ac88d4c Author: briangoetz Date: 2012-11-12 17:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b3fc2ac88d4c More garbage-collection of dead tests - test-ng/tests/org/openjdk/tests/java/util/MapStreamTest.java From forax at univ-mlv.fr Mon Nov 12 15:43:39 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Nov 2012 00:43:39 +0100 Subject: hg: lambda/lambda/jdk: 2 new changesets In-Reply-To: <20121112182620.5682A478F2@hg.openjdk.java.net> References: <20121112182620.5682A478F2@hg.openjdk.java.net> Message-ID: <50A189AB.8040703@univ-mlv.fr> On 11/12/2012 07:25 PM, brian.goetz at oracle.com wrote: > Changeset: 969458b5ee9d > Author: briangoetz > Date: 2012-11-12 12:45 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/969458b5ee9d > > Garbage-collect dead Iterators methods; move filter/map methods from {Filter,Map}Op to Iterators; add Iterators.asEnumeration > > ! src/share/classes/java/util/Iterators.java > ! src/share/classes/java/util/concurrent/ForkJoinUtils.java > ! src/share/classes/java/util/streams/ops/FilterOp.java > ! src/share/classes/java/util/streams/ops/MapOp.java > - test-ng/tests/org/openjdk/tests/java/util/IteratorsNullTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java When the methods were moved the iterator source specified as Iterator have lost there wildcard, I think it's a mistake. > > Changeset: e8517ea52d33 > Author: briangoetz > Date: 2012-11-12 13:25 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e8517ea52d33 > > Improved short-circuiting in Find{Any,First}Op, MatchOp > > ! src/share/classes/java/util/Iterators.java > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > ! src/share/classes/java/util/streams/ops/MatchOp.java > > R?mi From forax at univ-mlv.fr Mon Nov 12 17:04:45 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Nov 2012 02:04:45 +0100 Subject: hg: lambda/lambda/jdk: 2 new changesets In-Reply-To: <20121112182620.5682A478F2@hg.openjdk.java.net> References: <20121112182620.5682A478F2@hg.openjdk.java.net> Message-ID: <50A19CAD.6070505@univ-mlv.fr> On 11/12/2012 07:25 PM, brian.goetz at oracle.com wrote: > Changeset: 969458b5ee9d > Author: briangoetz > Date: 2012-11-12 12:45 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/969458b5ee9d > > Garbage-collect dead Iterators methods; move filter/map methods from {Filter,Map}Op to Iterators; add Iterators.asEnumeration > > ! src/share/classes/java/util/Iterators.java > ! src/share/classes/java/util/concurrent/ForkJoinUtils.java > ! src/share/classes/java/util/streams/ops/FilterOp.java > ! src/share/classes/java/util/streams/ops/MapOp.java > - test-ng/tests/org/openjdk/tests/java/util/IteratorsNullTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java also filterIterator should be written like this public static Iterator filter(Iterator source, Predicate predicate) { Objects.requireNonNull(source); Objects.requireNonNull(predicate); return new Iterator() { private boolean nextReady; private T nextValue; @Override public boolean hasNext() { if (nexReady) { return true; } while (source.hasNext()) { T nextValue = source.next(); if (predicate.test(nextValue)) { this.nextValue = nextValue; return nextReady = true; } } return false; } @Override public T next() { if (nextReady || hasNext()) { nextReady = false; T nextValue = this.nextValue; this.nextValue = null; // avoid reference leak return nextValue } throw new NoSuchElementException(); } }; } R?mi From brian.goetz at oracle.com Mon Nov 12 17:16:35 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 13 Nov 2012 01:16:35 +0000 Subject: hg: lambda/lambda/jdk: Resurrect specialized stream/parallel implementations on ARrayList/Vector Message-ID: <20121113011647.BF502478F9@hg.openjdk.java.net> Changeset: bd225e0a0200 Author: briangoetz Date: 2012-11-12 20:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bd225e0a0200 Resurrect specialized stream/parallel implementations on ARrayList/Vector ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/streams/Streams.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java From brian.goetz at oracle.com Mon Nov 12 17:17:43 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 13 Nov 2012 01:17:43 +0000 Subject: hg: lambda/lambda/jdk: Restore missing wildcards in Iterators.{map, filter} methods Message-ID: <20121113011754.C7653478FA@hg.openjdk.java.net> Changeset: 218bdab80e30 Author: briangoetz Date: 2012-11-12 20:17 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/218bdab80e30 Restore missing wildcards in Iterators.{map,filter} methods ! src/share/classes/java/util/Iterators.java From mike.duigou at oracle.com Mon Nov 12 21:31:27 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 13 Nov 2012 05:31:27 +0000 Subject: hg: lambda/lambda/jdk: Use AUTO_FILES_JAVA_DIRS to make maintaining old build easier. Message-ID: <20121113053140.754914791A@hg.openjdk.java.net> Changeset: 8ec18bd1b55f Author: alanb Date: 2012-11-12 21:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8ec18bd1b55f Use AUTO_FILES_JAVA_DIRS to make maintaining old build easier. ! make/java/java/FILES_java.gmk ! make/java/java/Makefile From paul.sandoz at oracle.com Tue Nov 13 00:53:05 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 13 Nov 2012 08:53:05 +0000 Subject: hg: lambda/lambda/jdk: - Rename StreamOpTestCase to OpTestCase. Message-ID: <20121113085338.7082D4791D@hg.openjdk.java.net> Changeset: 19cbd202a30a Author: psandoz Date: 2012-11-13 09:52 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/19cbd202a30a - Rename StreamOpTestCase to OpTestCase. OpTestCase is now generic to the shape of the stream. Refactored specific shape classes to StreamIntermediateOpTestScenario and StreamTestData. - Evaluation of the pipeline to a Node using AbstractPipeline.collectOutput() This is used by tests in OpTestCase for reference results or reference input. - StreamShape can create an AbstractPipeline given a Node of the same shape. - ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/StreamShape.java ! src/share/classes/java/util/streams/StreamShapeFactory.java + test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java + test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/InfiniteStreamWithLimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SkipOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SortedOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/StreamOpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UniqOpTest.java From paul.sandoz at oracle.com Tue Nov 13 01:13:03 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 13 Nov 2012 09:13:03 +0000 Subject: hg: lambda/lambda/jdk: Move BaseStream.getShape to AbstractPipeline.getOutputShape. Message-ID: <20121113091315.EDBE54791F@hg.openjdk.java.net> Changeset: ba5cff68c181 Author: psandoz Date: 2012-11-13 10:10 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ba5cff68c181 Move BaseStream.getShape to AbstractPipeline.getOutputShape. This ensures BaseStream does not expose any SPI-related classes in the public API. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/BaseStream.java From paul.sandoz at oracle.com Tue Nov 13 01:31:26 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 13 Nov 2012 09:31:26 +0000 Subject: hg: lambda/lambda/jdk: StreamShape consistently uses AbstractPipeline. Message-ID: <20121113093138.ABA8247920@hg.openjdk.java.net> Changeset: bac0249a3f18 Author: psandoz Date: 2012-11-13 10:30 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bac0249a3f18 StreamShape consistently uses AbstractPipeline. Methods on AbstractPipeline to chain to return a pipeline or a stream. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/StreamShape.java ! src/share/classes/java/util/streams/StreamShapeFactory.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java From paul.sandoz at oracle.com Tue Nov 13 04:31:30 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 13 Nov 2012 12:31:30 +0000 Subject: hg: lambda/lambda/jdk: Defer to the correct method to create the parallel stream. Message-ID: <20121113123215.A0D6847925@hg.openjdk.java.net> Changeset: 38dc6745cd9b Author: psandoz Date: 2012-11-13 13:31 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/38dc6745cd9b Defer to the correct method to create the parallel stream. Previously this behaviour resulted in a parallel stream with a spliterator of no natural splits (good test input though). ! src/share/classes/java/util/streams/Streams.java From maurizio.cimadamore at oracle.com Tue Nov 13 07:19:41 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 13 Nov 2012 15:19:41 +0000 Subject: hg: lambda/lambda/langtools: 35 new changesets Message-ID: <20121113152056.D215F4792A@hg.openjdk.java.net> Changeset: 16498acd21b5 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/16498acd21b5 Added tag jdk8-b62 for changeset b47bb81ba962 ! .hgtags Changeset: c75be5bc5283 Author: jjg Date: 2012-10-09 19:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c75be5bc5283 8000663: clean up langtools imports Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java ! src/share/classes/javax/annotation/processing/Completions.java ! src/share/classes/javax/annotation/processing/FilerException.java ! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/share/classes/javax/lang/model/element/AnnotationValue.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/ElementScanner8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java Changeset: fc123bdeddb8 Author: jjg Date: 2012-10-09 19:31 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fc123bdeddb8 8000208: fix langtools javadoc comment issues Reviewed-by: bpatel, mcimadamore ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java Changeset: 25e14ad23cef Author: jjg Date: 2012-10-10 16:48 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/25e14ad23cef 8000665: fix "internal API" comments on javadoc files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java Changeset: 560d4a5d14e6 Author: jjg Date: 2012-10-10 18:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/560d4a5d14e6 8000743: docencoding not available to stylesheet Reviewed-by: jjg Contributed-by: jviswana at linux.vnet.ibm.com ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java + test/com/sun/javadoc/testDocEncoding/pkg/Test.java Changeset: 6517bf8e50d0 Author: jjg Date: 2012-10-10 18:34 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6517bf8e50d0 8000418: javadoc should used a standard "generated by javadoc" string Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java + test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java + test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java Changeset: c46e0c9940d6 Author: jjg Date: 2012-10-10 18:44 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c46e0c9940d6 8000310: Clean up use of StringBuffer in langtools Reviewed-by: bpatel ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java Changeset: 0d1818e9d4ae Author: lana Date: 2012-10-12 14:53 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0d1818e9d4ae Merge Changeset: 8db45b13526e Author: jjg Date: 2012-10-15 17:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8db45b13526e 8000666: javadoc should write directly to Writer instead of composing strings Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 2013982bee34 Author: jjg Date: 2012-10-16 21:03 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2013982bee34 8000673: remove dead code from HtmlWriter and subtypes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java Changeset: 12cf6bfd8c05 Author: mcimadamore Date: 2012-10-17 16:43 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/12cf6bfd8c05 7192245: Add parser support for default methods Summary: Add support for 'default' keyword in modifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/DefaultMethodNotSupported.java Changeset: 5dde04b8bbb3 Author: lana Date: 2012-10-23 09:42 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5dde04b8bbb3 Merge Changeset: 669468143a5e Author: lana Date: 2012-10-25 20:33 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/669468143a5e Merge Changeset: 741cce355ba6 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/741cce355ba6 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 92e6f2190ca0 Author: katleman Date: 2012-10-31 18:36 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/92e6f2190ca0 Merge Changeset: 26831b6fcc4a Author: katleman Date: 2012-11-01 14:13 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/26831b6fcc4a Added tag jdk8-b63 for changeset 92e6f2190ca0 ! .hgtags Changeset: 78962d89f283 Author: jjg Date: 2012-10-23 13:20 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/78962d89f283 8000741: refactor javadoc to use abstraction to handle relative paths Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/SerialFieldTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java Changeset: 4a1c57a1c410 Author: jjg Date: 2012-10-23 13:58 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4a1c57a1c410 8000416: refactor javadoc to provide and use an abstraction for relative URIs Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: c002fdee76fd Author: jjg Date: 2012-10-25 11:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c002fdee76fd 7200915: convert TypeTags from a series of small ints to an enum Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java + src/share/classes/com/sun/tools/javac/code/TypeTag.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/tree/MakeLiteralTest.java Changeset: ea2616a6bd01 Author: jjg Date: 2012-10-25 13:33 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ea2616a6bd01 6725230: Java Compilation with Jsr199 ignores Class-Path in manifest Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/Paths/TestCompileJARInClassPath.java Changeset: 217c265158fe Author: jjg Date: 2012-10-26 13:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/217c265158fe 8001219: Clean up use of URLs in javadoc Extern class Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: e6cb81683ffe Author: jjg Date: 2012-10-26 16:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e6cb81683ffe 8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java Changeset: 64fce9f95b1d Author: jjg Date: 2012-10-26 17:17 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/64fce9f95b1d 8001714: add missing tests for 7199925 Reviewed-by: darcy + test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java + test/tools/javac/annotations/repeatingAnnotations/SeparateCompile.java Changeset: 384f7a4beae7 Author: jjg Date: 2012-10-26 18:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/384f7a4beae7 8001717: TypeTags cleanup breaks GenStubs Reviewed-by: jjh ! make/tools/genstubs/GenStubs.java Changeset: a65971893c50 Author: rfield Date: 2012-10-29 10:39 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a65971893c50 8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods Summary: Add lambda implementation code with calling/supporting code elsewhere in the compiler Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 23fe1a96bc0f Author: jjg Date: 2012-10-30 10:15 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/23fe1a96bc0f 8001929: fix doclint errors in langtools doc comments Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: 27f7952eea3c Author: lana Date: 2012-10-31 08:31 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/27f7952eea3c Merge Changeset: b980e8e6aabf Author: jjg Date: 2012-10-31 13:48 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b980e8e6aabf 8001664: refactor javadoc to use abstraction to handle files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java Changeset: bf54daa9dcd8 Author: ohrstrom Date: 2012-11-01 10:48 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bf54daa9dcd8 7153951: Add new lint option -Xlint:auxiliaryclass Reviewed-by: jjg, mcimadamore, forax ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out + test/tools/javac/warnings/AuxiliaryClass/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/NotAClassName.java + test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 75c936d14c6a Author: vromero Date: 2012-11-01 12:47 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/75c936d14c6a 8000483: cryptic error message when source file contains hash Summary: cryptic error message when source file contains hash Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/quid/T6999438.out Changeset: bf76f4190ef8 Author: jjg Date: 2012-11-02 14:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bf76f4190ef8 7169362: JDK8: Write compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out + test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out + test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out Changeset: e6ee43b3e247 Author: lana Date: 2012-11-02 17:55 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e6ee43b3e247 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java Changeset: 056d828ac1e1 Author: katleman Date: 2012-11-08 11:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/056d828ac1e1 Added tag jdk8-b64 for changeset e6ee43b3e247 ! .hgtags Changeset: 16dda9281400 Author: mcimadamore Date: 2012-11-13 14:39 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/16dda9281400 merge with jdk8-b64 ! .hgtags ! makefiles/Makefile ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java + src/share/classes/com/sun/tools/javac/code/TypeTag.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/GraphInfer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToInnerClass.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/LambdaTranslator.java ! src/share/classes/com/sun/tools/javac/comp/LegacyInfer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/quid/T6999438.out Changeset: 96f08d241623 Author: mcimadamore Date: 2012-11-13 15:18 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/96f08d241623 Temporarily revert changes to build-infra makefiles to keep new build happy ! makefiles/Makefile From georgiy.rakov at oracle.com Tue Nov 13 08:08:36 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 13 Nov 2012 20:08:36 +0400 Subject: Sorting streams containing nulls In-Reply-To: <509A6B59.7040307@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> Message-ID: <50A27084.2040805@oracle.com> On 07.11.2012 18:08, Sergey Kuksenko wrote: > But it is sorted stream. > How should we compare null with other values? The supplied comparator could treat nulls in a special way. There are some ways to do it for instance: - comparator could consider null as the lowest value; - when sorting integers comparator could consider null being equal to some integer value for instance 5; Georgiy > > On 11/07/2012 05:43 PM, Remi Forax wrote: >> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >> so it's an implementation bug ? >> All Queue don't accept null so either null need to be masked/unmasked or >> the implementation has to be changed. >> >> R?mi >> >>> >>> >>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>> >>>> Hello. >>>> >>>> When we make sorted(...).iterator() on Stream instance containing one >>>> ore more nulls we receive NPE. The example of stack trace is below: >>>> >>>> java.lang.NullPointerException >>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>> at >>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>> ... >>>> >>>> Could you please tell if it is considered as expected behavior or it's >>>> going to be fixed somehow. >>>> >>>> Georgiy. >>>> >> > From maurizio.cimadamore at oracle.com Tue Nov 13 08:30:38 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 13 Nov 2012 16:30:38 +0000 Subject: hg: lambda/lambda/langtools: Cleanup: revert unnecessary changes to DeferredAttr Message-ID: <20121113163043.0AEF54792D@hg.openjdk.java.net> Changeset: 3fa56c95b61d Author: mcimadamore Date: 2012-11-13 16:30 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3fa56c95b61d Cleanup: revert unnecessary changes to DeferredAttr ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! test/tools/javac/lambda/TargetType50.java ! test/tools/javac/lambda/TargetType50.out From howard.lovatt at gmail.com Tue Nov 13 09:15:18 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Tue, 13 Nov 2012 17:15:18 +0000 Subject: Sorting streams containing nulls In-Reply-To: <50A27084.2040805@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> Message-ID: <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. Sent from my iPad On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: > On 07.11.2012 18:08, Sergey Kuksenko wrote: >> But it is sorted stream. >> How should we compare null with other values? > The supplied comparator could treat nulls in a special way. There are > some ways to do it for instance: > - comparator could consider null as the lowest value; > - when sorting integers comparator could consider null being equal to > some integer value for instance 5; > > Georgiy > >> >> On 11/07/2012 05:43 PM, Remi Forax wrote: >>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>> so it's an implementation bug ? >>> All Queue don't accept null so either null need to be masked/unmasked or >>> the implementation has to be changed. >>> >>> R?mi >>> >>>> >>>> >>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>> >>>>> Hello. >>>>> >>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>> >>>>> java.lang.NullPointerException >>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>> at >>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>> ... >>>>> >>>>> Could you please tell if it is considered as expected behavior or it's >>>>> going to be fixed somehow. >>>>> >>>>> Georgiy. >>>>> >>> >> > From mike.duigou at oracle.com Tue Nov 13 11:05:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 13 Nov 2012 11:05:04 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces Message-ID: Hello all; I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ This update includes: - Mapper.map becomes Function.apply - Factory.make becomes Supplier.get - Specializations of Supplier for int, long, double - Reorder type variables to put result last - Fixes many javadoc and stylistic comments. What didn't change: - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? - Combiner will be part of the full API but it's only present in this patch as a comment. - No default methods. Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) Mike From brian.goetz at oracle.com Tue Nov 13 12:14:00 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 Nov 2012 15:14:00 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A2AA08.6060203@oracle.com> > I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: > > http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ > > This update includes: > > - Mapper.map becomes Function.apply > - Factory.make becomes Supplier.get > - Specializations of Supplier for int, long, double > - Reorder type variables to put result last > - Fixes many javadoc and stylistic comments. > > What didn't change: > - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? Block.accept. Also, to allow IntFunction to implement Function, need to adjust the method names. Propose applyAs{Int,Long,Double} for specializations. Similarly, need to do the same for Supplier: getAs{Int,Long,Double} with appropriate defaults for the specialized versions. From scolebourne at joda.org Tue Nov 13 14:56:54 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Nov 2012 22:56:54 +0000 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On 13 November 2012 19:05, Mike Duigou wrote: > I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: > > http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ > > This update includes: > > - Mapper.map becomes Function.apply > - Factory.make becomes Supplier.get > - Specializations of Supplier for int, long, double > - Reorder type variables to put result last > - Fixes many javadoc and stylistic comments. > > What didn't change: > - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? > - Combiner will be part of the full API but it's only present in this patch as a comment. > - No default methods. Can you confirm whether these are now considered to be the final naming choices, or whether they are still (improved) placeholders. Stephen From brian.goetz at oracle.com Tue Nov 13 15:12:26 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 Nov 2012 18:12:26 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A2D3DA.2040600@oracle.com> Nothing is final until (insert favorite metaphor here), but yes, we are looking for this to be the "effectively final" (though not necessarily complete) initial set of functional interfaces. There was already a previous round of review with comment from the EG and from lambda-dev, so this round of review should focus on changes since the previous round. On 11/13/2012 5:56 PM, Stephen Colebourne wrote: > On 13 November 2012 19:05, Mike Duigou wrote: >> I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: >> >> http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ >> >> This update includes: >> >> - Mapper.map becomes Function.apply >> - Factory.make becomes Supplier.get >> - Specializations of Supplier for int, long, double >> - Reorder type variables to put result last >> - Fixes many javadoc and stylistic comments. >> >> What didn't change: >> - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? >> - Combiner will be part of the full API but it's only present in this patch as a comment. >> - No default methods. > > Can you confirm whether these are now considered to be the final > naming choices, or whether they are still (improved) placeholders. > Stephen > From mike.duigou at oracle.com Tue Nov 13 15:28:22 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 13 Nov 2012 15:28:22 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <6BB67305-D9ED-441D-864E-44BC74DC197A@oracle.com> They won't be truly final until JSR-335 is ratified but they are more fixed than placeholders. Brian has provided some feedback for Block method name and some suggestions for naming of primitive specialization. I plan make those changes today and send out RFR #3 tomorrow around noon PST. Feedback is always welcome but it's the EG that needs to be convinced a change is warranted. Mike On Nov 13 2012, at 14:56 , Stephen Colebourne wrote: > On 13 November 2012 19:05, Mike Duigou wrote: >> I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: >> >> http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ >> >> This update includes: >> >> - Mapper.map becomes Function.apply >> - Factory.make becomes Supplier.get >> - Specializations of Supplier for int, long, double >> - Reorder type variables to put result last >> - Fixes many javadoc and stylistic comments. >> >> What didn't change: >> - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? >> - Combiner will be part of the full API but it's only present in this patch as a comment. >> - No default methods. > > Can you confirm whether these are now considered to be the final > naming choices, or whether they are still (improved) placeholders. > Stephen From brian.goetz at oracle.com Tue Nov 13 15:35:38 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 Nov 2012 18:35:38 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <6BB67305-D9ED-441D-864E-44BC74DC197A@oracle.com> References: <6BB67305-D9ED-441D-864E-44BC74DC197A@oracle.com> Message-ID: <50A2D94A.6050307@oracle.com> > They won't be truly final until JSR-335 is ratified but they are more fixed than placeholders. > > Brian has provided some feedback for Block method name and some suggestions for naming of primitive specialization. I plan make those changes today and send out RFR #3 tomorrow around noon PST. > > Feedback is always welcome but it's the EG that needs to be convinced a change is warranted. And, soon. We're well over our time box on this review, and it is blocking many other things. From mike.duigou at oracle.com Tue Nov 13 17:19:19 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 13 Nov 2012 17:19:19 -0800 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces Message-ID: Hello all; I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) This update includes: - Block.apply renamed to Block.accept - {Int|Long|Double}Block specializations added. - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. Mike [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From henry.jen at oracle.com Tue Nov 13 20:09:23 2012 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 13 Nov 2012 20:09:23 -0800 Subject: Request for Review: CR#8001667: Comparators class and Comparator extension method Message-ID: <50A31973.3080307@oracle.com> Hi, This is a change set regarding Comparator already in lambda repo, it depends on the CR#8001634, particularly the Function SAMs. It implements proposed extension methods on Comparator (reverse and compose) as well as static combinator methods in Comparators for things like turning a T -> {Comparable,int,long,double} into a Comparator. This allows things like: people.sort(Comparators.comparing(Person::getName)) Comparator byLastFirst = Comparators.comparing(Person::getLastName) .compose(Comparators.comparing(Person::getFirstName)) Please review and comment on the webrev[1]. [1] http://cr.openjdk.java.net/~henryjen/webrevs/8001667.0/ Cheers, Henry From luolong at gmail.com Tue Nov 13 21:21:29 2012 From: luolong at gmail.com (luolong) Date: Wed, 14 Nov 2012 07:21:29 +0200 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <0B0CBCF1-20E4-4400-B8F3-BC09D50E4A18@gmail.com> What about Block.run or Block.execute or Block.eval? Roland On 13.11.2012, at 21:05, Mike Duigou wrote: > Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform From pbenedict at apache.org Tue Nov 13 23:12:47 2012 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 14 Nov 2012 01:12:47 -0600 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0B0CBCF1-20E4-4400-B8F3-BC09D50E4A18@gmail.com> References: <0B0CBCF1-20E4-4400-B8F3-BC09D50E4A18@gmail.com> Message-ID: Is there an effort to avoid using "block" in the method name? Ex: blockApply() or applyBlock() isn't so bad, imo From jack at moxley.co.uk Tue Nov 13 23:33:29 2012 From: jack at moxley.co.uk (Jack Moxley) Date: Wed, 14 Nov 2012 07:33:29 +0000 Subject: Sorting streams containing nulls In-Reply-To: <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> Message-ID: <32B972BF-6B94-4512-A417-3F690A06F897@moxley.co.uk> Only filter for nulls if you think there are going to be nulls, otherwise why worry about it? For instance how many times do you check for nulls in your array lists? It seems backwards to want to remove functionality that doesn't effect you. Sent from my iPhone On 13 Nov 2012, at 17:15, Howard Lovatt wrote: > The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. > > Sent from my iPad > > On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: > >> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>> But it is sorted stream. >>> How should we compare null with other values? >> The supplied comparator could treat nulls in a special way. There are >> some ways to do it for instance: >> - comparator could consider null as the lowest value; >> - when sorting integers comparator could consider null being equal to >> some integer value for instance 5; >> >> Georgiy >> >>> >>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>> so it's an implementation bug ? >>>> All Queue don't accept null so either null need to be masked/unmasked or >>>> the implementation has to be changed. >>>> >>>> R?mi >>>> >>>>> >>>>> >>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>> >>>>>> Hello. >>>>>> >>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>> >>>>>> java.lang.NullPointerException >>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>> at >>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>> ... >>>>>> >>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>> going to be fixed somehow. >>>>>> >>>>>> Georgiy. > From howard.lovatt at gmail.com Wed Nov 14 00:05:52 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 14 Nov 2012 08:05:52 +0000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: Great rate of progress on this - well done. The package Javadoc still needs some work. Sent from my iPad On 14/11/2012, at 1:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From paul.sandoz at oracle.com Wed Nov 14 00:36:05 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Nov 2012 09:36:05 +0100 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On Nov 14, 2012, at 2:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > Looks good to me. > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > :-) code drop to lambda repo imminent... Paul. > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From paul.sandoz at oracle.com Wed Nov 14 01:53:33 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 14 Nov 2012 09:53:33 +0000 Subject: hg: lambda/lambda/jdk: Defer to the stream shape for the creation of a node builder Message-ID: <20121114095347.2D66247964@hg.openjdk.java.net> Changeset: 55b0174eac03 Author: psandoz Date: 2012-11-14 10:52 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55b0174eac03 Defer to the stream shape for the creation of a node builder holding elements of the required shape and to collect elements output from a pipeline into a node holding elements of the required shape. ! src/share/classes/java/util/streams/AbstractPipeline.java ! src/share/classes/java/util/streams/PipelineHelper.java ! src/share/classes/java/util/streams/StreamShape.java ! src/share/classes/java/util/streams/StreamShapeFactory.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/IntermediateOp.java ! src/share/classes/java/util/streams/ops/Node.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/OpUtils.java ! src/share/classes/java/util/streams/ops/TreeUtils.java From maurizio.cimadamore at oracle.com Wed Nov 14 02:28:29 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 14 Nov 2012 10:28:29 +0000 Subject: hg: lambda/lambda/langtools: Cleanup: remove spurious differences between lambda and JDK8 langtools branches Message-ID: <20121114102833.5E3B247967@hg.openjdk.java.net> Changeset: a69f7c559c7f Author: mcimadamore Date: 2012-11-14 10:27 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a69f7c559c7f Cleanup: remove spurious differences between lambda and JDK8 langtools branches ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java From scolebourne at joda.org Wed Nov 14 02:36:48 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Nov 2012 10:36:48 +0000 Subject: Request for Review: CR#8001667: Comparators class and Comparator extension method In-Reply-To: <50A31973.3080307@oracle.com> References: <50A31973.3080307@oracle.com> Message-ID: On 14 November 2012 04:09, Henry Jen wrote: > This is a change set regarding Comparator already in lambda repo, it > depends on the CR#8001634, particularly the Function SAMs. > > It implements proposed extension methods on Comparator > (reverse and compose) as well as static combinator methods in > Comparators for things like turning a T -> {Comparable,int,long,double} > into a Comparator. > > This allows things like: > > people.sort(Comparators.comparing(Person::getName)) > Comparator byLastFirst > = Comparators.comparing(Person::getLastName) > .compose(Comparators.comparing(Person::getFirstName)) > > Please review and comment on the webrev[1]. Comparators declares a static serializable inner class NaturalOrderComparator which is a singleton. Would it be worth declaring this as an enum with a single instance? (as per Effective Java version 2) Comparators line 77 could do with a

Comparators line 86: declaration about null that is covered in class level Javadoc Comparators line 92: who's -> whose Comparators general: I'd like to see @code around types, such as Comparable and Map.Entry While "compose" feels like the right name for Comparators, it feels like the wrong name for the equivalent method on Comparator (given the example below). "andThen" or "then" would be fluent alternatives. "composedWith" would be a more boring alternative. byLastName.compose(byFirstName) byLastName.andThen(byFirstName) byLastName.then(byFirstName) byLastName.composedWith(byFirstName) Stephen From scolebourne at joda.org Wed Nov 14 02:48:24 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Nov 2012 10:48:24 +0000 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On 13 November 2012 19:05, Mike Duigou wrote: > - Mapper.map becomes Function.apply > - Factory.make becomes Supplier.get > - Specializations of Supplier for int, long, double > - Reorder type variables to put result last > - Fixes many javadoc and stylistic comments. > > What didn't change: > - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? > - Combiner will be part of the full API but it's only present in this patch as a comment. > - No default methods. > > Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) The interface definitions say nothing about null. I'd like to see something in there, even if it is to say "null handling behaviour is defined by the implementation". I still find Block confusing. A code block is a block of code delimited by { }. It takes no arguments and returns nothing. "Receiver" was suggested as the interface name to match Supplier, and that made sense to me (and is better than Sink, which is very IO). I also find Predicate.test to be a non-optimal method name. "test" is a method name I only see in test cases. Commons collections used "evaluate". "is" would be a possible short option. I'm sure the EG can think of others. Stephen From georgiy.rakov at oracle.com Wed Nov 14 06:28:10 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 14 Nov 2012 18:28:10 +0400 Subject: forEach loops forever for infinite streams Message-ID: <50A3AA7A.7090803@oracle.com> Hello, forEach method call on infinite stream causes infinite looping over supplied block. Some of previous build threw IllegalStateException. The current behavior seems to be obvious and logic; could you please just confirm that it's really the expected behavior. Thanks, Georgiy. From brian.goetz at oracle.com Wed Nov 14 06:55:38 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 09:55:38 -0500 Subject: forEach loops forever for infinite streams In-Reply-To: <50A3AA7A.7090803@oracle.com> References: <50A3AA7A.7090803@oracle.com> Message-ID: <50A3B0EA.5070203@oracle.com> Yes, the previous behavior that threw ISE were just "training wheels" to get comfortable with the concepts. If you perform a terminal operation that consumes all the input (forEach, into, reduce, etc), it will consume all of the future as well. There are some terminal operations that are safe(r) on infinite streams, such as findFirst/findAny, and some intermediate operations that guarantee a finite result (such as limit). On 11/14/2012 9:28 AM, Georgiy Rakov wrote: > Hello, > > forEach method call on infinite stream causes infinite looping over > supplied block. Some of previous build threw IllegalStateException. The > current behavior seems to be obvious and logic; could you please just > confirm that it's really the expected behavior. > > Thanks, Georgiy. > From cmotlin at gmail.com Wed Nov 14 07:12:31 2012 From: cmotlin at gmail.com (Craig P. Motlin) Date: Wed, 14 Nov 2012 10:12:31 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: What's the issue with both methods being named apply? On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > The name Block.apply currently conflicts with Function.apply and should be > renamed. From Alan.Bateman at oracle.com Wed Nov 14 07:41:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 15:41:32 +0000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A3BBAC.2070907@oracle.com> On 14/11/2012 01:19, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > Just a few incy wincy comments on the latest webrev: - Don't forget functions->function in make/java/java/Makefile. - The @return in Predicate - it might read a bit better if there were a comma before "otherwise". - In the package description it reads "All functional interface implementations are expected to" but this doesn't flow well into the bullet point. It may be better to re-word this sentence to something like "Implementators of functional interfaces should keep in mind:". -Alan. From georgiy.rakov at oracle.com Wed Nov 14 09:11:03 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 14 Nov 2012 21:11:03 +0400 Subject: flatMap() concept Message-ID: <50A3D0A7.1040207@oracle.com> Hello, I have some concerns regarding current FlatMapper concept. Let's consider stream *s* of strings: {"a3", "b1000"}. And FlatMapper instance *fm* which returns following sequences on each item: - on "a3" it returns integers 1, 2, 3; - on "b1000" it returns integers 1, 2,...,1000; Suppose we have following situations while iterating over elements using iterator returned by *s.flatMap(fm).iterator()*. 1. We've iterated over first 3 items and then make *hasNext()* call and quit iteration because we need no more elements. In this case when *hasNext()* is called all 1000 elements would be supplied to *sink* passed to *fm* though there no needs for it. 2. We've iterated over first 4 items and then quit iteration because we need no more elements. In this case computational and memory resources will be engaged for handling 999 elements which we have no needs for. It seems that all these are desired to be avoided. I'd like to note that previous version of *flatMap* receiving *Mapper>* would allow us to avoid such potential waste of resources. Could you please give your comments. Thanks, Georgiy. From mike.duigou at oracle.com Wed Nov 14 09:12:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Nov 2012 09:12:04 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> The issue is primarily when one class wants to implement more than one functional interface. If the names collide then the class will only be able to implement one of the interfaces. Mike On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > What's the issue with both methods being named apply? > > On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > The name Block.apply currently conflicts with Function.apply and should be renamed. > From brian.goetz at oracle.com Wed Nov 14 09:21:39 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 14 Nov 2012 17:21:39 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121114172213.1FAE347971@hg.openjdk.java.net> Changeset: 3b1593c9f320 Author: briangoetz Date: 2012-11-14 11:41 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b1593c9f320 Refactor AbstractTask hierarchy to create cancelable and short-circuitable tasks; refine FindAny,FindFirst,Match to use same; combine Limit and Skip operations into a combined Slice operation; initial work on parallelizing Slice ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/FindAnyOp.java ! src/share/classes/java/util/streams/ops/FindFirstOp.java - src/share/classes/java/util/streams/ops/LimitOp.java ! src/share/classes/java/util/streams/ops/MatchOp.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/OpUtils.java - src/share/classes/java/util/streams/ops/SkipOp.java + src/share/classes/java/util/streams/ops/SliceOp.java ! src/share/classes/java/util/streams/ops/TreeUtils.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SkipOpTest.java Changeset: abcf56edb55c Author: briangoetz Date: 2012-11-14 12:21 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/abcf56edb55c Merge ! src/share/classes/java/util/streams/ops/AbstractTask.java - src/share/classes/java/util/streams/ops/LimitOp.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/OpUtils.java - src/share/classes/java/util/streams/ops/SkipOp.java ! src/share/classes/java/util/streams/ops/TreeUtils.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SkipOpTest.java From spullara at gmail.com Mon Nov 12 11:57:34 2012 From: spullara at gmail.com (Sam Pullara) Date: Mon, 12 Nov 2012 11:57:34 -0800 Subject: Lambda and intersection types In-Reply-To: References: Message-ID: <7701DB87-B729-479F-8063-B362811670DA@sampullara> I thought that one of them had to be a tagging interface with no methods? Shouldn't the compiler have failed to compile this? Sam On Nov 12, 2012, at 11:45 AM, Boaz Nahum wrote: > The follwing simple code ... > > ==================================== > interface I1 {void f();} > > interface I2 { > > void printMe()default { System.out.println("I2");} > > void f(); > } > > public static void main(String[] args) { > > I2 i2 = (I1 & I2) () -> {}; > > System.out.println( "i2 is I2=" + (i2 instanceof I2)); > > i2.printMe(); > } > ================================= > Output is: > > ------------------------------------- > i2 is I2=false > Exception in thread "main" java.lang.IncompatibleClassChangeError: Class > question.lambda_intersection_types.Q$$Lambda$2 does not implement the > requested interface question.lambda_intersection_types.I2 > ------------------------------------- > > What is the correct behavior ? > From tim at peierls.net Wed Nov 14 09:29:09 2012 From: tim at peierls.net (Tim Peierls) Date: Wed, 14 Nov 2012 12:29:09 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> References: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> Message-ID: Implementing more than one of the functional interfaces sounds like a bad idea; making it difficult or impossible to do is a *good *thing. Use apply everywhere to prevent things like Shimmer implements FloorWax, DessertTopping. Does anyone have any compelling example of why you actually might want to implement multiple functional interfaces that isn't satisfied by using asFunction, asPredicate, asProcedure, etc. methods? --tim On Wed, Nov 14, 2012 at 12:12 PM, Mike Duigou wrote: > The issue is primarily when one class wants to implement more than one > functional interface. If the names collide then the class will only be able > to implement one of the interfaces. > > Mike > > On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > > What's the issue with both methods being named apply? > > > On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > >> The name Block.apply currently conflicts with Function.apply and should >> be renamed. > > > > From brian.goetz at oracle.com Wed Nov 14 10:14:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 13:14:27 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> References: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> Message-ID: <50A3DF83.1030900@oracle.com> Or when one functional interface wants to extend another, such as IntBlock extends Block On 11/14/2012 12:12 PM, Mike Duigou wrote: > The issue is primarily when one class wants to implement more than one functional interface. If the names collide then the class will only be able to implement one of the interfaces. > > Mike > > On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > >> What's the issue with both methods being named apply? >> >> On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: >> The name Block.apply currently conflicts with Function.apply and should be renamed. >> > > From paul.sandoz at oracle.com Wed Nov 14 10:16:01 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 14 Nov 2012 18:16:01 +0000 Subject: hg: lambda/lambda/jdk: Support for int-based streams and testing of. Message-ID: <20121114181612.DA99F47975@hg.openjdk.java.net> Changeset: 507817d66484 Author: psandoz Date: 2012-11-14 18:49 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/507817d66484 Support for int-based streams and testing of. Can serve as a template for long and double-based streams. This commit does not go to any length, and deliberately so, to consolidate functionality. The initial objective is to get int-based streams working such that no boxing is performed, then iterate on that functionality. ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/StreamShapeFactory.java ! src/share/classes/java/util/streams/ops/Nodes.java + src/share/classes/java/util/streams/primitives/IntBlock.java + src/share/classes/java/util/streams/primitives/IntCollectorOps.java + src/share/classes/java/util/streams/primitives/IntFactory.java + src/share/classes/java/util/streams/primitives/IntFilterOp.java + src/share/classes/java/util/streams/primitives/IntForEachOp.java + src/share/classes/java/util/streams/primitives/IntIterable.java + src/share/classes/java/util/streams/primitives/IntIterator.java + src/share/classes/java/util/streams/primitives/IntLimitOp.java + src/share/classes/java/util/streams/primitives/IntMapOp.java + src/share/classes/java/util/streams/primitives/IntNode.java + src/share/classes/java/util/streams/primitives/IntNodeBuilder.java + src/share/classes/java/util/streams/primitives/IntNodes.java + src/share/classes/java/util/streams/primitives/IntPipeline.java + src/share/classes/java/util/streams/primitives/IntPredicate.java + src/share/classes/java/util/streams/primitives/IntSink.java + src/share/classes/java/util/streams/primitives/IntSortedOp.java + src/share/classes/java/util/streams/primitives/IntSpliterator.java + src/share/classes/java/util/streams/primitives/IntStream.java + src/share/classes/java/util/streams/primitives/IntSumOp.java + src/share/classes/java/util/streams/primitives/IntTeeOp.java + src/share/classes/java/util/streams/primitives/IntTerminalSink.java + src/share/classes/java/util/streams/primitives/IntToArrayOp.java + src/share/classes/java/util/streams/primitives/IntToIntegerOp.java ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java < src/share/classes/java/util/streams/ops/TreeUtils.java + src/share/classes/java/util/streams/primitives/IntUnaryOperator.java + src/share/classes/java/util/streams/primitives/Primitives.java + src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java From brian.goetz at oracle.com Wed Nov 14 10:25:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 13:25:27 -0500 Subject: flatMap() concept In-Reply-To: <50A3D0A7.1040207@oracle.com> References: <50A3D0A7.1040207@oracle.com> Message-ID: <50A3E217.6090707@oracle.com> Valid observations, but I think you're focusing on an uncommon case of an uncommon case. A key design assumption is that *most* stream operations will operate in "push" mode rather than "pull" mode. Pull mode (using iterators) only comes into play when you have an operation that may not consume all the input. Most terminal operations do consume all the input (forEach, into, reduce, groupBy); only a few do not (findFirst, findAny) and therefore can use the more efficient push mode. Similarly, asking explicitly for an iterator() is an "escape hatch" for when you cannot accomplish your goals with the built-in functionality. (That's the first level of "uncommon case"; the second level is that you are mapping one element to many. This happens sometimes, but it happens plenty frequently that one element maps to zero or one.) The current design of flatMap is optimized for pushing; it creates no intermediate arrays, collections, iterator, or other bookkeeping overhead for the per-input-element results, and if an element maps to nothing, rather than creating an empty descriptor and iterating it, the implementation simply does nothing. Much more efficient. So while there may be a "waste of resources" in some cases, the current design is far more resource-efficient in the common cases. On 11/14/2012 12:11 PM, Georgiy Rakov wrote: > Hello, > > I have some concerns regarding current FlatMapper concept. > > Let's consider stream *s* of strings: {"a3", "b1000"}. And FlatMapper > instance *fm* which returns following sequences on each item: > - on "a3" it returns integers 1, 2, 3; > - on "b1000" it returns integers 1, 2,...,1000; > > Suppose we have following situations while iterating over elements using > iterator returned by *s.flatMap(fm).iterator()*. > 1. We've iterated over first 3 items and then make *hasNext()* call and > quit iteration because we need no more elements. > In this case when *hasNext()* is called all 1000 elements would be > supplied to *sink* passed to *fm* though there no needs for it. > > 2. We've iterated over first 4 items and then quit iteration because we > need no more elements. > In this case computational and memory resources will be engaged for > handling 999 elements which we have no needs for. > > It seems that all these are desired to be avoided. > > I'd like to note that previous version of *flatMap* receiving *Mapper Iterable>* would allow us to avoid such potential waste of resources. > > Could you please give your comments. > > Thanks, > Georgiy. > From brian.goetz at oracle.com Wed Nov 14 10:26:04 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 13:26:04 -0500 Subject: hg: lambda/lambda/jdk: Support for int-based streams and testing of. In-Reply-To: <20121114181612.DA99F47975@hg.openjdk.java.net> References: <20121114181612.DA99F47975@hg.openjdk.java.net> Message-ID: <50A3E23C.2090607@oracle.com> This is a big milestone! On 11/14/2012 1:16 PM, paul.sandoz at oracle.com wrote: > Changeset: 507817d66484 > Author: psandoz > Date: 2012-11-14 18:49 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/507817d66484 > > Support for int-based streams and testing of. > Can serve as a template for long and double-based streams. > This commit does not go to any length, and deliberately so, to consolidate > functionality. The initial objective is to get int-based streams > working such that no boxing is performed, then iterate on that > functionality. > > ! src/share/classes/java/util/streams/ReferencePipeline.java > ! src/share/classes/java/util/streams/Stream.java > ! src/share/classes/java/util/streams/StreamShapeFactory.java > ! src/share/classes/java/util/streams/ops/Nodes.java > + src/share/classes/java/util/streams/primitives/IntBlock.java > + src/share/classes/java/util/streams/primitives/IntCollectorOps.java > + src/share/classes/java/util/streams/primitives/IntFactory.java > + src/share/classes/java/util/streams/primitives/IntFilterOp.java > + src/share/classes/java/util/streams/primitives/IntForEachOp.java > + src/share/classes/java/util/streams/primitives/IntIterable.java > + src/share/classes/java/util/streams/primitives/IntIterator.java > + src/share/classes/java/util/streams/primitives/IntLimitOp.java > + src/share/classes/java/util/streams/primitives/IntMapOp.java > + src/share/classes/java/util/streams/primitives/IntNode.java > + src/share/classes/java/util/streams/primitives/IntNodeBuilder.java > + src/share/classes/java/util/streams/primitives/IntNodes.java > + src/share/classes/java/util/streams/primitives/IntPipeline.java > + src/share/classes/java/util/streams/primitives/IntPredicate.java > + src/share/classes/java/util/streams/primitives/IntSink.java > + src/share/classes/java/util/streams/primitives/IntSortedOp.java > + src/share/classes/java/util/streams/primitives/IntSpliterator.java > + src/share/classes/java/util/streams/primitives/IntStream.java > + src/share/classes/java/util/streams/primitives/IntSumOp.java > + src/share/classes/java/util/streams/primitives/IntTeeOp.java > + src/share/classes/java/util/streams/primitives/IntTerminalSink.java > + src/share/classes/java/util/streams/primitives/IntToArrayOp.java > + src/share/classes/java/util/streams/primitives/IntToIntegerOp.java > ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java < src/share/classes/java/util/streams/ops/TreeUtils.java > + src/share/classes/java/util/streams/primitives/IntUnaryOperator.java > + src/share/classes/java/util/streams/primitives/Primitives.java > + src/share/classes/java/util/streams/primitives/RefToIntMapOp.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java > + test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java > + test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java > + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java > + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java > + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java > + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java > > From oleksander.demura at gmail.com Wed Nov 14 10:33:03 2012 From: oleksander.demura at gmail.com (Olexandr Demura) Date: Wed, 14 Nov 2012 20:33:03 +0200 Subject: flatMap() concept In-Reply-To: <50A3E217.6090707@oracle.com> References: <50A3D0A7.1040207@oracle.com> <50A3E217.6090707@oracle.com> Message-ID: BTW, which java version is expected to have coroutines/generators? 2012/11/14 Brian Goetz > Valid observations, but I think you're focusing on an uncommon case of > an uncommon case. > > A key design assumption is that *most* stream operations will operate in > "push" mode rather than "pull" mode. Pull mode (using iterators) only > comes into play when you have an operation that may not consume all the > input. Most terminal operations do consume all the input (forEach, > into, reduce, groupBy); only a few do not (findFirst, findAny) and > therefore can use the more efficient push mode. Similarly, asking > explicitly for an iterator() is an "escape hatch" for when you cannot > accomplish your goals with the built-in functionality. (That's the > first level of "uncommon case"; the second level is that you are mapping > one element to many. This happens sometimes, but it happens plenty > frequently that one element maps to zero or one.) > > The current design of flatMap is optimized for pushing; it creates no > intermediate arrays, collections, iterator, or other bookkeeping > overhead for the per-input-element results, and if an element maps to > nothing, rather than creating an empty descriptor and iterating it, the > implementation simply does nothing. Much more efficient. So while > there may be a "waste of resources" in some cases, the current design is > far more resource-efficient in the common cases. > From brian.goetz at oracle.com Wed Nov 14 10:41:04 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 13:41:04 -0500 Subject: flatMap() concept In-Reply-To: References: <50A3D0A7.1040207@oracle.com> <50A3E217.6090707@oracle.com> Message-ID: <50A3E5C0.1030206@oracle.com> That's an awfully optimistic way to phrase the question :) Not 8. Not 9. Future beyond that is hard to predict. On 11/14/2012 1:33 PM, Olexandr Demura wrote: > BTW, which java version is expected to have coroutines/generators? > > 2012/11/14 Brian Goetz > > > Valid observations, but I think you're focusing on an uncommon case of > an uncommon case. > > A key design assumption is that *most* stream operations will operate in > "push" mode rather than "pull" mode. Pull mode (using iterators) only > comes into play when you have an operation that may not consume all the > input. Most terminal operations do consume all the input (forEach, > into, reduce, groupBy); only a few do not (findFirst, findAny) and > therefore can use the more efficient push mode. Similarly, asking > explicitly for an iterator() is an "escape hatch" for when you cannot > accomplish your goals with the built-in functionality. (That's the > first level of "uncommon case"; the second level is that you are mapping > one element to many. This happens sometimes, but it happens plenty > frequently that one element maps to zero or one.) > > The current design of flatMap is optimized for pushing; it creates no > intermediate arrays, collections, iterator, or other bookkeeping > overhead for the per-input-element results, and if an element maps to > nothing, rather than creating an empty descriptor and iterating it, the > implementation simply does nothing. Much more efficient. So while > there may be a "waste of resources" in some cases, the current design is > far more resource-efficient in the common cases. > > From aleksey.shipilev at oracle.com Wed Nov 14 11:58:42 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 14 Nov 2012 20:58:42 +0100 Subject: FJP update Message-ID: <50A3F7F2.2030004@oracle.com> Hi guys, There is another spin on FJP improvements from Doug Lea. Here is the patch against current lambda/lambda: http://shipilev.net/pub/jdk/lambda/20121114-fjp-update-1.patch.gz Tested lambda/lambda to build, and Stream.parallel() performance tests to work and not degrade on my laptop. Please consider pushing this ASAP; we would need to get this into the nightlies and test it on larger machines :) Thanks, Aleksey. From paul.sandoz at oracle.com Wed Nov 14 13:24:38 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 14 Nov 2012 21:24:38 +0000 Subject: hg: lambda/lambda/jdk: Remove Sink.accept and defer to Block.apply. Message-ID: <20121114212459.71E7647987@hg.openjdk.java.net> Changeset: dd7327fe3467 Author: psandoz Date: 2012-11-14 22:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dd7327fe3467 Remove Sink.accept and defer to Block.apply. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/streams/Sink.java ! src/share/classes/java/util/streams/ops/ConcatOp.java ! src/share/classes/java/util/streams/ops/CumulateOp.java ! src/share/classes/java/util/streams/ops/FilterOp.java ! src/share/classes/java/util/streams/ops/FlatMapOp.java ! src/share/classes/java/util/streams/ops/FoldOp.java ! src/share/classes/java/util/streams/ops/ForEachOp.java ! src/share/classes/java/util/streams/ops/GroupByOp.java ! src/share/classes/java/util/streams/ops/MapOp.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/ReduceByOp.java ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java ! src/share/classes/java/util/streams/ops/SliceOp.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! src/share/classes/java/util/streams/ops/TeeOp.java ! src/share/classes/java/util/streams/ops/UniqOp.java ! src/share/classes/java/util/streams/primitives/IntFilterOp.java ! src/share/classes/java/util/streams/primitives/IntForEachOp.java ! src/share/classes/java/util/streams/primitives/IntMapOp.java ! src/share/classes/java/util/streams/primitives/IntNodes.java ! src/share/classes/java/util/streams/primitives/IntSink.java ! src/share/classes/java/util/streams/primitives/IntSortedOp.java ! src/share/classes/java/util/streams/primitives/IntSumOp.java ! src/share/classes/java/util/streams/primitives/IntTeeOp.java ! src/share/classes/java/util/streams/primitives/IntToIntegerOp.java ! src/share/classes/java/util/streams/primitives/Primitives.java ! src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java From eric.caspole at amd.com Wed Nov 14 14:36:54 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 14 Nov 2012 17:36:54 -0500 Subject: hg: lambda/lambda/jdk: Support for int-based streams and testing of. In-Reply-To: <50A3E23C.2090607@oracle.com> References: <20121114181612.DA99F47975@hg.openjdk.java.net> <50A3E23C.2090607@oracle.com> Message-ID: <50A41D06.9010602@amd.com> Does this work allow something like this, on int inputs[]; Arrays.stream(inputs).forEach(p->{ /* do something with p */; }); Or is there a different syntax to do this? I am working on deciphering its unit tests to see how it works. Thanks, Eric On 11/14/2012 01:26 PM, Brian Goetz wrote: > This is a big milestone! > > On 11/14/2012 1:16 PM, paul.sandoz at oracle.com wrote: >> Changeset: 507817d66484 >> Author: psandoz >> Date: 2012-11-14 18:49 +0100 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/507817d66484 >> >> Support for int-based streams and testing of. >> Can serve as a template for long and double-based streams. >> This commit does not go to any length, and deliberately so, to consolidate >> functionality. The initial objective is to get int-based streams >> working such that no boxing is performed, then iterate on that >> functionality. >> >> ! src/share/classes/java/util/streams/ReferencePipeline.java >> ! src/share/classes/java/util/streams/Stream.java >> ! src/share/classes/java/util/streams/StreamShapeFactory.java >> ! src/share/classes/java/util/streams/ops/Nodes.java >> + src/share/classes/java/util/streams/primitives/IntBlock.java >> + src/share/classes/java/util/streams/primitives/IntCollectorOps.java >> + src/share/classes/java/util/streams/primitives/IntFactory.java >> + src/share/classes/java/util/streams/primitives/IntFilterOp.java >> + src/share/classes/java/util/streams/primitives/IntForEachOp.java >> + src/share/classes/java/util/streams/primitives/IntIterable.java >> + src/share/classes/java/util/streams/primitives/IntIterator.java >> + src/share/classes/java/util/streams/primitives/IntLimitOp.java >> + src/share/classes/java/util/streams/primitives/IntMapOp.java >> + src/share/classes/java/util/streams/primitives/IntNode.java >> + src/share/classes/java/util/streams/primitives/IntNodeBuilder.java >> + src/share/classes/java/util/streams/primitives/IntNodes.java >> + src/share/classes/java/util/streams/primitives/IntPipeline.java >> + src/share/classes/java/util/streams/primitives/IntPredicate.java >> + src/share/classes/java/util/streams/primitives/IntSink.java >> + src/share/classes/java/util/streams/primitives/IntSortedOp.java >> + src/share/classes/java/util/streams/primitives/IntSpliterator.java >> + src/share/classes/java/util/streams/primitives/IntStream.java >> + src/share/classes/java/util/streams/primitives/IntSumOp.java >> + src/share/classes/java/util/streams/primitives/IntTeeOp.java >> + src/share/classes/java/util/streams/primitives/IntTerminalSink.java >> + src/share/classes/java/util/streams/primitives/IntToArrayOp.java >> + src/share/classes/java/util/streams/primitives/IntToIntegerOp.java >> ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java < src/share/classes/java/util/streams/ops/TreeUtils.java >> + src/share/classes/java/util/streams/primitives/IntUnaryOperator.java >> + src/share/classes/java/util/streams/primitives/Primitives.java >> + src/share/classes/java/util/streams/primitives/RefToIntMapOp.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java >> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java >> >> > > From mike.duigou at oracle.com Wed Nov 14 14:44:21 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Nov 2012 22:44:21 +0000 Subject: hg: lambda/lambda: add java.util.streams.primitives to ct.sym Message-ID: <20121114224421.8975C4798B@hg.openjdk.java.net> Changeset: 24573dca0033 Author: mduigou Date: 2012-11-14 14:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/24573dca0033 add java.util.streams.primitives to ct.sym ! common/makefiles/javadoc/CORE_PKGS.gmk From mike.duigou at oracle.com Wed Nov 14 14:46:24 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Nov 2012 22:46:24 +0000 Subject: hg: lambda/lambda/jdk: another file needing update for ct.sym generation Message-ID: <20121114224636.13E404798C@hg.openjdk.java.net> Changeset: 04097f9a3410 Author: mduigou Date: 2012-11-14 14:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/04097f9a3410 another file needing update for ct.sym generation ! make/docs/CORE_PKGS.gmk From brian.goetz at oracle.com Wed Nov 14 14:48:48 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 17:48:48 -0500 Subject: hg: lambda/lambda/jdk: Support for int-based streams and testing of. In-Reply-To: <50A41D06.9010602@amd.com> References: <20121114181612.DA99F47975@hg.openjdk.java.net> <50A3E23C.2090607@oracle.com> <50A41D06.9010602@amd.com> Message-ID: <50A41FD0.7060603@oracle.com> Eventually so. I am not sure if Arrays.stream(int[]) is there yet in this push, but certainly in the plans. (Remember, this is the first push. Paint not yet dry.) On 11/14/2012 5:36 PM, Eric Caspole wrote: > Does this work allow something like this, on > > int inputs[]; > > Arrays.stream(inputs).forEach(p->{ /* do something with p */; }); > > Or is there a different syntax to do this? > I am working on deciphering its unit tests to see how it works. > Thanks, > Eric > > > On 11/14/2012 01:26 PM, Brian Goetz wrote: >> This is a big milestone! >> >> On 11/14/2012 1:16 PM, paul.sandoz at oracle.com wrote: >>> Changeset: 507817d66484 >>> Author: psandoz >>> Date: 2012-11-14 18:49 +0100 >>> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/507817d66484 >>> >>> Support for int-based streams and testing of. >>> Can serve as a template for long and double-based streams. >>> This commit does not go to any length, and deliberately so, to consolidate >>> functionality. The initial objective is to get int-based streams >>> working such that no boxing is performed, then iterate on that >>> functionality. >>> >>> ! src/share/classes/java/util/streams/ReferencePipeline.java >>> ! src/share/classes/java/util/streams/Stream.java >>> ! src/share/classes/java/util/streams/StreamShapeFactory.java >>> ! src/share/classes/java/util/streams/ops/Nodes.java >>> + src/share/classes/java/util/streams/primitives/IntBlock.java >>> + src/share/classes/java/util/streams/primitives/IntCollectorOps.java >>> + src/share/classes/java/util/streams/primitives/IntFactory.java >>> + src/share/classes/java/util/streams/primitives/IntFilterOp.java >>> + src/share/classes/java/util/streams/primitives/IntForEachOp.java >>> + src/share/classes/java/util/streams/primitives/IntIterable.java >>> + src/share/classes/java/util/streams/primitives/IntIterator.java >>> + src/share/classes/java/util/streams/primitives/IntLimitOp.java >>> + src/share/classes/java/util/streams/primitives/IntMapOp.java >>> + src/share/classes/java/util/streams/primitives/IntNode.java >>> + src/share/classes/java/util/streams/primitives/IntNodeBuilder.java >>> + src/share/classes/java/util/streams/primitives/IntNodes.java >>> + src/share/classes/java/util/streams/primitives/IntPipeline.java >>> + src/share/classes/java/util/streams/primitives/IntPredicate.java >>> + src/share/classes/java/util/streams/primitives/IntSink.java >>> + src/share/classes/java/util/streams/primitives/IntSortedOp.java >>> + src/share/classes/java/util/streams/primitives/IntSpliterator.java >>> + src/share/classes/java/util/streams/primitives/IntStream.java >>> + src/share/classes/java/util/streams/primitives/IntSumOp.java >>> + src/share/classes/java/util/streams/primitives/IntTeeOp.java >>> + src/share/classes/java/util/streams/primitives/IntTerminalSink.java >>> + src/share/classes/java/util/streams/primitives/IntToArrayOp.java >>> + src/share/classes/java/util/streams/primitives/IntToIntegerOp.java >>> ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java < src/share/classes/java/util/streams/ops/TreeUtils.java >>> + src/share/classes/java/util/streams/primitives/IntUnaryOperator.java >>> + src/share/classes/java/util/streams/primitives/Primitives.java >>> + src/share/classes/java/util/streams/primitives/RefToIntMapOp.java >>> ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java >>> ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java >>> + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java >>> >>> >> >> > > From mike.duigou at oracle.com Wed Nov 14 14:43:26 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Nov 2012 22:43:26 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121114224349.6A95947989@hg.openjdk.java.net> Changeset: 9b7246d917a1 Author: mduigou Date: 2012-11-14 14:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b7246d917a1 update to latest fork/join pool Contributed-by: dl, shade ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/TreeUtils.java ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java Changeset: be4f3fcc5420 Author: mduigou Date: 2012-11-14 14:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/be4f3fcc5420 add java.util.streams.primitives to ct.sym ! makefiles/docs/CORE_PKGS.gmk From mike.duigou at oracle.com Wed Nov 14 16:32:54 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 15 Nov 2012 00:32:54 +0000 Subject: hg: lambda/lambda/jdk: disable auxiliaryclass warnings preventing -Xlint:all compilation Message-ID: <20121115003306.21D724798D@hg.openjdk.java.net> Changeset: 5e01e9ac2123 Author: mduigou Date: 2012-11-14 16:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e01e9ac2123 disable auxiliaryclass warnings preventing -Xlint:all compilation ! make/com/sun/crypto/provider/Makefile ! make/com/sun/net/httpserver/Makefile ! make/sun/security/other/Makefile From brian.goetz at oracle.com Wed Nov 14 22:24:00 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 06:24:00 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121115062423.3BCBC479A0@hg.openjdk.java.net> Changeset: 30db89b2808e Author: briangoetz Date: 2012-11-15 00:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/30db89b2808e Add slice op (combination of skip+limit); merge SkipOP and LimitOp implementations into a single SliceOp; parallel implementation of SliceOp; more tests ! make/com/sun/crypto/provider/Makefile ! make/com/sun/net/httpserver/Makefile ! make/docs/CORE_PKGS.gmk ! make/sun/security/other/Makefile ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Sink.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/StreamShapeFactory.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/ConcatOp.java ! src/share/classes/java/util/streams/ops/CumulateOp.java ! src/share/classes/java/util/streams/ops/FilterOp.java ! src/share/classes/java/util/streams/ops/FlatMapOp.java ! src/share/classes/java/util/streams/ops/FoldOp.java ! src/share/classes/java/util/streams/ops/ForEachOp.java ! src/share/classes/java/util/streams/ops/GroupByOp.java ! src/share/classes/java/util/streams/ops/MapOp.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/ReduceByOp.java ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java ! src/share/classes/java/util/streams/ops/SliceOp.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! src/share/classes/java/util/streams/ops/TeeOp.java ! src/share/classes/java/util/streams/ops/TreeUtils.java ! src/share/classes/java/util/streams/ops/UniqOp.java + src/share/classes/java/util/streams/primitives/IntBlock.java + src/share/classes/java/util/streams/primitives/IntCollectorOps.java + src/share/classes/java/util/streams/primitives/IntFactory.java + src/share/classes/java/util/streams/primitives/IntFilterOp.java + src/share/classes/java/util/streams/primitives/IntForEachOp.java + src/share/classes/java/util/streams/primitives/IntIterable.java + src/share/classes/java/util/streams/primitives/IntIterator.java + src/share/classes/java/util/streams/primitives/IntLimitOp.java + src/share/classes/java/util/streams/primitives/IntMapOp.java + src/share/classes/java/util/streams/primitives/IntNode.java + src/share/classes/java/util/streams/primitives/IntNodeBuilder.java + src/share/classes/java/util/streams/primitives/IntNodes.java + src/share/classes/java/util/streams/primitives/IntPipeline.java + src/share/classes/java/util/streams/primitives/IntPredicate.java + src/share/classes/java/util/streams/primitives/IntSink.java + src/share/classes/java/util/streams/primitives/IntSortedOp.java + src/share/classes/java/util/streams/primitives/IntSpliterator.java + src/share/classes/java/util/streams/primitives/IntStream.java + src/share/classes/java/util/streams/primitives/IntSumOp.java + src/share/classes/java/util/streams/primitives/IntTeeOp.java + src/share/classes/java/util/streams/primitives/IntTerminalSink.java + src/share/classes/java/util/streams/primitives/IntToArrayOp.java + src/share/classes/java/util/streams/primitives/IntToIntegerOp.java + src/share/classes/java/util/streams/primitives/IntTreeUtils.java + src/share/classes/java/util/streams/primitives/IntUnaryOperator.java + src/share/classes/java/util/streams/primitives/Primitives.java + src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/LimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/SkipOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java + test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java Changeset: 5a54b0ddbbcb Author: briangoetz Date: 2012-11-15 00:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5a54b0ddbbcb Merge ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/ops/AbstractTask.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/SliceOp.java ! src/share/classes/java/util/streams/primitives/IntFilterOp.java ! src/share/classes/java/util/streams/primitives/IntForEachOp.java ! src/share/classes/java/util/streams/primitives/IntMapOp.java ! src/share/classes/java/util/streams/primitives/IntNodes.java ! src/share/classes/java/util/streams/primitives/IntSink.java ! src/share/classes/java/util/streams/primitives/IntSortedOp.java ! src/share/classes/java/util/streams/primitives/IntSumOp.java ! src/share/classes/java/util/streams/primitives/IntTeeOp.java ! src/share/classes/java/util/streams/primitives/IntToIntegerOp.java ! src/share/classes/java/util/streams/primitives/IntTreeUtils.java ! src/share/classes/java/util/streams/primitives/Primitives.java ! src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java From david.holmes at oracle.com Wed Nov 14 22:56:05 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 16:56:05 +1000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A49205.6030108@oracle.com> Hi Mike, My original comment still stands regarding the wording in the Function specializations versus all the others. Why does, for example, IntFunction say "this is the {@code int}-bearing specialization for {@link Function}", yet IntBinaryOperator does not make a similar statement regarding BinaryOperator? David On 14/11/2012 11:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From dmitry.bessonov at oracle.com Thu Nov 15 00:32:49 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Thu, 15 Nov 2012 12:32:49 +0400 Subject: Stream.limit() - puzzler/bug/feature Message-ID: <50A4A8B1.5000904@oracle.com> Hello, While playing with method Sream.limit(int) using a mini-code like final Stream s = Arrays.asStream(1, 2, 3, 4, 5); final Stream to3 = s.limit(3); final Stream to4 = s.limit(4); have to admit that there's no unambiguous answer to the question of contents of streams "to3" and "to4". It depends on which of the streams is consumed first. Might situations (and mis-usage?) like this above be a trap for novice users that should be well described? Dmitry From paul.sandoz at oracle.com Thu Nov 15 02:31:44 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Nov 2012 11:31:44 +0100 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <50A4A8B1.5000904@oracle.com> References: <50A4A8B1.5000904@oracle.com> Message-ID: <2E2A13CC-B1D5-45B3-AEA5-5CCD2B9BBAA7@oracle.com> Hi, On Nov 15, 2012, at 9:32 AM, Dmitry Bessonov wrote: > Hello, > > While playing with method Sream.limit(int) using a mini-code like > > final Stream s = Arrays.asStream(1, 2, 3, 4, 5); > final Stream to3 = s.limit(3); > final Stream to4 = s.limit(4); > > have to admit that there's no unambiguous answer > to the question of contents of streams "to3" and "to4". > It depends on which of the streams is consumed first. > Right. > Might situations (and mis-usage?) like this above > be a trap for novice users > that should be well described? > The limit is is really "at most", so the stream can contain less than the limit but no more than. I think we just need to describe it in terms of that. Stream.iterator() is like a "get of jail" card for those that need to do something on streams that cannot be done with other terminal operations. So IMHO i don't think we need to go to great lengths to describe such potential traps. Paul. From paul.sandoz at oracle.com Thu Nov 15 02:44:07 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Nov 2012 11:44:07 +0100 Subject: Initial support for int streams Message-ID: <894005A9-8815-44AF-9C88-6449ED4866D9@oracle.com> Hi, Initial support for int streams has been pushed to the code repo. It's a little rough'n'ready, the initial goal was to get something working for pull/push/sequential/parallel without boxing. There has not been much attempt to consolidate functionality between reference and int streams (beyond that of the core and test framework). Nor has there been much attempt to find the right locations for various pieces of functionality e.g. Arrays.stream(int[] ). We can now stand back a little and see what can be shared and what should go where, such as: - it looks possible to share much of the the work that Brian recently did for parallel tasks with FindAny/FirstFirst/Match*/Splice for reference streams. - we can add a method Random.intStream() to return an infinite stream of randomly generated integers. For the curious some simple test examples can be found here: http://hg.openjdk.java.net/lambda/lambda/jdk/raw-file/tip/test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java Paul. From brian.goetz at oracle.com Thu Nov 15 07:17:42 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 10:17:42 -0500 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <50A4A8B1.5000904@oracle.com> References: <50A4A8B1.5000904@oracle.com> Message-ID: <50A50796.1030203@oracle.com> Yes, don't do that :) On 11/15/2012 3:32 AM, Dmitry Bessonov wrote: > Hello, > > While playing with method Sream.limit(int) using a mini-code like > > final Stream s = Arrays.asStream(1, 2, 3, 4, 5); > final Stream to3 = s.limit(3); > final Stream to4 = s.limit(4); > > have to admit that there's no unambiguous answer > to the question of contents of streams "to3" and "to4". > It depends on which of the streams is consumed first. > > Might situations (and mis-usage?) like this above > be a trap for novice users > that should be well described? > > Dmitry > > From maurizio.cimadamore at oracle.com Thu Nov 15 07:28:54 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 15 Nov 2012 15:28:54 +0000 Subject: hg: lambda/lambda/langtools: 17 new changesets Message-ID: <20121115152929.B76F7479AF@hg.openjdk.java.net> Changeset: 2443d24d096a Author: vromero Date: 2012-11-01 13:06 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2443d24d096a 6949443: visitTree assertion triggered using -Xjcov on small sample program Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java + test/tools/javac/options/T6949443.java Changeset: a33770a91b00 Author: jjg Date: 2012-11-02 19:17 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a33770a91b00 Merge Changeset: ef3ad754f5c7 Author: jjg Date: 2012-11-03 21:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ef3ad754f5c7 8002146: javadoc doesn't release resources in a timely manner Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: 352d130c47c5 Author: jjg Date: 2012-11-03 21:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/352d130c47c5 8002168: Cleanup initialization of javadoc Messager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Start.java ! test/tools/javadoc/6958836/Test.java Changeset: d7d932236fee Author: mcimadamore Date: 2012-11-04 10:59 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d7d932236fee 7192246: Add type-checking support for default methods Summary: Add type-checking support for default methods as per Featherweight-Defender document Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java + test/tools/javac/defaultMethods/ClassReaderTest/pkg/Foo.java + test/tools/javac/defaultMethods/Neg01.java + test/tools/javac/defaultMethods/Neg01.out + test/tools/javac/defaultMethods/Neg02.java + test/tools/javac/defaultMethods/Neg02.out + test/tools/javac/defaultMethods/Neg03.java + test/tools/javac/defaultMethods/Neg03.out + test/tools/javac/defaultMethods/Neg04.java + test/tools/javac/defaultMethods/Neg04.out + test/tools/javac/defaultMethods/Neg05.java + test/tools/javac/defaultMethods/Neg05.out + test/tools/javac/defaultMethods/Neg06.java + test/tools/javac/defaultMethods/Neg06.out + test/tools/javac/defaultMethods/Neg07.java + test/tools/javac/defaultMethods/Neg07.out + test/tools/javac/defaultMethods/Neg08.java + test/tools/javac/defaultMethods/Neg08.out + test/tools/javac/defaultMethods/Neg09.java + test/tools/javac/defaultMethods/Neg09.out + test/tools/javac/defaultMethods/Neg10.java + test/tools/javac/defaultMethods/Neg10.out + test/tools/javac/defaultMethods/Neg11.java + test/tools/javac/defaultMethods/Neg11.out + test/tools/javac/defaultMethods/Neg12.java + test/tools/javac/defaultMethods/Neg12.out + test/tools/javac/defaultMethods/Neg13.java + test/tools/javac/defaultMethods/Neg13.out + test/tools/javac/defaultMethods/Neg14.java + test/tools/javac/defaultMethods/Neg14.out + test/tools/javac/defaultMethods/Neg15.java + test/tools/javac/defaultMethods/Neg15.out + test/tools/javac/defaultMethods/Neg16.java + test/tools/javac/defaultMethods/Neg16.out + test/tools/javac/defaultMethods/Pos01.java + test/tools/javac/defaultMethods/Pos02.java + test/tools/javac/defaultMethods/Pos04.java + test/tools/javac/defaultMethods/Pos05.java + test/tools/javac/defaultMethods/Pos06.java + test/tools/javac/defaultMethods/Pos07.java + test/tools/javac/defaultMethods/Pos08.java + test/tools/javac/defaultMethods/Pos10.java + test/tools/javac/defaultMethods/Pos11.java + test/tools/javac/defaultMethods/Pos12.java + test/tools/javac/defaultMethods/Pos13.java + test/tools/javac/defaultMethods/Pos14.java + test/tools/javac/defaultMethods/Pos15.java + test/tools/javac/defaultMethods/Pos16.java + test/tools/javac/defaultMethods/TestDefaultBody.java + test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java + test/tools/javac/defaultMethods/crossCompile/Clinit.java + test/tools/javac/defaultMethods/crossCompile/CrossCompile.java + test/tools/javac/defaultMethods/fd/FDTest.java + test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java + test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java + test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java + test/tools/javac/defaultMethods/fd/shapegen/Rule.java + test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java + test/tools/javac/defaultMethods/fd/shapegen/TTNode.java + test/tools/javac/defaultMethods/fd/shapegen/TTParser.java + test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/defaultMethods/separate/Separate.java + test/tools/javac/defaultMethods/separate/pkg1/A.java + test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java + test/tools/javac/diags/examples/DefaultOverridesObjectMember.java + test/tools/javac/diags/examples/OverriddenDefault.java + test/tools/javac/diags/examples/RedundantSupertype.java + test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java + test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: dbc94b8363dd Author: mcimadamore Date: 2012-11-04 11:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dbc94b8363dd 8000931: Cleanup Resolve.java Summary: Unify all method resolution routines Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/resolve/tests/AmbiguityPrecedence.java Changeset: 9bce0c73583d Author: ksrini Date: 2012-10-31 10:21 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9bce0c73583d 8001112: Make -target 8 in javac generate version 52.0 classfile Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh Changeset: 9b85813d2262 Author: mcimadamore Date: 2012-11-06 14:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9b85813d2262 8002286: Regression: Fix for 8000931 causes a JCK test failure Summary: Wrong type used as 'site' in Resolve.resolveMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/8002286/T8002286.java + test/tools/javac/8002286/T8002286.out Changeset: 8abc56be3131 Author: jjg Date: 2012-11-06 14:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8abc56be3131 8000612: Discrepancy between resources provided in javadoc resource files and resources required by code Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/tools/javac/diags/CheckResourceKeys.java + test/tools/javadoc/CheckResourceKeys.java Changeset: 55a007aaf63d Author: jjg Date: 2012-11-06 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/55a007aaf63d 7198690: missing compiler message Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: 6dc8616cea9b Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6dc8616cea9b Merge Changeset: 19d6ba779759 Author: vromero Date: 2012-11-05 16:26 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/19d6ba779759 8000484: Bad error recovery when 'catch' without 'try' is found Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/incompleteStatements/T8000484.java + test/tools/javac/incompleteStatements/T8000484.out Changeset: 2986e7052952 Author: jjg Date: 2012-11-07 17:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2986e7052952 8002157: Write combo compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java Changeset: a1dc543483fc Author: jjg Date: 2012-11-07 17:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a1dc543483fc 8003134: CheckResourceKeys issues Reviewed-by: jjh, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javadoc/CheckResourceKeys.java Changeset: 5f2faba89cac Author: lana Date: 2012-11-09 14:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5f2faba89cac Merge Changeset: 790182264621 Author: mcimadamore Date: 2012-11-14 12:12 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/790182264621 merge with jdk8-b65 ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6799605/T6799605.out + test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java + test/tools/javac/defaultMethods/Neg01.java + test/tools/javac/defaultMethods/Neg02.java + test/tools/javac/defaultMethods/Neg03.java + test/tools/javac/defaultMethods/Neg04.java + test/tools/javac/defaultMethods/Neg05.java + test/tools/javac/defaultMethods/Neg06.java + test/tools/javac/defaultMethods/Neg07.java + test/tools/javac/defaultMethods/Neg08.java + test/tools/javac/defaultMethods/Neg09.java + test/tools/javac/defaultMethods/Neg10.java + test/tools/javac/defaultMethods/Neg11.java + test/tools/javac/defaultMethods/Neg12.java + test/tools/javac/defaultMethods/Neg12.out + test/tools/javac/defaultMethods/Neg13.java + test/tools/javac/defaultMethods/Neg14.java + test/tools/javac/defaultMethods/Neg15.java + test/tools/javac/defaultMethods/Neg16.java + test/tools/javac/defaultMethods/Pos01.java + test/tools/javac/defaultMethods/Pos02.java + test/tools/javac/defaultMethods/Pos04.java + test/tools/javac/defaultMethods/Pos05.java + test/tools/javac/defaultMethods/Pos06.java + test/tools/javac/defaultMethods/Pos07.java + test/tools/javac/defaultMethods/Pos08.java + test/tools/javac/defaultMethods/Pos10.java + test/tools/javac/defaultMethods/Pos11.java + test/tools/javac/defaultMethods/Pos12.java + test/tools/javac/defaultMethods/Pos13.java + test/tools/javac/defaultMethods/Pos14.java + test/tools/javac/defaultMethods/Pos15.java + test/tools/javac/defaultMethods/Pos16.java + test/tools/javac/defaultMethods/TestDefaultBody.java + test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java + test/tools/javac/defaultMethods/fd/FDTest.java + test/tools/javac/defaultMethods/separate/Separate.java + test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/defender/ClassReaderTest/ClassReaderTest.java - test/tools/javac/defender/ClassReaderTest/pkg/Foo.java - test/tools/javac/defender/Neg01.java - test/tools/javac/defender/Neg01.out - test/tools/javac/defender/Neg02.java - test/tools/javac/defender/Neg02.out - test/tools/javac/defender/Neg03.java - test/tools/javac/defender/Neg03.out - test/tools/javac/defender/Neg04.java - test/tools/javac/defender/Neg04.out - test/tools/javac/defender/Neg05.java - test/tools/javac/defender/Neg05.out - test/tools/javac/defender/Neg06.java - test/tools/javac/defender/Neg06.out - test/tools/javac/defender/Neg07.java - test/tools/javac/defender/Neg07.out - test/tools/javac/defender/Neg08.java - test/tools/javac/defender/Neg08.out - test/tools/javac/defender/Neg09.java - test/tools/javac/defender/Neg09.out - test/tools/javac/defender/Neg10.java - test/tools/javac/defender/Neg10.out - test/tools/javac/defender/Neg11.java - test/tools/javac/defender/Neg11.out - test/tools/javac/defender/Neg12.java - test/tools/javac/defender/Neg12.out - test/tools/javac/defender/Neg13.java - test/tools/javac/defender/Neg13.out - test/tools/javac/defender/Neg14.java - test/tools/javac/defender/Neg14.out - test/tools/javac/defender/Pos01.java - test/tools/javac/defender/Pos02.java - test/tools/javac/defender/Pos04.java - test/tools/javac/defender/Pos05.java - test/tools/javac/defender/Pos06.java - test/tools/javac/defender/Pos07.java - test/tools/javac/defender/Pos08.java - test/tools/javac/defender/Pos09.java - test/tools/javac/defender/Pos10.java - test/tools/javac/defender/Pos11.java - test/tools/javac/defender/Pos12.java - test/tools/javac/defender/Pos13.java - test/tools/javac/defender/Pos14.java - test/tools/javac/defender/Pos15.java - test/tools/javac/defender/Pos16.java - test/tools/javac/defender/TestInlinedDefenderBody.java - test/tools/javac/defender/TestNoBridgeOnDefenders.java - test/tools/javac/defender/crossCompile/Clinit.java - test/tools/javac/defender/crossCompile/CrossCompile.java - test/tools/javac/defender/fd/FDTest.java - test/tools/javac/defender/fd/shapegen/ClassCase.java - test/tools/javac/defender/fd/shapegen/Hierarchy.java - test/tools/javac/defender/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defender/fd/shapegen/Rule.java - test/tools/javac/defender/fd/shapegen/RuleGroup.java - test/tools/javac/defender/fd/shapegen/TTNode.java - test/tools/javac/defender/fd/shapegen/TTParser.java - test/tools/javac/defender/fd/shapegen/TTShape.java - test/tools/javac/defender/pkg1/A.java - test/tools/javac/defender/super/TestDefenderSuperCall.java - test/tools/javac/defender/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantAccessInnerClsConstr.java ! test/tools/javac/diags/examples/CantApplySymbolFragment.java ! test/tools/javac/diags/examples/CantApplySymbolsFragment.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java ! test/tools/javac/diags/examples/CatchWithoutTry.java ! test/tools/javac/diags/examples/CyclicInference.java + test/tools/javac/diags/examples/DefaultOverridesObjectMember.java ! test/tools/javac/diags/examples/IncompatibleAbstracts.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/IncompatibleTypesInConditional.java ! test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java ! test/tools/javac/diags/examples/MissingReturnValueFragment.java ! test/tools/javac/diags/examples/NoAbstracts.java ! test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotAFunctionalIntf.java ! test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java + test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/diags/examples/PotentialLambdaFound.java + test/tools/javac/diags/examples/RedundantSupertype.java ! test/tools/javac/diags/examples/RefAmbiguousFragment.java + test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java + test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/diags/examples/UnexpectedMref.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/generics/7022054/T7022054pos2.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/7086601/T7086601a.out ! test/tools/javac/lambda/ErroneousArg.out ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType44.out ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 3ae3cbc02852 Author: mcimadamore Date: 2012-11-15 15:28 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3ae3cbc02852 Fix issues post jdk8-b65 merge: *) problems in check logic for qualified super calls *) new check for default methods in ClassReader doesn't work well with ct.sym *) Behavior of target-typing w/ conditionals causes source incompatibilities *) Behavior of target-typing in throw statements causes source incompatibilities *) Types.directSuperInterfaces should use symbols, not types *) Temporarily revert classfile version changes to make build happy ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh From paul.sandoz at oracle.com Thu Nov 15 07:37:19 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 15 Nov 2012 15:37:19 +0000 Subject: hg: lambda/lambda/jdk: applyInt should be used. Message-ID: <20121115153730.AC135479B0@hg.openjdk.java.net> Changeset: 4cae7924b7ef Author: psandoz Date: 2012-11-15 16:34 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4cae7924b7ef applyInt should be used. ! src/share/classes/java/util/streams/primitives/IntSpliterator.java From Eric.Caspole at amd.com Thu Nov 15 07:55:54 2012 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 15 Nov 2012 15:55:54 +0000 Subject: Lambda does not compile against JDK8 binary snapshot as boot JDK Message-ID: Hi lambda people, I seem to have found a problem when using the last week's lamdba binary snapshot as the boot JDK for the build. The build works fine if the boot JDK is 7u9. I don't think I ever tried this combination before. Looks like there is a new java.util.Mapping in 8. So I think the guilty thing is use of java.util.* in src/share/classes/com/sun/tools/javac/code/Types.java? 26 package com.sun.tools.javac.code; 27 28 import java.lang.ref.SoftReference; 29 import java.util.*; 30 Regards, Eric Here is my build output: ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ java -version openjdk version "1.8.0-ea" OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) ==================================================== A new configuration has been successfully created in /home/ecaspole/Documents/121115/lambda/build/linux-x86_64-normal-server-release using default settings. Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 * Boot JDK: /opt/jdk1.8.0 Build performance summary: * Cores to use: 4 * Memory limit: 7986 MB * ccache status: not installed (consider installing) ... ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ make images Building OpenJDK for target 'images' in configuration 'linux-x86_64-normal-server-release' ######################################################################## ######################################################################## ##### Entering langtools for target(s) all ##### ######################################################################## Compiling 2 files for BUILD_TOOLS /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous private final Mapping lowerBoundMapping = new Mapping("lowerBound") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous private Mapping elemTypeFun = new Mapping ("elemTypeFun") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous private Mapping erasureFun = new Mapping ("erasure") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous private Mapping erasureRecFun = new Mapping ("erasureRecursive") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous static private Mapping newInstanceFun = new Mapping("newInstanceFun") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous private final Mapping lowerBoundMapping = new Mapping("lowerBound") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous private Mapping elemTypeFun = new Mapping ("elemTypeFun") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous private Mapping erasureFun = new Mapping ("erasure") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous private Mapping erasureRecFun = new Mapping ("erasureRecursive") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous static private Mapping newInstanceFun = new Mapping("newInstanceFun") { ^ both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match 10 errors make[1]: *** No rule to make target `all', needed by `default'. Stop. make: *** [langtools-only] Error 2 From forax at univ-mlv.fr Thu Nov 15 08:05:48 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 Nov 2012 17:05:48 +0100 Subject: Lambda does not compile against JDK8 binary snapshot as boot JDK In-Reply-To: References: Message-ID: <50A512DC.4000205@univ-mlv.fr> On 11/15/2012 04:55 PM, Caspole, Eric wrote: > Hi lambda people, > I seem to have found a problem when using the last week's lamdba binary snapshot as the boot JDK for the build. The build works fine if the boot JDK is 7u9. I don't think I ever tried this combination before. > > Looks like there is a new java.util.Mapping in 8. So I think the guilty thing is use of java.util.* in src/share/classes/com/sun/tools/javac/code/Types.java? > > 26 package com.sun.tools.javac.code; > 27 > 28 import java.lang.ref.SoftReference; > 29 import java.util.*; > 30 > > Regards, > Eric Classical import * bug. BTW, java.util.Mapping was removed very recently, so it should work again. R?mi > > Here is my build output: > > ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ java -version > openjdk version "1.8.0-ea" > OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) > OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) > > ==================================================== > A new configuration has been successfully created in > /home/ecaspole/Documents/121115/lambda/build/linux-x86_64-normal-server-release > using default settings. > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 > * Boot JDK: /opt/jdk1.8.0 > > Build performance summary: > * Cores to use: 4 > * Memory limit: 7986 MB > * ccache status: not installed (consider installing) > > ... > > ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ make images > Building OpenJDK for target 'images' in configuration 'linux-x86_64-normal-server-release' > > > ######################################################################## > ######################################################################## > ##### Entering langtools for target(s) all ##### > ######################################################################## > > Compiling 2 files for BUILD_TOOLS > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous > private final Mapping lowerBoundMapping = new Mapping("lowerBound") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous > private Mapping elemTypeFun = new Mapping ("elemTypeFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous > private Mapping erasureFun = new Mapping ("erasure") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous > private Mapping erasureRecFun = new Mapping ("erasureRecursive") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous > static private Mapping newInstanceFun = new Mapping("newInstanceFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous > private final Mapping lowerBoundMapping = new Mapping("lowerBound") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous > private Mapping elemTypeFun = new Mapping ("elemTypeFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous > private Mapping erasureFun = new Mapping ("erasure") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous > private Mapping erasureRecFun = new Mapping ("erasureRecursive") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous > static private Mapping newInstanceFun = new Mapping("newInstanceFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > 10 errors > make[1]: *** No rule to make target `all', needed by `default'. Stop. > make: *** [langtools-only] Error 2 > > From maurizio.cimadamore at oracle.com Thu Nov 15 08:09:48 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 Nov 2012 16:09:48 +0000 Subject: Lambda does not compile against JDK8 binary snapshot as boot JDK In-Reply-To: References: Message-ID: <50A513CC.5050000@oracle.com> On 15/11/12 15:55, Caspole, Eric wrote: > Hi lambda people, > I seem to have found a problem when using the last week's lamdba binary snapshot as the boot JDK for the build. The build works fine if the boot JDK is 7u9. I don't think I ever tried this combination before. > > Looks like there is a new java.util.Mapping in 8. So I think the guilty thing is use of java.util.* in src/share/classes/com/sun/tools/javac/code/Types.java? > > 26 package com.sun.tools.javac.code; > 27 > 28 import java.lang.ref.SoftReference; > 29 import java.util.*; > 30 Ouch - I agree the import should be modified. Maurizio > > Regards, > Eric > > Here is my build output: > > ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ java -version > openjdk version "1.8.0-ea" > OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) > OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) > > ==================================================== > A new configuration has been successfully created in > /home/ecaspole/Documents/121115/lambda/build/linux-x86_64-normal-server-release > using default settings. > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 > * Boot JDK: /opt/jdk1.8.0 > > Build performance summary: > * Cores to use: 4 > * Memory limit: 7986 MB > * ccache status: not installed (consider installing) > > ... > > ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ make images > Building OpenJDK for target 'images' in configuration 'linux-x86_64-normal-server-release' > > > ######################################################################## > ######################################################################## > ##### Entering langtools for target(s) all ##### > ######################################################################## > > Compiling 2 files for BUILD_TOOLS > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous > private final Mapping lowerBoundMapping = new Mapping("lowerBound") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous > private Mapping elemTypeFun = new Mapping ("elemTypeFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous > private Mapping erasureFun = new Mapping ("erasure") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous > private Mapping erasureRecFun = new Mapping ("erasureRecursive") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous > static private Mapping newInstanceFun = new Mapping("newInstanceFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous > private final Mapping lowerBoundMapping = new Mapping("lowerBound") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous > private Mapping elemTypeFun = new Mapping ("elemTypeFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous > private Mapping erasureFun = new Mapping ("erasure") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous > private Mapping erasureRecFun = new Mapping ("erasureRecursive") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous > static private Mapping newInstanceFun = new Mapping("newInstanceFun") { > ^ > both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match > 10 errors > make[1]: *** No rule to make target `all', needed by `default'. Stop. > make: *** [langtools-only] Error 2 > > From paul.sandoz at oracle.com Thu Nov 15 08:37:20 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 15 Nov 2012 16:37:20 +0000 Subject: hg: lambda/lambda/jdk: change Stream.mapToInt to Stream.map Message-ID: <20121115163733.75AA2479B1@hg.openjdk.java.net> Changeset: 5cdf42e26646 Author: psandoz Date: 2012-11-15 17:35 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5cdf42e26646 change Stream.mapToInt to Stream.map ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Stream.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/InfiniteStreamWithLimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java From paul.sandoz at oracle.com Thu Nov 15 08:56:06 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 15 Nov 2012 16:56:06 +0000 Subject: hg: lambda/lambda/jdk: - OpTestCase.TestData generic to the input stream type. Message-ID: <20121115165619.405ED479B2@hg.openjdk.java.net> Changeset: e80b94da6538 Author: psandoz Date: 2012-11-15 17:55 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e80b94da6538 - OpTestCase.TestData generic to the input stream type. - exercising ops generic to the input and output stream. - expected result can be declared to override inducing the expected result. ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java From marcus at thiesen.org Thu Nov 15 09:11:48 2012 From: marcus at thiesen.org (Marcus Thiesen) Date: Thu, 15 Nov 2012 18:11:48 +0100 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <50A4A8B1.5000904@oracle.com> References: <50A4A8B1.5000904@oracle.com> Message-ID: Hey List, sorry, I haven't followed the whole Stream discussion and without publicliy available JavaDocs (are there?) I'm currently trying to figure out what this comment means, because without all that background I read the code as annotated: 2012/11/15 Dmitry Bessonov > While playing with method Sream.limit(int) using a mini-code like > > final Stream s = Arrays.asStream(1, 2, 3, 4, 5); > Give me a "Stream" view of the Array int[] 1, 2, 3, 4, 5. > final Stream to3 = s.limit(3); > Give me a Stream view of s limitted to 3 values. > final Stream to4 = s.limit(4); > Give me a Stream view of s limitted to 4 values. > > have to admit that there's no unambiguous answer > to the question of contents of streams "to3" and "to4". > It depends on which of the streams is consumed first. > > My best guess would be to3 = [ 1, 2, 3 ] and to4 = [ 1, 2, 3, 4 ]. Given my naive understanding of the above code the comment does not make sense. The only way the above comment makes sense is that we are not talking of (somehow immutable) views here but that those operations mutate the backing array on read time of the resulting stream. Am I right? Cheers, Marcus -- Marcus Thiesen :: www.thiesen.org :: @mthiesen :: 0173 / 28 01 82 4 From mike.duigou at oracle.com Thu Nov 15 09:21:34 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 15 Nov 2012 09:21:34 -0800 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: References: <50A4A8B1.5000904@oracle.com> Message-ID: <1B984920-F884-4753-88F1-79493F162FE1@oracle.com> On Nov 15 2012, at 09:11 , Marcus Thiesen wrote: > publicliy available JavaDocs (are there?) Javadocs are available on the lambda download page at: http://jdk8.java.net/lambda/ From brian.goetz at oracle.com Thu Nov 15 09:22:14 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 12:22:14 -0500 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: References: <50A4A8B1.5000904@oracle.com> Message-ID: <50A524C6.1010802@oracle.com> The best way to think about it is that a Stream is more like an Iterator than a data structure. There is some abstract source of data somewhere (it might be in a data structure, or might be generated from a function, or read from a network), and a series of transformations applied to the data between the source and the consumer. Streams can additionally execute using parallelism, if requested. Stream constructs like: Stream s = people.stream() .filter(p -> p.getLastName().equals("Smith"))) do not do any filtering on construction. It simply says "there's a stream source, the collection 'people', and when you consume from the stream s, you'll get the results of filtering the source values." The confusion in Dmitry's example is akin to multiple activities reading from the same IO channel -- they might interfere with each other over who gets the next value, and any buffering that any consumer does may confuse other consumers. On 11/15/2012 12:11 PM, Marcus Thiesen wrote: > Hey List, > > sorry, I haven't followed the whole Stream discussion and without publicliy > available JavaDocs (are there?) I'm currently trying to figure out what > this comment means, because without all that background I read the code as > annotated: > > 2012/11/15 Dmitry Bessonov > >> While playing with method Sream.limit(int) using a mini-code like >> >> final Stream s = Arrays.asStream(1, 2, 3, 4, 5); >> > > Give me a "Stream" view of the Array int[] 1, 2, 3, 4, 5. > > > >> final Stream to3 = s.limit(3); >> > > Give me a Stream view of s limitted to 3 values. > > >> final Stream to4 = s.limit(4); >> > > Give me a Stream view of s limitted to 4 values. > > >> >> have to admit that there's no unambiguous answer >> to the question of contents of streams "to3" and "to4". >> It depends on which of the streams is consumed first. >> >> > My best guess would be to3 = [ 1, 2, 3 ] and to4 = [ 1, 2, 3, 4 ]. > > Given my naive understanding of the above code the comment does not make > sense. The only way the above comment makes sense is that we are not > talking of (somehow immutable) views here but that those operations mutate > the backing array on read time of the resulting stream. Am I right? > > Cheers, > Marcus > > > > From forax at univ-mlv.fr Thu Nov 15 09:36:22 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 Nov 2012 18:36:22 +0100 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <50A524C6.1010802@oracle.com> References: <50A4A8B1.5000904@oracle.com> <50A524C6.1010802@oracle.com> Message-ID: <50A52816.8020004@univ-mlv.fr> On 11/15/2012 06:22 PM, Brian Goetz wrote: > The best way to think about it is that a Stream is more like an Iterator > than a data structure. There is some abstract source of data somewhere > (it might be in a data structure, or might be generated from a function, > or read from a network), and a series of transformations applied to the > data between the source and the consumer. Streams can additionally > execute using parallelism, if requested. > > Stream constructs like: > > Stream s = people.stream() > .filter(p -> p.getLastName().equals("Smith"))) > > do not do any filtering on construction. It simply says "there's a > stream source, the collection 'people', and when you consume from the > stream s, you'll get the results of filtering the source values." > > The confusion in Dmitry's example is akin to multiple activities reading > from the same IO channel -- they might interfere with each other over > who gets the next value, and any buffering that any consumer does may > confuse other consumers. Maybe the implementation should protect users to use two aliases of a non-replayable stream. Using the example of Dmitry, if the stream is an IO channel, the second call to limit() or to any method of 's' should throw an IllegalStateException. R?mi > > > > On 11/15/2012 12:11 PM, Marcus Thiesen wrote: >> Hey List, >> >> sorry, I haven't followed the whole Stream discussion and without publicliy >> available JavaDocs (are there?) I'm currently trying to figure out what >> this comment means, because without all that background I read the code as >> annotated: >> >> 2012/11/15 Dmitry Bessonov >> >>> While playing with method Sream.limit(int) using a mini-code like >>> >>> final Stream s = Arrays.asStream(1, 2, 3, 4, 5); >>> >> Give me a "Stream" view of the Array int[] 1, 2, 3, 4, 5. >> >> >> >>> final Stream to3 = s.limit(3); >>> >> Give me a Stream view of s limitted to 3 values. >> >> >>> final Stream to4 = s.limit(4); >>> >> Give me a Stream view of s limitted to 4 values. >> >> >>> have to admit that there's no unambiguous answer >>> to the question of contents of streams "to3" and "to4". >>> It depends on which of the streams is consumed first. >>> >>> >> My best guess would be to3 = [ 1, 2, 3 ] and to4 = [ 1, 2, 3, 4 ]. >> >> Given my naive understanding of the above code the comment does not make >> sense. The only way the above comment makes sense is that we are not >> talking of (somehow immutable) views here but that those operations mutate >> the backing array on read time of the resulting stream. Am I right? >> >> Cheers, >> Marcus >> >> >> >> From spullara at gmail.com Thu Nov 15 10:10:59 2012 From: spullara at gmail.com (Sam Pullara) Date: Thu, 15 Nov 2012 10:10:59 -0800 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <50A52816.8020004@univ-mlv.fr> References: <50A4A8B1.5000904@oracle.com> <50A524C6.1010802@oracle.com> <50A52816.8020004@univ-mlv.fr> Message-ID: <20A6B743-CBA6-4FE1-BF53-068B4A5379D9@sampullara> This was my thinking when I read the example. Not sure if that is practical but it might reduce errors such as the one described. Sam On Nov 15, 2012, at 9:36 AM, Remi Forax wrote: > On 11/15/2012 06:22 PM, Brian Goetz wrote: >> The best way to think about it is that a Stream is more like an Iterator >> than a data structure. There is some abstract source of data somewhere >> (it might be in a data structure, or might be generated from a function, >> or read from a network), and a series of transformations applied to the >> data between the source and the consumer. Streams can additionally >> execute using parallelism, if requested. >> >> Stream constructs like: >> >> Stream s = people.stream() >> .filter(p -> p.getLastName().equals("Smith"))) >> >> do not do any filtering on construction. It simply says "there's a >> stream source, the collection 'people', and when you consume from the >> stream s, you'll get the results of filtering the source values." >> >> The confusion in Dmitry's example is akin to multiple activities reading >> from the same IO channel -- they might interfere with each other over >> who gets the next value, and any buffering that any consumer does may >> confuse other consumers. > > Maybe the implementation should protect users to use two aliases of a > non-replayable stream. > Using the example of Dmitry, if the stream is an IO channel, the second > call to limit() or to any method of 's' should throw an > IllegalStateException. > > R?mi > >> >> >> >> On 11/15/2012 12:11 PM, Marcus Thiesen wrote: >>> Hey List, >>> >>> sorry, I haven't followed the whole Stream discussion and without publicliy >>> available JavaDocs (are there?) I'm currently trying to figure out what >>> this comment means, because without all that background I read the code as >>> annotated: >>> >>> 2012/11/15 Dmitry Bessonov >>> >>>> While playing with method Sream.limit(int) using a mini-code like >>>> >>>> final Stream s = Arrays.asStream(1, 2, 3, 4, 5); >>>> >>> Give me a "Stream" view of the Array int[] 1, 2, 3, 4, 5. >>> >>> >>> >>>> final Stream to3 = s.limit(3); >>>> >>> Give me a Stream view of s limitted to 3 values. >>> >>> >>>> final Stream to4 = s.limit(4); >>>> >>> Give me a Stream view of s limitted to 4 values. >>> >>> >>>> have to admit that there's no unambiguous answer >>>> to the question of contents of streams "to3" and "to4". >>>> It depends on which of the streams is consumed first. >>>> >>>> >>> My best guess would be to3 = [ 1, 2, 3 ] and to4 = [ 1, 2, 3, 4 ]. >>> >>> Given my naive understanding of the above code the comment does not make >>> sense. The only way the above comment makes sense is that we are not >>> talking of (somehow immutable) views here but that those operations mutate >>> the backing array on read time of the resulting stream. Am I right? >>> >>> Cheers, >>> Marcus >>> >>> >>> >>> > > From zhong.j.yu at gmail.com Thu Nov 15 10:22:33 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 15 Nov 2012 12:22:33 -0600 Subject: Stream.limit() - puzzler/bug/feature In-Reply-To: <20A6B743-CBA6-4FE1-BF53-068B4A5379D9@sampullara> References: <50A4A8B1.5000904@oracle.com> <50A524C6.1010802@oracle.com> <50A52816.8020004@univ-mlv.fr> <20A6B743-CBA6-4FE1-BF53-068B4A5379D9@sampullara> Message-ID: People don't have this problem with InputStream, so it's probably not a big deal. On Thu, Nov 15, 2012 at 12:10 PM, Sam Pullara wrote: > This was my thinking when I read the example. Not sure if that is practical but it might reduce errors such as the one described. > > Sam > > On Nov 15, 2012, at 9:36 AM, Remi Forax wrote: > >> On 11/15/2012 06:22 PM, Brian Goetz wrote: >>> The best way to think about it is that a Stream is more like an Iterator >>> than a data structure. There is some abstract source of data somewhere >>> (it might be in a data structure, or might be generated from a function, >>> or read from a network), and a series of transformations applied to the >>> data between the source and the consumer. Streams can additionally >>> execute using parallelism, if requested. >>> >>> Stream constructs like: >>> >>> Stream s = people.stream() >>> .filter(p -> p.getLastName().equals("Smith"))) >>> >>> do not do any filtering on construction. It simply says "there's a >>> stream source, the collection 'people', and when you consume from the >>> stream s, you'll get the results of filtering the source values." >>> >>> The confusion in Dmitry's example is akin to multiple activities reading >>> from the same IO channel -- they might interfere with each other over >>> who gets the next value, and any buffering that any consumer does may >>> confuse other consumers. >> >> Maybe the implementation should protect users to use two aliases of a >> non-replayable stream. >> Using the example of Dmitry, if the stream is an IO channel, the second >> call to limit() or to any method of 's' should throw an >> IllegalStateException. >> >> R?mi >> >>> >>> >>> >>> On 11/15/2012 12:11 PM, Marcus Thiesen wrote: >>>> Hey List, >>>> >>>> sorry, I haven't followed the whole Stream discussion and without publicliy >>>> available JavaDocs (are there?) I'm currently trying to figure out what >>>> this comment means, because without all that background I read the code as >>>> annotated: >>>> >>>> 2012/11/15 Dmitry Bessonov >>>> >>>>> While playing with method Sream.limit(int) using a mini-code like >>>>> >>>>> final Stream s = Arrays.asStream(1, 2, 3, 4, 5); >>>>> >>>> Give me a "Stream" view of the Array int[] 1, 2, 3, 4, 5. >>>> >>>> >>>> >>>>> final Stream to3 = s.limit(3); >>>>> >>>> Give me a Stream view of s limitted to 3 values. >>>> >>>> >>>>> final Stream to4 = s.limit(4); >>>>> >>>> Give me a Stream view of s limitted to 4 values. >>>> >>>> >>>>> have to admit that there's no unambiguous answer >>>>> to the question of contents of streams "to3" and "to4". >>>>> It depends on which of the streams is consumed first. >>>>> >>>>> >>>> My best guess would be to3 = [ 1, 2, 3 ] and to4 = [ 1, 2, 3, 4 ]. >>>> >>>> Given my naive understanding of the above code the comment does not make >>>> sense. The only way the above comment makes sense is that we are not >>>> talking of (somehow immutable) views here but that those operations mutate >>>> the backing array on read time of the resulting stream. Am I right? >>>> >>>> Cheers, >>>> Marcus >>>> >>>> >>>> >>>> >> >> > > From brian.goetz at oracle.com Thu Nov 15 10:31:32 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 13:31:32 -0500 Subject: Updated State of the Collections Message-ID: <50A53504.2030407@oracle.com> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html From brian.goetz at oracle.com Thu Nov 15 10:36:35 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 18:36:35 +0000 Subject: hg: lambda/lambda/jdk: Parallel version of ReduceByOp Message-ID: <20121115183646.D7B20479B6@hg.openjdk.java.net> Changeset: ae4e5994cbb4 Author: briangoetz Date: 2012-11-15 13:36 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ae4e5994cbb4 Parallel version of ReduceByOp ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/ops/GroupByOp.java ! src/share/classes/java/util/streams/ops/ReduceByOp.java ! src/share/classes/java/util/streams/ops/SliceOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java From mike.duigou at oracle.com Thu Nov 15 10:55:42 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 15 Nov 2012 18:55:42 +0000 Subject: hg: lambda/lambda/jdk: rename java.util.functions -> java.util.function Message-ID: <20121115185553.8099D479B8@hg.openjdk.java.net> Changeset: ef5e16bf1045 Author: mduigou Date: 2012-11-15 10:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ef5e16bf1045 rename java.util.functions -> java.util.function ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java + src/share/classes/java/util/function/BiBlock.java + src/share/classes/java/util/function/BiMapper.java + src/share/classes/java/util/function/BiPredicate.java + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/Combiner.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleMapper.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Factory.java + src/share/classes/java/util/function/FlatMapper.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntMapper.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongMapper.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Mapper.java + src/share/classes/java/util/function/Mappers.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Predicates.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package.html - src/share/classes/java/util/functions/BiBlock.java - src/share/classes/java/util/functions/BiMapper.java - src/share/classes/java/util/functions/BiPredicate.java - src/share/classes/java/util/functions/BinaryOperator.java - src/share/classes/java/util/functions/Block.java - src/share/classes/java/util/functions/Combiner.java - src/share/classes/java/util/functions/DoubleBinaryOperator.java - src/share/classes/java/util/functions/DoubleMapper.java - src/share/classes/java/util/functions/DoubleUnaryOperator.java - src/share/classes/java/util/functions/Factory.java - src/share/classes/java/util/functions/FlatMapper.java - src/share/classes/java/util/functions/IntBinaryOperator.java - src/share/classes/java/util/functions/IntMapper.java - src/share/classes/java/util/functions/IntUnaryOperator.java - src/share/classes/java/util/functions/LongBinaryOperator.java - src/share/classes/java/util/functions/LongMapper.java - src/share/classes/java/util/functions/LongUnaryOperator.java - src/share/classes/java/util/functions/Mapper.java - src/share/classes/java/util/functions/Mappers.java - src/share/classes/java/util/functions/Predicate.java - src/share/classes/java/util/functions/Predicates.java - src/share/classes/java/util/functions/UnaryOperator.java - src/share/classes/java/util/functions/package.html ! src/share/classes/java/util/streams/ReferencePipeline.java ! src/share/classes/java/util/streams/Sink.java ! src/share/classes/java/util/streams/Spliterator.java ! src/share/classes/java/util/streams/Stream.java ! src/share/classes/java/util/streams/Streams.java ! src/share/classes/java/util/streams/ops/CumulateOp.java ! src/share/classes/java/util/streams/ops/FilterOp.java ! src/share/classes/java/util/streams/ops/FlatMapOp.java ! src/share/classes/java/util/streams/ops/FoldOp.java ! src/share/classes/java/util/streams/ops/ForEachOp.java ! src/share/classes/java/util/streams/ops/GroupByOp.java ! src/share/classes/java/util/streams/ops/MapOp.java ! src/share/classes/java/util/streams/ops/MatchOp.java ! src/share/classes/java/util/streams/ops/NodeBuilder.java ! src/share/classes/java/util/streams/ops/Nodes.java ! src/share/classes/java/util/streams/ops/OpUtils.java ! src/share/classes/java/util/streams/ops/ReduceByOp.java ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java ! src/share/classes/java/util/streams/ops/TeeOp.java ! src/share/classes/java/util/streams/primitives/IntBlock.java ! src/share/classes/java/util/streams/primitives/IntFactory.java ! src/share/classes/java/util/streams/primitives/IntIterable.java ! src/share/classes/java/util/streams/primitives/IntIterator.java ! src/share/classes/java/util/streams/primitives/IntNodeBuilder.java ! src/share/classes/java/util/streams/primitives/IntNodes.java ! src/share/classes/java/util/streams/primitives/IntPipeline.java ! src/share/classes/java/util/streams/primitives/IntSpliterator.java ! src/share/classes/java/util/streams/primitives/IntStream.java ! src/share/classes/java/util/streams/primitives/IntUnaryOperator.java ! src/share/classes/java/util/streams/primitives/Primitives.java ! src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalFactoryTest.java ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalTest.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/concurrent/AtomicReferenceTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/DoubleUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/IntUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/LongUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/PredicatesTest.java ! test-ng/tests/org/openjdk/tests/java/util/functions/UnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest2.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java ! test/java/util/Collection/MOAT.java From mike.duigou at oracle.com Thu Nov 15 10:56:51 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 15 Nov 2012 18:56:51 +0000 Subject: hg: lambda/lambda: rename of java.util.functions to java.util.function Message-ID: <20121115185651.CDC43479B9@hg.openjdk.java.net> Changeset: dfca3559fdc4 Author: mduigou Date: 2012-11-15 10:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/dfca3559fdc4 rename of java.util.functions to java.util.function ! common/makefiles/javadoc/CORE_PKGS.gmk From pbenedict at apache.org Thu Nov 15 11:13:03 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 15 Nov 2012 13:13:03 -0600 Subject: hg: lambda/lambda/jdk: rename java.util.functions -> java.util.function In-Reply-To: <20121115185553.8099D479B8@hg.openjdk.java.net> References: <20121115185553.8099D479B8@hg.openjdk.java.net> Message-ID: Mike, why is the singular preferred? I am curious on the reasoning. Some other packages use plural. For example, "util.streams", "util.prefs", "nio.channels". Paul On Thu, Nov 15, 2012 at 12:55 PM, wrote: > Changeset: ef5e16bf1045 > Author: mduigou > Date: 2012-11-15 10:55 -0800 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ef5e16bf1045 > > rename java.util.functions -> java.util.function > > ! make/docs/CORE_PKGS.gmk > ! make/java/java/Makefile > ! makefiles/docs/CORE_PKGS.gmk > ! src/share/classes/java/lang/CharSequence.java > ! src/share/classes/java/lang/Iterable.java > ! src/share/classes/java/lang/ThreadLocal.java > ! src/share/classes/java/util/Collection.java > ! src/share/classes/java/util/Comparators.java > ! src/share/classes/java/util/Iterables.java > ! src/share/classes/java/util/Iterator.java > ! src/share/classes/java/util/Iterators.java > ! src/share/classes/java/util/Map.java > ! src/share/classes/java/util/Optional.java > ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java > ! > src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java > ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java > ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java > ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java > ! > src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java > + src/share/classes/java/util/function/BiBlock.java > + src/share/classes/java/util/function/BiMapper.java > + src/share/classes/java/util/function/BiPredicate.java > + src/share/classes/java/util/function/BinaryOperator.java > + src/share/classes/java/util/function/Block.java > + src/share/classes/java/util/function/Combiner.java > + src/share/classes/java/util/function/DoubleBinaryOperator.java > + src/share/classes/java/util/function/DoubleMapper.java > + src/share/classes/java/util/function/DoubleUnaryOperator.java > + src/share/classes/java/util/function/Factory.java > + src/share/classes/java/util/function/FlatMapper.java > + src/share/classes/java/util/function/IntBinaryOperator.java > + src/share/classes/java/util/function/IntMapper.java > + src/share/classes/java/util/function/IntUnaryOperator.java > + src/share/classes/java/util/function/LongBinaryOperator.java > + src/share/classes/java/util/function/LongMapper.java > + src/share/classes/java/util/function/LongUnaryOperator.java > + src/share/classes/java/util/function/Mapper.java > + src/share/classes/java/util/function/Mappers.java > + src/share/classes/java/util/function/Predicate.java > + src/share/classes/java/util/function/Predicates.java > + src/share/classes/java/util/function/UnaryOperator.java > + src/share/classes/java/util/function/package.html > - src/share/classes/java/util/functions/BiBlock.java > - src/share/classes/java/util/functions/BiMapper.java > - src/share/classes/java/util/functions/BiPredicate.java > - src/share/classes/java/util/functions/BinaryOperator.java > - src/share/classes/java/util/functions/Block.java > - src/share/classes/java/util/functions/Combiner.java > - src/share/classes/java/util/functions/DoubleBinaryOperator.java > - src/share/classes/java/util/functions/DoubleMapper.java > - src/share/classes/java/util/functions/DoubleUnaryOperator.java > - src/share/classes/java/util/functions/Factory.java > - src/share/classes/java/util/functions/FlatMapper.java > - src/share/classes/java/util/functions/IntBinaryOperator.java > - src/share/classes/java/util/functions/IntMapper.java > - src/share/classes/java/util/functions/IntUnaryOperator.java > - src/share/classes/java/util/functions/LongBinaryOperator.java > - src/share/classes/java/util/functions/LongMapper.java > - src/share/classes/java/util/functions/LongUnaryOperator.java > - src/share/classes/java/util/functions/Mapper.java > - src/share/classes/java/util/functions/Mappers.java > - src/share/classes/java/util/functions/Predicate.java > - src/share/classes/java/util/functions/Predicates.java > - src/share/classes/java/util/functions/UnaryOperator.java > - src/share/classes/java/util/functions/package.html > ! src/share/classes/java/util/streams/ReferencePipeline.java > ! src/share/classes/java/util/streams/Sink.java > ! src/share/classes/java/util/streams/Spliterator.java > ! src/share/classes/java/util/streams/Stream.java > ! src/share/classes/java/util/streams/Streams.java > ! src/share/classes/java/util/streams/ops/CumulateOp.java > ! src/share/classes/java/util/streams/ops/FilterOp.java > ! src/share/classes/java/util/streams/ops/FlatMapOp.java > ! src/share/classes/java/util/streams/ops/FoldOp.java > ! src/share/classes/java/util/streams/ops/ForEachOp.java > ! src/share/classes/java/util/streams/ops/GroupByOp.java > ! src/share/classes/java/util/streams/ops/MapOp.java > ! src/share/classes/java/util/streams/ops/MatchOp.java > ! src/share/classes/java/util/streams/ops/NodeBuilder.java > ! src/share/classes/java/util/streams/ops/Nodes.java > ! src/share/classes/java/util/streams/ops/OpUtils.java > ! src/share/classes/java/util/streams/ops/ReduceByOp.java > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > ! src/share/classes/java/util/streams/ops/TeeOp.java > ! src/share/classes/java/util/streams/primitives/IntBlock.java > ! src/share/classes/java/util/streams/primitives/IntFactory.java > ! src/share/classes/java/util/streams/primitives/IntIterable.java > ! src/share/classes/java/util/streams/primitives/IntIterator.java > ! src/share/classes/java/util/streams/primitives/IntNodeBuilder.java > ! src/share/classes/java/util/streams/primitives/IntNodes.java > ! src/share/classes/java/util/streams/primitives/IntPipeline.java > ! src/share/classes/java/util/streams/primitives/IntSpliterator.java > ! src/share/classes/java/util/streams/primitives/IntStream.java > ! src/share/classes/java/util/streams/primitives/IntUnaryOperator.java > ! src/share/classes/java/util/streams/primitives/Primitives.java > ! src/share/classes/java/util/streams/primitives/RefToIntMapOp.java > ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalFactoryTest.java > ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalTest.java > ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java > ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java > ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java > ! > test-ng/tests/org/openjdk/tests/java/util/concurrent/AtomicReferenceTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/functions/DoubleUnaryOperatorTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/functions/IntUnaryOperatorTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/functions/LongUnaryOperatorTest.java > ! test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java > ! test-ng/tests/org/openjdk/tests/java/util/functions/PredicatesTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/functions/UnaryOperatorTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java > ! > test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java > ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java > ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest2.java > ! > test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java > ! test/java/util/Collection/MOAT.java > > > From brian.goetz at oracle.com Thu Nov 15 11:16:58 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 14:16:58 -0500 Subject: hg: lambda/lambda/jdk: rename java.util.functions -> java.util.function In-Reply-To: References: <20121115185553.8099D479B8@hg.openjdk.java.net> Message-ID: <50A53FAA.7080208@oracle.com> In keeping with JDK package naming guidelines (for which counterexamples or course can be found) that packages be singular names. util.streams will also change to util.stream. On 11/15/2012 2:13 PM, Paul Benedict wrote: > Mike, why is the singular preferred? I am curious on the reasoning. Some > other packages use plural. For example, "util.streams", "util.prefs", > "nio.channels". > > Paul > > On Thu, Nov 15, 2012 at 12:55 PM, wrote: > >> Changeset: ef5e16bf1045 >> Author: mduigou >> Date: 2012-11-15 10:55 -0800 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ef5e16bf1045 >> >> rename java.util.functions -> java.util.function >> >> ! make/docs/CORE_PKGS.gmk >> ! make/java/java/Makefile >> ! makefiles/docs/CORE_PKGS.gmk >> ! src/share/classes/java/lang/CharSequence.java >> ! src/share/classes/java/lang/Iterable.java >> ! src/share/classes/java/lang/ThreadLocal.java >> ! src/share/classes/java/util/Collection.java >> ! src/share/classes/java/util/Comparators.java >> ! src/share/classes/java/util/Iterables.java >> ! src/share/classes/java/util/Iterator.java >> ! src/share/classes/java/util/Iterators.java >> ! src/share/classes/java/util/Map.java >> ! src/share/classes/java/util/Optional.java >> ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java >> ! >> src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java >> ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java >> ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java >> ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java >> ! >> src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java >> + src/share/classes/java/util/function/BiBlock.java >> + src/share/classes/java/util/function/BiMapper.java >> + src/share/classes/java/util/function/BiPredicate.java >> + src/share/classes/java/util/function/BinaryOperator.java >> + src/share/classes/java/util/function/Block.java >> + src/share/classes/java/util/function/Combiner.java >> + src/share/classes/java/util/function/DoubleBinaryOperator.java >> + src/share/classes/java/util/function/DoubleMapper.java >> + src/share/classes/java/util/function/DoubleUnaryOperator.java >> + src/share/classes/java/util/function/Factory.java >> + src/share/classes/java/util/function/FlatMapper.java >> + src/share/classes/java/util/function/IntBinaryOperator.java >> + src/share/classes/java/util/function/IntMapper.java >> + src/share/classes/java/util/function/IntUnaryOperator.java >> + src/share/classes/java/util/function/LongBinaryOperator.java >> + src/share/classes/java/util/function/LongMapper.java >> + src/share/classes/java/util/function/LongUnaryOperator.java >> + src/share/classes/java/util/function/Mapper.java >> + src/share/classes/java/util/function/Mappers.java >> + src/share/classes/java/util/function/Predicate.java >> + src/share/classes/java/util/function/Predicates.java >> + src/share/classes/java/util/function/UnaryOperator.java >> + src/share/classes/java/util/function/package.html >> - src/share/classes/java/util/functions/BiBlock.java >> - src/share/classes/java/util/functions/BiMapper.java >> - src/share/classes/java/util/functions/BiPredicate.java >> - src/share/classes/java/util/functions/BinaryOperator.java >> - src/share/classes/java/util/functions/Block.java >> - src/share/classes/java/util/functions/Combiner.java >> - src/share/classes/java/util/functions/DoubleBinaryOperator.java >> - src/share/classes/java/util/functions/DoubleMapper.java >> - src/share/classes/java/util/functions/DoubleUnaryOperator.java >> - src/share/classes/java/util/functions/Factory.java >> - src/share/classes/java/util/functions/FlatMapper.java >> - src/share/classes/java/util/functions/IntBinaryOperator.java >> - src/share/classes/java/util/functions/IntMapper.java >> - src/share/classes/java/util/functions/IntUnaryOperator.java >> - src/share/classes/java/util/functions/LongBinaryOperator.java >> - src/share/classes/java/util/functions/LongMapper.java >> - src/share/classes/java/util/functions/LongUnaryOperator.java >> - src/share/classes/java/util/functions/Mapper.java >> - src/share/classes/java/util/functions/Mappers.java >> - src/share/classes/java/util/functions/Predicate.java >> - src/share/classes/java/util/functions/Predicates.java >> - src/share/classes/java/util/functions/UnaryOperator.java >> - src/share/classes/java/util/functions/package.html >> ! src/share/classes/java/util/streams/ReferencePipeline.java >> ! src/share/classes/java/util/streams/Sink.java >> ! src/share/classes/java/util/streams/Spliterator.java >> ! src/share/classes/java/util/streams/Stream.java >> ! src/share/classes/java/util/streams/Streams.java >> ! src/share/classes/java/util/streams/ops/CumulateOp.java >> ! src/share/classes/java/util/streams/ops/FilterOp.java >> ! src/share/classes/java/util/streams/ops/FlatMapOp.java >> ! src/share/classes/java/util/streams/ops/FoldOp.java >> ! src/share/classes/java/util/streams/ops/ForEachOp.java >> ! src/share/classes/java/util/streams/ops/GroupByOp.java >> ! src/share/classes/java/util/streams/ops/MapOp.java >> ! src/share/classes/java/util/streams/ops/MatchOp.java >> ! src/share/classes/java/util/streams/ops/NodeBuilder.java >> ! src/share/classes/java/util/streams/ops/Nodes.java >> ! src/share/classes/java/util/streams/ops/OpUtils.java >> ! src/share/classes/java/util/streams/ops/ReduceByOp.java >> ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java >> ! src/share/classes/java/util/streams/ops/TeeOp.java >> ! src/share/classes/java/util/streams/primitives/IntBlock.java >> ! src/share/classes/java/util/streams/primitives/IntFactory.java >> ! src/share/classes/java/util/streams/primitives/IntIterable.java >> ! src/share/classes/java/util/streams/primitives/IntIterator.java >> ! src/share/classes/java/util/streams/primitives/IntNodeBuilder.java >> ! src/share/classes/java/util/streams/primitives/IntNodes.java >> ! src/share/classes/java/util/streams/primitives/IntPipeline.java >> ! src/share/classes/java/util/streams/primitives/IntSpliterator.java >> ! src/share/classes/java/util/streams/primitives/IntStream.java >> ! src/share/classes/java/util/streams/primitives/IntUnaryOperator.java >> ! src/share/classes/java/util/streams/primitives/Primitives.java >> ! src/share/classes/java/util/streams/primitives/RefToIntMapOp.java >> ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalFactoryTest.java >> ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java >> ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/concurrent/AtomicReferenceTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/functions/DoubleUnaryOperatorTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/functions/IntUnaryOperatorTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/functions/LongUnaryOperatorTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/functions/PredicatesTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/functions/UnaryOperatorTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java >> ! >> test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java >> ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest2.java >> ! >> test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java >> ! test/java/util/Collection/MOAT.java >> >> >> > From pbenedict at apache.org Thu Nov 15 11:19:46 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 15 Nov 2012 13:19:46 -0600 Subject: hg: lambda/lambda/jdk: rename java.util.functions -> java.util.function In-Reply-To: <50A53FAA.7080208@oracle.com> References: <20121115185553.8099D479B8@hg.openjdk.java.net> <50A53FAA.7080208@oracle.com> Message-ID: Sounds good to me. Perhaps you were a Data Architect at one point! Data modelers prefer the singular form too. :-) On Thu, Nov 15, 2012 at 1:16 PM, Brian Goetz wrote: > In keeping with JDK package naming guidelines (for which counterexamples > or course can be found) that packages be singular names. util.streams will > also change to util.stream. > > > On 11/15/2012 2:13 PM, Paul Benedict wrote: > >> Mike, why is the singular preferred? I am curious on the reasoning. Some >> other packages use plural. For example, "util.streams", "util.prefs", >> "nio.channels". >> >> Paul >> >> On Thu, Nov 15, 2012 at 12:55 PM, wrote: >> >> Changeset: ef5e16bf1045 >>> Author: mduigou >>> Date: 2012-11-15 10:55 -0800 >>> URL: http://hg.openjdk.java.net/**lambda/lambda/jdk/rev/** >>> ef5e16bf1045 >>> >>> rename java.util.functions -> java.util.function >>> >>> ! make/docs/CORE_PKGS.gmk >>> ! make/java/java/Makefile >>> ! makefiles/docs/CORE_PKGS.gmk >>> ! src/share/classes/java/lang/**CharSequence.java >>> ! src/share/classes/java/lang/**Iterable.java >>> ! src/share/classes/java/lang/**ThreadLocal.java >>> ! src/share/classes/java/util/**Collection.java >>> ! src/share/classes/java/util/**Comparators.java >>> ! src/share/classes/java/util/**Iterables.java >>> ! src/share/classes/java/util/**Iterator.java >>> ! src/share/classes/java/util/**Iterators.java >>> ! src/share/classes/java/util/**Map.java >>> ! src/share/classes/java/util/**Optional.java >>> ! src/share/classes/java/util/**concurrent/atomic/**AtomicInteger.java >>> ! >>> src/share/classes/java/util/**concurrent/atomic/** >>> AtomicIntegerFieldUpdater.java >>> ! src/share/classes/java/util/**concurrent/atomic/AtomicLong.**java >>> ! src/share/classes/java/util/**concurrent/atomic/** >>> AtomicLongFieldUpdater.java >>> ! src/share/classes/java/util/**concurrent/atomic/**AtomicReference.java >>> ! >>> src/share/classes/java/util/**concurrent/atomic/** >>> AtomicReferenceFieldUpdater.**java >>> + src/share/classes/java/util/**function/BiBlock.java >>> + src/share/classes/java/util/**function/BiMapper.java >>> + src/share/classes/java/util/**function/BiPredicate.java >>> + src/share/classes/java/util/**function/BinaryOperator.java >>> + src/share/classes/java/util/**function/Block.java >>> + src/share/classes/java/util/**function/Combiner.java >>> + src/share/classes/java/util/**function/DoubleBinaryOperator.**java >>> + src/share/classes/java/util/**function/DoubleMapper.java >>> + src/share/classes/java/util/**function/DoubleUnaryOperator.**java >>> + src/share/classes/java/util/**function/Factory.java >>> + src/share/classes/java/util/**function/FlatMapper.java >>> + src/share/classes/java/util/**function/IntBinaryOperator.**java >>> + src/share/classes/java/util/**function/IntMapper.java >>> + src/share/classes/java/util/**function/IntUnaryOperator.java >>> + src/share/classes/java/util/**function/LongBinaryOperator.**java >>> + src/share/classes/java/util/**function/LongMapper.java >>> + src/share/classes/java/util/**function/LongUnaryOperator.**java >>> + src/share/classes/java/util/**function/Mapper.java >>> + src/share/classes/java/util/**function/Mappers.java >>> + src/share/classes/java/util/**function/Predicate.java >>> + src/share/classes/java/util/**function/Predicates.java >>> + src/share/classes/java/util/**function/UnaryOperator.java >>> + src/share/classes/java/util/**function/package.html >>> - src/share/classes/java/util/**functions/BiBlock.java >>> - src/share/classes/java/util/**functions/BiMapper.java >>> - src/share/classes/java/util/**functions/BiPredicate.java >>> - src/share/classes/java/util/**functions/BinaryOperator.java >>> - src/share/classes/java/util/**functions/Block.java >>> - src/share/classes/java/util/**functions/Combiner.java >>> - src/share/classes/java/util/**functions/**DoubleBinaryOperator.java >>> - src/share/classes/java/util/**functions/DoubleMapper.java >>> - src/share/classes/java/util/**functions/DoubleUnaryOperator.**java >>> - src/share/classes/java/util/**functions/Factory.java >>> - src/share/classes/java/util/**functions/FlatMapper.java >>> - src/share/classes/java/util/**functions/IntBinaryOperator.**java >>> - src/share/classes/java/util/**functions/IntMapper.java >>> - src/share/classes/java/util/**functions/IntUnaryOperator.**java >>> - src/share/classes/java/util/**functions/LongBinaryOperator.**java >>> - src/share/classes/java/util/**functions/LongMapper.java >>> - src/share/classes/java/util/**functions/LongUnaryOperator.**java >>> - src/share/classes/java/util/**functions/Mapper.java >>> - src/share/classes/java/util/**functions/Mappers.java >>> - src/share/classes/java/util/**functions/Predicate.java >>> - src/share/classes/java/util/**functions/Predicates.java >>> - src/share/classes/java/util/**functions/UnaryOperator.java >>> - src/share/classes/java/util/**functions/package.html >>> ! src/share/classes/java/util/**streams/ReferencePipeline.java >>> ! src/share/classes/java/util/**streams/Sink.java >>> ! src/share/classes/java/util/**streams/Spliterator.java >>> ! src/share/classes/java/util/**streams/Stream.java >>> ! src/share/classes/java/util/**streams/Streams.java >>> ! src/share/classes/java/util/**streams/ops/CumulateOp.java >>> ! src/share/classes/java/util/**streams/ops/FilterOp.java >>> ! src/share/classes/java/util/**streams/ops/FlatMapOp.java >>> ! src/share/classes/java/util/**streams/ops/FoldOp.java >>> ! src/share/classes/java/util/**streams/ops/ForEachOp.java >>> ! src/share/classes/java/util/**streams/ops/GroupByOp.java >>> ! src/share/classes/java/util/**streams/ops/MapOp.java >>> ! src/share/classes/java/util/**streams/ops/MatchOp.java >>> ! src/share/classes/java/util/**streams/ops/NodeBuilder.java >>> ! src/share/classes/java/util/**streams/ops/Nodes.java >>> ! src/share/classes/java/util/**streams/ops/OpUtils.java >>> ! src/share/classes/java/util/**streams/ops/ReduceByOp.java >>> ! src/share/classes/java/util/**streams/ops/SeedlessFoldOp.**java >>> ! src/share/classes/java/util/**streams/ops/TeeOp.java >>> ! src/share/classes/java/util/**streams/primitives/IntBlock.**java >>> ! src/share/classes/java/util/**streams/primitives/IntFactory.**java >>> ! src/share/classes/java/util/**streams/primitives/**IntIterable.java >>> ! src/share/classes/java/util/**streams/primitives/**IntIterator.java >>> ! src/share/classes/java/util/**streams/primitives/**IntNodeBuilder.java >>> ! src/share/classes/java/util/**streams/primitives/IntNodes.**java >>> ! src/share/classes/java/util/**streams/primitives/**IntPipeline.java >>> ! src/share/classes/java/util/**streams/primitives/**IntSpliterator.java >>> ! src/share/classes/java/util/**streams/primitives/IntStream.**java >>> ! src/share/classes/java/util/**streams/primitives/** >>> IntUnaryOperator.java >>> ! src/share/classes/java/util/**streams/primitives/Primitives.**java >>> ! src/share/classes/java/util/**streams/primitives/**RefToIntMapOp.java >>> ! test-ng/tests/org/openjdk/**tests/java/lang/** >>> ThreadLocalFactoryTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/lang/**ThreadLocalTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/**ComparatorsTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/**LambdaTestHelpers.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/**NullArgsTestCase.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/concurrent/** >>> AtomicReferenceTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> DoubleUnaryOperatorTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> IntUnaryOperatorTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> LongUnaryOperatorTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> MappersTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> PredicatesTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/functions/** >>> UnaryOperatorTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/**OpTestCase.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/streams/** >>> StreamIntermediateOpTestScenar**io.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/streams/** >>> StreamTestDataProvider.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> FindAnyOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> FlagOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> FlatMapOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> GroupByOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> IntNodeTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> MapOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> MatchOpTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> NodeBuilderTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> NodeTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> ReduceByOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> SliceOpTest.java >>> ! test-ng/tests/org/openjdk/**tests/java/util/streams/ops/** >>> TeeOpTest.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/streams/**primitives/** >>> IntStreamIntermediateOpTestSce**nario.java >>> ! >>> test-ng/tests/org/openjdk/**tests/java/util/streams/**primitives/** >>> IntStreamTestDataProvider.java >>> ! test-ng/tests/org/openjdk/**tests/javac/**LambdaTranslationTest1.java >>> ! test-ng/tests/org/openjdk/**tests/javac/**LambdaTranslationTest2.java >>> ! >>> test-ng/tests/org/openjdk/**tests/javac/**MethodReferenceTestInstanceMet >>> **hod.java >>> ! test/java/util/Collection/**MOAT.java >>> >>> >>> >>> >> From mike.duigou at oracle.com Thu Nov 15 11:20:15 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 15 Nov 2012 11:20:15 -0800 Subject: hg: lambda/lambda/jdk: rename java.util.functions -> java.util.function In-Reply-To: References: <20121115185553.8099D479B8@hg.openjdk.java.net> Message-ID: <899A79C5-0B24-443B-8BBC-6C99468F2A25@oracle.com> The current JDK preferred naming scheme is to use the singular form. There are obviously historical exceptions that can't be changed. We were asked to rename the java.util.functions, etc. as part of the review for inclusion into jdk8. I will be renaming java.util.streams, java.util.streams.ops, and java.util.streams.primitives in a changeset coming shortly. There will be three or four changesets today to match the naming proposed for integration into jdk8 mainline. They are being done as separate commits so that people can more easily update their in-flight patches. ie. pull the repo, update to the package rename rev, fix your mq patches, pop the mq patches, apply the next rev, repeat until your patches are at the head Mike On Nov 15 2012, at 11:13 , Paul Benedict wrote: > Mike, why is the singular preferred? I am curious on the reasoning. Some other packages use plural. For example, "util.streams", "util.prefs", "nio.channels". > > Paul > > On Thu, Nov 15, 2012 at 12:55 PM, wrote: > Changeset: ef5e16bf1045 > Author: mduigou > Date: 2012-11-15 10:55 -0800 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ef5e16bf1045 > > rename java.util.functions -> java.util.function From brian.goetz at oracle.com Thu Nov 15 11:27:41 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 19:27:41 +0000 Subject: hg: lambda/lambda/jdk: (weak) parallel version of SortedOp Message-ID: <20121115192753.14446479BA@hg.openjdk.java.net> Changeset: 3832536fbed9 Author: briangoetz Date: 2012-11-15 14:27 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3832536fbed9 (weak) parallel version of SortedOp ! src/share/classes/java/util/streams/ops/SortedOp.java From misterm at gmail.com Thu Nov 15 12:05:58 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 15 Nov 2012 18:05:58 -0200 Subject: Updated State of the Collections In-Reply-To: <50A53504.2030407@oracle.com> References: <50A53504.2030407@oracle.com> Message-ID: Hi Brian, I think Lambda lib efforts would be a lot easier to follow if Javadoc was available online somewhere and updated every now and then. Is it possible to do that? Regards, Michael On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz wrote: > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > From brian.goetz at oracle.com Thu Nov 15 12:16:11 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 15:16:11 -0500 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com> Message-ID: <50A54D8B.60900@oracle.com> Javadocs are available on the lambda download page at: http://jdk8.java.net/lambda/ They are updated when we update the binary builds. On 11/15/2012 3:05 PM, Michael Nascimento wrote: > Hi Brian, > > I think Lambda lib efforts would be a lot easier to follow if Javadoc > was available online somewhere and updated every now and then. Is it > possible to do that? > > Regards, > Michael > > On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz wrote: >> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >> From misterm at gmail.com Thu Nov 15 12:19:23 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 15 Nov 2012 18:19:23 -0200 Subject: Updated State of the Collections In-Reply-To: <50A54D8B.60900@oracle.com> References: <50A53504.2030407@oracle.com> <50A54D8B.60900@oracle.com> Message-ID: Totally missed that, Brian, thanks. Still, having them online would be awesome. :-) Regards, Michael On Thu, Nov 15, 2012 at 6:16 PM, Brian Goetz wrote: > Javadocs are available on the lambda download page at: > > http://jdk8.java.net/lambda/ > > They are updated when we update the binary builds. > > > On 11/15/2012 3:05 PM, Michael Nascimento wrote: >> >> Hi Brian, >> >> I think Lambda lib efforts would be a lot easier to follow if Javadoc >> was available online somewhere and updated every now and then. Is it >> possible to do that? >> >> Regards, >> Michael >> >> On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz >> wrote: >>> >>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >>> > From brian.goetz at oracle.com Thu Nov 15 12:30:45 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 15:30:45 -0500 Subject: hg: lambda/lambda/jdk: (weak) parallel version of SortedOp In-Reply-To: <20121115192753.14446479BA@hg.openjdk.java.net> References: <20121115192753.14446479BA@hg.openjdk.java.net> Message-ID: <50A550F5.1060101@oracle.com> This is a minor milestone -- all implemented Stream operations now have parallel implementations (previously, some parallel implementations were just the serial implementation.) They don't all have *good* parallel implementations, but we'll work on that. On 11/15/2012 2:27 PM, brian.goetz at oracle.com wrote: > Changeset: 3832536fbed9 > Author: briangoetz > Date: 2012-11-15 14:27 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3832536fbed9 > > (weak) parallel version of SortedOp > > ! src/share/classes/java/util/streams/ops/SortedOp.java > > From brian.goetz at oracle.com Thu Nov 15 13:41:59 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 21:41:59 +0000 Subject: hg: lambda/lambda/jdk: Fix bug in Streams.stream() where ArraySpliterator was being wrapped incorrectly with size-ignorant spliterator Message-ID: <20121115214212.D08C2479C0@hg.openjdk.java.net> Changeset: 16ebde8b1e17 Author: briangoetz Date: 2012-11-15 16:41 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/16ebde8b1e17 Fix bug in Streams.stream() where ArraySpliterator was being wrapped incorrectly with size-ignorant spliterator ! src/share/classes/java/util/streams/Streams.java ! src/share/classes/java/util/streams/ops/SortedOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SortedOpTest.java From brian.goetz at oracle.com Thu Nov 15 14:19:46 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 22:19:46 +0000 Subject: hg: lambda/lambda/jdk: Cleanup in Optional Message-ID: <20121115221957.C5B23479C1@hg.openjdk.java.net> Changeset: ab258565c0c9 Author: briangoetz Date: 2012-11-15 17:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 Cleanup in Optional ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/streams/ops/FindAnyOp.java ! src/share/classes/java/util/streams/ops/FindFirstOp.java ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java From pbenedict at apache.org Thu Nov 15 14:39:54 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 15 Nov 2012 16:39:54 -0600 Subject: UniqOp -> UniqueOp Message-ID: I would like to propose renaming UniqOp to UniqueOp. I do not see any benefit in leaving off the last 2 letters in the word. I also do not see any other class in the package oddly abbreviated. From brian.goetz at oracle.com Thu Nov 15 14:45:43 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 15 Nov 2012 17:45:43 -0500 Subject: UniqOp -> UniqueOp In-Reply-To: References: Message-ID: <50A57097.3010509@oracle.com> OK, but bear in mind the XxxOp classes are not going to be part of the public API. These are strictly implementation-only. On 11/15/2012 5:39 PM, Paul Benedict wrote: > I would like to propose renaming UniqOp to UniqueOp. I do not see any > benefit in leaving off the last 2 letters in the word. I also do not see > any other class in the package oddly abbreviated. > From brian.goetz at oracle.com Thu Nov 15 14:54:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 22:54:04 +0000 Subject: hg: lambda/lambda/jdk: Static methods on Integer suitable for use as method refs (Integer::sum, Integer::min, Integer::max) Message-ID: <20121115225416.15C15479C4@hg.openjdk.java.net> Changeset: 1257aeafc7f5 Author: briangoetz Date: 2012-11-15 17:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1257aeafc7f5 Static methods on Integer suitable for use as method refs (Integer::sum, Integer::min, Integer::max) ! src/share/classes/java/lang/Integer.java + test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java From brian.goetz at oracle.com Thu Nov 15 15:15:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 15 Nov 2012 23:15:04 +0000 Subject: hg: lambda/lambda/jdk: Add log(Level, Factory) to j.u.logging Message-ID: <20121115231516.1C8AE479C5@hg.openjdk.java.net> Changeset: dfed78f69c8b Author: briangoetz Date: 2012-11-15 18:15 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dfed78f69c8b Add log(Level, Factory) to j.u.logging ! src/share/classes/java/util/logging/Logger.java From misterm at gmail.com Thu Nov 15 15:30:02 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 15 Nov 2012 21:30:02 -0200 Subject: Lambda Tree API changes feedback Message-ID: Hi, Some feedback / questions: - What is the purpose of having a special getBodyKind() in LambdaExpressionTree? Why isn't the regular getKind() in the Tree returned by getBody() enough? - Isn't the grammar in MemberReferenceTree supposed to use :: instead of #? - Any reason for not providing a super interface between IntersectionTypeTree and TypeParameterTree or MethodTree and LambdaExpressionTree? Great work, guys, I didn't expect the Tree API to be updated already. Regards, Michael From misterm at gmail.com Thu Nov 15 17:38:31 2012 From: misterm at gmail.com (Michael Nascimento) Date: Thu, 15 Nov 2012 23:38:31 -0200 Subject: Optional relationship to Sized, Stream and other Message-ID: Hi folks, After finally taking a look at the latest Javadoc and thinking about it, I really think Optional could be better integrated with the Collections framework and Lambda libs if it: - Implemented Sized; - Had a stream() method, allowing map to be called on the final result only, for instance; - Had a toSet() method Regards, Michael From mike.duigou at oracle.com Thu Nov 15 19:23:11 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 16 Nov 2012 03:23:11 +0000 Subject: hg: lambda/lambda/jdk: package renames Message-ID: <20121116032322.D9243479CA@hg.openjdk.java.net> Changeset: c5b238ae25fe Author: mduigou Date: 2012-11-15 19:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c5b238ae25fe package renames java.util.streams -> java.util.stream java.util.streams.ops -> java.util.op java.util.streams.primitives -> java.util.primitive ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/Vector.java + src/share/classes/java/util/stream/AbstractPipeline.java + src/share/classes/java/util/stream/BaseStream.java + src/share/classes/java/util/stream/ParallelPipelineHelper.java + src/share/classes/java/util/stream/PipelineHelper.java + src/share/classes/java/util/stream/ReferencePipeline.java + src/share/classes/java/util/stream/Sink.java + src/share/classes/java/util/stream/Spliterator.java + src/share/classes/java/util/stream/Stream.java + src/share/classes/java/util/stream/StreamOpFlags.java + src/share/classes/java/util/stream/StreamShape.java + src/share/classes/java/util/stream/StreamShapeFactory.java + src/share/classes/java/util/stream/Streamable.java + src/share/classes/java/util/stream/Streams.java + src/share/classes/java/util/stream/TerminalSink.java + src/share/classes/java/util/stream/op/AbstractTask.java + src/share/classes/java/util/stream/op/CollectorOps.java + src/share/classes/java/util/stream/op/ConcatOp.java + src/share/classes/java/util/stream/op/CumulateOp.java + src/share/classes/java/util/stream/op/FilterOp.java + src/share/classes/java/util/stream/op/FindAnyOp.java + src/share/classes/java/util/stream/op/FindFirstOp.java + src/share/classes/java/util/stream/op/FlagDeclaringOp.java + src/share/classes/java/util/stream/op/FlatMapOp.java + src/share/classes/java/util/stream/op/FoldOp.java + src/share/classes/java/util/stream/op/ForEachOp.java + src/share/classes/java/util/stream/op/GroupByOp.java + src/share/classes/java/util/stream/op/IntermediateOp.java + src/share/classes/java/util/stream/op/MapOp.java + src/share/classes/java/util/stream/op/MatchOp.java + src/share/classes/java/util/stream/op/Node.java + src/share/classes/java/util/stream/op/NodeBuilder.java + src/share/classes/java/util/stream/op/Nodes.java + src/share/classes/java/util/stream/op/OpUtils.java + src/share/classes/java/util/stream/op/ReduceByOp.java + src/share/classes/java/util/stream/op/SeedlessFoldOp.java + src/share/classes/java/util/stream/op/SliceOp.java + src/share/classes/java/util/stream/op/SortedOp.java + src/share/classes/java/util/stream/op/StatefulOp.java + src/share/classes/java/util/stream/op/StreamOp.java + src/share/classes/java/util/stream/op/TeeOp.java + src/share/classes/java/util/stream/op/TerminalOp.java + src/share/classes/java/util/stream/op/ToArrayOp.java + src/share/classes/java/util/stream/op/TreeUtils.java + src/share/classes/java/util/stream/op/UniqOp.java + src/share/classes/java/util/stream/primitive/IntBlock.java + src/share/classes/java/util/stream/primitive/IntCollectorOps.java + src/share/classes/java/util/stream/primitive/IntFactory.java + src/share/classes/java/util/stream/primitive/IntFilterOp.java + src/share/classes/java/util/stream/primitive/IntForEachOp.java + src/share/classes/java/util/stream/primitive/IntIterable.java + src/share/classes/java/util/stream/primitive/IntIterator.java + src/share/classes/java/util/stream/primitive/IntLimitOp.java + src/share/classes/java/util/stream/primitive/IntMapOp.java + src/share/classes/java/util/stream/primitive/IntNode.java + src/share/classes/java/util/stream/primitive/IntNodeBuilder.java + src/share/classes/java/util/stream/primitive/IntNodes.java + src/share/classes/java/util/stream/primitive/IntPipeline.java + src/share/classes/java/util/stream/primitive/IntPredicate.java + src/share/classes/java/util/stream/primitive/IntSink.java + src/share/classes/java/util/stream/primitive/IntSortedOp.java + src/share/classes/java/util/stream/primitive/IntSpliterator.java + src/share/classes/java/util/stream/primitive/IntStream.java + src/share/classes/java/util/stream/primitive/IntSumOp.java + src/share/classes/java/util/stream/primitive/IntTeeOp.java + src/share/classes/java/util/stream/primitive/IntTerminalSink.java + src/share/classes/java/util/stream/primitive/IntToArrayOp.java + src/share/classes/java/util/stream/primitive/IntToIntegerOp.java + src/share/classes/java/util/stream/primitive/IntTreeUtils.java + src/share/classes/java/util/stream/primitive/IntUnaryOperator.java + src/share/classes/java/util/stream/primitive/Primitives.java + src/share/classes/java/util/stream/primitive/RefToIntMapOp.java - src/share/classes/java/util/streams/AbstractPipeline.java - src/share/classes/java/util/streams/BaseStream.java - src/share/classes/java/util/streams/ParallelPipelineHelper.java - src/share/classes/java/util/streams/PipelineHelper.java - src/share/classes/java/util/streams/ReferencePipeline.java - src/share/classes/java/util/streams/Sink.java - src/share/classes/java/util/streams/Spliterator.java - src/share/classes/java/util/streams/Stream.java - src/share/classes/java/util/streams/StreamOpFlags.java - src/share/classes/java/util/streams/StreamShape.java - src/share/classes/java/util/streams/StreamShapeFactory.java - src/share/classes/java/util/streams/Streamable.java - src/share/classes/java/util/streams/Streams.java - src/share/classes/java/util/streams/TerminalSink.java - src/share/classes/java/util/streams/ops/AbstractTask.java - src/share/classes/java/util/streams/ops/CollectorOps.java - src/share/classes/java/util/streams/ops/ConcatOp.java - src/share/classes/java/util/streams/ops/CumulateOp.java - src/share/classes/java/util/streams/ops/FilterOp.java - src/share/classes/java/util/streams/ops/FindAnyOp.java - src/share/classes/java/util/streams/ops/FindFirstOp.java - src/share/classes/java/util/streams/ops/FlagDeclaringOp.java - src/share/classes/java/util/streams/ops/FlatMapOp.java - src/share/classes/java/util/streams/ops/FoldOp.java - src/share/classes/java/util/streams/ops/ForEachOp.java - src/share/classes/java/util/streams/ops/GroupByOp.java - src/share/classes/java/util/streams/ops/IntermediateOp.java - src/share/classes/java/util/streams/ops/MapOp.java - src/share/classes/java/util/streams/ops/MatchOp.java - src/share/classes/java/util/streams/ops/Node.java - src/share/classes/java/util/streams/ops/NodeBuilder.java - src/share/classes/java/util/streams/ops/Nodes.java - src/share/classes/java/util/streams/ops/OpUtils.java - src/share/classes/java/util/streams/ops/ReduceByOp.java - src/share/classes/java/util/streams/ops/SeedlessFoldOp.java - src/share/classes/java/util/streams/ops/SliceOp.java - src/share/classes/java/util/streams/ops/SortedOp.java - src/share/classes/java/util/streams/ops/StatefulOp.java - src/share/classes/java/util/streams/ops/StreamOp.java - src/share/classes/java/util/streams/ops/TeeOp.java - src/share/classes/java/util/streams/ops/TerminalOp.java - src/share/classes/java/util/streams/ops/ToArrayOp.java - src/share/classes/java/util/streams/ops/TreeUtils.java - src/share/classes/java/util/streams/ops/UniqOp.java - src/share/classes/java/util/streams/primitives/IntBlock.java - src/share/classes/java/util/streams/primitives/IntCollectorOps.java - src/share/classes/java/util/streams/primitives/IntFactory.java - src/share/classes/java/util/streams/primitives/IntFilterOp.java - src/share/classes/java/util/streams/primitives/IntForEachOp.java - src/share/classes/java/util/streams/primitives/IntIterable.java - src/share/classes/java/util/streams/primitives/IntIterator.java - src/share/classes/java/util/streams/primitives/IntLimitOp.java - src/share/classes/java/util/streams/primitives/IntMapOp.java - src/share/classes/java/util/streams/primitives/IntNode.java - src/share/classes/java/util/streams/primitives/IntNodeBuilder.java - src/share/classes/java/util/streams/primitives/IntNodes.java - src/share/classes/java/util/streams/primitives/IntPipeline.java - src/share/classes/java/util/streams/primitives/IntPredicate.java - src/share/classes/java/util/streams/primitives/IntSink.java - src/share/classes/java/util/streams/primitives/IntSortedOp.java - src/share/classes/java/util/streams/primitives/IntSpliterator.java - src/share/classes/java/util/streams/primitives/IntStream.java - src/share/classes/java/util/streams/primitives/IntSumOp.java - src/share/classes/java/util/streams/primitives/IntTeeOp.java - src/share/classes/java/util/streams/primitives/IntTerminalSink.java - src/share/classes/java/util/streams/primitives/IntToArrayOp.java - src/share/classes/java/util/streams/primitives/IntToIntegerOp.java - src/share/classes/java/util/streams/primitives/IntTreeUtils.java - src/share/classes/java/util/streams/primitives/IntUnaryOperator.java - src/share/classes/java/util/streams/primitives/Primitives.java - src/share/classes/java/util/streams/primitives/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/FillableStringTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/streams/CollectionModifyStreamTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamOpFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/InfiniteStreamWithLimitOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java From mike.duigou at oracle.com Thu Nov 15 19:25:46 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 16 Nov 2012 03:25:46 +0000 Subject: hg: lambda/lambda: package renames Message-ID: <20121116032546.E1032479CB@hg.openjdk.java.net> Changeset: 4ab3a1efa794 Author: mduigou Date: 2012-11-15 19:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/4ab3a1efa794 package renames java.util.streams -> java.util.stream java.util.streams.ops -> java.util.streams.op java.util.streams.primitives -> java.util.streams.primitive ! common/makefiles/javadoc/CORE_PKGS.gmk From mike.duigou at oracle.com Thu Nov 15 22:03:25 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 16 Nov 2012 06:03:25 +0000 Subject: hg: lambda/lambda/jdk: More renames: Message-ID: <20121116060337.0CFCE479DF@hg.openjdk.java.net> Changeset: a4c10f71e673 Author: mduigou Date: 2012-11-15 22:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a4c10f71e673 More renames: (*)Mapper -> (*)Function.apply (*)Factory -> (*)Supplier.get(*) Moved IntSupplier from java.util.stream.primitive to java.util.function ! makefiles/Setup.gmk ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/Optional.java + src/share/classes/java/util/function/BiFunction.java - src/share/classes/java/util/function/BiMapper.java + src/share/classes/java/util/function/DoubleFunction.java - src/share/classes/java/util/function/DoubleMapper.java - src/share/classes/java/util/function/Factory.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/Functions.java + src/share/classes/java/util/function/IntFunction.java - src/share/classes/java/util/function/IntMapper.java ! src/share/classes/java/util/function/IntSupplier.java < src/share/classes/java/util/stream/primitive/IntFactory.java + src/share/classes/java/util/function/LongFunction.java - src/share/classes/java/util/function/LongMapper.java - src/share/classes/java/util/function/Mapper.java - src/share/classes/java/util/function/Mappers.java ! src/share/classes/java/util/function/Predicates.java + src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/MapOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/OpUtils.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java - test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalFactoryTest.java + test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalSupplierTest.java ! test-ng/tests/org/openjdk/tests/java/lang/ThreadLocalTest.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java + test-ng/tests/org/openjdk/tests/java/util/functions/FunctionsTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest2.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java From jgetino at telefonica.net Thu Nov 15 22:58:49 2012 From: jgetino at telefonica.net (Jose) Date: Fri, 16 Nov 2012 07:58:49 +0100 Subject: Updated State of the Collections In-Reply-To: <50A53504.2030407@oracle.com> References: <50A53504.2030407@oracle.com> Message-ID: <80DA72BB0C954960BE954746D1610F25@Superx64> Would you mind to provide an example of the use of flatMap?. I need to adapt old b56 code like this: Set lines(mapName){}; namesColl.flatMap(name -> lines(name)).into(...); to the new sintax but I have no idea how to start with (do I have to provide a Block.instance?) I made some web search on flatMap and jdk8 but everyone seems to be talking about Optional. And in the repos I couln't find a single example, only discussions about the sintax. -----Mensaje original----- De: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian Goetz Enviado el: jueves, 15 de noviembre de 2012 19:32 Para: lambda-dev at openjdk.java.net Asunto: Updated State of the Collections is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html From michael.hixson at gmail.com Thu Nov 15 23:30:04 2012 From: michael.hixson at gmail.com (Michael Hixson) Date: Thu, 15 Nov 2012 23:30:04 -0800 Subject: Updated State of the Collections In-Reply-To: <80DA72BB0C954960BE954746D1610F25@Superx64> References: <50A53504.2030407@oracle.com> <80DA72BB0C954960BE954746D1610F25@Superx64> Message-ID: flatMap caused me a lot of trouble as well. Eventually I figured out you can use it without casting, declaring anonymous classes, or using a helper method like this: List authors = ... // Assume author.getBooks() returns List List books = authors.stream() .flatMap((sink, author) -> author.getBooks().forEach(sink) .into(new ArrayList()); // Assume author.getDeceasedDate() returns Optional List deceasedDates = authors.stream() .flatMap(sink, author) -> author.getDeceasedDate().ifPresent(sink)) .into(new ArrayList()); The generic for the flatMap invocations (".flatMap" and "flatMap" above) seem to be necessary. I don't know if that was because of the IDE I was using (IntelliJ 12 EAP) or because that's just how it has to be. On Thu, Nov 15, 2012 at 10:58 PM, Jose wrote: > > Would you mind to provide an example of the use of flatMap?. > > I need to adapt old b56 code like this: > > Set lines(mapName){}; > namesColl.flatMap(name -> lines(name)).into(...); > > to the new sintax but I have no idea how to start with (do I have to > provide > a Block.instance?) > > I made some web search on flatMap and jdk8 but everyone seems to be talking > about Optional. > And in the repos I couln't find a single example, only discussions about > the > sintax. > > > > > -----Mensaje original----- > De: lambda-dev-bounces at openjdk.java.net > [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian Goetz > Enviado el: jueves, 15 de noviembre de 2012 19:32 > Para: lambda-dev at openjdk.java.net > Asunto: Updated State of the Collections > > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > > > From sam at sampullara.com Thu Nov 15 23:34:16 2012 From: sam at sampullara.com (Sam Pullara) Date: Thu, 15 Nov 2012 23:34:16 -0800 Subject: Updated State of the Collections In-Reply-To: <80DA72BB0C954960BE954746D1610F25@Superx64> References: <50A53504.2030407@oracle.com> <80DA72BB0C954960BE954746D1610F25@Superx64> Message-ID: <268236C4-C038-4895-9483-991D98291864@sampullara.com> Something like: namesColl.flatMap( (sink, name) -> { for (PolyLine line : lines(name)) sink.accept(line); } ).into(...); Didn't compile it, but that is the idea. Sam On Nov 15, 2012, at 10:58 PM, "Jose" wrote: > > Would you mind to provide an example of the use of flatMap?. > > I need to adapt old b56 code like this: > > Set lines(mapName){}; > namesColl.flatMap(name -> lines(name)).into(...); > > to the new sintax but I have no idea how to start with (do I have to provide > a Block.instance?) > > I made some web search on flatMap and jdk8 but everyone seems to be talking > about Optional. > And in the repos I couln't find a single example, only discussions about the > sintax. > > > > > -----Mensaje original----- > De: lambda-dev-bounces at openjdk.java.net > [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian Goetz > Enviado el: jueves, 15 de noviembre de 2012 19:32 > Para: lambda-dev at openjdk.java.net > Asunto: Updated State of the Collections > > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > > From maurizio.cimadamore at oracle.com Fri Nov 16 00:49:08 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 16 Nov 2012 08:49:08 +0000 Subject: Lambda Tree API changes feedback In-Reply-To: References: Message-ID: <50A5FE04.8020707@oracle.com> On 15/11/12 23:30, Michael Nascimento wrote: > Hi, > > Some feedback / questions: > > - What is the purpose of having a special getBodyKind() in > LambdaExpressionTree? Why isn't the regular getKind() in the Tree > returned by getBody() enough? Yeah - that should be enough - however since the spec stresses difference between statement/expression lambdas I thought it might be useful having it more explicit > - Isn't the grammar in MemberReferenceTree supposed to use :: instead of #? sure > - Any reason for not providing a super interface between > IntersectionTypeTree and TypeParameterTree or MethodTree and > LambdaExpressionTree? These are distinct concepts - a type parameter might have a bound that is an intersection type, but it's not itself an intersection type. Also, a lambda looks like a method declaration, but it's not - it's an expression and not a symbol declaration. Those differences, in my mind, are enough to justify use of different interfaces (with bit of duplication). > > Great work, guys, I didn't expect the Tree API to be updated already. > > Regards, > Michael > From paul.sandoz at oracle.com Fri Nov 16 01:40:06 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 Nov 2012 10:40:06 +0100 Subject: Build failure on Mac "javac: invalid flag" Message-ID: Hi, For some reason the following change to jdk/makefiles/Setup.gmk results in a build failure: http://hg.openjdk.java.net/lambda/lambda/jdk/diff/a4c10f71e673/makefiles/Setup.gmk Generating headers for jdk base classes Compiling 886 files for BUILD_JOBJC_JAR Compiling 886 files for BUILD_JOBJC_HEADERS_JAR javac: invalid flag: -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass Usage: javac use -help for a list of possible options make[2]: *** [/Users/sandoz/Projects/jdk8/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 2 Reverting the change fixed the problem for me. Paul. From jgetino at telefonica.net Fri Nov 16 01:40:43 2012 From: jgetino at telefonica.net (Jose) Date: Fri, 16 Nov 2012 10:40:43 +0100 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com><80DA72BB0C954960BE954746D1610F25@Superx64> Message-ID: <22A79D4CA4F9481C9084F54DE5229A46@Superx64> So flatMap function has two arguments. For the second one you provide a List of authors that you defined previously. But what about the first argument?, sink is just a variable, it has not being initialized at any place I find this like defining the square function as: sq=(x,y)->y*y and then using it in this way sq(x,3)==9 -----Mensaje original----- De: Michael Hixson [mailto:michael.hixson at gmail.com] Enviado el: viernes, 16 de noviembre de 2012 8:30 Para: Jose CC: lambda-dev at openjdk.java.net Asunto: Re: Updated State of the Collections flatMap caused me a lot of trouble as well. Eventually I figured out you can use it without casting, declaring anonymous classes, or using a helper method like this: List authors = ... // Assume author.getBooks() returns List List books = authors.stream() .flatMap((sink, author) -> author.getBooks().forEach(sink) .into(new ArrayList()); // Assume author.getDeceasedDate() returns Optional List deceasedDates = authors.stream() .flatMap(sink, author) -> author.getDeceasedDate().ifPresent(sink)) .into(new ArrayList()); The generic for the flatMap invocations (".flatMap" and "flatMap" above) seem to be necessary. I don't know if that was because of the IDE I was using (IntelliJ 12 EAP) or because that's just how it has to be. On Thu, Nov 15, 2012 at 10:58 PM, Jose wrote: Would you mind to provide an example of the use of flatMap?. I need to adapt old b56 code like this: Set lines(mapName){}; namesColl.flatMap(name -> lines(name)).into(...); to the new sintax but I have no idea how to start with (do I have to provide a Block.instance?) I made some web search on flatMap and jdk8 but everyone seems to be talking about Optional. And in the repos I couln't find a single example, only discussions about the sintax. -----Mensaje original----- De: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian Goetz Enviado el: jueves, 15 de noviembre de 2012 19:32 Para: lambda-dev at openjdk.java.net Asunto: Updated State of the Collections is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html From paul.sandoz at oracle.com Fri Nov 16 01:49:25 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Nov 2012 09:49:25 +0000 Subject: hg: lambda/lambda/jdk: Rename directories to correct package names. Message-ID: <20121116095014.C6297479EF@hg.openjdk.java.net> Changeset: 68a734033306 Author: psandoz Date: 2012-11-16 10:49 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/68a734033306 Rename directories to correct package names. + test-ng/tests/org/openjdk/tests/java/util/function/DoubleUnaryOperatorTest.java = test-ng/tests/org/openjdk/tests/java/util/function/FunctionsTest.java < test-ng/tests/org/openjdk/tests/java/util/functions/FunctionsTest.java + test-ng/tests/org/openjdk/tests/java/util/function/IntUnaryOperatorTest.java + test-ng/tests/org/openjdk/tests/java/util/function/LongUnaryOperatorTest.java + test-ng/tests/org/openjdk/tests/java/util/function/PredicatesTest.java + test-ng/tests/org/openjdk/tests/java/util/function/UnaryOperatorTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/DoubleUnaryOperatorTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/IntUnaryOperatorTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/LongUnaryOperatorTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/PredicatesTest.java - test-ng/tests/org/openjdk/tests/java/util/functions/UnaryOperatorTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/CollectionModifyStreamTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java < test-ng/tests/org/openjdk/tests/java/util/streams/OpTestCase.java = test-ng/tests/org/openjdk/tests/java/util/stream/StreamIntermediateOpTestScenario.java < test-ng/tests/org/openjdk/tests/java/util/streams/StreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/FilterOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlagOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/GroupByOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/InfiniteStreamWithLimitOpTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/IntNodeTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/MapOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeBuilderTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/NodeTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceByOpTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceByOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java < test-ng/tests/org/openjdk/tests/java/util/streams/ops/SliceOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/TestFlagExpectedOp.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/UnorderedStreamTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFilterOpTest.java = test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamIntermediateOpTestScenario.java < test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java - test-ng/tests/org/openjdk/tests/java/util/streams/CollectionModifyStreamTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/StreamOpFlagsTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestData.java - test-ng/tests/org/openjdk/tests/java/util/streams/StreamTestDataProvider.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/ConcatOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/CumulateOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/FilterOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindAnyOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/FindFirstOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/FlatMapOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/ForEachOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/InfiniteStreamWithLimitOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/MapOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/MatchOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/PrimitiveOpsTests.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/ReduceTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/SortedOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/TeeOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/TestFlagExpectedOp.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/ToArrayOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/UniqOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/ops/UnorderedStreamTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntFilterOpTest.java - test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestData.java - test-ng/tests/org/openjdk/tests/java/util/streams/primitives/IntStreamTestDataProvider.java From paul.sandoz at oracle.com Fri Nov 16 01:59:28 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 Nov 2012 10:59:28 +0100 Subject: Updated State of the Collections In-Reply-To: <22A79D4CA4F9481C9084F54DE5229A46@Superx64> References: <50A53504.2030407@oracle.com><80DA72BB0C954960BE954746D1610F25@Superx64> <22A79D4CA4F9481C9084F54DE5229A46@Superx64> Message-ID: <7FDDA705-EF57-4254-8EF2-5797C1901720@oracle.com> On Nov 16, 2012, at 10:40 AM, Jose wrote: > > > So flatMap function has two arguments. For the second one you provide a > List of authors that you defined previously. > > But what about the first argument?, sink is just a variable, it has not > being initialized at any place > FlatMapper has two arguments: void flatMapInto(Block sink, T element); The second is the element, of type T, to apply the flat map operation. The first is the Block that accepts zero or more elements, of type R, where an element, of type T, is "flattened" to zero or more elements of type R. The framework creates an instance of Block. The framework invokes FlatMapper.flatMapInto(...), the application invokes sink.apply(...) zero or more times. Paul. From michael.hixson at gmail.com Fri Nov 16 02:13:49 2012 From: michael.hixson at gmail.com (Michael Hixson) Date: Fri, 16 Nov 2012 02:13:49 -0800 Subject: Updated State of the Collections In-Reply-To: <22A79D4CA4F9481C9084F54DE5229A46@Superx64> References: <50A53504.2030407@oracle.com> <80DA72BB0C954960BE954746D1610F25@Superx64> <22A79D4CA4F9481C9084F54DE5229A46@Superx64> Message-ID: The sink is provided to you by the stream - you don't create it yourself. So in this example: List books = authors.stream() .flatMap((sink, author) -> author.getBooks().forEach(sink)) .into(new ArrayList()); the object behind the "sink" variable was created by the stream upon calling .flatMap. The flatMap method is basically saying, "I'm giving you a sink. It's what I'm using to build the result. For each author, use the sink to mark which books will appear in the result." This lambda: (sink, author) -> author.getBooks().forEach(sink) instructs the sink to include every book for every author in the result. I agree that it's confusing. Without looking at the method signature, I expected flatMap to do that dumping into the sink for me. Something like this: // Note: this doesn't work List books = authors.stream() .flatMap(author -> author.getBooks()) .into(new ArrayList()); But I see why they didn't write flatMap that way. In my example, I have author.getBooks() which returns a collection. If I didn't have a method like that, or I didn't want to create a throwaway collection just to hold each author's books (which will all then get merged into one collection), then if they only gave me a flatMap(A -> Collection) method I'd be hosed. The fact that they give me the sink lets me pick and choose the elements in the result individually from wherever I want. -Michael On Fri, Nov 16, 2012 at 1:40 AM, Jose wrote: > > > So flatMap function has two arguments. For the second one you provide a > List of authors that you defined previously. > > But what about the first argument?, sink is just a variable, it has not > being initialized at any place > > I find this like defining the square function as: > > sq=(x,y)->y*y > > and then using it in this way > > sq(x,3)==9 > > > > > > -----Mensaje original----- > De: Michael Hixson [mailto:michael.hixson at gmail.com] > Enviado el: viernes, 16 de noviembre de 2012 8:30 > Para: Jose > CC: lambda-dev at openjdk.java.net > Asunto: Re: Updated State of the Collections > > flatMap caused me a lot of trouble as well. Eventually I figured out you > can use it without casting, declaring anonymous classes, or using a helper > method like this: > > List authors = ... > // Assume author.getBooks() returns List List books = > authors.stream() > .flatMap((sink, author) -> author.getBooks().forEach(sink) > .into(new ArrayList()); > // Assume author.getDeceasedDate() returns Optional List > deceasedDates = authors.stream() > .flatMap(sink, author) -> > author.getDeceasedDate().ifPresent(sink)) > .into(new ArrayList()); > > The generic for the flatMap invocations (".flatMap" and > "flatMap" above) seem to be necessary. I don't know if that was > because of the IDE I was using (IntelliJ 12 EAP) or because that's just how > it has to be. > > > > On Thu, Nov 15, 2012 at 10:58 PM, Jose wrote: > > > > Would you mind to provide an example of the use of flatMap?. > > I need to adapt old b56 code like this: > > Set lines(mapName){}; > namesColl.flatMap(name -> lines(name)).into(...); > > to the new sintax but I have no idea how to start with (do I have > to > provide > a Block.instance?) > > I made some web search on flatMap and jdk8 but everyone seems to be > talking > about Optional. > And in the repos I couln't find a single example, only discussions > about the > sintax. > > > > > -----Mensaje original----- > De: lambda-dev-bounces at openjdk.java.net > [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian > Goetz > Enviado el: jueves, 15 de noviembre de 2012 19:32 > Para: lambda-dev at openjdk.java.net > Asunto: Updated State of the Collections > > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > > > > > > > > From v.a.ammodytes at googlemail.com Fri Nov 16 02:26:18 2012 From: v.a.ammodytes at googlemail.com (Arne Siegel) Date: Fri, 16 Nov 2012 11:26:18 +0100 Subject: Updated State of the Collections In-Reply-To: <50A53504.2030407@oracle.com> Message-ID: <50A622DA.6697.576191@v.a.ammodytes.googlemail.com> Just one observation: the proposed way to handle the "error" strategy for nulls won't compile, as it fails to comply the contract for a Predicate: filter(e -> { (if e == null) throw new NPE(); } I can think of two compilable alternatives: filter(e -> { (if e == null) throw new NPE(); else return true; } tee(e -> { (if e == null) throw new NPE(); } On 15 Nov 2012 at 13:31, Brian Goetz wrote: > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > From paul.sandoz at oracle.com Fri Nov 16 02:26:26 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Nov 2012 10:26:26 +0000 Subject: hg: lambda/lambda/jdk: Optimize imports and re-format. Message-ID: <20121116102731.B68DA479FC@hg.openjdk.java.net> Changeset: e9b1e2f1094c Author: psandoz Date: 2012-11-16 11:26 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e9b1e2f1094c Optimize imports and re-format. ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java From forax at univ-mlv.fr Fri Nov 16 03:11:13 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 Nov 2012 12:11:13 +0100 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: <20121115221957.C5B23479C1@hg.openjdk.java.net> References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: <50A61F51.5010704@univ-mlv.fr> On 11/15/2012 11:19 PM, brian.goetz at oracle.com wrote: > Changeset: ab258565c0c9 > Author: briangoetz > Date: 2012-11-15 17:19 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > > Cleanup in Optional > > ! src/share/classes/java/util/Optional.java > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > > Brian, or Optional should be final, or you have to change equals() to do an instanceof check. but currently the implementation of equals is not correct. cheers, R?mi From misterm at gmail.com Fri Nov 16 03:14:10 2012 From: misterm at gmail.com (Michael Nascimento) Date: Fri, 16 Nov 2012 09:14:10 -0200 Subject: Lambda Tree API changes feedback In-Reply-To: <50A5FE04.8020707@oracle.com> References: <50A5FE04.8020707@oracle.com> Message-ID: On Fri, Nov 16, 2012 at 6:49 AM, Maurizio Cimadamore wrote: > On 15/11/12 23:30, Michael Nascimento wrote: >> - What is the purpose of having a special getBodyKind() in >> LambdaExpressionTree? Why isn't the regular getKind() in the Tree >> returned by getBody() enough? > > Yeah - that should be enough - however since the spec stresses difference > between statement/expression lambdas I thought it might be useful having it > more explicit Well, it is actually confusing. It gives the impression there is something different going on. It seems better to remove it, imho. >> - Any reason for not providing a super interface between >> IntersectionTypeTree and TypeParameterTree or MethodTree and >> LambdaExpressionTree? > > These are distinct concepts - a type parameter might have a bound that is an > intersection type, but it's not itself an intersection type. Also, a lambda > looks like a method declaration, but it's not - it's an expression and not a > symbol declaration. Those differences, in my mind, are enough to justify use > of different interfaces (with bit of duplication). I do think there should be separate interfaces, but for me the only difference between MT and LET is the introduction of a symbol connected with a class, so it feels like one might want to handle these in a similar way depending on the analysis being done and a superinterface or hierarchy here would be helpful. Regards, Michael From misterm at gmail.com Fri Nov 16 03:20:51 2012 From: misterm at gmail.com (Michael Nascimento) Date: Fri, 16 Nov 2012 09:20:51 -0200 Subject: Optional relationship to Sized, Stream and other In-Reply-To: References: Message-ID: Hi guys, Just realized I missed Streamable as I took a look at the API, so Optional could implement it instead of just having a stream() method. Regards, Michael On Thu, Nov 15, 2012 at 11:38 PM, Michael Nascimento wrote: > Hi folks, > > After finally taking a look at the latest Javadoc and thinking about > it, I really think Optional could be better integrated with the > Collections framework and Lambda libs if it: > > - Implemented Sized; > - Had a stream() method, allowing map to be called on the final result > only, for instance; > - Had a toSet() method > > Regards, > Michael From jgetino at telefonica.net Fri Nov 16 03:26:42 2012 From: jgetino at telefonica.net (Jose) Date: Fri, 16 Nov 2012 12:26:42 +0100 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com><80DA72BB0C954960BE954746D1610F25@Superx64><22A79D4CA4F9481C9084F54DE5229A46@Superx64> Message-ID: Thanks for the explanations! I think I'm starting to get the idea: - I don't have to see flatMap as function of two arguments, because I'm only allowed to provide one. - The first argument is just a workaround to access (but not to set) an internal variable of the flapMap method. - The way this argument is used in the flatMap body defines a concrete flavor of the "old" flatMap version. I'm correct? _____ De: Michael Hixson [mailto:michael.hixson at gmail.com] Enviado el: viernes, 16 de noviembre de 2012 11:14 Para: Jose CC: lambda-dev at openjdk.java.net Asunto: Re: Updated State of the Collections The sink is provided to you by the stream - you don't create it yourself. So in this example: List books = authors.stream() .flatMap((sink, author) -> author.getBooks().forEach(sink)) .into(new ArrayList()); the object behind the "sink" variable was created by the stream upon calling .flatMap. The flatMap method is basically saying, "I'm giving you a sink. It's what I'm using to build the result. For each author, use the sink to mark which books will appear in the result." This lambda: (sink, author) -> author.getBooks().forEach(sink) instructs the sink to include every book for every author in the result. I agree that it's confusing. Without looking at the method signature, I expected flatMap to do that dumping into the sink for me. Something like this: // Note: this doesn't work List books = authors.stream() .flatMap(author -> author.getBooks()) .into(new ArrayList()); But I see why they didn't write flatMap that way. In my example, I have author.getBooks() which returns a collection. If I didn't have a method like that, or I didn't want to create a throwaway collection just to hold each author's books (which will all then get merged into one collection), then if they only gave me a flatMap(A -> Collection) method I'd be hosed. The fact that they give me the sink lets me pick and choose the elements in the result individually from wherever I want. -Michael On Fri, Nov 16, 2012 at 1:40 AM, Jose wrote: So flatMap function has two arguments. For the second one you provide a List of authors that you defined previously. But what about the first argument?, sink is just a variable, it has not being initialized at any place I find this like defining the square function as: sq=(x,y)->y*y and then using it in this way sq(x,3)==9 -----Mensaje original----- De: Michael Hixson [mailto:michael.hixson at gmail.com] Enviado el: viernes, 16 de noviembre de 2012 8:30 Para: Jose CC: lambda-dev at openjdk.java.net Asunto: Re: Updated State of the Collections flatMap caused me a lot of trouble as well. Eventually I figured out you can use it without casting, declaring anonymous classes, or using a helper method like this: List authors = ... // Assume author.getBooks() returns List List books = authors.stream() .flatMap((sink, author) -> author.getBooks().forEach(sink) .into(new ArrayList()); // Assume author.getDeceasedDate() returns Optional List deceasedDates = authors.stream() .flatMap(sink, author) -> author.getDeceasedDate().ifPresent(sink)) .into(new ArrayList()); The generic for the flatMap invocations (".flatMap" and "flatMap" above) seem to be necessary. I don't know if that was because of the IDE I was using (IntelliJ 12 EAP) or because that's just how it has to be. On Thu, Nov 15, 2012 at 10:58 PM, Jose wrote: Would you mind to provide an example of the use of flatMap?. I need to adapt old b56 code like this: Set lines(mapName){}; namesColl.flatMap(name -> lines(name)).into(...); to the new sintax but I have no idea how to start with (do I have to provide a Block.instance?) I made some web search on flatMap and jdk8 but everyone seems to be talking about Optional. And in the repos I couln't find a single example, only discussions about the sintax. -----Mensaje original----- De: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian Goetz Enviado el: jueves, 15 de noviembre de 2012 19:32 Para: lambda-dev at openjdk.java.net Asunto: Updated State of the Collections is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html From grundlefleck at gmail.com Fri Nov 16 04:33:49 2012 From: grundlefleck at gmail.com (Graham Allan) Date: Fri, 16 Nov 2012 12:33:49 +0000 Subject: Optional relationship to Sized, Stream and other In-Reply-To: References: Message-ID: Hi Michael, You may find lambda-dev eerily quiet when Optional is brought up. The discussion that lead to this post ( http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006365.html ) may give you some context on why that might be. HTH, Graham On 16 November 2012 11:20, Michael Nascimento wrote: > Hi guys, > > Just realized I missed Streamable as I took a look at the API, so > Optional could implement it instead of just having a stream() method. > > Regards, > Michael > > On Thu, Nov 15, 2012 at 11:38 PM, Michael Nascimento wrote: >> Hi folks, >> >> After finally taking a look at the latest Javadoc and thinking about >> it, I really think Optional could be better integrated with the >> Collections framework and Lambda libs if it: >> >> - Implemented Sized; >> - Had a stream() method, allowing map to be called on the final result >> only, for instance; >> - Had a toSet() method >> >> Regards, >> Michael > From sergey.kuksenko at oracle.com Fri Nov 16 05:38:19 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Fri, 16 Nov 2012 17:38:19 +0400 Subject: Updated State of the Collections In-Reply-To: <50A622DA.6697.576191@v.a.ammodytes.googlemail.com> References: <50A622DA.6697.576191@v.a.ammodytes.googlemail.com> Message-ID: <50A641CB.5070304@oracle.com> I have to note that suggested null handle example is not a filter. It is an assert and the following explicit methods would be useful: Stream assert(Predicate predicate); and one of (or both): Stream assert(Predicate predicate, Supplier throwFactory); or Stream assert(Predicate predicate, Supplier messageFactory); Open questions: - name of methods (assert is keyword), - to do connections with "-ea" option or not? On 11/16/2012 02:26 PM, Arne Siegel wrote: > Just one observation: the proposed way to handle the "error" strategy for nulls won't compile, > as it fails to comply the contract for a Predicate: > > filter(e -> { (if e == null) throw new NPE(); } > > > I can think of two compilable alternatives: > > filter(e -> { (if e == null) throw new NPE(); else return true; } > > tee(e -> { (if e == null) throw new NPE(); } > > > > On 15 Nov 2012 at 13:31, Brian Goetz wrote: > >> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >> > > > -- Best regards, Sergey Kuksenko From vitalyd at gmail.com Fri Nov 16 05:49:24 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 16 Nov 2012 08:49:24 -0500 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: <50A61F51.5010704@univ-mlv.fr> References: <20121115221957.C5B23479C1@hg.openjdk.java.net> <50A61F51.5010704@univ-mlv.fr> Message-ID: the constructor is private now so equals() is correct but I agree that marking as final and doing instanceof is more explicit. Also, doing exact class check is useful when you want symmetry in equality. Otherwise, Base.equals(Derived) may return true but Derived.equals(Base) will return false. Sent from my phone On Nov 16, 2012 6:14 AM, "Remi Forax" wrote: > On 11/15/2012 11:19 PM, brian.goetz at oracle.com wrote: > > Changeset: ab258565c0c9 > > Author: briangoetz > > Date: 2012-11-15 17:19 -0500 > > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > > > > Cleanup in Optional > > > > ! src/share/classes/java/util/Optional.java > > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > > > > > > Brian, > or Optional should be final, or you have to change equals() to do an > instanceof check. > but currently the implementation of equals is not correct. > > cheers, > R?mi > > From brian.goetz at oracle.com Fri Nov 16 06:42:08 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Nov 2012 09:42:08 -0500 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com> <80DA72BB0C954960BE954746D1610F25@Superx64> <22A79D4CA4F9481C9084F54DE5229A46@Superx64> Message-ID: <50A650C0.5010703@oracle.com> > But I see why they didn't write flatMap that way. In my example, I have > author.getBooks() which returns a collection. If I didn't have a method > like that, or I didn't want to create a throwaway collection just to hold > each author's books (which will all then get merged into one collection), > then if they only gave me a flatMap(A -> Collection) method I'd be > hosed. The fact that they give me the sink lets me pick and choose the > elements in the result individually from wherever I want. Exactly right. Not only is it extra work to create a throwaway collection (and its extra code in the lambda too, too -- try it), its also extra work for the library to iterate it on the other side. This overhead is at its worst when most elements map to zero or one elements (like a filter), where you're doing work to create and iterate an empty collection. We've received the feedback that this API is confusing from many people are are looking into it. Havnig a "convenience" version that lets you just provide a collection (if you've already got one lying around, as you did with author.getBooks()) would probably help. But, if we had to pick one primitive, the one we've got completely dominates the "map to collection" version because collections are too heavyweight. From brian.goetz at oracle.com Fri Nov 16 06:44:55 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Nov 2012 09:44:55 -0500 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com><80DA72BB0C954960BE954746D1610F25@Superx64><22A79D4CA4F9481C9084F54DE5229A46@Superx64> Message-ID: <50A65167.8080406@oracle.com> Mostly. Think of the Sink argument as the workaround for not having "yield" in the language. On 11/16/2012 6:26 AM, Jose wrote: > Thanks for the explanations! > > I think I'm starting to get the idea: > > - I don't have to see flatMap as function of two arguments, because I'm only > allowed to provide one. > - The first argument is just a workaround to access (but not to set) an > internal variable of the flapMap method. > - The way this argument is used in the flatMap body defines a concrete > flavor of the "old" flatMap version. > > I'm correct? > > > > > _____ > > De: Michael Hixson [mailto:michael.hixson at gmail.com] > Enviado el: viernes, 16 de noviembre de 2012 11:14 > Para: Jose > CC: lambda-dev at openjdk.java.net > Asunto: Re: Updated State of the Collections > > > The sink is provided to you by the stream - you don't create it yourself. > So in this example: > > List books = authors.stream() > .flatMap((sink, author) -> author.getBooks().forEach(sink)) > .into(new ArrayList()); > > the object behind the "sink" variable was created by the stream upon calling > .flatMap. The flatMap method is basically saying, "I'm giving you a sink. > It's what I'm using to build the result. For each author, use the sink to > mark which books will appear in the result." This lambda: > > (sink, author) -> author.getBooks().forEach(sink) > > instructs the sink to include every book for every author in the result. > > I agree that it's confusing. Without looking at the method signature, I > expected flatMap to do that dumping into the sink for me. Something like > this: > > // Note: this doesn't work > List books = authors.stream() > .flatMap(author -> author.getBooks()) > .into(new ArrayList()); > > But I see why they didn't write flatMap that way. In my example, I have > author.getBooks() which returns a collection. If I didn't have a method > like that, or I didn't want to create a throwaway collection just to hold > each author's books (which will all then get merged into one collection), > then if they only gave me a flatMap(A -> Collection) method I'd be hosed. > The fact that they give me the sink lets me pick and choose the elements in > the result individually from wherever I want. > > -Michael > > > On Fri, Nov 16, 2012 at 1:40 AM, Jose wrote: > > > > > So flatMap function has two arguments. For the second one you provide a > List of authors that you defined previously. > > But what about the first argument?, sink is just a variable, it has not > being initialized at any place > > I find this like defining the square function as: > > sq=(x,y)->y*y > > and then using it in this way > > sq(x,3)==9 > > > > > > -----Mensaje original----- > De: Michael Hixson [mailto:michael.hixson at gmail.com] > Enviado el: viernes, 16 de noviembre de 2012 8:30 > Para: Jose > CC: lambda-dev at openjdk.java.net > Asunto: Re: Updated State of the Collections > > > flatMap caused me a lot of trouble as well. Eventually I figured out you > can use it without casting, declaring anonymous classes, or using a helper > method like this: > > List authors = ... > // Assume author.getBooks() returns List List books = > authors.stream() > .flatMap((sink, author) -> author.getBooks().forEach(sink) > .into(new ArrayList()); > // Assume author.getDeceasedDate() returns Optional List > deceasedDates = authors.stream() > .flatMap(sink, author) -> > author.getDeceasedDate().ifPresent(sink)) > .into(new ArrayList()); > > The generic for the flatMap invocations (".flatMap" and > "flatMap" above) seem to be necessary. I don't know if that was > because of the IDE I was using (IntelliJ 12 EAP) or because that's just how > it has to be. > > > > On Thu, Nov 15, 2012 at 10:58 PM, Jose wrote: > > > > Would you mind to provide an example of the use of flatMap?. > > I need to adapt old b56 code like this: > > Set lines(mapName){}; > namesColl.flatMap(name -> lines(name)).into(...); > > to the new sintax but I have no idea how to start with (do I have to > provide > a Block.instance?) > > I made some web search on flatMap and jdk8 but everyone seems to be > talking > about Optional. > And in the repos I couln't find a single example, only discussions > about the > sintax. > > > > > -----Mensaje original----- > De: lambda-dev-bounces at openjdk.java.net > [mailto:lambda-dev-bounces at openjdk.java.net] En nombre de Brian > Goetz > Enviado el: jueves, 15 de noviembre de 2012 19:32 > Para: lambda-dev at openjdk.java.net > Asunto: Updated State of the Collections > > is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > > > > > > > > > > > From georgiy.rakov at oracle.com Fri Nov 16 06:49:50 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 16 Nov 2012 18:49:50 +0400 Subject: Infinite stream in parallel mode Message-ID: <50A6528E.9030203@oracle.com> Hello, I wonder if it is possible to process infinite stream in parallel mode now. Maybe it is going to be implemented later somehow? Thanks, Gerogiy. From forax at univ-mlv.fr Fri Nov 16 06:58:03 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 Nov 2012 15:58:03 +0100 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: References: <20121115221957.C5B23479C1@hg.openjdk.java.net> <50A61F51.5010704@univ-mlv.fr> Message-ID: <50A6547B.30509@univ-mlv.fr> On 11/16/2012 02:49 PM, Vitaly Davidovich wrote: > > the constructor is private now so equals() is correct but I agree that > marking as final and doing instanceof is more explicit. > You're right, but because I want to have the last word, the current implementation still allow to create an inner class that extends Optional. > Also, doing exact class check is useful when you want symmetry in > equality. Otherwise, Base.equals(Derived) may return true but > Derived.equals(Base) will return false. > That's by the way the main arguments against having a language with operator overloading but without explicit conversion. > Sent from my phone > R?mi > On Nov 16, 2012 6:14 AM, "Remi Forax" > wrote: > > On 11/15/2012 11:19 PM, brian.goetz at oracle.com > wrote: > > Changeset: ab258565c0c9 > > Author: briangoetz > > Date: 2012-11-15 17:19 -0500 > > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > > > > Cleanup in Optional > > > > ! src/share/classes/java/util/Optional.java > > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > > > > > > Brian, > or Optional should be final, or you have to change equals() to do an > instanceof check. > but currently the implementation of equals is not correct. > > cheers, > R?mi > From brian.goetz at oracle.com Fri Nov 16 07:06:13 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Nov 2012 10:06:13 -0500 Subject: Infinite stream in parallel mode In-Reply-To: <50A6528E.9030203@oracle.com> References: <50A6528E.9030203@oracle.com> Message-ID: <50A65665.7020900@oracle.com> We're almost there! There's a few pieces missing. 1. A Spliterator that can deal with arbitrary iterators. The obvious splitting strategy there is pretty weak; split into (first, rest). This can probably be improved by splitting into (first n, rest), where n varies with the number of splits. So the first split is (first, rest), the second split is (first two, rest), the next is (first four, rest) up until you hit some target size (derived from core count.) This lets early splits create some work to get some forking going faster, while later splits have lower task management overhead once the pool is hot. 2. Some way of canceling a source. Right now, the only way a computation on an infinite stream completes is that an intermediate operation (like limit) truncates the stream or the terminal operation (like findFirst) cancels the computation. But it is also useful to do something like: infiniteEventStream.parallel().forEach(...) and let it burn until you're "tired" (e.g., timer expires, shutdown is requested, an adequately good solution is found.) What we need is a way of wiring that termination criteria back into the source, so it says "no more elemnets" and the computation can quiesce naturally. (This latter one applies equally to serial and parallel modes.) On 11/16/2012 9:49 AM, Georgiy Rakov wrote: > Hello, > > I wonder if it is possible to process infinite stream in parallel mode now. > Maybe it is going to be implemented later somehow? > > Thanks, Gerogiy. > From pbenedict at apache.org Fri Nov 16 07:19:25 2012 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 16 Nov 2012 09:19:25 -0600 Subject: UniqOp -> UniqueOp In-Reply-To: <50A57097.3010509@oracle.com> References: <50A57097.3010509@oracle.com> Message-ID: Are you planning to rename these implementation-only packages to com.sun or org.openjdk or something else? I take that you need to get them out of the java.* namespace then. On Thu, Nov 15, 2012 at 4:45 PM, Brian Goetz wrote: > OK, but bear in mind the XxxOp classes are not going to be part of the > public API. These are strictly implementation-only. > > > On 11/15/2012 5:39 PM, Paul Benedict wrote: > >> I would like to propose renaming UniqOp to UniqueOp. I do not see any >> benefit in leaving off the last 2 letters in the word. I also do not see >> any other class in the package oddly abbreviated. >> >> From brian.goetz at oracle.com Fri Nov 16 07:27:40 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Nov 2012 10:27:40 -0500 Subject: UniqOp -> UniqueOp In-Reply-To: References: <50A57097.3010509@oracle.com> Message-ID: <50A65B6C.2090209@oracle.com> No, we intend to make them package-private until such time as we're ready to release and support the *Op API. On 11/16/2012 10:19 AM, Paul Benedict wrote: > Are you planning to rename these implementation-only packages to com.sun > or org.openjdk or something else? I take that you need to get them out > of the java.* namespace then. > > On Thu, Nov 15, 2012 at 4:45 PM, Brian Goetz > wrote: > > OK, but bear in mind the XxxOp classes are not going to be part of > the public API. These are strictly implementation-only. > > > On 11/15/2012 5:39 PM, Paul Benedict wrote: > > I would like to propose renaming UniqOp to UniqueOp. I do not > see any > benefit in leaving off the last 2 letters in the word. I also do > not see > any other class in the package oddly abbreviated. > > From zhong.j.yu at gmail.com Fri Nov 16 07:37:27 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Fri, 16 Nov 2012 09:37:27 -0600 Subject: void vs Void Message-ID: If a method returns Void, the method body must "return null;" somewhere. That is ugly in a lambda expression. Is it possible that the compiler adds the "return null" implicitly? Void foo(){ System.out.println("foo"); } Zhong Yu From paul.sandoz at oracle.com Fri Nov 16 07:45:16 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Nov 2012 15:45:16 +0000 Subject: hg: lambda/lambda/jdk: - where possible all intermediate ops tests use stream supplier Message-ID: <20121116154601.043D247A08@hg.openjdk.java.net> Changeset: 9363babb2172 Author: psandoz Date: 2012-11-16 16:44 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9363babb2172 - where possible all intermediate ops tests use stream supplier - hide away IntermediateOp[] usages in another builder. ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UnorderedStreamTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFilterOpTest.java From brian.goetz at oracle.com Fri Nov 16 07:57:03 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 16 Nov 2012 10:57:03 -0500 Subject: void vs Void In-Reply-To: References: Message-ID: <50A6624F.4010301@oracle.com> It is possible :) We had this on the list of things to clean up as part of this effort, but it looks like we're not going to have the time. On 11/16/2012 10:37 AM, Zhong Yu wrote: > If a method returns Void, the method body must "return null;" > somewhere. That is ugly in a lambda expression. Is it possible that > the compiler adds the "return null" implicitly? > > Void foo(){ System.out.println("foo"); } > > Zhong Yu > From paul.sandoz at oracle.com Fri Nov 16 08:04:00 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Nov 2012 16:04:00 +0000 Subject: hg: lambda/lambda/jdk: - exercise terminal ops using stream suppliers. Message-ID: <20121116160430.901B747A0A@hg.openjdk.java.net> Changeset: ba27872c81f8 Author: psandoz Date: 2012-11-16 17:03 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ba27872c81f8 - exercise terminal ops using stream suppliers. - update all relevant tests. ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java - test-ng/tests/org/openjdk/tests/java/util/stream/StreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java - test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamIntermediateOpTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From forax at univ-mlv.fr Fri Nov 16 08:39:30 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 Nov 2012 17:39:30 +0100 Subject: void vs Void In-Reply-To: <50A6624F.4010301@oracle.com> References: <50A6624F.4010301@oracle.com> Message-ID: <50A66C42.4050900@univ-mlv.fr> On 11/16/2012 04:57 PM, Brian Goetz wrote: > It is possible :) > > We had this on the list of things to clean up as part of this effort, > but it looks like we're not going to have the time. Zhong Yu, for your information, some members of the EG are also eager to have this, at least the ones that often implement some Visitor :) so this issue will not be fixed for Java 8 but will be fixed ASAP. R?mi > > On 11/16/2012 10:37 AM, Zhong Yu wrote: >> If a method returns Void, the method body must "return null;" >> somewhere. That is ugly in a lambda expression. Is it possible that >> the compiler adds the "return null" implicitly? >> >> Void foo(){ System.out.println("foo"); } >> >> Zhong Yu >> From zhong.j.yu at gmail.com Fri Nov 16 09:10:12 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Fri, 16 Nov 2012 11:10:12 -0600 Subject: void vs Void In-Reply-To: <50A66C42.4050900@univ-mlv.fr> References: <50A6624F.4010301@oracle.com> <50A66C42.4050900@univ-mlv.fr> Message-ID: On Fri, Nov 16, 2012 at 10:39 AM, Remi Forax wrote: > On 11/16/2012 04:57 PM, Brian Goetz wrote: >> It is possible :) >> >> We had this on the list of things to clean up as part of this effort, >> but it looks like we're not going to have the time. > > Zhong Yu, for your information, some members of the EG are also eager to > have this, > at least the ones that often implement some Visitor :) > so this issue will not be fixed for Java 8 but will be fixed ASAP. Cool. I guess the real problem is if we make another visitor class just for `void`, we'll have to name it, and naming is no fun. > > R?mi > >> >> On 11/16/2012 10:37 AM, Zhong Yu wrote: >>> If a method returns Void, the method body must "return null;" >>> somewhere. That is ugly in a lambda expression. Is it possible that >>> the compiler adds the "return null" implicitly? >>> >>> Void foo(){ System.out.println("foo"); } >>> >>> Zhong Yu >>> > > From brian.goetz at oracle.com Fri Nov 16 12:19:23 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 16 Nov 2012 20:19:23 +0000 Subject: hg: lambda/lambda/jdk: Clean up Streams API for constructing streams; move Array-related helpers (iterator, spliterator) into Arrays Message-ID: <20121116201936.CF8F347A17@hg.openjdk.java.net> Changeset: 3039509789a6 Author: briangoetz Date: 2012-11-16 15:18 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3039509789a6 Clean up Streams API for constructing streams; move Array-related helpers (iterator, spliterator) into Arrays ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/Nodes.java ! test-ng/tests/org/openjdk/tests/java/util/FillableStringTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java From mike.duigou at oracle.com Fri Nov 16 13:36:55 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 16 Nov 2012 13:36:55 -0800 Subject: Build failure on Mac "javac: invalid flag" In-Reply-To: References: Message-ID: <4CB057FF-1FA6-49CB-9EC4-7F39EED09D58@oracle.com> Very odd. Do you see the auxiliary class warnings? Mike On Nov 16 2012, at 01:40 , Paul Sandoz wrote: > Hi, > > For some reason the following change to jdk/makefiles/Setup.gmk results in a build failure: > > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/a4c10f71e673/makefiles/Setup.gmk > > Generating headers for jdk base classes > Compiling 886 files for BUILD_JOBJC_JAR > Compiling 886 files for BUILD_JOBJC_HEADERS_JAR > javac: invalid flag: -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass > Usage: javac > use -help for a list of possible options > make[2]: *** [/Users/sandoz/Projects/jdk8/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 2 > > Reverting the change fixed the problem for me. > > Paul. > From aruld at acm.org Fri Nov 16 13:57:27 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Fri, 16 Nov 2012 11:57:27 -1000 Subject: incompatible types compile error Message-ID: Hi, I am trying to run a slightly modified version from the latest State of the Lambda libraries edition. List sortedFavs = albums.stream() .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) .sorted(comparing((Mapper) album -> album.name)) .into(new ArrayList()); java: incompatible types: java.util.stream.Stream.Destination cannot be converted to java.util.List Any idea what could be wrong here? -Arul From forax at univ-mlv.fr Fri Nov 16 14:38:34 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 Nov 2012 23:38:34 +0100 Subject: incompatible types compile error In-Reply-To: References: Message-ID: <50A6C06A.2030301@univ-mlv.fr> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > Hi, > > I am trying to run a slightly modified version from the latest State of the > Lambda libraries edition. > > List sortedFavs = > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Mapper) album -> > album.name)) > .into(new ArrayList()); > > java: incompatible types: java.util.stream.Stream.Destination cannot be > converted to java.util.List > > Any idea what could be wrong here? the signature of the method into. > > -Arul > R?mi From aruld at acm.org Fri Nov 16 15:01:07 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Fri, 16 Nov 2012 13:01:07 -1000 Subject: incompatible types compile error In-Reply-To: <50A6C06A.2030301@univ-mlv.fr> References: <50A6C06A.2030301@univ-mlv.fr> Message-ID: This works, btw. List sortedFavs = new ArrayList(); albums.stream() .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) .sorted(comparing((Mapper) album -> album.name)) .into(sortedFavs); On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: > On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > > Hi, > > > > I am trying to run a slightly modified version from the latest State of > the > > Lambda libraries edition. > > > > List sortedFavs = > > albums.stream() > > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= > 4))) > > .sorted(comparing((Mapper) album -> > > album.name)) > > .into(new ArrayList()); > > > > java: incompatible types: java.util.stream.Stream.Destination cannot be > > converted to java.util.List > > > > Any idea what could be wrong here? > > the signature of the method into. > > > > > -Arul > > > > R?mi > > > From jonathan.gibbons at oracle.com Fri Nov 16 15:11:07 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 16 Nov 2012 15:11:07 -0800 Subject: Build failure on Mac "javac: invalid flag" In-Reply-To: <4CB057FF-1FA6-49CB-9EC4-7F39EED09D58@oracle.com> References: <4CB057FF-1FA6-49CB-9EC4-7F39EED09D58@oracle.com> Message-ID: <50A6C80B.8040804@oracle.com> Maybe indicative of the wrong compiler being used. -- Jon On 11/16/2012 01:36 PM, Mike Duigou wrote: > Very odd. > > Do you see the auxiliary class warnings? > > Mike > > On Nov 16 2012, at 01:40 , Paul Sandoz wrote: > >> Hi, >> >> For some reason the following change to jdk/makefiles/Setup.gmk results in a build failure: >> >> http://hg.openjdk.java.net/lambda/lambda/jdk/diff/a4c10f71e673/makefiles/Setup.gmk >> >> Generating headers for jdk base classes >> Compiling 886 files for BUILD_JOBJC_JAR >> Compiling 886 files for BUILD_JOBJC_HEADERS_JAR >> javac: invalid flag: -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass >> Usage: javac >> use -help for a list of possible options >> make[2]: *** [/Users/sandoz/Projects/jdk8/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 2 >> >> Reverting the change fixed the problem for me. >> >> Paul. >> > From mike.duigou at oracle.com Fri Nov 16 20:57:25 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 17 Nov 2012 04:57:25 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121117045748.E157647A23@hg.openjdk.java.net> Changeset: 9362e6b9866a Author: mduigou Date: 2012-11-16 18:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9362e6b9866a More renames and primitive specializations. sync with proposed TL patch ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/Combiner.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/FlatMapper.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/Functions.java ! src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java - src/share/classes/java/util/function/package.html ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java Changeset: c79261933eb2 Author: mduigou Date: 2012-11-16 18:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c79261933eb2 Merge From david.holmes at oracle.com Fri Nov 16 21:39:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Nov 2012 15:39:39 +1000 Subject: Build failure on Mac "javac: invalid flag" In-Reply-To: References: Message-ID: <50A7231B.6070207@oracle.com> Are you building langtools or importing? Looks like your javac is not the latest. David On 16/11/2012 7:40 PM, Paul Sandoz wrote: > Hi, > > For some reason the following change to jdk/makefiles/Setup.gmk results in a build failure: > > http://hg.openjdk.java.net/lambda/lambda/jdk/diff/a4c10f71e673/makefiles/Setup.gmk > > Generating headers for jdk base classes > Compiling 886 files for BUILD_JOBJC_JAR > Compiling 886 files for BUILD_JOBJC_HEADERS_JAR > javac: invalid flag: -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass > Usage: javac > use -help for a list of possible options > make[2]: *** [/Users/sandoz/Projects/jdk8/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 2 > > Reverting the change fixed the problem for me. > > Paul. > From mike.duigou at oracle.com Fri Nov 16 21:40:36 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 17 Nov 2012 05:40:36 +0000 Subject: hg: lambda/lambda/jdk: Move classes to packages so that jtreg doesn't get confused. Message-ID: <20121117054048.357BC47A26@hg.openjdk.java.net> Changeset: 97d337a98c67 Author: akhil Date: 2012-11-16 21:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/97d337a98c67 Move classes to packages so that jtreg doesn't get confused. ! test-ng/tests/org/openjdk/tests/vm/DefaultMethodsTest.java ! test-ng/tests/org/openjdk/tests/vm/StrictfpDefault.java ! test-ng/tests/org/openjdk/tests/vm/SynchronizedDefault.java From mike.duigou at oracle.com Fri Nov 16 21:42:54 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 17 Nov 2012 05:42:54 +0000 Subject: hg: lambda/lambda/jdk: additional ignores for jtreg, webrev and IDE Message-ID: <20121117054306.04C2247A27@hg.openjdk.java.net> Changeset: 789b1e626278 Author: akhil Date: 2012-11-16 21:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/789b1e626278 additional ignores for jtreg, webrev and IDE ! .hgignore From mike.duigou at oracle.com Fri Nov 16 21:48:19 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 17 Nov 2012 05:48:19 +0000 Subject: hg: lambda/lambda/jdk: ignore files that aren't tests Message-ID: <20121117054831.AF88347A28@hg.openjdk.java.net> Changeset: f0986f56995f Author: ksrini Date: 2012-11-16 21:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f0986f56995f ignore files that aren't tests ! test-ng/tests/org/openjdk/tests/vm/StrictfpDefault.java ! test-ng/tests/org/openjdk/tests/vm/SynchronizedDefault.java From mike.duigou at oracle.com Fri Nov 16 22:47:22 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 17 Nov 2012 06:47:22 +0000 Subject: hg: lambda/lambda/jdk: Add IntelliJ project Message-ID: <20121117064733.AF3DF47A29@hg.openjdk.java.net> Changeset: 74db42e35ed1 Author: mduigou Date: 2012-11-16 22:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74db42e35ed1 Add IntelliJ project + .idea/ant.xml + .idea/codeStyleSettings.xml + .idea/compiler.xml + .idea/encodings.xml + .idea/misc.xml + .idea/modules.xml + .idea/vcs.xml + combo-tests/tests/combo-tests.iml + test-ng/tests/tests.iml From brian.goetz at oracle.com Sat Nov 17 07:16:01 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 17 Nov 2012 15:16:01 +0000 Subject: hg: lambda/lambda/jdk: backout IDEA files Message-ID: <20121117151646.E7B8347A2C@hg.openjdk.java.net> Changeset: 9b67467f86bf Author: briangoetz Date: 2012-11-17 10:13 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b67467f86bf backout IDEA files - .idea/ant.xml - .idea/codeStyleSettings.xml - .idea/compiler.xml - .idea/encodings.xml - .idea/misc.xml - .idea/modules.xml - .idea/vcs.xml - combo-tests/tests/combo-tests.iml - test-ng/tests/tests.iml From brian.goetz at oracle.com Sat Nov 17 09:16:51 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 17 Nov 2012 17:16:51 +0000 Subject: hg: lambda/lambda/jdk: More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner Message-ID: <20121117171703.5917747A2D@hg.openjdk.java.net> Changeset: 112b2a64495a Author: briangoetz Date: 2012-11-17 12:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/112b2a64495a More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/Combiner.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/FlatMapper.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/Functions.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/Predicates.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/op/ConcatOp.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/FilterOp.java ! src/share/classes/java/util/stream/op/FlatMapOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/MapOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/TeeOp.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntBlock.java ! src/share/classes/java/util/stream/primitive/IntIterable.java ! src/share/classes/java/util/stream/primitive/IntIterator.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSpliterator.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/function/FunctionsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java From brian.goetz at oracle.com Sat Nov 17 09:31:17 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 17 Nov 2012 17:31:17 +0000 Subject: hg: lambda/lambda/jdk: One more rename missed by previous checkin Message-ID: <20121117173128.DC42647A30@hg.openjdk.java.net> Changeset: 7c6e15368d4d Author: briangoetz Date: 2012-11-17 12:31 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7c6e15368d4d One more rename missed by previous checkin ! src/share/classes/java/util/stream/op/ForEachOp.java From maurice at morninglight.co.uk Sat Nov 17 09:37:38 2012 From: maurice at morninglight.co.uk (Maurice Naftalin) Date: Sat, 17 Nov 2012 17:37:38 +0000 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com> <50A54D8B.60900@oracle.com> Message-ID: I've put the latest Javadocs online as part of the lambda FAQ. They are linked from this page: http://lambdafaq.org/resources. They'll be kept up to date at least until Oracle have a version online. Regards Maurice On 15 Nov 2012, at 20:19, Michael Nascimento wrote: > Totally missed that, Brian, thanks. Still, having them online would be > awesome. :-) > > Regards, > Michael > > On Thu, Nov 15, 2012 at 6:16 PM, Brian Goetz wrote: >> Javadocs are available on the lambda download page at: >> >> http://jdk8.java.net/lambda/ >> >> They are updated when we update the binary builds. >> >> >> On 11/15/2012 3:05 PM, Michael Nascimento wrote: >>> >>> Hi Brian, >>> >>> I think Lambda lib efforts would be a lot easier to follow if Javadoc >>> was available online somewhere and updated every now and then. Is it >>> possible to do that? >>> >>> Regards, >>> Michael >>> >>> On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz >>> wrote: >>>> >>>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >>>> >> > From forax at univ-mlv.fr Sat Nov 17 09:45:02 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 17 Nov 2012 18:45:02 +0100 Subject: hg: lambda/lambda/jdk: More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner In-Reply-To: <20121117171703.5917747A2D@hg.openjdk.java.net> References: <20121117171703.5917747A2D@hg.openjdk.java.net> Message-ID: <50A7CD1E.8030900@univ-mlv.fr> Brian, Paul, it seams there is two IntBlock, one in j.u.function and one in j.u.stream.primitive. The one in primitive should be removed or there is something I don't understand. R?mi On 11/17/2012 06:16 PM, brian.goetz at oracle.com wrote: > Changeset: 112b2a64495a > Author: briangoetz > Date: 2012-11-17 12:16 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/112b2a64495a > > More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner > > ! src/share/classes/java/lang/CharSequence.java > ! src/share/classes/java/lang/Iterable.java > ! src/share/classes/java/util/Arrays.java > ! src/share/classes/java/util/Comparators.java > ! src/share/classes/java/util/Iterator.java > ! src/share/classes/java/util/Iterators.java > ! src/share/classes/java/util/Optional.java > ! src/share/classes/java/util/function/BiFunction.java > ! src/share/classes/java/util/function/BinaryOperator.java > ! src/share/classes/java/util/function/Block.java > ! src/share/classes/java/util/function/Combiner.java > ! src/share/classes/java/util/function/DoubleBlock.java > ! src/share/classes/java/util/function/DoubleFunction.java > ! src/share/classes/java/util/function/FlatMapper.java > ! src/share/classes/java/util/function/Function.java > ! src/share/classes/java/util/function/Functions.java > ! src/share/classes/java/util/function/IntBlock.java > ! src/share/classes/java/util/function/IntFunction.java > ! src/share/classes/java/util/function/LongBlock.java > ! src/share/classes/java/util/function/LongFunction.java > ! src/share/classes/java/util/function/Predicates.java > ! src/share/classes/java/util/function/UnaryOperator.java > ! src/share/classes/java/util/stream/ReferencePipeline.java > ! src/share/classes/java/util/stream/Spliterator.java > ! src/share/classes/java/util/stream/Stream.java > ! src/share/classes/java/util/stream/op/ConcatOp.java > ! src/share/classes/java/util/stream/op/CumulateOp.java > ! src/share/classes/java/util/stream/op/FilterOp.java > ! src/share/classes/java/util/stream/op/FlatMapOp.java > ! src/share/classes/java/util/stream/op/FoldOp.java > ! src/share/classes/java/util/stream/op/ForEachOp.java > ! src/share/classes/java/util/stream/op/GroupByOp.java > ! src/share/classes/java/util/stream/op/MapOp.java > ! src/share/classes/java/util/stream/op/MatchOp.java > ! src/share/classes/java/util/stream/op/Nodes.java > ! src/share/classes/java/util/stream/op/ReduceByOp.java > ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java > ! src/share/classes/java/util/stream/op/SliceOp.java > ! src/share/classes/java/util/stream/op/SortedOp.java > ! src/share/classes/java/util/stream/op/TeeOp.java > ! src/share/classes/java/util/stream/op/UniqOp.java > ! src/share/classes/java/util/stream/primitive/IntBlock.java > ! src/share/classes/java/util/stream/primitive/IntIterable.java > ! src/share/classes/java/util/stream/primitive/IntIterator.java > ! src/share/classes/java/util/stream/primitive/IntNodes.java > ! src/share/classes/java/util/stream/primitive/IntSpliterator.java > ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java > ! src/share/classes/java/util/stream/primitive/Primitives.java > ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java > ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java > ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java > ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java > ! test-ng/tests/org/openjdk/tests/java/util/function/FunctionsTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java > ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java > ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java > > From brian.goetz at oracle.com Sat Nov 17 10:29:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 17 Nov 2012 13:29:57 -0500 Subject: hg: lambda/lambda/jdk: More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner In-Reply-To: <50A7CD1E.8030900@univ-mlv.fr> References: <20121117171703.5917747A2D@hg.openjdk.java.net> <50A7CD1E.8030900@univ-mlv.fr> Message-ID: <50A7D7A5.2010002@oracle.com> Yes, the primitives stuff is still in a very raw state, and the lambda (sandbox) repo currently represents the union of two independent efforts -- Mike's effort to get the initial set of SAMs cleaned up and put back to jdk8 (since all the other pieces depend at least on that) and Paul's effort to get a minimal implementation of primitives working. Once we're satisfied that the approach is sound and that we have reasonable test coverage (in progress), we'll work on rationalizing things, which include both the issue you raise (duplication of SAMs) as well as the fact that many of the terminal op implementations (and some of the stateful ones) can be merged to act on multiple shapes (so we can have one ForEachOp for all shapes rather than one for each shape.) Since we have not a lot of time left to get everything done, and there is still plenty of work to do before things settle, the chaos level is pretty high. On 11/17/2012 12:45 PM, Remi Forax wrote: > Brian, Paul, > it seams there is two IntBlock, one in j.u.function and one in > j.u.stream.primitive. > The one in primitive should be removed or there is something I don't > understand. > > R?mi > > On 11/17/2012 06:16 PM, brian.goetz at oracle.com wrote: >> Changeset: 112b2a64495a >> Author: briangoetz >> Date: 2012-11-17 12:16 -0500 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/112b2a64495a >> >> More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner >> >> ! src/share/classes/java/lang/CharSequence.java >> ! src/share/classes/java/lang/Iterable.java >> ! src/share/classes/java/util/Arrays.java >> ! src/share/classes/java/util/Comparators.java >> ! src/share/classes/java/util/Iterator.java >> ! src/share/classes/java/util/Iterators.java >> ! src/share/classes/java/util/Optional.java >> ! src/share/classes/java/util/function/BiFunction.java >> ! src/share/classes/java/util/function/BinaryOperator.java >> ! src/share/classes/java/util/function/Block.java >> ! src/share/classes/java/util/function/Combiner.java >> ! src/share/classes/java/util/function/DoubleBlock.java >> ! src/share/classes/java/util/function/DoubleFunction.java >> ! src/share/classes/java/util/function/FlatMapper.java >> ! src/share/classes/java/util/function/Function.java >> ! src/share/classes/java/util/function/Functions.java >> ! src/share/classes/java/util/function/IntBlock.java >> ! src/share/classes/java/util/function/IntFunction.java >> ! src/share/classes/java/util/function/LongBlock.java >> ! src/share/classes/java/util/function/LongFunction.java >> ! src/share/classes/java/util/function/Predicates.java >> ! src/share/classes/java/util/function/UnaryOperator.java >> ! src/share/classes/java/util/stream/ReferencePipeline.java >> ! src/share/classes/java/util/stream/Spliterator.java >> ! src/share/classes/java/util/stream/Stream.java >> ! src/share/classes/java/util/stream/op/ConcatOp.java >> ! src/share/classes/java/util/stream/op/CumulateOp.java >> ! src/share/classes/java/util/stream/op/FilterOp.java >> ! src/share/classes/java/util/stream/op/FlatMapOp.java >> ! src/share/classes/java/util/stream/op/FoldOp.java >> ! src/share/classes/java/util/stream/op/ForEachOp.java >> ! src/share/classes/java/util/stream/op/GroupByOp.java >> ! src/share/classes/java/util/stream/op/MapOp.java >> ! src/share/classes/java/util/stream/op/MatchOp.java >> ! src/share/classes/java/util/stream/op/Nodes.java >> ! src/share/classes/java/util/stream/op/ReduceByOp.java >> ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java >> ! src/share/classes/java/util/stream/op/SliceOp.java >> ! src/share/classes/java/util/stream/op/SortedOp.java >> ! src/share/classes/java/util/stream/op/TeeOp.java >> ! src/share/classes/java/util/stream/op/UniqOp.java >> ! src/share/classes/java/util/stream/primitive/IntBlock.java >> ! src/share/classes/java/util/stream/primitive/IntIterable.java >> ! src/share/classes/java/util/stream/primitive/IntIterator.java >> ! src/share/classes/java/util/stream/primitive/IntNodes.java >> ! src/share/classes/java/util/stream/primitive/IntSpliterator.java >> ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java >> ! src/share/classes/java/util/stream/primitive/Primitives.java >> ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java >> ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java >> ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java >> ! test-ng/tests/org/openjdk/tests/java/util/function/FunctionsTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java >> ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java >> ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java >> >> > > From maurice at morninglight.co.uk Sat Nov 17 12:33:13 2012 From: maurice at morninglight.co.uk (Maurice Naftalin) Date: Sat, 17 Nov 2012 20:33:13 +0000 Subject: Updated State of the Collections In-Reply-To: <50A7D6DA.8010804@oracle.com> References: <50A53504.2030407@oracle.com> <50A54D8B.60900@oracle.com> <50A7D6DA.8010804@oracle.com> Message-ID: <50A7F489.4090007@morninglight.co.uk> Sorry! That should have been http://www.lambdafaq.org/lambda-resources/ The link is at the beginning of the second section. On 17/11/2012 18:26, Brian Goetz wrote: > Thanks! But when I go there, I get "Not Found". > > On 11/17/2012 12:37 PM, Maurice Naftalin wrote: >> I've put the latest Javadocs online as part of the lambda FAQ. They >> are >> linked from this page: http://lambdafaq.org/resources. They'll be >> kept up >> to date at least until Oracle have a version online. >> >> Regards >> Maurice >> >> On 15 Nov 2012, at 20:19, Michael Nascimento wrote: >> >>> Totally missed that, Brian, thanks. Still, having them online would be >>> awesome. :-) >>> >>> Regards, >>> Michael >>> >>> On Thu, Nov 15, 2012 at 6:16 PM, Brian Goetz >>> wrote: >>>> Javadocs are available on the lambda download page at: >>>> >>>> http://jdk8.java.net/lambda/ >>>> >>>> They are updated when we update the binary builds. >>>> >>>> >>>> On 11/15/2012 3:05 PM, Michael Nascimento wrote: >>>>> >>>>> Hi Brian, >>>>> >>>>> I think Lambda lib efforts would be a lot easier to follow if Javadoc >>>>> was available online somewhere and updated every now and then. Is it >>>>> possible to do that? >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz >>>>> wrote: >>>>>> >>>>>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >>>>>> >>>> >>> >> >> From v.a.ammodytes at googlemail.com Sun Nov 18 04:38:37 2012 From: v.a.ammodytes at googlemail.com (Arne Siegel) Date: Sun, 18 Nov 2012 13:38:37 +0100 Subject: Updated State of the Collections In-Reply-To: <50A641CB.5070304@oracle.com> References: <50A622DA.6697.576191@v.a.ammodytes.googlemail.com> Message-ID: <50A8E4DD.17106.55438D8@v.a.ammodytes.googlemail.com> Another possible way to express the not-null-ness requirement in the current API: .map(Objects::requireNonNull) Or, when desiring control of the NPE message: .map(e -> Objects.requireNonNull(e, "null disallowed in stream")) Best regards Arne Siegel On 16 Nov 2012 at 17:38, Sergey Kuksenko wrote: > I have to note that suggested null handle example is not a filter. It is > an assert and the following explicit methods would be useful: > > Stream assert(Predicate predicate); > > and one of (or both): > > Stream assert(Predicate predicate, Supplier > throwFactory); > or > Stream assert(Predicate predicate, Supplier > messageFactory); > > > Open questions: > - name of methods (assert is keyword), > - to do connections with "-ea" option or not? > > > On 11/16/2012 02:26 PM, Arne Siegel wrote: > > Just one observation: the proposed way to handle the "error" strategy for nulls won't compile, > > as it fails to comply the contract for a Predicate: > > > > filter(e -> { (if e == null) throw new NPE(); } > > > > > > I can think of two compilable alternatives: > > > > filter(e -> { (if e == null) throw new NPE(); else return true; } > > > > tee(e -> { (if e == null) throw new NPE(); } > > > > > > > > On 15 Nov 2012 at 13:31, Brian Goetz wrote: > > > >> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > >> > > > > > > > > > -- > Best regards, > Sergey Kuksenko > From brian.goetz at oracle.com Sun Nov 18 09:35:09 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 18 Nov 2012 12:35:09 -0500 Subject: Updated State of the Collections In-Reply-To: <50A8E4DD.17106.55438D8@v.a.ammodytes.googlemail.com> References: <50A622DA.6697.576191@v.a.ammodytes.googlemail.com> <50A8E4DD.17106.55438D8@v.a.ammodytes.googlemail.com> Message-ID: <50A91C4D.4040407@oracle.com> Exactly right. The benefit of the current approach is that allows users to simulate any of the other approaches (filter nulls, throw on nulls) relatively easily. The disadvantage of the current approach is it requires users to reason about nulls in error-prone ways, and people are likely to be caught off guard by not realizing that their sources might contain nulls. On 11/18/2012 7:38 AM, Arne Siegel wrote: > Another possible way to express the not-null-ness requirement in the current API: > > .map(Objects::requireNonNull) > > > Or, when desiring control of the NPE message: > > .map(e -> Objects.requireNonNull(e, "null disallowed in stream")) > > > Best regards > Arne Siegel > > > > On 16 Nov 2012 at 17:38, Sergey Kuksenko wrote: > >> I have to note that suggested null handle example is not a filter. It is >> an assert and the following explicit methods would be useful: >> >> Stream assert(Predicate predicate); >> >> and one of (or both): >> >> Stream assert(Predicate predicate, Supplier >> throwFactory); >> or >> Stream assert(Predicate predicate, Supplier >> messageFactory); >> >> >> Open questions: >> - name of methods (assert is keyword), >> - to do connections with "-ea" option or not? >> >> >> On 11/16/2012 02:26 PM, Arne Siegel wrote: >>> Just one observation: the proposed way to handle the "error" strategy for nulls won't compile, >>> as it fails to comply the contract for a Predicate: >>> >>> filter(e -> { (if e == null) throw new NPE(); } >>> >>> >>> I can think of two compilable alternatives: >>> >>> filter(e -> { (if e == null) throw new NPE(); else return true; } >>> >>> tee(e -> { (if e == null) throw new NPE(); } >>> >>> >>> >>> On 15 Nov 2012 at 13:31, Brian Goetz wrote: >>> >>>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >>>> >>> >>> >>> >> >> >> -- >> Best regards, >> Sergey Kuksenko >> > > > From brian.goetz at oracle.com Sun Nov 18 10:57:33 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sun, 18 Nov 2012 18:57:33 +0000 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists Message-ID: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> Changeset: f7c32272e02f Author: briangoetz Date: 2012-11-18 13:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f7c32272e02f Streams cleanups; add optimized forEach implementations; include subList in tested lists ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/Streams.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java From forax at univ-mlv.fr Sun Nov 18 11:57:49 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 18 Nov 2012 20:57:49 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> Message-ID: <50A93DBD.2060508@univ-mlv.fr> On 11/18/2012 07:57 PM, brian.goetz at oracle.com wrote: > Changeset: f7c32272e02f > Author: briangoetz > Date: 2012-11-18 13:56 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f7c32272e02f > > Streams cleanups; add optimized forEach implementations; include subList in tested lists > > ! src/share/classes/java/util/ArrayList.java > ! src/share/classes/java/util/Arrays.java > ! src/share/classes/java/util/Vector.java > ! src/share/classes/java/util/stream/Spliterator.java > ! src/share/classes/java/util/stream/Streams.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java > > Brian, the code of ArrayList.forEach should be: Object[] elementData = this.elementData; int size = this.size; if (size > elementData.length) throw new ConcurrentModificationException(); int modCount = this.modCount; for (int i=0; i { arraylist.remove(e); }) The modCount check will be hoisted by the VM if it can prove that the block doesn't change modCount. Also most of the implementations of java.util that uses array, tend to do the cast when the objects are pull out of the array instead of casting the array to E[]. R?mi From brian.goetz at oracle.com Sun Nov 18 12:28:39 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 18 Nov 2012 15:28:39 -0500 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <50A93DBD.2060508@univ-mlv.fr> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> Message-ID: <50A944F7.5040508@oracle.com> > A code like this should throw a CME and not an AIOOBE > arraylist.forEach(e -> { arraylist.remove(e); }) The current code won't do that, as it copies the array into a local var before the loop, so the indexes are always valid. A reasonable middle ground is a comodification check after the loop terminates. From forax at univ-mlv.fr Sun Nov 18 13:00:22 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 18 Nov 2012 22:00:22 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <50A944F7.5040508@oracle.com> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> Message-ID: <50A94C66.10602@univ-mlv.fr> On 11/18/2012 09:28 PM, Brian Goetz wrote: >> A code like this should throw a CME and not an AIOOBE >> arraylist.forEach(e -> { arraylist.remove(e); }) > > The current code won't do that, as it copies the array into a local > var before the loop, so the indexes are always valid. the index may be valid but not the content of the array. > > A reasonable middle ground is a comodification check after the loop > terminates. > R?mi From mike.duigou at oracle.com Sun Nov 18 13:05:30 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 18 Nov 2012 13:05:30 -0800 Subject: hg: lambda/lambda/jdk: More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner In-Reply-To: <50A7CD1E.8030900@univ-mlv.fr> References: <20121117171703.5917747A2D@hg.openjdk.java.net> <50A7CD1E.8030900@univ-mlv.fr> Message-ID: <2E760C16-D986-4BB9-BBD3-8E974C721C29@oracle.com> I was pretty sure I had moved the ones from primitives. I will check again. Mike On Nov 17 2012, at 09:45 , Remi Forax wrote: > Brian, Paul, > it seams there is two IntBlock, one in j.u.function and one in > j.u.stream.primitive. > The one in primitive should be removed or there is something I don't > understand. > > R?mi > > On 11/17/2012 06:16 PM, brian.goetz at oracle.com wrote: >> Changeset: 112b2a64495a >> Author: briangoetz >> Date: 2012-11-17 12:16 -0500 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/112b2a64495a >> >> More renames: Block.apply -> Block.accept; revert type parameter order change for Function,BiFunction,Combiner >> >> ! src/share/classes/java/lang/CharSequence.java >> ! src/share/classes/java/lang/Iterable.java >> ! src/share/classes/java/util/Arrays.java >> ! src/share/classes/java/util/Comparators.java >> ! src/share/classes/java/util/Iterator.java >> ! src/share/classes/java/util/Iterators.java >> ! src/share/classes/java/util/Optional.java >> ! src/share/classes/java/util/function/BiFunction.java >> ! src/share/classes/java/util/function/BinaryOperator.java >> ! src/share/classes/java/util/function/Block.java >> ! src/share/classes/java/util/function/Combiner.java >> ! src/share/classes/java/util/function/DoubleBlock.java >> ! src/share/classes/java/util/function/DoubleFunction.java >> ! src/share/classes/java/util/function/FlatMapper.java >> ! src/share/classes/java/util/function/Function.java >> ! src/share/classes/java/util/function/Functions.java >> ! src/share/classes/java/util/function/IntBlock.java >> ! src/share/classes/java/util/function/IntFunction.java >> ! src/share/classes/java/util/function/LongBlock.java >> ! src/share/classes/java/util/function/LongFunction.java >> ! src/share/classes/java/util/function/Predicates.java >> ! src/share/classes/java/util/function/UnaryOperator.java >> ! src/share/classes/java/util/stream/ReferencePipeline.java >> ! src/share/classes/java/util/stream/Spliterator.java >> ! src/share/classes/java/util/stream/Stream.java >> ! src/share/classes/java/util/stream/op/ConcatOp.java >> ! src/share/classes/java/util/stream/op/CumulateOp.java >> ! src/share/classes/java/util/stream/op/FilterOp.java >> ! src/share/classes/java/util/stream/op/FlatMapOp.java >> ! src/share/classes/java/util/stream/op/FoldOp.java >> ! src/share/classes/java/util/stream/op/ForEachOp.java >> ! src/share/classes/java/util/stream/op/GroupByOp.java >> ! src/share/classes/java/util/stream/op/MapOp.java >> ! src/share/classes/java/util/stream/op/MatchOp.java >> ! src/share/classes/java/util/stream/op/Nodes.java >> ! src/share/classes/java/util/stream/op/ReduceByOp.java >> ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java >> ! src/share/classes/java/util/stream/op/SliceOp.java >> ! src/share/classes/java/util/stream/op/SortedOp.java >> ! src/share/classes/java/util/stream/op/TeeOp.java >> ! src/share/classes/java/util/stream/op/UniqOp.java >> ! src/share/classes/java/util/stream/primitive/IntBlock.java >> ! src/share/classes/java/util/stream/primitive/IntIterable.java >> ! src/share/classes/java/util/stream/primitive/IntIterator.java >> ! src/share/classes/java/util/stream/primitive/IntNodes.java >> ! src/share/classes/java/util/stream/primitive/IntSpliterator.java >> ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java >> ! src/share/classes/java/util/stream/primitive/Primitives.java >> ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java >> ! test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java >> ! test-ng/tests/org/openjdk/tests/java/util/NullArgsTestCase.java >> ! test-ng/tests/org/openjdk/tests/java/util/function/FunctionsTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java >> ! test-ng/tests/org/openjdk/tests/javac/LambdaTranslationTest1.java >> ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestInstanceMethod.java >> >> > > From brian.goetz at oracle.com Sun Nov 18 20:54:05 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 19 Nov 2012 04:54:05 +0000 Subject: hg: lambda/lambda/jdk: Add minBy(Comparator), maxBy(Comparator) Message-ID: <20121119045423.A88D047A44@hg.openjdk.java.net> Changeset: b5c2376af431 Author: briangoetz Date: 2012-11-18 23:51 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b5c2376af431 Add minBy(Comparator), maxBy(Comparator) ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/MinMaxByTest.java From boaznahum at gmail.com Mon Nov 19 00:43:22 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 19 Nov 2012 10:43:22 +0200 Subject: Question: Primitives functioanl classes Message-ID: I see that in some cases you preserve the original method name IntUnaryOperator { public default Integer operate(Integer operand) { return operate((int) operand); } public int operate(int operand); ----------------------------------------------------- IntBlock { public default void accept(Integer t) { apply((int) t); } public void apply(int t); But in others, you introduce new method name: IntFunction { public default Integer apply(T t) { return applyAsInt(t); } public int applyAsInt(T t) ----------------------------------------------------- IntSupplier { public default Integer get() { return getAsInt(); } public int getAsInt() ----------------------------------------------------- What problems were caused when tried to persevere the original name in the last two examples Thanks Boaz From boaznahum at gmail.com Mon Nov 19 00:53:09 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 19 Nov 2012 10:53:09 +0200 Subject: Bind parameters in BiXXX (lifting) Message-ID: If find it usfull in some places if I can convert BiXXX to unary, for example public interface BiFunction { R map(T t, U u); Function bind1(T p1) default { return (u) -> {return map(p1,u); }; } } --------------------- BiFunction add = (a,b)->{return ((int)a) + b;}; Function inc = add.bind1(1); Thanks Boaz From paul.sandoz at oracle.com Mon Nov 19 01:12:37 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Nov 2012 10:12:37 +0100 Subject: Build failure on Mac "javac: invalid flag" In-Reply-To: <4CB057FF-1FA6-49CB-9EC4-7F39EED09D58@oracle.com> References: <4CB057FF-1FA6-49CB-9EC4-7F39EED09D58@oracle.com> Message-ID: On Nov 16, 2012, at 10:36 PM, Mike Duigou wrote: > Very odd. > BTW, i am using the new build system and building everything. Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 * Boot JDK: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home > Do you see the auxiliary class warnings? > Yes, with my patch e.g.: Compiling 9451 files for BUILD_JDK /Users/sandoz/Projects/jdk8/lambda/jdk/src/share/classes/java/util/stream/op/FindAnyOp.java:71: warning: auxiliary class AbstractShortCircuitTask in /Users/sandoz/Projects/jdk8/lambda/jdk/src/share/classes/java/util/stream/op/AbstractTask.java should not be accessed from outside its own source file private static class FindAnyTask extends AbstractShortCircuitTask, FindAnyTask> { Without my patch i see no such warnings (the above source file compiles fine). The error seems to be related to compiling the Mac specific Java source, perhaps using the boot JDK? Paul. From paul.sandoz at oracle.com Mon Nov 19 01:16:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Nov 2012 10:16:39 +0100 Subject: Question: Primitives functioanl classes In-Reply-To: References: Message-ID: On Nov 19, 2012, at 9:43 AM, Boaz Nahum wrote: > I see that in some cases you preserve the original method name > > IntUnaryOperator { > > public default Integer operate(Integer operand) { return operate((int) > operand); } > > public int operate(int operand); > ----------------------------------------------------- > IntBlock { > public default void accept(Integer t) { apply((int) t); } > > public void apply(int t); > There is a glitch in IntBlock we need to fix. The method names are inconsistent, it should be "accept(int i)". > > But in others, you introduce new method name: > > IntFunction { > > public default Integer apply(T t) { return applyAsInt(t); } > > public int applyAsInt(T t) > ----------------------------------------------------- > > > IntSupplier { > > public default Integer get() { return getAsInt(); } > > public int getAsInt() > ----------------------------------------------------- > > > What problems were caused when tried to persevere the original name in the > last two examples > The return type is different. Paul. From paul.sandoz at oracle.com Mon Nov 19 01:47:59 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Nov 2012 10:47:59 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <50A944F7.5040508@oracle.com> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> Message-ID: On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: >> A code like this should throw a CME and not an AIOOBE >> arraylist.forEach(e -> { arraylist.remove(e); }) > > The current code won't do that, as it copies the array into a local var > before the loop, so the indexes are always valid. > > A reasonable middle ground is a comodification check after the loop > terminates. > Yes, that's what Mike did with the original array proxy stuff. It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. Paul. From filipp.zhinkin at oracle.com Mon Nov 19 01:55:06 2012 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 19 Nov 2012 13:55:06 +0400 Subject: javac throwing NPE at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply Message-ID: <50AA01FA.2080503@oracle.com> Hi, I've found that following code force javac to throw NullPointerException: public class NPE { public static void main(String args[]) { // "cannot find symbol" error is expected new Integer(0).forEach(System.out::println); } } $java -version openjdk version "1.8.0-ea" OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) OpenJDK Server VM (build 25.0-b05, mixed mode) $javac NPE.java An exception has occurred in the compiler (1.8.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1197) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1395) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:173) at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1226) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitBlock(Flow.java:960) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:839) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitMethodDef(Flow.java:927) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:723) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:890) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:645) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1277) at com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1267) at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:210) at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1297) at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1271) at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:911) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:870) at com.sun.tools.javac.main.Main.compile(Main.java:441) at com.sun.tools.javac.main.Main.compile(Main.java:358) at com.sun.tools.javac.main.Main.compile(Main.java:347) at com.sun.tools.javac.main.Main.compile(Main.java:338) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) With method reference replaced by lambda expression javac will report semantic error as expected: public class SemError { public static void main(String args[]) { new Integer(0).forEach((x) -> { System.out.println(x); }); } } $javac SemError.java SemError.java:3: error: cannot find symbol new Integer(0).forEach((x) -> { System.out.println(x); }); ^ symbol: method forEach() location: class Integer 1 error Hope it will be useful. Filipp. From forax at univ-mlv.fr Mon Nov 19 02:51:11 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Nov 2012 11:51:11 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> Message-ID: <50AA0F1F.8050107@univ-mlv.fr> On 11/19/2012 10:47 AM, Paul Sandoz wrote: > On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: > >>> A code like this should throw a CME and not an AIOOBE >>> arraylist.forEach(e -> { arraylist.remove(e); }) >> The current code won't do that, as it copies the array into a local var >> before the loop, so the indexes are always valid. >> >> A reasonable middle ground is a comodification check after the loop >> terminates. >> > Yes, that's what Mike did with the original array proxy stuff. > > It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. The question is why ArrayList.forEach should not be fail-fast ? java.util collection iterators are fail-fast, I think that forEach on such collections should be fail-fast too, just to have a clean defined semantics. > > Paul. > > R?mi From misterm at gmail.com Mon Nov 19 02:58:07 2012 From: misterm at gmail.com (Michael Nascimento) Date: Mon, 19 Nov 2012 08:58:07 -0200 Subject: Updated State of the Collections In-Reply-To: References: <50A53504.2030407@oracle.com> <50A54D8B.60900@oracle.com> Message-ID: Great news - or as I said before, awesome! :-) Thanks a lot! Regards, Michael On Sat, Nov 17, 2012 at 3:37 PM, Maurice Naftalin wrote: > I've put the latest Javadocs online as part of the lambda FAQ. They are > linked from this page: http://lambdafaq.org/resources. They'll be kept up > to date at least until Oracle have a version online. > > Regards > Maurice > > On 15 Nov 2012, at 20:19, Michael Nascimento wrote: > >> Totally missed that, Brian, thanks. Still, having them online would be >> awesome. :-) >> >> Regards, >> Michael >> >> On Thu, Nov 15, 2012 at 6:16 PM, Brian Goetz wrote: >>> Javadocs are available on the lambda download page at: >>> >>> http://jdk8.java.net/lambda/ >>> >>> They are updated when we update the binary builds. >>> >>> >>> On 11/15/2012 3:05 PM, Michael Nascimento wrote: >>>> >>>> Hi Brian, >>>> >>>> I think Lambda lib efforts would be a lot easier to follow if Javadoc >>>> was available online somewhere and updated every now and then. Is it >>>> possible to do that? >>>> >>>> Regards, >>>> Michael >>>> >>>> On Thu, Nov 15, 2012 at 4:31 PM, Brian Goetz >>>> wrote: >>>>> >>>>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html >>>>> >>> >> > From paul.sandoz at oracle.com Mon Nov 19 04:53:40 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Nov 2012 13:53:40 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <50AA0F1F.8050107@univ-mlv.fr> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> <50AA0F1F.8050107@univ-mlv.fr> Message-ID: <8B792744-C399-45F6-B10D-EB0C28A96ACA@oracle.com> On Nov 19, 2012, at 11:51 AM, Remi Forax wrote: > On 11/19/2012 10:47 AM, Paul Sandoz wrote: >> On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: >> >>>> A code like this should throw a CME and not an AIOOBE >>>> arraylist.forEach(e -> { arraylist.remove(e); }) >>> The current code won't do that, as it copies the array into a local var >>> before the loop, so the indexes are always valid. >>> >>> A reasonable middle ground is a comodification check after the loop >>> terminates. >>> >> Yes, that's what Mike did with the original array proxy stuff. >> >> It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. > > The question is why ArrayList.forEach should not be fail-fast ? I think we have to consider the wider context of Iterable/Iterator/Spliterator.forEach when used for parallel evaluation. In such cases it is advantageous not to fail-fast. So while there is a precedent for the Iterator impls to fail-fast it does not necessarily mean all forEach impls should by default do the same. Paul. From maurice at morninglight.co.uk Mon Nov 19 05:04:57 2012 From: maurice at morninglight.co.uk (Maurice Naftalin) Date: Mon, 19 Nov 2012 13:04:57 +0000 Subject: Next binary/Javadoc drop? Message-ID: <12056FF4-1B1D-4418-8E5E-51B464757FEA@morninglight.co.uk> Is there a planned date for the next drop to the early access page? Maurice From maurizio.cimadamore at oracle.com Mon Nov 19 05:16:55 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 19 Nov 2012 13:16:55 +0000 Subject: javac throwing NPE at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply In-Reply-To: <50AA01FA.2080503@oracle.com> References: <50AA01FA.2080503@oracle.com> Message-ID: <50AA3147.7000306@oracle.com> On 19/11/12 09:55, Filipp Zhinkin wrote: > Hi, > > I've found that following code force javac to throw NullPointerException: > > public class NPE { > public static void main(String args[]) { > // "cannot find symbol" error is expected > new Integer(0).forEach(System.out::println); > } > } > > $java -version > openjdk version "1.8.0-ea" > OpenJDK Runtime Environment (build > 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) > OpenJDK Server VM (build 25.0-b05, mixed mode) > > $javac NPE.java > An exception has occurred in the compiler (1.8.0-ea). Please file a bug > at the Java Developer Connection > (http://java.sun.com/webapps/bugreport) after checking the Bug Parade > for duplicates. Include your program and the following diagnostic in > your report. Thank you. > java.lang.NullPointerException > at > com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitApply(Flow.java:1197) > at > com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1395) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at com.sun.tools.javac.tree.TreeScanner.visitExec(TreeScanner.java:173) > at > com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1226) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) > at com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitBlock(Flow.java:960) > at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:839) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at > com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitMethodDef(Flow.java:927) > at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:723) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at > com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:890) > at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:645) > at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at > com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1277) > at > com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1267) > at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:210) > at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1297) > at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1271) > at > com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:911) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:870) > at com.sun.tools.javac.main.Main.compile(Main.java:441) > at com.sun.tools.javac.main.Main.compile(Main.java:358) > at com.sun.tools.javac.main.Main.compile(Main.java:347) > at com.sun.tools.javac.main.Main.compile(Main.java:338) > at com.sun.tools.javac.Main.compile(Main.java:76) > at com.sun.tools.javac.Main.main(Main.java:61) > > > With method reference replaced by lambda expression javac will report > semantic error as expected: > > public class SemError { > public static void main(String args[]) { > new Integer(0).forEach((x) -> { System.out.println(x); }); > } > } > > $javac SemError.java > SemError.java:3: error: cannot find symbol > new Integer(0).forEach((x) -> { System.out.println(x); }); > ^ > symbol: method forEach() > location: class Integer > 1 error > > Hope it will be useful. This seems to be fixed in the latest compiler - I get: error: cannot find symbol new Integer(0).forEach(System.out::println); ^ symbol: method forEach() location: class Integer The diagnostic should be improved of course - i.e. it should not be displaying that , burt no exception is coming from javac. Maurizio > > Filipp. > > From maurizio.cimadamore at oracle.com Mon Nov 19 05:37:46 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 19 Nov 2012 13:37:46 +0000 Subject: incompatible types compile error In-Reply-To: References: <50A6C06A.2030301@univ-mlv.fr> Message-ID: <50AA362A.7020004@oracle.com> The problem is that, since you are using Comparable (note the absence of type-parameters) you are effectively triggering an uunchecked conversion there - the result would be that the erased signature of 'into' will be used instead - that is, the return type of into will be simply Destination - not the type inferred from the argument - hence the incompatible types error. Btw - I'm getting the error for both versions of the example you sent. Maurizio On 16/11/12 23:01, Arul Dhesiaseelan wrote: > This works, btw. > > List sortedFavs = new ArrayList(); > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Mapper) album -> > album.name)) > .into(sortedFavs); > > > > On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: > >> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: >>> Hi, >>> >>> I am trying to run a slightly modified version from the latest State of >> the >>> Lambda libraries edition. >>> >>> List sortedFavs = >>> albums.stream() >>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >> 4))) >>> .sorted(comparing((Mapper) album -> >>> album.name)) >>> .into(new ArrayList()); >>> >>> java: incompatible types: java.util.stream.Stream.Destination cannot be >>> converted to java.util.List >>> >>> Any idea what could be wrong here? >> the signature of the method into. >> >>> -Arul >>> >> R?mi >> >> >> From paul.sandoz at oracle.com Mon Nov 19 06:19:44 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Nov 2012 14:19:44 +0000 Subject: hg: lambda/lambda/jdk: - Fail fast streams. BaseStream.iterator() is considered Message-ID: <20121119142018.8028E47A50@hg.openjdk.java.net> Changeset: 1440e2129616 Author: psandoz Date: 2012-11-19 15:19 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1440e2129616 - Fail fast streams. BaseStream.iterator() is considered a terminal operation. Only one terminal operation may be performed on at most one stream in the pipeline, otherwise an ISE will result. - removed mixed test case scenarios ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From paul.sandoz at oracle.com Mon Nov 19 06:29:38 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Nov 2012 15:29:38 +0100 Subject: No-reuse streams Message-ID: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> Hi, Brian and I just pushed a changeset that: - turns Stream/IntStream.iterator() into a terminal operation - only one terminal operation may be performed on at most one stream in the pipeline, otherwise an ISE will be thrown. Based on feedback on stream iteration and terminal operation we decided to swing to the other end of the evaluation spectrum. No laissez-faire attitude to pulling and terminal operations. Streams are now very strict. Note that we pulled away from throwing ISEs with regards to infinite streams but in that case we don't think it possible to efficiently detect every scenario that will end up either looping indefinitely or result in a stack overflow or out of memory error. Paul. From johan.haleby at gmail.com Mon Nov 19 06:39:30 2012 From: johan.haleby at gmail.com (Johan Haleby) Date: Mon, 19 Nov 2012 15:39:30 +0100 Subject: Working with immutable collections Message-ID: Hi, I'm sorry if this has been discussed before but here goes: Let's say I have an immutable list called "xList" that I want to filter and return the result as a new *immutable* list. I could do something like this: Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new ArrayList()))); How ever I think this is quite verbose and doesn't follow the fluent style of the API. What I would like to have is something a long these lines: xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so I don't need to wrap all statements where I want to return an immutable collection. What are your thoughts on this? Regards, /Johan From aleksey.shipilev at oracle.com Mon Nov 19 07:01:15 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 19 Nov 2012 19:01:15 +0400 Subject: No-reuse streams In-Reply-To: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> Message-ID: <50AA49BB.9030105@oracle.com> On 11/19/2012 06:29 PM, Paul Sandoz wrote: > Brian and I just pushed a changeset that: > > - turns Stream/IntStream.iterator() into a terminal operation > > - only one terminal operation may be performed on at most one stream > in the pipeline, otherwise an ISE will be thrown. Isn't iterator() the exception from this rule, being the "extension" of the stream? I would naturally presume the *same* iterator is returned for the given stream, so this will still be the valid code: Stream stream = ...; T first = stream.iterator().next() // ...many, many lines of code... T second = stream.iterator().next() -Aleksey. From maurizio.cimadamore at oracle.com Mon Nov 19 07:03:13 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 19 Nov 2012 15:03:13 +0000 Subject: hg: lambda/lambda/langtools: Fix: bad compiler diagnostic generated when poly expression is passed to non-existent method Message-ID: <20121119150317.7233347A51@hg.openjdk.java.net> Changeset: 7e860c43abf4 Author: mcimadamore Date: 2012-11-19 15:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7e860c43abf4 Fix: bad compiler diagnostic generated when poly expression is passed to non-existent method ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out From mcnepp02 at googlemail.com Mon Nov 19 07:07:06 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 19 Nov 2012 16:07:06 +0100 Subject: Working with immutable collections In-Reply-To: References: Message-ID: <50AA4B1A.1020402@googlemail.com> I'd rather have an "unmodifiable" member function in java.util.Collection, together with a "synchronized" function, something like this: public interface Collection { /** Returns an unmodifiable view of this Collection. @return an unmodifiable view of this Collection (may be {@code this} instance if is already unmodifiable). public Collection unmodifiable() default { return Collections.unmodifiableCollection(this); } /** Returns a synchronized view of this Collection. @param lock the Lock to use. @return a view of this Collection that executes all operations while holding a Lock. (may be {@code this} instance if is already synchronized on the supplied Lock). @throws IllegalArgumentException if this Collection is already synchronized on a different Lock. public Collection synchronize(Lock lock) default { return Collections.synchronize(this, lock); } } These should of course be co-variantly overriden in java.util.List, java.util.Set etc.! Am 19.11.2012 15:39, schrieb Johan Haleby: > Hi, > > I'm sorry if this has been discussed before but here goes: > > Let's say I have an immutable list called "xList" that I want to filter and > return the result as a new *immutable* list. I could do something like this: > > Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new > ArrayList()))); > > How ever I think this is quite verbose and doesn't follow the fluent style > of the API. What I would like to have is something a long these lines: > > xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); > > "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so > I don't need to wrap all statements where I want to return an immutable > collection. > > What are your thoughts on this? > > Regards, > /Johan > From johan.haleby at gmail.com Mon Nov 19 07:15:19 2012 From: johan.haleby at gmail.com (Johan Haleby) Date: Mon, 19 Nov 2012 16:15:19 +0100 Subject: Working with immutable collections In-Reply-To: <50AA4B1A.1020402@googlemail.com> References: <50AA4B1A.1020402@googlemail.com> Message-ID: This would work fine as well, the main point is that I want to avoid wrapping my statement in Collections.unmodifiableList(..) etc. /Johan On Mon, Nov 19, 2012 at 4:07 PM, Gernot Neppert wrote: > I'd rather have an "unmodifiable" member function in java.util.Collection, > together with a "synchronized" function, something like this: > > public interface Collection { > > /** > Returns an unmodifiable view of this Collection. > @return an unmodifiable view of this Collection (may be {@code this} > instance if is already unmodifiable). > public Collection unmodifiable() default { > return Collections.**unmodifiableCollection(this); > } > > /** > Returns a synchronized view of this Collection. > @param lock the Lock to use. > @return a view of this Collection that executes all operations while > holding a Lock. (may be {@code this} instance if is already synchronized on > the supplied Lock). > @throws IllegalArgumentException if this Collection is already > synchronized on a different Lock. > public Collection synchronize(Lock lock) default { > return Collections.synchronize(this, lock); > } > > } > > > These should of course be co-variantly overriden in java.util.List, > java.util.Set etc.! > > > > > > > Am 19.11.2012 15:39, schrieb Johan Haleby: > >> Hi, >> >> I'm sorry if this has been discussed before but here goes: >> >> Let's say I have an immutable list called "xList" that I want to filter >> and >> return the result as a new *immutable* list. I could do something like >> this: >> >> >> Collections.unmodifiableList(**xList.filter(obj -> >> obj.something()).into(new >> ArrayList()))); >> >> How ever I think this is quite verbose and doesn't follow the fluent style >> of the API. What I would like to have is something a long these lines: >> >> xList.filter(obj -> obj.something()).**intoImmutable(new >> ArrayList())); >> >> "intoImmutable" could then do "Collections.unmodifiableList(**..)" for >> me so >> I don't need to wrap all statements where I want to return an immutable >> collection. >> >> What are your thoughts on this? >> >> Regards, >> /Johan >> >> > From elena.votchennikova at oracle.com Mon Nov 19 07:17:41 2012 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Mon, 19 Nov 2012 19:17:41 +0400 Subject: Behavior of concat(null) Message-ID: <50AA4D95.4060507@oracle.com> Hello, I'm trying to use method concat(Stream) of some Stream implementation with null-argument and currently it doesn't throw NullPointerException. Exception is thrown only when I call some method of the resulting Stream, for example iterator(). Could you please explain - is it an expected behavior or concat() with null-argument should throw NPE? Thanks a lot, Elena From aleksey.shipilev at oracle.com Mon Nov 19 07:21:00 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 19 Nov 2012 19:21:00 +0400 Subject: Primitive collections support breaks existing code Message-ID: <50AA4E5C.8090608@oracle.com> Hi there, I understand primitive streams are still in flux, but those are breaking the existing test/benchmark code since lambdas are getting inferenced to primitive interfaces, and implicitly moving to primitive streams (which is an awesome idea when it is completed :)). Down to specific questions: 1. Is there a timeline for skeleton implementations for IntStream? If that would take longer than, say, a week, I would work that around in the tests. 2. Does IntStream.into() omitted for the reason? This does not compile: @Test public void test3() { Assert.assertEquals( Arrays.asList(3, 3, 3), Arrays.asList("Foo", "Bar", "Baz") .stream() .map((s) -> s.length()) .into(new ArrayList()) ); } -Aleksey. From mcnepp02 at googlemail.com Mon Nov 19 07:42:55 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 19 Nov 2012 16:42:55 +0100 Subject: Working with immutable collections In-Reply-To: References: <50AA4B1A.1020402@googlemail.com> Message-ID: <50AA537F.3040009@googlemail.com> Hmm, what you proposed was: List filtered = xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); whereas my proposal would lead to: List filtered = xList.filter(obj -> obj.something()).into(new ArrayList()).unmodifiable(); Not that much more verbose, don't you think? Am 19.11.2012 16:15, schrieb Johan Haleby: > This would work fine as well, the main point is that I want to avoid > wrapping my statement in Collections.unmodifiableList(..) etc. > > /Johan > > On Mon, Nov 19, 2012 at 4:07 PM, Gernot Neppert > > wrote: > > I'd rather have an "unmodifiable" member function in > java.util.Collection, together with a "synchronized" function, > something like this: > > public interface Collection { > > /** > Returns an unmodifiable view of this Collection. > @return an unmodifiable view of this Collection (may be {@code > this} instance if is already unmodifiable). > public Collection unmodifiable() default { > return Collections.unmodifiableCollection(this); > } > > /** > Returns a synchronized view of this Collection. > @param lock the Lock to use. > @return a view of this Collection that executes all operations > while holding a Lock. (may be {@code this} instance if is already > synchronized on the supplied Lock). > @throws IllegalArgumentException if this Collection is already > synchronized on a different Lock. > public Collection synchronize(Lock lock) default { > return Collections.synchronize(this, lock); > } > > } > > > These should of course be co-variantly overriden in > java.util.List, java.util.Set etc.! > > > > > > > Am 19.11.2012 15:39, schrieb Johan Haleby: > > Hi, > > I'm sorry if this has been discussed before but here goes: > > Let's say I have an immutable list called "xList" that I want > to filter and > return the result as a new *immutable* list. I could do > something like this: > > > Collections.unmodifiableList(xList.filter(obj -> > obj.something()).into(new > ArrayList()))); > > How ever I think this is quite verbose and doesn't follow the > fluent style > of the API. What I would like to have is something a long > these lines: > > xList.filter(obj -> obj.something()).intoImmutable(new > ArrayList())); > > "intoImmutable" could then do > "Collections.unmodifiableList(..)" for me so > I don't need to wrap all statements where I want to return an > immutable > collection. > > What are your thoughts on this? > > Regards, > /Johan > > > From brian.goetz at oracle.com Mon Nov 19 07:49:42 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 10:49:42 -0500 Subject: Working with immutable collections In-Reply-To: References: Message-ID: <50AA5516.4070801@oracle.com> I understand the use case. The specific suggestion (add a new stream operation for this one use case, that cannot help with others, and will invariably give birth to cries for many more) would be a serious mistake. What I think you want is a Builder that implements Destination, therefore piggybacking on the mechanism that lets into work with any Collection type (and more). Then it is entirely supported within the library: class MyCollectionBuilder implements Stream.Destination { void addAll(...) T build() ... } and then you could say stream.filter(...).blah(...) .into(new MyCollectionBuilder(new ArrayList())).build(); On 11/19/2012 9:39 AM, Johan Haleby wrote: > Hi, > > I'm sorry if this has been discussed before but here goes: > > Let's say I have an immutable list called "xList" that I want to filter and > return the result as a new *immutable* list. I could do something like this: > > Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new > ArrayList()))); > > How ever I think this is quite verbose and doesn't follow the fluent style > of the API. What I would like to have is something a long these lines: > > xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); > > "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so > I don't need to wrap all statements where I want to return an immutable > collection. > > What are your thoughts on this? > > Regards, > /Johan > From brian.goetz at oracle.com Mon Nov 19 07:50:53 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 10:50:53 -0500 Subject: No-reuse streams In-Reply-To: <50AA49BB.9030105@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> <50AA49BB.9030105@oracle.com> Message-ID: <50AA555D.5010209@oracle.com> The iterator() method (and soon, spliterator()) are the escape hatch for "the library can't help me, I have to do it myself." You then get the iterator and can do whatever you want with it. But, what you can't do is call iterator(), pull elements from the stream, and *then* try and do more stream operations on that stream. On 11/19/2012 10:01 AM, Aleksey Shipilev wrote: > On 11/19/2012 06:29 PM, Paul Sandoz wrote: >> Brian and I just pushed a changeset that: >> >> - turns Stream/IntStream.iterator() into a terminal operation >> >> - only one terminal operation may be performed on at most one stream >> in the pipeline, otherwise an ISE will be thrown. > > Isn't iterator() the exception from this rule, being the "extension" of > the stream? I would naturally presume the *same* iterator is returned > for the given stream, so this will still be the valid code: > > Stream stream = ...; > T first = stream.iterator().next() > // ...many, many lines of code... > T second = stream.iterator().next() > > -Aleksey. > From brian.goetz at oracle.com Mon Nov 19 07:54:39 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 10:54:39 -0500 Subject: Working with immutable collections In-Reply-To: <50AA4B1A.1020402@googlemail.com> References: <50AA4B1A.1020402@googlemail.com> Message-ID: <50AA563F.7080905@oracle.com> That's on the list. (Similar for synchronized()). Unfortunately, it's trickier than it looks, because of inheritance diamonds. LinkedList implements List and Queue, so when you try to inherit unmodifiable() from both List (returns List) and Queue (returns Queue), you have to override it with something that returns both a List and a Queue. Unfortunately this means reimplementing Unmodifiable for ad-hoc intersections like List&Queue. We can work around this one by leaving List in the cold, but we still find landmines. For example, there's a stupid class in the JDK that implements both List and Set (for bad reasons) and that happens to be serializable so we can't even fix it easily. Having the same problem with List and Set is particularly annoying because you cannot simultaneously implement the contract of List and Set! But that didn't stop whoever wrote this class. So what sounds like a no-brainer is actually more work than it looks. On 11/19/2012 10:07 AM, Gernot Neppert wrote: > I'd rather have an "unmodifiable" member function in > java.util.Collection, together with a "synchronized" function, something > like this: > > public interface Collection { > > /** > Returns an unmodifiable view of this Collection. > @return an unmodifiable view of this Collection (may be {@code this} > instance if is already unmodifiable). > public Collection unmodifiable() default { > return Collections.unmodifiableCollection(this); > } > > /** > Returns a synchronized view of this Collection. > @param lock the Lock to use. > @return a view of this Collection that executes all operations while > holding a Lock. (may be {@code this} instance if is already synchronized > on the supplied Lock). > @throws IllegalArgumentException if this Collection is already > synchronized on a different Lock. > public Collection synchronize(Lock lock) default { > return Collections.synchronize(this, lock); > } > > } > > > These should of course be co-variantly overriden in java.util.List, > java.util.Set etc.! > > > > > > > Am 19.11.2012 15:39, schrieb Johan Haleby: >> Hi, >> >> I'm sorry if this has been discussed before but here goes: >> >> Let's say I have an immutable list called "xList" that I want to filter and >> return the result as a new *immutable* list. I could do something like this: >> >> Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new >> ArrayList()))); >> >> How ever I think this is quite verbose and doesn't follow the fluent style >> of the API. What I would like to have is something a long these lines: >> >> xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); >> >> "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so >> I don't need to wrap all statements where I want to return an immutable >> collection. >> >> What are your thoughts on this? >> >> Regards, >> /Johan >> > > From brian.goetz at oracle.com Mon Nov 19 07:57:50 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 10:57:50 -0500 Subject: Behavior of concat(null) In-Reply-To: <50AA4D95.4060507@oracle.com> References: <50AA4D95.4060507@oracle.com> Message-ID: <50AA56FE.3040701@oracle.com> We do not guarantee that any given operation WILL or WILL NOT throw NPE when present with nulls. We have made some efforts to avoid throwing NPEs from within the Streams library code, but even that is not guaranteed (put that in the "reasonable efforts" category.) We expect most, but not all, NPEs resulting from null elements to come from code outside java.util.stream, such as lambdas passed to the operation, Arrays.sort(), the constructor of Optional, etc. On 11/19/2012 10:17 AM, elena votchennikova wrote: > Hello, > > I'm trying to use method concat(Stream) of some Stream implementation > with null-argument and currently it doesn't throw NullPointerException. > Exception is thrown only when I call some method of the resulting > Stream, for example iterator(). > > Could you please explain - is it an expected behavior or concat() with > null-argument should throw NPE? > > > Thanks a lot, > Elena > From brian.goetz at oracle.com Mon Nov 19 08:02:21 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 11:02:21 -0500 Subject: Primitive collections support breaks existing code In-Reply-To: <50AA4E5C.8090608@oracle.com> References: <50AA4E5C.8090608@oracle.com> Message-ID: <50AA580D.9020903@oracle.com> > I understand primitive streams are still in flux, but those are breaking > the existing test/benchmark code since lambdas are getting inferenced to > primitive interfaces, and implicitly moving to primitive streams (which > is an awesome idea when it is completed :)). I think the overload of map(Function) and map(IntFunction) is here to stay. The compiler will try and avoid boxing/unboxing, so if you have: map((Integer i) -> i) it will prefer Function, whereas if you have map((Integer i) -> i.intValue()) it will prefer IntFunction. Probably best to update tests that currently map to a primitive but are intended to test reference streams cast to references. > Down to specific questions: > > 1. Is there a timeline for skeleton implementations for IntStream? If > that would take longer than, say, a week, I would work that around in > the tests. Depends what you mean by skeleton! We've got filter/map/reduce already :) > 2. Does IntStream.into() omitted for the reason? This does not compile: > > @Test > public void test3() { > Assert.assertEquals( > Arrays.asList(3, 3, 3), > Arrays.asList("Foo", "Bar", "Baz") > .stream() > .map((s) -> s.length()) > .into(new ArrayList()) > ); > } Yes, because you'd have to box anyway. The idea is that primitive streams are primarily there for supporting reduction on primitives (sum, min, max, etc.) There is a "boxed" op that gets you back to Stream: Arrays.asList("Foo", "Bar", "Baz") .stream() .map(String::length) .boxed() .into(new ArrayList()) (or you could box implicitly in the map: Arrays.asList("Foo", "Bar", "Baz") .stream() .map(s -> (Integer) s.length()) .into(new ArrayList()) From mcnepp02 at googlemail.com Mon Nov 19 08:03:38 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 19 Nov 2012 17:03:38 +0100 Subject: Working with immutable collections In-Reply-To: <50AA563F.7080905@oracle.com> References: <50AA4B1A.1020402@googlemail.com> <50AA563F.7080905@oracle.com> Message-ID: <50AA585A.2030706@googlemail.com> Nice to hear that it's being considered! > LinkedList implements List and Queue, so when you try to inherit unmodifiable() from both List (returns List) and Queue (returns Queue), you have to override it with something that returns both a List and a Queue. ...and the top candidate for that "something" would be LinkedList, wouldnt' it? > Unfortunately this means reimplementing Unmodifiable for ad-hoc intersections like List&Queue. OK, I get what you mean, but wouldn't this only prevent you from implementing both List and Queue in an anonymous manner? Otherwise, similiar to LinkedList, you'd simply have to return the implementing class type from such methods. Am 19.11.2012 16:54, schrieb Brian Goetz: > That's on the list. (Similar for synchronized()). > > Unfortunately, it's trickier than it looks, because of inheritance > diamonds. LinkedList implements List and Queue, so when you try to > inherit unmodifiable() from both List (returns List) and Queue > (returns Queue), you have to override it with something that returns > both a List and a Queue. Unfortunately this means reimplementing > Unmodifiable for ad-hoc intersections like List&Queue. We can work > around this one by leaving List in the cold, but we still find > landmines. For example, there's a stupid class in the JDK that > implements both List and Set (for bad reasons) and that happens to be > serializable so we can't even fix it easily. Having the same problem > with List and Set is particularly annoying because you cannot > simultaneously implement the contract of List and Set! But that > didn't stop whoever wrote this class. > > So what sounds like a no-brainer is actually more work than it looks. > > On 11/19/2012 10:07 AM, Gernot Neppert wrote: >> I'd rather have an "unmodifiable" member function in >> java.util.Collection, together with a "synchronized" function, something >> like this: >> >> public interface Collection { >> >> /** >> Returns an unmodifiable view of this Collection. >> @return an unmodifiable view of this Collection (may be {@code this} >> instance if is already unmodifiable). >> public Collection unmodifiable() default { >> return Collections.unmodifiableCollection(this); >> } >> >> /** >> Returns a synchronized view of this Collection. >> @param lock the Lock to use. >> @return a view of this Collection that executes all operations while >> holding a Lock. (may be {@code this} instance if is already synchronized >> on the supplied Lock). >> @throws IllegalArgumentException if this Collection is already >> synchronized on a different Lock. >> public Collection synchronize(Lock lock) default { >> return Collections.synchronize(this, lock); >> } >> >> } >> >> >> These should of course be co-variantly overriden in java.util.List, >> java.util.Set etc.! >> >> >> >> >> >> >> Am 19.11.2012 15:39, schrieb Johan Haleby: >>> Hi, >>> >>> I'm sorry if this has been discussed before but here goes: >>> >>> Let's say I have an immutable list called "xList" that I want to >>> filter and >>> return the result as a new *immutable* list. I could do something >>> like this: >>> >>> Collections.unmodifiableList(xList.filter(obj -> >>> obj.something()).into(new >>> ArrayList()))); >>> >>> How ever I think this is quite verbose and doesn't follow the fluent >>> style >>> of the API. What I would like to have is something a long these lines: >>> >>> xList.filter(obj -> obj.something()).intoImmutable(new >>> ArrayList())); >>> >>> "intoImmutable" could then do "Collections.unmodifiableList(..)" for >>> me so >>> I don't need to wrap all statements where I want to return an immutable >>> collection. >>> >>> What are your thoughts on this? >>> >>> Regards, >>> /Johan >>> >> >> From brian.goetz at oracle.com Mon Nov 19 08:06:09 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 11:06:09 -0500 Subject: Working with immutable collections In-Reply-To: <50AA585A.2030706@googlemail.com> References: <50AA4B1A.1020402@googlemail.com> <50AA563F.7080905@oracle.com> <50AA585A.2030706@googlemail.com> Message-ID: <50AA58F1.6020700@oracle.com> > > LinkedList implements List and Queue, so when you try to inherit > unmodifiable() from both List (returns List) and Queue (returns Queue), > you have to override it with something that returns both a List and a > Queue. > > ...and the top candidate for that "something" would be LinkedList, > wouldnt' it? Right. But, if you were the maintainer of LinkedList, and someone came along and said "hey, I know your class was working fine, but now you have to implement these two additional methods (which are each probably 60 lines of (admittedly trivial) code", you'd probably be grumpy at that someone. > > Unfortunately this means reimplementing Unmodifiable for ad-hoc > intersections like List&Queue. > > OK, I get what you mean, but wouldn't this only prevent you from > implementing both List and Queue in an anonymous manner? > Otherwise, similiar to LinkedList, you'd simply have to return the > implementing class type from such methods. But you actually have to implement the functionality, and there's no class that does it for you (unless you want to call both supers, cache the result, and wrap a dynamic proxy around them.) Which means YOU have to re-implement unmodifiableLinkedList. From brian.goetz at oracle.com Mon Nov 19 08:06:30 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 11:06:30 -0500 Subject: Working with immutable collections In-Reply-To: References: Message-ID: <50AA5906.8010704@oracle.com> I understand the use case. The specific suggestion (add a new stream operation for this one use case, that cannot help with others, and will invariably give birth to cries for many more) would be a serious mistake. What I think you want is a Builder that implements Destination, therefore piggybacking on the mechanism that lets into work with any Collection type (and more). Then it is entirely supported within the library: class MyCollectionBuilder implements Stream.Destination { void addAll(...) T build() ... } and then you could say stream.filter(...).blah(...) .into(new MyCollectionBuilder(new ArrayList())).build(); On 11/19/2012 9:39 AM, Johan Haleby wrote: > Hi, > > I'm sorry if this has been discussed before but here goes: > > Let's say I have an immutable list called "xList" that I want to filter and > return the result as a new *immutable* list. I could do something like this: > > Collections.unmodifiableList(xList.filter(obj -> obj.something()).into(new > ArrayList()))); > > How ever I think this is quite verbose and doesn't follow the fluent style > of the API. What I would like to have is something a long these lines: > > xList.filter(obj -> obj.something()).intoImmutable(new ArrayList())); > > "intoImmutable" could then do "Collections.unmodifiableList(..)" for me so > I don't need to wrap all statements where I want to return an immutable > collection. > > What are your thoughts on this? > > Regards, > /Johan > From paul.sandoz at oracle.com Mon Nov 19 08:18:19 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Nov 2012 16:18:19 +0000 Subject: hg: lambda/lambda/jdk: - pushed IntSink into Sink (a primitive kitchen sink :-) ). Message-ID: <20121119161838.7BB5747A53@hg.openjdk.java.net> Changeset: 1359dedd5475 Author: psandoz Date: 2012-11-19 17:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1359dedd5475 - pushed IntSink into Sink (a primitive kitchen sink :-) ). - cleaned up functional SAMs. - merged IntForEachOp into ForEachOp. - re-jigged methods on Primitives to be in sync with style and use as that on Streams. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/TerminalSink.java ! src/share/classes/java/util/stream/op/ConcatOp.java ! src/share/classes/java/util/stream/op/FilterOp.java ! src/share/classes/java/util/stream/op/FlatMapOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/MapOp.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/TeeOp.java ! src/share/classes/java/util/stream/op/UniqOp.java - src/share/classes/java/util/stream/primitive/IntBlock.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java - src/share/classes/java/util/stream/primitive/IntForEachOp.java ! src/share/classes/java/util/stream/primitive/IntIterable.java ! src/share/classes/java/util/stream/primitive/IntIterator.java ! src/share/classes/java/util/stream/primitive/IntLimitOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntNodeBuilder.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java - src/share/classes/java/util/stream/primitive/IntSink.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpliterator.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! src/share/classes/java/util/stream/primitive/IntSumOp.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java - src/share/classes/java/util/stream/primitive/IntTerminalSink.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java - src/share/classes/java/util/stream/primitive/IntUnaryOperator.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/function/DoubleUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/IntUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/LongUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From aleksey.shipilev at oracle.com Mon Nov 19 08:19:41 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 19 Nov 2012 20:19:41 +0400 Subject: No-reuse streams In-Reply-To: <50AA555D.5010209@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> <50AA49BB.9030105@oracle.com> <50AA555D.5010209@oracle.com> Message-ID: <50AA5C1D.60901@oracle.com> Well, of course! I was thinking about returning the same iterator nevertheless; so that we share the traversal states between two iterators from iterator() call. I think this provisioning would help to write cleaner code in some of the cases, at the cost of making stream appear to bear the state. I'm fine with opting out of that behavior if it is considered not that clean. -Aleksey. On 11/19/2012 07:50 PM, Brian Goetz wrote: > The iterator() method (and soon, spliterator()) are the escape hatch for > "the library can't help me, I have to do it myself." You then get the > iterator and can do whatever you want with it. But, what you can't do > is call iterator(), pull elements from the stream, and *then* try and do > more stream operations on that stream. > > On 11/19/2012 10:01 AM, Aleksey Shipilev wrote: >> On 11/19/2012 06:29 PM, Paul Sandoz wrote: >>> Brian and I just pushed a changeset that: >>> >>> - turns Stream/IntStream.iterator() into a terminal operation >>> >>> - only one terminal operation may be performed on at most one stream >>> in the pipeline, otherwise an ISE will be thrown. >> >> Isn't iterator() the exception from this rule, being the "extension" of >> the stream? I would naturally presume the *same* iterator is returned >> for the given stream, so this will still be the valid code: >> >> Stream stream = ...; >> T first = stream.iterator().next() >> // ...many, many lines of code... >> T second = stream.iterator().next() >> >> -Aleksey. >> From aleksey.shipilev at oracle.com Mon Nov 19 08:23:20 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 19 Nov 2012 20:23:20 +0400 Subject: Primitive collections support breaks existing code In-Reply-To: <50AA580D.9020903@oracle.com> References: <50AA4E5C.8090608@oracle.com> <50AA580D.9020903@oracle.com> Message-ID: <50AA5CF8.3010106@oracle.com> On 11/19/2012 08:02 PM, Brian Goetz wrote: > it will prefer IntFunction. Probably best to update tests that > currently map to a primitive but are intended to test reference streams > cast to references. In most of our tests, there is not provisioning yet on the reference-vs-primitive. Some day we will have to split those up. >> 1. Is there a timeline for skeleton implementations for IntStream? If >> that would take longer than, say, a week, I would work that around in >> the tests. > > Depends what you mean by skeleton! We've got filter/map/reduce already :) Hmmm, nope? This fails: @Test public void test4() { Assert.assertEquals( Integer.valueOf(9), Arrays.asList("Foo", "BarBar", "BazBazBaz") .stream() .map(s -> s.length()) .reduce((l, r) -> (l > r ? l : r)) .get() ); } with: java.lang.UnsupportedOperationException at java.util.stream.primitive.IntPipeline.reduce(IntPipeline.java:137) at net.openjdk.streams.StreamAPITest.test4(StreamAPITest.java:54) > Yes, because you'd have to box anyway. The idea is that primitive > streams are primarily there for supporting reduction on primitives (sum, > min, max, etc.) There is a "boxed" op that gets you back to > Stream: > > Arrays.asList("Foo", "Bar", "Baz") > .stream() > .map(String::length) > .boxed() > .into(new ArrayList()) Yes, boxed() is nice and enough. Thanks, -Aleksey. From brian.goetz at oracle.com Mon Nov 19 08:25:45 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 11:25:45 -0500 Subject: No-reuse streams In-Reply-To: <50AA5C1D.60901@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> <50AA49BB.9030105@oracle.com> <50AA555D.5010209@oracle.com> <50AA5C1D.60901@oracle.com> Message-ID: <50AA5D89.5080504@oracle.com> BTW, I know you've used the trick of asking for an iterator() to for "pull mode" for performance testing purposes. We've got a new trick for forcing that in our tests; see the use of PullOnlyOp in the latest test sources. Returning the same iterator/spliterator is a possibility, and not entirely precluded by this approach, though it would require special support. (This approach is what is used by Socket.get{Input,Output}Stream.) The current behavior, which I would guess is dispensing a new iterator that will throw when you try and use it, is not so great. On 11/19/2012 11:19 AM, Aleksey Shipilev wrote: > Well, of course! > > I was thinking about returning the same iterator nevertheless; so that > we share the traversal states between two iterators from iterator() > call. I think this provisioning would help to write cleaner code in some > of the cases, at the cost of making stream appear to bear the state. I'm > fine with opting out of that behavior if it is considered not that clean. > > -Aleksey. > > On 11/19/2012 07:50 PM, Brian Goetz wrote: >> The iterator() method (and soon, spliterator()) are the escape hatch for >> "the library can't help me, I have to do it myself." You then get the >> iterator and can do whatever you want with it. But, what you can't do >> is call iterator(), pull elements from the stream, and *then* try and do >> more stream operations on that stream. >> >> On 11/19/2012 10:01 AM, Aleksey Shipilev wrote: >>> On 11/19/2012 06:29 PM, Paul Sandoz wrote: >>>> Brian and I just pushed a changeset that: >>>> >>>> - turns Stream/IntStream.iterator() into a terminal operation >>>> >>>> - only one terminal operation may be performed on at most one stream >>>> in the pipeline, otherwise an ISE will be thrown. >>> >>> Isn't iterator() the exception from this rule, being the "extension" of >>> the stream? I would naturally presume the *same* iterator is returned >>> for the given stream, so this will still be the valid code: >>> >>> Stream stream = ...; >>> T first = stream.iterator().next() >>> // ...many, many lines of code... >>> T second = stream.iterator().next() >>> >>> -Aleksey. >>> > From brian.goetz at oracle.com Mon Nov 19 08:36:49 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 11:36:49 -0500 Subject: Primitive collections support breaks existing code In-Reply-To: <50AA5CF8.3010106@oracle.com> References: <50AA4E5C.8090608@oracle.com> <50AA580D.9020903@oracle.com> <50AA5CF8.3010106@oracle.com> Message-ID: <50AA6021.2020004@oracle.com> More generally: the philosophy behind having specialized primitive streams (e.g., IntStream) is fraught with nasty tradeoffs. On the one hand, it's lots of ugly code duplication, interface pollution, etc. On the other hand, any kind of arithmetic on boxed ops sucks, and having no story for reducing over ints would be terrible. So we're in a tough corner, and we're trying to not make it worse. Trick #1 for not making it worse is: we're not doing all eight primitive types. We're doing int, long, and double; all the others could be simulated by these. Arguably we could get rid of int too, but we don't think most Java developers are ready for that. Yes, there will be calls for Character, and the answer is "stick it in an int." (Each specialization is projected to ~100K to the JRE footprint.) Trick #2 is: we're using primitive streams to expose things that are best done in the primitive domain (sorting, reduction) but not trying to duplicate everything you can do in the boxed domain. For example, there's no IntStream.into(), as Aleksey points out. (If there were, the next question(s) would be "Where is IntCollection? IntArrayList? IntConcurrentSkipListMap?) The intention is many streams may start as reference streams and end up as primitive streams, but not vice versa. That's OK, and that reduces the number of conversions needed (e.g., no overload of map for int -> T, no specialization of Function for int -> T, etc.) On 11/19/2012 11:23 AM, Aleksey Shipilev wrote: > On 11/19/2012 08:02 PM, Brian Goetz wrote: >> it will prefer IntFunction. Probably best to update tests that >> currently map to a primitive but are intended to test reference streams >> cast to references. > > In most of our tests, there is not provisioning yet on the > reference-vs-primitive. Some day we will have to split those up. > >>> 1. Is there a timeline for skeleton implementations for IntStream? If >>> that would take longer than, say, a week, I would work that around in >>> the tests. >> >> Depends what you mean by skeleton! We've got filter/map/reduce already :) > > Hmmm, nope? This fails: > > @Test > public void test4() { > Assert.assertEquals( > Integer.valueOf(9), > Arrays.asList("Foo", "BarBar", "BazBazBaz") > .stream() > .map(s -> s.length()) > .reduce((l, r) -> (l > r ? l : r)) > .get() > ); > } > > with: > > java.lang.UnsupportedOperationException > at java.util.stream.primitive.IntPipeline.reduce(IntPipeline.java:137) > at net.openjdk.streams.StreamAPITest.test4(StreamAPITest.java:54) > > >> Yes, because you'd have to box anyway. The idea is that primitive >> streams are primarily there for supporting reduction on primitives (sum, >> min, max, etc.) There is a "boxed" op that gets you back to >> Stream: >> >> Arrays.asList("Foo", "Bar", "Baz") >> .stream() >> .map(String::length) >> .boxed() >> .into(new ArrayList()) > > Yes, boxed() is nice and enough. > > Thanks, > -Aleksey. > From brian.goetz at oracle.com Mon Nov 19 08:38:21 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 19 Nov 2012 16:38:21 +0000 Subject: hg: lambda/lambda/jdk: Rename min/maxBy to min/max Message-ID: <20121119163833.61EFA47A54@hg.openjdk.java.net> Changeset: 76facba329a1 Author: briangoetz Date: 2012-11-19 11:37 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/76facba329a1 Rename min/maxBy to min/max ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MinMaxByTest.java From mcnepp02 at googlemail.com Mon Nov 19 08:52:22 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 19 Nov 2012 17:52:22 +0100 Subject: Use of HashMap in Stream functions: is there a better way? Message-ID: <50AA63C6.7020006@googlemail.com> Hello, there is something in the Stream-API that I find a little awkward: All of Stream's methods either return other Streams, which can be seen as views of the original Stream, or final types such as boolean or Optional. Only "Stream.groupBy" and "Stream.reduceBy" return a java.util.Map, which somehow doesn't quite fit into the framework. It forces the implementer to pick a concrete Map implementation, but the API doesn't convey which one. Also, you cannot, in a single step, fill a TreeMap with the result. The alternative that comes to my mind looks like this: - Make java.util.Map a Stream.Destination: interface Map extends Stream.Destination> { public void addAll(Stream> stream) default { for(Entry entry : stream) { put(entry.getKey(), entry.getValue()); } } } - And change Stream to: interface Stream { public Stream> groupBy(Mapper mapper); } With this change, "groupBy" could be used for mappings to unique keys as well as for non-unique keys. The only thing missing for this would be a "java.util.MultiMap" - but isn't that long overdue anyway? Examples: // Unique Mapping: Map byId = warehouse.stock().stream().groupBy(pojo -> pojo.getId()).into(new HashMap()); // Non-Unique Mapping: MultiMap byQuantity = warehouse.stock().stream().groupBy(pojo -> pojo.getQuantity()).into(new HashMultiMap()); From zhong.j.yu at gmail.com Mon Nov 19 09:06:58 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 19 Nov 2012 11:06:58 -0600 Subject: No-reuse streams In-Reply-To: <50AA5C1D.60901@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> <50AA49BB.9030105@oracle.com> <50AA555D.5010209@oracle.com> <50AA5C1D.60901@oracle.com> Message-ID: What about a Stream *is a* Iterator? Or just ditch Iterator, add hasNext()/next() methods in Stream interface? On Mon, Nov 19, 2012 at 10:19 AM, Aleksey Shipilev wrote: > Well, of course! > > I was thinking about returning the same iterator nevertheless; so that > we share the traversal states between two iterators from iterator() > call. I think this provisioning would help to write cleaner code in some > of the cases, at the cost of making stream appear to bear the state. I'm > fine with opting out of that behavior if it is considered not that clean. > > -Aleksey. > > On 11/19/2012 07:50 PM, Brian Goetz wrote: >> The iterator() method (and soon, spliterator()) are the escape hatch for >> "the library can't help me, I have to do it myself." You then get the >> iterator and can do whatever you want with it. But, what you can't do >> is call iterator(), pull elements from the stream, and *then* try and do >> more stream operations on that stream. >> >> On 11/19/2012 10:01 AM, Aleksey Shipilev wrote: >>> On 11/19/2012 06:29 PM, Paul Sandoz wrote: >>>> Brian and I just pushed a changeset that: >>>> >>>> - turns Stream/IntStream.iterator() into a terminal operation >>>> >>>> - only one terminal operation may be performed on at most one stream >>>> in the pipeline, otherwise an ISE will be thrown. >>> >>> Isn't iterator() the exception from this rule, being the "extension" of >>> the stream? I would naturally presume the *same* iterator is returned >>> for the given stream, so this will still be the valid code: >>> >>> Stream stream = ...; >>> T first = stream.iterator().next() >>> // ...many, many lines of code... >>> T second = stream.iterator().next() >>> >>> -Aleksey. >>> > > From brian.goetz at oracle.com Mon Nov 19 09:24:29 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 12:24:29 -0500 Subject: Use of HashMap in Stream functions: is there a better way? In-Reply-To: <50AA63C6.7020006@googlemail.com> References: <50AA63C6.7020006@googlemail.com> Message-ID: <50AA6B4D.6050808@oracle.com> > there is something in the Stream-API that I find a little awkward: > All of Stream's methods either return other Streams, which can be seen > as views of the original Stream, or final types such as boolean or Optional. Yes, we find it awkward too. We went around and around with many variants and eventually settled on this as the lesser of evils. (Even when MapStream was around, there was still a good argument to be made that it should return a Map and not a MapStream, since the implementation has to create a Map anyway, and forcing the user to pay the cost of an into(Map) to get at it seemed excessive.) There are some things our our list to explore making this better, such as: - Define an interface more like Stream.Destination, as we did for into(), as you allude to; - Provide alternate entry points that allow the user to pass a Map in to receive the results (as well as factories for the per-key Collections), like into() does. > The only thing missing for this would be a "java.util.MultiMap" - but > isn't that long overdue anyway? We've considered it many times. But, each time, we look at the thrust-to-weight ratio (look at the total size of the Guava MultiXxx classes as a proxy for weight), and it never quite makes the cut. In any case, there's no chance to add a big new feature like this into the 8 bucket. From brian.goetz at oracle.com Mon Nov 19 09:52:16 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 19 Nov 2012 17:52:16 +0000 Subject: hg: lambda/lambda/jdk: Move parallel sort helpers from FJUtils to Arrays/ArraySortHelpers; get rid of FJUtils Message-ID: <20121119175227.B2C4C47A57@hg.openjdk.java.net> Changeset: ef7e5c6f01f4 Author: briangoetz Date: 2012-11-19 12:15 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ef7e5c6f01f4 Move parallel sort helpers from FJUtils to Arrays/ArraySortHelpers; get rid of FJUtils ! src/share/classes/java/util/Arrays.java - src/share/classes/java/util/concurrent/ForkJoinUtils.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! test/java/util/concurrent/forkjoin/ParallelSorting.java From brian.goetz at oracle.com Mon Nov 19 10:39:02 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 19 Nov 2012 18:39:02 +0000 Subject: hg: lambda/lambda/jdk: Add ArraySortHelpers, missing from previous push Message-ID: <20121119183914.0C71547A58@hg.openjdk.java.net> Changeset: 054fd74129f6 Author: briangoetz Date: 2012-11-19 13:38 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/054fd74129f6 Add ArraySortHelpers, missing from previous push + src/share/classes/java/util/ArraySortHelpers.java From paul.sandoz at oracle.com Mon Nov 19 12:35:50 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Nov 2012 20:35:50 +0000 Subject: hg: lambda/lambda/jdk: - builder for terminal tests Message-ID: <20121119203601.7619047A5C@hg.openjdk.java.net> Changeset: 2090a6765d9d Author: psandoz Date: 2012-11-19 21:35 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2090a6765d9d - builder for terminal tests ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From paul.sandoz at oracle.com Mon Nov 19 12:54:43 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Nov 2012 20:54:43 +0000 Subject: hg: lambda/lambda/jdk: For op tests change the data provider name to be the type Message-ID: <20121119205454.CF60347A5D@hg.openjdk.java.net> Changeset: ebfb2df4ab5b Author: psandoz Date: 2012-11-19 21:46 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ebfb2df4ab5b For op tests change the data provider name to be the type that extends OpTestCase.TestData> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MinMaxByTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From aruld at acm.org Mon Nov 19 13:36:37 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Mon, 19 Nov 2012 11:36:37 -1000 Subject: incompatible types compile error In-Reply-To: <50AA362A.7020004@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> Message-ID: Thanks Maurizio for the clarification. For me, the first usage fails to compile as expected. The second usage works perfectly fine, I wonder what is different that make second example work without the type parameter. I tested with today's build. List sortedFavs1 = albums.stream() .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) .sorted(comparing((Function) album -> album.name )) .into(new ArrayList());//java: incompatible types: java.util.stream.Stream.Destination cannot be converted to java.util.List List sortedFavs2 = new ArrayList(); albums.stream() .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) .sorted(comparing((Function) album -> album.name )) .into(sortedFavs2); Here is the working version with the type parameter. List sortedFavs = albums.stream() .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) .sorted(comparing((Function) album -> album.name)) .into(new ArrayList()); - Arul On Mon, Nov 19, 2012 at 3:37 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > The problem is that, since you are using Comparable (note the absence of > type-parameters) you are effectively triggering an uunchecked conversion > there - the result would be that the erased signature of 'into' will be > used instead - that is, the return type of into will be simply Destination > - not the type inferred from the argument - hence the incompatible types > error. > > Btw - I'm getting the error for both versions of the example you sent. > > Maurizio > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > >> This works, btw. >> >> List sortedFavs = new ArrayList(); >> albums.stream() >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >> 4))) >> .sorted(comparing((Mapper<**Comparable, Album>) album -> >> album.name)) >> .into(sortedFavs); >> >> >> >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: >> >> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: >>> >>>> Hi, >>>> >>>> I am trying to run a slightly modified version from the latest State of >>>> >>> the >>> >>>> Lambda libraries edition. >>>> >>>> List sortedFavs = >>>> albums.stream() >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >>>> >>> 4))) >>> >>>> .sorted(comparing((Mapper<**Comparable, Album>) album -> >>>> album.name)) >>>> .into(new ArrayList()); >>>> >>>> java: incompatible types: java.util.stream.Stream.**Destination cannot >>>> be >>>> converted to java.util.List >>>> >>>> Any idea what could be wrong here? >>>> >>> the signature of the method into. >>> >>> -Arul >>>> >>>> R?mi >>> >>> >>> >>> > From forax at univ-mlv.fr Mon Nov 19 14:26:45 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Nov 2012 23:26:45 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <8B792744-C399-45F6-B10D-EB0C28A96ACA@oracle.com> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> <50AA0F1F.8050107@univ-mlv.fr> <8B792744-C399-45F6-B10D-EB0C28A96ACA@oracle.com> Message-ID: <50AAB225.9060201@univ-mlv.fr> On 11/19/2012 01:53 PM, Paul Sandoz wrote: > On Nov 19, 2012, at 11:51 AM, Remi Forax wrote: > >> On 11/19/2012 10:47 AM, Paul Sandoz wrote: >>> On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: >>> >>>>> A code like this should throw a CME and not an AIOOBE >>>>> arraylist.forEach(e -> { arraylist.remove(e); }) >>>> The current code won't do that, as it copies the array into a local var >>>> before the loop, so the indexes are always valid. >>>> >>>> A reasonable middle ground is a comodification check after the loop >>>> terminates. >>>> >>> Yes, that's what Mike did with the original array proxy stuff. >>> >>> It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. >> The question is why ArrayList.forEach should not be fail-fast ? > I think we have to consider the wider context of Iterable/Iterator/Spliterator.forEach when used for parallel evaluation. In such cases it is advantageous not to fail-fast. I agree, for parrallel evaluation, forEach is not necessary fail-fast but it has to be or snapshot or weekly consistent and not to have an undefined behaviour. > > So while there is a precedent for the Iterator impls to fail-fast it does not necessarily mean all forEach impls should by default do the same. forEach doesn't have to be fail-fast but ArrayList.forEach has to be failfast. > > Paul. > R?mi From forax at univ-mlv.fr Mon Nov 19 14:52:42 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Nov 2012 23:52:42 +0100 Subject: No-reuse streams In-Reply-To: <50AA5C1D.60901@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> <50AA49BB.9030105@oracle.com> <50AA555D.5010209@oracle.com> <50AA5C1D.60901@oracle.com> Message-ID: <50AAB83A.8060103@univ-mlv.fr> On 11/19/2012 05:19 PM, Aleksey Shipilev wrote: > Well, of course! > > I was thinking about returning the same iterator nevertheless; so that > we share the traversal states between two iterators from iterator() > call. I think this provisioning would help to write cleaner code in some > of the cases, at the cost of making stream appear to bear the state. I'm > fine with opting out of that behavior if it is considered not that clean. Stream is a weaker version of an Iterator, weaker because even if the terminal op doesn't consume the whole stream, you can't access to the data that were not consumed. The method iterator() is not a method that should be used in most of the use cases when you use a Stream, The method is here just for interropt between the new world of streams and the old world of iterators. The method iterator() allows you to upgrade a stream to the stronger semantics of the Iterator but in that case you can't use the fancy method of stream anymore. This allow us to have a clean specification of the state of a stream after terminal op like findFirst(), you can't access the non-consumed data. Given this is an interropt feature, The Stream implementations should not have to have an additional field for implementing the semantics you propose but you can store the iterator in a local variable in the code that use stream.iterator() if you want to re-use the iterator. > > -Aleksey. R?mi > > On 11/19/2012 07:50 PM, Brian Goetz wrote: >> The iterator() method (and soon, spliterator()) are the escape hatch for >> "the library can't help me, I have to do it myself." You then get the >> iterator and can do whatever you want with it. But, what you can't do >> is call iterator(), pull elements from the stream, and *then* try and do >> more stream operations on that stream. >> >> On 11/19/2012 10:01 AM, Aleksey Shipilev wrote: >>> On 11/19/2012 06:29 PM, Paul Sandoz wrote: >>>> Brian and I just pushed a changeset that: >>>> >>>> - turns Stream/IntStream.iterator() into a terminal operation >>>> >>>> - only one terminal operation may be performed on at most one stream >>>> in the pipeline, otherwise an ISE will be thrown. >>> Isn't iterator() the exception from this rule, being the "extension" of >>> the stream? I would naturally presume the *same* iterator is returned >>> for the given stream, so this will still be the valid code: >>> >>> Stream stream = ...; >>> T first = stream.iterator().next() >>> // ...many, many lines of code... >>> T second = stream.iterator().next() >>> >>> -Aleksey. >>> > From forax at univ-mlv.fr Mon Nov 19 14:57:36 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Nov 2012 23:57:36 +0100 Subject: Behavior of concat(null) In-Reply-To: <50AA56FE.3040701@oracle.com> References: <50AA4D95.4060507@oracle.com> <50AA56FE.3040701@oracle.com> Message-ID: <50AAB960.10101@univ-mlv.fr> Elena, just to understand do you try to call 1) stream.concat(null); or 2) stream.concate(stream2); // with some null in stream2 for case 1) concat should throw a NPE, for case 2) see the answer of Brian :) R?mi On 11/19/2012 04:57 PM, Brian Goetz wrote: > We do not guarantee that any given operation WILL or WILL NOT throw NPE > when present with nulls. We have made some efforts to avoid throwing > NPEs from within the Streams library code, but even that is not > guaranteed (put that in the "reasonable efforts" category.) We expect > most, but not all, NPEs resulting from null elements to come from code > outside java.util.stream, such as lambdas passed to the operation, > Arrays.sort(), the constructor of Optional, etc. > > On 11/19/2012 10:17 AM, elena votchennikova wrote: >> Hello, >> >> I'm trying to use method concat(Stream) of some Stream implementation >> with null-argument and currently it doesn't throw NullPointerException. >> Exception is thrown only when I call some method of the resulting >> Stream, for example iterator(). >> >> Could you please explain - is it an expected behavior or concat() with >> null-argument should throw NPE? >> >> >> Thanks a lot, >> Elena >> From brian.goetz at oracle.com Mon Nov 19 15:05:17 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 19 Nov 2012 23:05:17 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121119230541.5317A47A5F@hg.openjdk.java.net> Changeset: 728100b14718 Author: briangoetz Date: 2012-11-19 17:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/728100b14718 Expose Stream.getStreamFlags, with some (currently failing) tests ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/StreamOpFlags.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java Changeset: c54ba7563085 Author: briangoetz Date: 2012-11-19 18:05 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c54ba7563085 Merge From pbenedict at apache.org Mon Nov 19 15:12:31 2012 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 19 Nov 2012 17:12:31 -0600 Subject: Convert getStreamFlags() -> EnumSet Message-ID: Brian, I was wondering if there is value in exposing the stream flags also as an EnumSet. What do you think? Or at least a conversion method that can take the int and generate the EnumSet Paul From brian.goetz at oracle.com Mon Nov 19 15:20:37 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 18:20:37 -0500 Subject: Behavior of concat(null) In-Reply-To: <50AAB960.10101@univ-mlv.fr> References: <50AA4D95.4060507@oracle.com> <50AA56FE.3040701@oracle.com> <50AAB960.10101@univ-mlv.fr> Message-ID: <50AABEC5.3050806@oracle.com> Its pretty reasonable for (1) to throw NPE. On 11/19/2012 5:57 PM, Remi Forax wrote: > Elena, > just to understand do you try to call > 1) stream.concat(null); > or > 2) stream.concate(stream2); // with some null in stream2 > > for case 1) concat should throw a NPE, for case 2) see the answer of > Brian :) > > R?mi > > On 11/19/2012 04:57 PM, Brian Goetz wrote: >> We do not guarantee that any given operation WILL or WILL NOT throw NPE >> when present with nulls. We have made some efforts to avoid throwing >> NPEs from within the Streams library code, but even that is not >> guaranteed (put that in the "reasonable efforts" category.) We expect >> most, but not all, NPEs resulting from null elements to come from code >> outside java.util.stream, such as lambdas passed to the operation, >> Arrays.sort(), the constructor of Optional, etc. >> >> On 11/19/2012 10:17 AM, elena votchennikova wrote: >>> Hello, >>> >>> I'm trying to use method concat(Stream) of some Stream implementation >>> with null-argument and currently it doesn't throw NullPointerException. >>> Exception is thrown only when I call some method of the resulting >>> Stream, for example iterator(). >>> >>> Could you please explain - is it an expected behavior or concat() with >>> null-argument should throw NPE? >>> >>> >>> Thanks a lot, >>> Elena >>> > > From brian.goetz at oracle.com Mon Nov 19 15:34:48 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Nov 2012 18:34:48 -0500 Subject: Convert getStreamFlags() -> EnumSet In-Reply-To: References: Message-ID: <50AAC218.7010603@oracle.com> Given that stream flags are largely an internal implementation mechanism, our current preference is for leaving these things in the integer domain. (Note that we use two bits per flag, to track operation characteristics such as injects-X, preserves-X, clears-X). But a method in StreamOpFlags that takes an int and returns an EnumSet is harmless as long as we don't force its use. A reasonable thing to consider when we expose the Ops APIs. On 11/19/2012 6:12 PM, Paul Benedict wrote: > Brian, I was wondering if there is value in exposing the stream flags also > as an EnumSet. What do you think? Or at least a conversion method that can > take the int and generate the EnumSet > > Paul > From mike.duigou at oracle.com Mon Nov 19 19:55:38 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 19:55:38 -0800 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <50A49205.6030108@oracle.com> References: <50A49205.6030108@oracle.com> Message-ID: <477DA9BF-CC3A-4390-93CB-118C622F9066@oracle.com> The reason is that {Int|Double|Long}Function take an object and yield a primitive. Supplier, BinaryOperator, UnaryOperator and Block variants all operate on the primitive type (or the boxed version) and don't utilize any generic reference types. The only reference types used are the boxed versions of the primitive. Mike On Nov 14 2012, at 22:56 , David Holmes wrote: > Hi Mike, > > My original comment still stands regarding the wording in the Function specializations versus all the others. Why does, for example, IntFunction say "this is the {@code int}-bearing specialization for {@link Function}", yet IntBinaryOperator does not make a similar statement regarding BinaryOperator? > > David > > On 14/11/2012 11:19 AM, Mike Duigou wrote: >> Hello all; >> >> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >> >> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >> >> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >> >> This update includes: >> >> - Block.apply renamed to Block.accept >> - {Int|Long|Double}Block specializations added. >> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >> >> Mike >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From mike.duigou at oracle.com Mon Nov 19 20:55:33 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 20:55:33 -0800 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> I have posted another revision at http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. We don't anticipate many (any?) further changes to the naming before commit at this point. Mike On Nov 13 2012, at 17:19 , Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From mike.duigou at oracle.com Mon Nov 19 20:58:12 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 20:58:12 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On Nov 14 2012, at 02:48 , Stephen Colebourne wrote: > On 13 November 2012 19:05, Mike Duigou wrote: >> - Mapper.map becomes Function.apply >> - Factory.make becomes Supplier.get >> - Specializations of Supplier for int, long, double >> - Reorder type variables to put result last >> - Fixes many javadoc and stylistic comments. >> >> What didn't change: >> - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? >> - Combiner will be part of the full API but it's only present in this patch as a comment. >> - No default methods. >> >> Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) > > The interface definitions say nothing about null. I'd like to see > something in there, even if it is to say "null handling behaviour is > defined by the implementation". For these interfaces it's defined by the APIs which utilize them. I'm unsure how useful it is to say "treatment of nulls depends on usage". Mike From henry.jen at oracle.com Mon Nov 19 21:55:31 2012 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 19 Nov 2012 21:55:31 -0800 Subject: incompatible types compile error In-Reply-To: <50AA362A.7020004@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> Message-ID: <50AB1B53.5060301@oracle.com> On 11/19/2012 05:37 AM, Maurizio Cimadamore wrote: > The problem is that, since you are using Comparable (note the absence of > type-parameters) you are effectively triggering an uunchecked conversion > there - the result would be that the erased signature of 'into' will be > used instead - that is, the return type of into will be simply > Destination - not the type inferred from the argument - hence the > incompatible types error. > I don't quite understand this Comparable cause erased signature for into. Comparators.comparing> should return a Comparator given correct Function type, then in sorted(Comparator) should gave a Stream, isn't the type obvious? Apology if this is a dumb question, I don't know how exactly type inference works. But seems to me, the target type is available. What am I missing? Thanks in advance. Cheers, Henry > Btw - I'm getting the error for both versions of the example you sent. > > Maurizio > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: >> This works, btw. >> >> List sortedFavs = new ArrayList(); >> albums.stream() >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) >> .sorted(comparing((Mapper) album -> >> album.name)) >> .into(sortedFavs); >> >> >> >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: >> >>> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: >>>> Hi, >>>> >>>> I am trying to run a slightly modified version from the latest State of >>> the >>>> Lambda libraries edition. >>>> >>>> List sortedFavs = >>>> albums.stream() >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >>> 4))) >>>> .sorted(comparing((Mapper) album -> >>>> album.name)) >>>> .into(new ArrayList()); >>>> >>>> java: incompatible types: java.util.stream.Stream.Destination cannot be >>>> converted to java.util.List >>>> >>>> Any idea what could be wrong here? >>> the signature of the method into. >>> >>>> -Arul >>>> >>> R?mi >>> >>> >>> > > From ricky.clarkson at gmail.com Mon Nov 19 22:10:01 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Tue, 20 Nov 2012 03:10:01 -0300 Subject: incompatible types compile error In-Reply-To: <50AB1B53.5060301@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> <50AB1B53.5060301@oracle.com> Message-ID: >From the original post: .sorted(comparing((Mapper) album -> Note the raw Comparable. On Tue, Nov 20, 2012 at 2:55 AM, Henry Jen wrote: > On 11/19/2012 05:37 AM, Maurizio Cimadamore wrote: > > The problem is that, since you are using Comparable (note the absence of > > type-parameters) you are effectively triggering an uunchecked conversion > > there - the result would be that the erased signature of 'into' will be > > used instead - that is, the return type of into will be simply > > Destination - not the type inferred from the argument - hence the > > incompatible types error. > > > > I don't quite understand this Comparable cause erased signature for into. > > Comparators.comparing> should > return a Comparator given correct Function type, then in > sorted(Comparator) should gave a Stream, isn't the type > obvious? > > Apology if this is a dumb question, I don't know how exactly type > inference works. But seems to me, the target type is available. What am > I missing? Thanks in advance. > > Cheers, > Henry > > > > Btw - I'm getting the error for both versions of the example you sent. > > > > Maurizio > > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > >> This works, btw. > >> > >> List sortedFavs = new ArrayList(); > >> albums.stream() > >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= > 4))) > >> .sorted(comparing((Mapper) album -> > >> album.name)) > >> .into(sortedFavs); > >> > >> > >> > >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: > >> > >>> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > >>>> Hi, > >>>> > >>>> I am trying to run a slightly modified version from the latest State > of > >>> the > >>>> Lambda libraries edition. > >>>> > >>>> List sortedFavs = > >>>> albums.stream() > >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating > >= > >>> 4))) > >>>> .sorted(comparing((Mapper) album -> > >>>> album.name)) > >>>> .into(new ArrayList()); > >>>> > >>>> java: incompatible types: java.util.stream.Stream.Destination cannot > be > >>>> converted to java.util.List > >>>> > >>>> Any idea what could be wrong here? > >>> the signature of the method into. > >>> > >>>> -Arul > >>>> > >>> R?mi > >>> > >>> > >>> > > > > > > > From david.holmes at oracle.com Mon Nov 19 22:31:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Nov 2012 16:31:42 +1000 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> References: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> Message-ID: <50AB23CE.2030104@oracle.com> Hi Mike, Minor typos and inconsistencies: DoubleBinaryOperator.java 28 * Combines two {@code double} operands producing an {@code double} result. an -> a 51 * @param rightvalue used as the right operand Need space after right 52 * @return result value of the operation "result value" doesn't read right - just "@return the result of ..." - as for BinaryOperator.operate General consistency: all like methods in a family of interfaces should use the same wording. Eg BinaryOperator.operate says "upon the provided operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto across families ie UnaryOperator and BinaryOperator should use consistent terminology for operands and results. --- DoubleBlock.java: 31 * @param The type of input objects to {@code accept}. DoubleBlock is not a generic type. (Surely this should be generating a javadoc warning?) --- DoubleFunction.java 32 * @param the type of input objects to the {@code apply} operation. You now potentially have multiple operation methods, and T refers to the input of all of them. ---- General consistency comments across everything: - Use of operand versus provided operand versus input value etc - Use of result vs computed result vs result value vs output etc --- Function.java 33 * @param the type of output objects from {@code apply} operation. from -> from the 43 * @param t the input object to be to which the function will be applied. delete "to be" ? Or else re-word. --- UnaryOperator.java 28 * Operator on a single operand. Operator -> operate ? 30 * @param the type of input objects to {@code operate} and of the result. objects -> object --- Cheers, David On 20/11/2012 2:55 PM, Mike Duigou wrote: > I have posted another revision at > > http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ > > This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. > > The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. > > We don't anticipate many (any?) further changes to the naming before commit at this point. > > Mike > > On Nov 13 2012, at 17:19 , Mike Duigou wrote: > >> Hello all; >> >> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >> >> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >> >> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >> >> This update includes: >> >> - Block.apply renamed to Block.accept >> - {Int|Long|Double}Block specializations added. >> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >> >> Mike >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From henry.jen at oracle.com Mon Nov 19 22:34:36 2012 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 19 Nov 2012 22:34:36 -0800 Subject: incompatible types compile error In-Reply-To: References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> <50AB1B53.5060301@oracle.com> Message-ID: <78F42FDA-0FE0-4233-849B-DA3A069730B2@oracle.com> On Nov 19, 2012, at 10:10 PM, Ricky Clarkson wrote: > From the original post: > > .sorted(comparing((Mapper) album -> > > Note the raw Comparable. > Yes, but I assume that was at the point where Mapper have the type declaration of Mapper, in that case, Comparators.comparing should still return Comparator. I must miss some point. Cheers, Henry > > On Tue, Nov 20, 2012 at 2:55 AM, Henry Jen wrote: > On 11/19/2012 05:37 AM, Maurizio Cimadamore wrote: > > The problem is that, since you are using Comparable (note the absence of > > type-parameters) you are effectively triggering an uunchecked conversion > > there - the result would be that the erased signature of 'into' will be > > used instead - that is, the return type of into will be simply > > Destination - not the type inferred from the argument - hence the > > incompatible types error. > > > > I don't quite understand this Comparable cause erased signature for into. > > Comparators.comparing> should > return a Comparator given correct Function type, then in > sorted(Comparator) should gave a Stream, isn't the type > obvious? > > Apology if this is a dumb question, I don't know how exactly type > inference works. But seems to me, the target type is available. What am > I missing? Thanks in advance. > > Cheers, > Henry > > > > Btw - I'm getting the error for both versions of the example you sent. > > > > Maurizio > > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > >> This works, btw. > >> > >> List sortedFavs = new ArrayList(); > >> albums.stream() > >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > >> .sorted(comparing((Mapper) album -> > >> album.name)) > >> .into(sortedFavs); > >> > >> > >> > >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: > >> > >>> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > >>>> Hi, > >>>> > >>>> I am trying to run a slightly modified version from the latest State of > >>> the > >>>> Lambda libraries edition. > >>>> > >>>> List sortedFavs = > >>>> albums.stream() > >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= > >>> 4))) > >>>> .sorted(comparing((Mapper) album -> > >>>> album.name)) > >>>> .into(new ArrayList()); > >>>> > >>>> java: incompatible types: java.util.stream.Stream.Destination cannot be > >>>> converted to java.util.List > >>>> > >>>> Any idea what could be wrong here? > >>> the signature of the method into. > >>> > >>>> -Arul > >>>> > >>> R?mi > >>> > >>> > >>> > > > > > > > From johan.haleby at gmail.com Mon Nov 19 23:23:46 2012 From: johan.haleby at gmail.com (Johan Haleby) Date: Tue, 20 Nov 2012 08:23:46 +0100 Subject: Working with immutable collections In-Reply-To: <50AA5906.8010704@oracle.com> References: <50AA5906.8010704@oracle.com> Message-ID: Alright that would probably work, thanks for your answer. How ever personally I'd like to endorse immutability to a greater extent and think it's quite an important concept that has many nice side effects. I can imagine that it doesn't come natural for most people to use a custom CollectionBuilder and thus working immutable data structures will feel like a "second-class citizen" and possible neglected because it's harder and requires extra work. By having an explicit and simple way to create an immutable collection from a stream would probably lower the bar by quite a margin. Regards, /Johan On Mon, Nov 19, 2012 at 5:06 PM, Brian Goetz wrote: > I understand the use case. > > The specific suggestion (add a new stream operation for this one use case, > that cannot help with others, and will invariably give birth to cries for > many more) would be a serious mistake. > > What I think you want is a Builder that implements Destination, therefore > piggybacking on the mechanism that lets into work with any Collection type > (and more). Then it is entirely supported within the library: > > class MyCollectionBuilder implements Stream.Destination { > void addAll(...) > > T build() ... > } > > and then you could say > > stream.filter(...).blah(...) > .into(new MyCollectionBuilder(new ArrayList())).build(); > > > > On 11/19/2012 9:39 AM, Johan Haleby wrote: > >> Hi, >> >> I'm sorry if this has been discussed before but here goes: >> >> Let's say I have an immutable list called "xList" that I want to filter >> and >> return the result as a new *immutable* list. I could do something like >> this: >> >> >> Collections.unmodifiableList(**xList.filter(obj -> >> obj.something()).into(new >> ArrayList()))); >> >> How ever I think this is quite verbose and doesn't follow the fluent style >> of the API. What I would like to have is something a long these lines: >> >> xList.filter(obj -> obj.something()).**intoImmutable(new >> ArrayList())); >> >> "intoImmutable" could then do "Collections.unmodifiableList(**..)" for >> me so >> I don't need to wrap all statements where I want to return an immutable >> collection. >> >> What are your thoughts on this? >> >> Regards, >> /Johan >> >> From boaznahum at gmail.com Mon Nov 19 23:38:02 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Tue, 20 Nov 2012 09:38:02 +0200 Subject: incompatible types compile error In-Reply-To: References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> Message-ID: But it still fails (b64) even without the comparator ------------------------------------------------- //http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html List blue = shapes.stream() .filter(s -> s.getColor() == Color.BLUE) .into(new ArrayList<>()); ------------------------------------------------------------------------------- java: incompatible types: java.util.ArrayList cannot be converted to java.util.List Is it valid code ? Or should I add the type parameter ?: ------------------------------------------------------- List blue = shapes.stream() .filter(s -> s.getColor() == Color.BLUE) .into(new ArrayList()); ------------------------------------------------------- Thanks Boaz On Mon, Nov 19, 2012 at 11:36 PM, Arul Dhesiaseelan wrote: > Thanks Maurizio for the clarification. > > For me, the first usage fails to compile as expected. The second usage > works perfectly fine, I wonder what is different that make second example > work without the type parameter. I tested with today's build. > > List sortedFavs1 = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name > )) > .into(new ArrayList());//java: incompatible types: > java.util.stream.Stream.Destination cannot be converted to > java.util.List > > List sortedFavs2 = new ArrayList(); > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name > )) > .into(sortedFavs2); > > Here is the working version with the type parameter. > > List sortedFavs = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> album.name)) > .into(new ArrayList()); > > > - Arul > > > On Mon, Nov 19, 2012 at 3:37 AM, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > > The problem is that, since you are using Comparable (note the absence of > > type-parameters) you are effectively triggering an uunchecked conversion > > there - the result would be that the erased signature of 'into' will be > > used instead - that is, the return type of into will be simply > Destination > > - not the type inferred from the argument - hence the incompatible types > > error. > > > > Btw - I'm getting the error for both versions of the example you sent. > > > > Maurizio > > > > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > > > >> This works, btw. > >> > >> List sortedFavs = new ArrayList(); > >> albums.stream() > >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= > >> 4))) > >> .sorted(comparing((Mapper<**Comparable, Album>) album -> > >> album.name)) > >> .into(sortedFavs); > >> > >> > >> > >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: > >> > >> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > >>> > >>>> Hi, > >>>> > >>>> I am trying to run a slightly modified version from the latest State > of > >>>> > >>> the > >>> > >>>> Lambda libraries edition. > >>>> > >>>> List sortedFavs = > >>>> albums.stream() > >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating > >= > >>>> > >>> 4))) > >>> > >>>> .sorted(comparing((Mapper<**Comparable, Album>) album -> > >>>> album.name)) > >>>> .into(new ArrayList()); > >>>> > >>>> java: incompatible types: java.util.stream.Stream.**Destination cannot > >>>> be > >>>> converted to java.util.List > >>>> > >>>> Any idea what could be wrong here? > >>>> > >>> the signature of the method into. > >>> > >>> -Arul > >>>> > >>>> R?mi > >>> > >>> > >>> > >>> > > > > From aruld at acm.org Tue Nov 20 00:43:22 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Mon, 19 Nov 2012 22:43:22 -1000 Subject: incompatible types compile error In-Reply-To: <78F42FDA-0FE0-4233-849B-DA3A069730B2@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> <50AB1B53.5060301@oracle.com> <78F42FDA-0FE0-4233-849B-DA3A069730B2@oracle.com> Message-ID: It looks like the inference rules behave differently for these two cases. Case 1 is illegal as per the current rules (erasure?), as you pointed out sorted(comparing((Function) album -> album.name)) does return Stream, so I wonder why the compiler can't infer the type for the terminal op into. I believe this should be legal as well? Case 2 is legal as the type is known before the terminal op and compiler infers just fine. -Arul On Mon, Nov 19, 2012 at 8:34 PM, Henry Jen wrote: > > On Nov 19, 2012, at 10:10 PM, Ricky Clarkson > wrote: > > > From the original post: > > > > .sorted(comparing((Mapper) album -> > > > > Note the raw Comparable. > > > > Yes, but I assume that was at the point where Mapper have the type > declaration of Mapper, in that case, Comparators.comparing should > still return Comparator. I must miss some point. > > Cheers, > Henry > > > > > > On Tue, Nov 20, 2012 at 2:55 AM, Henry Jen wrote: > > On 11/19/2012 05:37 AM, Maurizio Cimadamore wrote: > > > The problem is that, since you are using Comparable (note the absence > of > > > type-parameters) you are effectively triggering an uunchecked > conversion > > > there - the result would be that the erased signature of 'into' will be > > > used instead - that is, the return type of into will be simply > > > Destination - not the type inferred from the argument - hence the > > > incompatible types error. > > > > > > > I don't quite understand this Comparable cause erased signature for into. > > > > Comparators.comparing> should > > return a Comparator given correct Function type, then in > > sorted(Comparator) should gave a Stream, isn't the type > > obvious? > > > > Apology if this is a dumb question, I don't know how exactly type > > inference works. But seems to me, the target type is available. What am > > I missing? Thanks in advance. > > > > Cheers, > > Henry > > > > > > > Btw - I'm getting the error for both versions of the example you sent. > > > > > > Maurizio > > > > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > > >> This works, btw. > > >> > > >> List sortedFavs = new ArrayList(); > > >> albums.stream() > > >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating > >= 4))) > > >> .sorted(comparing((Mapper) album -> > > >> album.name)) > > >> .into(sortedFavs); > > >> > > >> > > >> > > >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax > wrote: > > >> > > >>> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > > >>>> Hi, > > >>>> > > >>>> I am trying to run a slightly modified version from the latest > State of > > >>> the > > >>>> Lambda libraries edition. > > >>>> > > >>>> List sortedFavs = > > >>>> albums.stream() > > >>>> .filter(a -> a.tracks.stream().anyMatch(t -> > (t.rating >= > > >>> 4))) > > >>>> .sorted(comparing((Mapper) album -> > > >>>> album.name)) > > >>>> .into(new ArrayList()); > > >>>> > > >>>> java: incompatible types: java.util.stream.Stream.Destination > cannot be > > >>>> converted to java.util.List > > >>>> > > >>>> Any idea what could be wrong here? > > >>> the signature of the method into. > > >>> > > >>>> -Arul > > >>>> > > >>> R?mi > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > From paul.sandoz at oracle.com Tue Nov 20 00:45:41 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 Nov 2012 09:45:41 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: <50AAB225.9060201@univ-mlv.fr> References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> <50AA0F1F.8050107@univ-mlv.fr> <8B792744-C399-45F6-B10D-EB0C28A96ACA@oracle.com> <50AAB225.9060201@univ-mlv.fr> Message-ID: On Nov 19, 2012, at 11:26 PM, Remi Forax wrote: > On 11/19/2012 01:53 PM, Paul Sandoz wrote: >> On Nov 19, 2012, at 11:51 AM, Remi Forax wrote: >> >>> On 11/19/2012 10:47 AM, Paul Sandoz wrote: >>>> On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: >>>> >>>>>> A code like this should throw a CME and not an AIOOBE >>>>>> arraylist.forEach(e -> { arraylist.remove(e); }) >>>>> The current code won't do that, as it copies the array into a local var >>>>> before the loop, so the indexes are always valid. >>>>> >>>>> A reasonable middle ground is a comodification check after the loop >>>>> terminates. >>>>> >>>> Yes, that's what Mike did with the original array proxy stuff. >>>> >>>> It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. >>> The question is why ArrayList.forEach should not be fail-fast ? >> I think we have to consider the wider context of Iterable/Iterator/Spliterator.forEach when used for parallel evaluation. In such cases it is advantageous not to fail-fast. > > I agree, for parrallel evaluation, forEach is not necessary fail-fast > but it has to be or snapshot or weekly consistent > and not to have an undefined behaviour. > >> >> So while there is a precedent for the Iterator impls to fail-fast it does not necessarily mean all forEach impls should by default do the same. > > forEach doesn't have to be fail-fast but ArrayList.forEach has to be > failfast. > I tend to agreed. Perhaps we can state something along the lines that unless otherwise stated forEach implementations are not fail-fast. Paul. From paul.sandoz at oracle.com Tue Nov 20 00:51:01 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 Nov 2012 09:51:01 +0100 Subject: Convert getStreamFlags() -> EnumSet In-Reply-To: <50AAC218.7010603@oracle.com> References: <50AAC218.7010603@oracle.com> Message-ID: <7747E9FB-B8AC-4ADF-98E3-512A6E15BB5E@oracle.com> On Nov 20, 2012, at 12:34 AM, Brian Goetz wrote: > Given that stream flags are largely an internal implementation > mechanism, our current preference is for leaving these things in the > integer domain. (Note that we use two bits per flag, to track operation > characteristics such as injects-X, preserves-X, clears-X). > Right, it's more efficient to do all the bit operations for producing bit masks and combining. > But a method in StreamOpFlags that takes an int and returns an EnumSet > is harmless as long as we don't force its use. A reasonable thing to > consider when we expose the Ops APIs. > It's probably useful for debugging/tests even if it is not used really used for other purposes as it makes me go cross eyed looking at the binary values. When i have a spare moment i will add something. Paul. > On 11/19/2012 6:12 PM, Paul Benedict wrote: >> Brian, I was wondering if there is value in exposing the stream flags also >> as an EnumSet. What do you think? Or at least a conversion method that can >> take the int and generate the EnumSet >> >> Paul >> > From aruld at acm.org Tue Nov 20 01:06:54 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Mon, 19 Nov 2012 23:06:54 -1000 Subject: incompatible types compile error In-Reply-To: References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> Message-ID: I believe you should still need to add the type parameter in this case. Some background on this can be found in this thread : http://mail.openjdk.java.net/pipermail/lambda-dev/2012-May/004951.html -Arul On Mon, Nov 19, 2012 at 9:38 PM, Boaz Nahum wrote: > But it still fails (b64) even without the comparator > ------------------------------------------------- > //http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html > > List blue = shapes.stream() > .filter(s -> s.getColor() == Color.BLUE) > .into(new ArrayList<>()); > > ------------------------------------------------------------------------------- > java: incompatible types: java.util.ArrayList cannot be > converted to java.util.List > > Is it valid code ? Or should I add the type parameter ?: > ------------------------------------------------------- > List blue = shapes.stream() > .filter(s -> s.getColor() == Color.BLUE) > .into(new ArrayList()); > ------------------------------------------------------- > > Thanks > Boaz > > > > On Mon, Nov 19, 2012 at 11:36 PM, Arul Dhesiaseelan wrote: > > > Thanks Maurizio for the clarification. > > > > For me, the first usage fails to compile as expected. The second usage > > works perfectly fine, I wonder what is different that make second example > > work without the type parameter. I tested with today's build. > > > > List sortedFavs1 = albums.stream() > > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > > .sorted(comparing((Function) album -> > > album.name > > )) > > .into(new ArrayList());//java: incompatible types: > > java.util.stream.Stream.Destination cannot be converted to > > java.util.List > > > > List sortedFavs2 = new ArrayList(); > > albums.stream() > > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > > .sorted(comparing((Function) album -> > > album.name > > )) > > .into(sortedFavs2); > > > > Here is the working version with the type parameter. > > > > List sortedFavs = albums.stream() > > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > > .sorted(comparing((Function) album -> album.name > )) > > .into(new ArrayList()); > > > > > > - Arul > > > > > > On Mon, Nov 19, 2012 at 3:37 AM, Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com> wrote: > > > > > The problem is that, since you are using Comparable (note the absence > of > > > type-parameters) you are effectively triggering an uunchecked > conversion > > > there - the result would be that the erased signature of 'into' will be > > > used instead - that is, the return type of into will be simply > > Destination > > > - not the type inferred from the argument - hence the incompatible > types > > > error. > > > > > > Btw - I'm getting the error for both versions of the example you sent. > > > > > > Maurizio > > > > > > > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > > > > > >> This works, btw. > > >> > > >> List sortedFavs = new ArrayList(); > > >> albums.stream() > > >> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= > > >> 4))) > > >> .sorted(comparing((Mapper<**Comparable, Album>) album -> > > >> album.name)) > > >> .into(sortedFavs); > > >> > > >> > > >> > > >> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax > wrote: > > >> > > >> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> I am trying to run a slightly modified version from the latest State > > of > > >>>> > > >>> the > > >>> > > >>>> Lambda libraries edition. > > >>>> > > >>>> List sortedFavs = > > >>>> albums.stream() > > >>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating > > >= > > >>>> > > >>> 4))) > > >>> > > >>>> .sorted(comparing((Mapper<**Comparable, Album>) album > -> > > >>>> album.name)) > > >>>> .into(new ArrayList()); > > >>>> > > >>>> java: incompatible types: java.util.stream.Stream.**Destination > cannot > > >>>> be > > >>>> converted to java.util.List > > >>>> > > >>>> Any idea what could be wrong here? > > >>>> > > >>> the signature of the method into. > > >>> > > >>> -Arul > > >>>> > > >>>> R?mi > > >>> > > >>> > > >>> > > >>> > > > > > > > > From forax at univ-mlv.fr Tue Nov 20 02:32:04 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 20 Nov 2012 11:32:04 +0100 Subject: hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists In-Reply-To: References: <20121118185815.2B7EE47A3D@hg.openjdk.java.net> <50A93DBD.2060508@univ-mlv.fr> <50A944F7.5040508@oracle.com> <50AA0F1F.8050107@univ-mlv.fr> <8B792744-C399-45F6-B10D-EB0C28A96ACA@oracle.com> <50AAB225.9060201@univ-mlv.fr> Message-ID: <50AB5C24.6030207@univ-mlv.fr> On 11/20/2012 09:45 AM, Paul Sandoz wrote: > On Nov 19, 2012, at 11:26 PM, Remi Forax wrote: > >> On 11/19/2012 01:53 PM, Paul Sandoz wrote: >>> On Nov 19, 2012, at 11:51 AM, Remi Forax wrote: >>> >>>> On 11/19/2012 10:47 AM, Paul Sandoz wrote: >>>>> On Nov 18, 2012, at 9:28 PM, Brian Goetz wrote: >>>>> >>>>>>> A code like this should throw a CME and not an AIOOBE >>>>>>> arraylist.forEach(e -> { arraylist.remove(e); }) >>>>>> The current code won't do that, as it copies the array into a local var >>>>>> before the loop, so the indexes are always valid. >>>>>> >>>>>> A reasonable middle ground is a comodification check after the loop >>>>>> terminates. >>>>>> >>>>> Yes, that's what Mike did with the original array proxy stuff. >>>>> >>>>> It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException. >>>> The question is why ArrayList.forEach should not be fail-fast ? >>> I think we have to consider the wider context of Iterable/Iterator/Spliterator.forEach when used for parallel evaluation. In such cases it is advantageous not to fail-fast. >> I agree, for parrallel evaluation, forEach is not necessary fail-fast >> but it has to be or snapshot or weekly consistent >> and not to have an undefined behaviour. >> >>> So while there is a precedent for the Iterator impls to fail-fast it does not necessarily mean all forEach impls should by default do the same. >> forEach doesn't have to be fail-fast but ArrayList.forEach has to be >> failfast. >> > I tend to agreed. > > Perhaps we can state something along the lines that unless otherwise stated forEach implementations are not fail-fast. > > Paul. > I prefer something like if the stream is created from a collection and if the iterator of this collection is fail-fast then the forEach implementation must be fail-fast. R?mi From maurizio.cimadamore at oracle.com Tue Nov 20 04:51:58 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 20 Nov 2012 12:51:58 +0000 Subject: incompatible types compile error In-Reply-To: References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> Message-ID: <50AB7CEE.20104@oracle.com> On 19/11/12 21:36, Arul Dhesiaseelan wrote: > Thanks Maurizio for the clarification. > > For me, the first usage fails to compile as expected. The second usage > works perfectly fine, I wonder what is different that make second > example work without the type parameter. I tested with today's build. > > List sortedFavs1 = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name )) > .into(new ArrayList());//java: incompatible types: > java.util.stream.Stream.Destination cannot be converted to > java.util.List > > List sortedFavs2 = new ArrayList(); > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name )) > .into(sortedFavs2); The difference between the two versions is that in the second one you are not assigning the results of 'into' to anything - unlike the first case - that is, the compiler doesn't detect the incompatibility because there's no incompatibility to detect! As for why the program fails - here's a quick reproducer we can reason about: import java.util.function.*; import java.util.*; import java.util.stream.*; import static java.util.Comparators.comparing; class Album { } class Test { void test(Stream albums, List d) { List test1(Stream s, Function f) { return s.sorted(comparing(f)).into(new ArrayList()); } List test2(Stream s, Function f, List d) { return s.sorted(comparing(f)).into(d); } } Note that this doesn't even have lambdas in it - the fact that you were using a cast actually made the lambda pointless in terms of how inference/overload resolution work - i.e. when you have: (Function) the type of the lambda WILL be Function - no matter what's the contents of the lambda. So, why does this give an unchecked warning in the first place? The signature of Comparator.comparing is: > Comparator comparing(Function mapper) So, in order to check method applicability we have to test as to whether Function is a subtype of Function, written Function <: Function Now, after subtyping, you end up with the following constraints on inference variables: T, U T <: Album U :> Comparable Since the first part of type-inference (15.12.2.7) takes lower bound into account, you end up with U inferred to Comparable. The next step is to check as to whether the inferred type conforms to the declared bound - to do that you have to replace the inferred type in the bound declaration and see whether the inferred type is a subtype of that replacement: Comparable <: [U:=Comparable]Comparable = Comparable This is valid - but requires an unchecked conversion for going from Comparable (raw) to Comparable - hence, an unchecked conversion is required here. The spec mandates that whenever an unchecked conversion occurs within a method call, the signature of the method must be erased - this means that the Comparators.comparing method will simply return a raw 'Comparator'. So again, we are passing a raw type where a generic type is expected - again unchecked conversion kicks in and the return type of 'Stream.sorted' is erased leading to a raw 'Stream'. Now, accessing a member of a raw type ('into' in this case) always cause the signature of the method to be erased, which means the compiler will see that 'into' has the following signature: Destination into(Destination) So, it's absolutely fine to pass in any implementation of the Destination class (as ArrayList is) - but the problem is in the return type - which will only be (a raw) Destination. So, trying to assign the return type of a raw 'into' call to anithing but Destination will result in a type-mismatch. Maurizio > > Here is the working version with the type parameter. > > List sortedFavs = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name )) > .into(new ArrayList()); > > > - Arul > > > On Mon, Nov 19, 2012 at 3:37 AM, Maurizio Cimadamore > > wrote: > > The problem is that, since you are using Comparable (note the > absence of type-parameters) you are effectively triggering an > uunchecked conversion there - the result would be that the erased > signature of 'into' will be used instead - that is, the return > type of into will be simply Destination - not the type inferred > from the argument - hence the incompatible types error. > > Btw - I'm getting the error for both versions of the example you sent. > > Maurizio > > > On 16/11/12 23:01, Arul Dhesiaseelan wrote: > > This works, btw. > > List sortedFavs = new ArrayList(); > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> > (t.rating >= 4))) > .sorted(comparing((Mapper) > album -> > album.name )) > .into(sortedFavs); > > > > On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax > > wrote: > > On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: > > Hi, > > I am trying to run a slightly modified version from > the latest State of > > the > > Lambda libraries edition. > > List sortedFavs = > albums.stream() > .filter(a -> > a.tracks.stream().anyMatch(t -> (t.rating >= > > 4))) > > .sorted(comparing((Mapper Album>) album -> > album.name )) > .into(new ArrayList()); > > java: incompatible types: > java.util.stream.Stream.Destination cannot be > converted to java.util.List > > Any idea what could be wrong here? > > the signature of the method into. > > -Arul > > R?mi > > > > > From paul.sandoz at oracle.com Tue Nov 20 04:53:46 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 20 Nov 2012 12:53:46 +0000 Subject: hg: lambda/lambda/jdk: Ensure stream flags are correctly obtained from combined stream and ops flags. Message-ID: <20121120125406.C0E0A47A79@hg.openjdk.java.net> Changeset: 0a30434d0121 Author: psandoz Date: 2012-11-20 13:53 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0a30434d0121 Ensure stream flags are correctly obtained from combined stream and ops flags. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/StreamOpFlags.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java From paul.sandoz at oracle.com Tue Nov 20 06:25:19 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 20 Nov 2012 14:25:19 +0000 Subject: hg: lambda/lambda/jdk: - fold and seedless fold ops for IntStream.reduce methods Message-ID: <20121120142539.5C27D47A7D@hg.openjdk.java.net> Changeset: ffc074f5b2e9 Author: psandoz Date: 2012-11-20 15:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ffc074f5b2e9 - fold and seedless fold ops for IntStream.reduce methods - IntStream.min/max/sum impls using reduce with base value ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java + src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java + src/share/classes/java/util/stream/primitive/IntSeedlessFoldOp.java ! src/share/classes/java/util/stream/primitive/IntStream.java - src/share/classes/java/util/stream/primitive/IntSumOp.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSumTest.java From paul.sandoz at oracle.com Tue Nov 20 07:34:38 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 20 Nov 2012 15:34:38 +0000 Subject: hg: lambda/lambda/jdk: - implement IntStream.average (arithemtic mean). Message-ID: <20121120153449.CEC4547A84@hg.openjdk.java.net> Changeset: 932b4939d7c8 Author: psandoz Date: 2012-11-20 16:34 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/932b4939d7c8 - implement IntStream.average (arithemtic mean). + src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntAverageOpTest.java From brian.goetz at oracle.com Tue Nov 20 07:51:07 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 Nov 2012 10:51:07 -0500 Subject: hg: lambda/lambda/jdk: - implement IntStream.average (arithemtic mean). In-Reply-To: <20121120153449.CEC4547A84@hg.openjdk.java.net> References: <20121120153449.CEC4547A84@hg.openjdk.java.net> Message-ID: <50ABA6EB.5050507@oracle.com> Rather than reduce with Integer::sum, should sum() use a reducing sink that internally does computation in long so as to be less sensitive to overflow when adding BIG + BIG + NEGATIVE_BIG? On 11/20/2012 10:34 AM, paul.sandoz at oracle.com wrote: > Changeset: 932b4939d7c8 > Author: psandoz > Date: 2012-11-20 16:34 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/932b4939d7c8 > > - implement IntStream.average (arithemtic mean). > > + src/share/classes/java/util/stream/primitive/IntAverageOp.java > ! src/share/classes/java/util/stream/primitive/IntPipeline.java > ! src/share/classes/java/util/stream/primitive/IntStream.java > + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntAverageOpTest.java > > From forax at univ-mlv.fr Tue Nov 20 07:58:08 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 20 Nov 2012 16:58:08 +0100 Subject: hg: lambda/lambda/jdk: - implement IntStream.average (arithemtic mean). In-Reply-To: <50ABA6EB.5050507@oracle.com> References: <20121120153449.CEC4547A84@hg.openjdk.java.net> <50ABA6EB.5050507@oracle.com> Message-ID: <50ABA890.80700@univ-mlv.fr> On 11/20/2012 04:51 PM, Brian Goetz wrote: > Rather than reduce with Integer::sum, should sum() use a reducing sink > that internally does computation in long so as to be less sensitive to > overflow when adding BIG + BIG + NEGATIVE_BIG? I don't think it's a good idea because you can't use the same trick for long.average(). R?mi > > On 11/20/2012 10:34 AM, paul.sandoz at oracle.com wrote: >> Changeset: 932b4939d7c8 >> Author: psandoz >> Date: 2012-11-20 16:34 +0100 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/932b4939d7c8 >> >> - implement IntStream.average (arithemtic mean). >> >> + src/share/classes/java/util/stream/primitive/IntAverageOp.java >> ! src/share/classes/java/util/stream/primitive/IntPipeline.java >> ! src/share/classes/java/util/stream/primitive/IntStream.java >> + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntAverageOpTest.java >> >> From richard.warburton at gmail.com Tue Nov 20 08:07:16 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 20 Nov 2012 16:07:16 +0000 Subject: Library changes related to Lambdas Message-ID: Hey all, We're trying to solicit community feedback on Lambda-related library changes and make a collated list easily accessible to the expert group. If you have any suggestions for library additions then please submit them at the following form: http://bit.ly/TO9FD4 regards, Richard From paul.sandoz at oracle.com Tue Nov 20 08:46:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 Nov 2012 17:46:56 +0100 Subject: hg: lambda/lambda/jdk: - implement IntStream.average (arithemtic mean). In-Reply-To: <50ABA6EB.5050507@oracle.com> References: <20121120153449.CEC4547A84@hg.openjdk.java.net> <50ABA6EB.5050507@oracle.com> Message-ID: On Nov 20, 2012, at 4:51 PM, Brian Goetz wrote: > Rather than reduce with Integer::sum, should sum() use a reducing sink that internally does computation in long so as to be less sensitive to overflow when adding BIG + BIG + NEGATIVE_BIG? > I was wondering about whether IntStream.sum() should return long or not, and also what to do on overflows, i suppose one such answer would be for developers to do: s.reduce(0, Math::addExact) and catch the ArithmeticException. Perhaps another solution is to widen the stream? s.asLongs().sum() Not as efficient though. Paul. > On 11/20/2012 10:34 AM, paul.sandoz at oracle.com wrote: >> Changeset: 932b4939d7c8 >> Author: psandoz >> Date: 2012-11-20 16:34 +0100 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/932b4939d7c8 >> >> - implement IntStream.average (arithemtic mean). >> >> + src/share/classes/java/util/stream/primitive/IntAverageOp.java >> ! src/share/classes/java/util/stream/primitive/IntPipeline.java >> ! src/share/classes/java/util/stream/primitive/IntStream.java >> + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntAverageOpTest.java >> >> From henry.jen at oracle.com Tue Nov 20 08:52:47 2012 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 20 Nov 2012 08:52:47 -0800 Subject: incompatible types compile error In-Reply-To: <50AB7CEE.20104@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> <50AB7CEE.20104@oracle.com> Message-ID: <0921C3AC-A3D7-4B86-961A-18EF476293D0@oracle.com> On Nov 20, 2012, at 4:51 AM, Maurizio Cimadamore wrote: > The spec mandates that whenever an unchecked conversion occurs within a > method call, the signature of the method must be erased - this means > that the Comparators.comparing method will simply return a raw > 'Comparator'. Thanks for the detailed explanation, really appreciate. Cheers, Henry From brian.goetz at oracle.com Tue Nov 20 08:55:46 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 20 Nov 2012 16:55:46 +0000 Subject: hg: lambda/lambda/jdk: More stream flags tests Message-ID: <20121120165608.58A2247A8C@hg.openjdk.java.net> Changeset: 8a58ecf4853e Author: briangoetz Date: 2012-11-20 11:55 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8a58ecf4853e More stream flags tests ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/StreamOpFlags.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java From brian.goetz at oracle.com Tue Nov 20 09:44:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 20 Nov 2012 17:44:04 +0000 Subject: hg: lambda/lambda/jdk: Improve implementation of ArrayList.forEach Message-ID: <20121120174416.2688C47A90@hg.openjdk.java.net> Changeset: 17888810ebe5 Author: briangoetz Date: 2012-11-20 12:44 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/17888810ebe5 Improve implementation of ArrayList.forEach ! src/share/classes/java/util/ArrayList.java From per at bothner.com Tue Nov 20 10:23:58 2012 From: per at bothner.com (Per Bothner) Date: Tue, 20 Nov 2012 10:23:58 -0800 Subject: API design: (start,length) vs (start,end) Message-ID: <50ABCABE.4020901@bothner.com> The Java APIs have many methods that select a slice of a sequence or an array, but there is no consistency as to how to specify the slice: Many places uses (fromIndex, toIndex), and many other places uses (fromIndex,length). Specifically, I notice that java.util.streams.Streams uses (fromIndex,length), while *older* methods in java.util.Arrays use (fromIndex, toIndex), but the newly added ones use (fromIndex,length). This inconsistency is unfortunate. As mentioned the Java APIs are already inconsistent, so to some extent we just have to live with it, but the inconsistency within the Arrays class seems extra unfortunate. Was there a considered decision to use (fromIndex,length) instead of (fromIndex,toIndex) in new methods? When designing my own APIs is there any reason to choose one or the other? -- --Per Bothner per at bothner.com http://per.bothner.com/ From julianhyde at gmail.com Tue Nov 20 10:30:40 2012 From: julianhyde at gmail.com (Julian Hyde) Date: Tue, 20 Nov 2012 10:30:40 -0800 Subject: API design: (start,length) vs (start,end) In-Reply-To: <50ABCABE.4020901@bothner.com> References: <50ABCABE.4020901@bothner.com> Message-ID: <1300D057-4F91-4B23-8F8B-580B123E8D0E@gmail.com> On Nov 20, 2012, at 10:23 AM, Per Bothner wrote: > The Java APIs have many methods that select a slice of a > sequence or an array, but there is no consistency as to > how to specify the slice: Many places uses (fromIndex, > toIndex), and many other places uses (fromIndex,length). Good point. Every language I use (e.g. Java, awk, SQL), I have to consult the manual on the substr/substring function, for the same reason. Julian From brian.goetz at oracle.com Tue Nov 20 10:34:12 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 Nov 2012 13:34:12 -0500 Subject: API design: (start,length) vs (start,end) In-Reply-To: <50ABCABE.4020901@bothner.com> References: <50ABCABE.4020901@bothner.com> Message-ID: <50ABCD24.5060708@oracle.com> That's a good point. I had thought there was more precedent for (start, length) but I am not finding it right now. (The inconsistency is made more unfortunate by the fact that both use (int,int) so its easy to get it wrong.) We'll take a look and see what the impact would be here. On 11/20/2012 1:23 PM, Per Bothner wrote: > The Java APIs have many methods that select a slice of a > sequence or an array, but there is no consistency as to > how to specify the slice: Many places uses (fromIndex, > toIndex), and many other places uses (fromIndex,length). > > Specifically, I notice that java.util.streams.Streams uses > (fromIndex,length), while *older* methods in java.util.Arrays > use (fromIndex, toIndex), but the newly added ones use > (fromIndex,length). > > This inconsistency is unfortunate. As mentioned the Java APIs > are already inconsistent, so to some extent we just have to > live with it, but the inconsistency within the Arrays class > seems extra unfortunate. > > Was there a considered decision to use (fromIndex,length) > instead of (fromIndex,toIndex) in new methods? When designing > my own APIs is there any reason to choose one or the other? > From per at bothner.com Tue Nov 20 10:42:12 2012 From: per at bothner.com (Per Bothner) Date: Tue, 20 Nov 2012 10:42:12 -0800 Subject: API design: (start,length) vs (start,end) In-Reply-To: <50ABCD24.5060708@oracle.com> References: <50ABCABE.4020901@bothner.com> <50ABCD24.5060708@oracle.com> Message-ID: <50ABCF04.9070800@bothner.com> On 11/20/2012 10:34 AM, Brian Goetz wrote: > That's a good point. I had thought there was more precedent for (start, > length) but I am not finding it right now. The java.lang.String constructors take (offset,count) - but String#subssring and CharSequence#subSequence take (fromIndex,toIndex). -- --Per Bothner per at bothner.com http://per.bothner.com/ From kevinb at google.com Tue Nov 20 10:43:33 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 20 Nov 2012 10:43:33 -0800 Subject: API design: (start,length) vs (start,end) In-Reply-To: <50ABCABE.4020901@bothner.com> References: <50ABCABE.4020901@bothner.com> Message-ID: It's "delightful" that classes like Writer have even wound up with methods of both styles right in the same class. I've never been quite able to "solve" this issue, but I would note that from/length is a lot more, shall we say, "streamy" in nature than from/to. On Tue, Nov 20, 2012 at 10:23 AM, Per Bothner wrote: > The Java APIs have many methods that select a slice of a > sequence or an array, but there is no consistency as to > how to specify the slice: Many places uses (fromIndex, > toIndex), and many other places uses (fromIndex,length). > > Specifically, I notice that java.util.streams.Streams uses > (fromIndex,length), while *older* methods in java.util.Arrays > use (fromIndex, toIndex), but the newly added ones use > (fromIndex,length). > > This inconsistency is unfortunate. As mentioned the Java APIs > are already inconsistent, so to some extent we just have to > live with it, but the inconsistency within the Arrays class > seems extra unfortunate. > > Was there a considered decision to use (fromIndex,length) > instead of (fromIndex,toIndex) in new methods? When designing > my own APIs is there any reason to choose one or the other? > -- > --Per Bothner > per at bothner.com http://per.bothner.com/ > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From jonathan.gibbons at oracle.com Tue Nov 20 10:52:51 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Nov 2012 10:52:51 -0800 Subject: API design: (start,length) vs (start,end) In-Reply-To: <50ABCD24.5060708@oracle.com> References: <50ABCABE.4020901@bothner.com> <50ABCD24.5060708@oracle.com> Message-ID: <50ABD183.5070701@oracle.com> Don't forget to examine the added factor of closed intervals vs half-open intervals. -- Jon On 11/20/2012 10:34 AM, Brian Goetz wrote: > That's a good point. I had thought there was more precedent for (start, > length) but I am not finding it right now. (The inconsistency is made > more unfortunate by the fact that both use (int,int) so its easy to get > it wrong.) > > We'll take a look and see what the impact would be here. > > On 11/20/2012 1:23 PM, Per Bothner wrote: >> The Java APIs have many methods that select a slice of a >> sequence or an array, but there is no consistency as to >> how to specify the slice: Many places uses (fromIndex, >> toIndex), and many other places uses (fromIndex,length). >> >> Specifically, I notice that java.util.streams.Streams uses >> (fromIndex,length), while *older* methods in java.util.Arrays >> use (fromIndex, toIndex), but the newly added ones use >> (fromIndex,length). >> >> This inconsistency is unfortunate. As mentioned the Java APIs >> are already inconsistent, so to some extent we just have to >> live with it, but the inconsistency within the Arrays class >> seems extra unfortunate. >> >> Was there a considered decision to use (fromIndex,length) >> instead of (fromIndex,toIndex) in new methods? When designing >> my own APIs is there any reason to choose one or the other? >> From aruld at acm.org Tue Nov 20 11:05:47 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Tue, 20 Nov 2012 09:05:47 -1000 Subject: incompatible types compile error In-Reply-To: <50AB7CEE.20104@oracle.com> References: <50A6C06A.2030301@univ-mlv.fr> <50AA362A.7020004@oracle.com> <50AB7CEE.20104@oracle.com> Message-ID: Thanks Maurizio for the excellent writeup, this clears up many things for me. On Tue, Nov 20, 2012 at 2:51 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > On 19/11/12 21:36, Arul Dhesiaseelan wrote: > > Thanks Maurizio for the clarification. > > For me, the first usage fails to compile as expected. The second usage > works perfectly fine, I wonder what is different that make second example > work without the type parameter. I tested with today's build. > > List sortedFavs1 = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name)) > .into(new ArrayList());//java: incompatible types: > java.util.stream.Stream.Destination cannot be converted to > java.util.List > > List sortedFavs2 = new ArrayList(); > albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> > album.name)) > .into(sortedFavs2); > > > The difference between the two versions is that in the second one you are > not assigning the results of 'into' to anything - unlike the first case - > that is, the compiler doesn't detect the incompatibility because there's no > incompatibility to detect! > > As for why the program fails - here's a quick reproducer we can reason > about: > > import java.util.function.*; > import java.util.*; > import java.util.stream.*; > > import static java.util.Comparators.comparing; > > class Album { } > > class Test { > > > void test(Stream albums, List d) { > List test1(Stream s, Function f) { > return s.sorted(comparing(f)).into(new ArrayList()); > } > > List test2(Stream s, Function f, > List d) { > return s.sorted(comparing(f)).into(d); > } > } > > Note that this doesn't even have lambdas in it - the fact that you were > using a cast actually made the lambda pointless in terms of how > inference/overload resolution work - i.e. when you have: > > (Function) > > the type of the lambda WILL be Function - no matter > what's the contents of the lambda. > > So, why does this give an unchecked warning in the first place? > > The signature of Comparator.comparing is: > > > Comparator comparing(Function mapper) > > > So, in order to check method applicability we have to test as to whether > Function is a subtype of Function U>, written > > Function <: Function > > Now, after subtyping, you end up with the following constraints on > inference variables: T, U > > T <: Album > U :> Comparable > > Since the first part of type-inference (15.12.2.7) takes lower bound into > account, you end up with U inferred to Comparable. > The next step is to check as to whether the inferred type conforms to the > declared bound - to do that you have to replace the inferred type in the > bound declaration and see whether the inferred type is a subtype of that > replacement: > > Comparable <: [U:=Comparable]Comparable = Comparable Comparable> > > This is valid - but requires an unchecked conversion for going from > Comparable (raw) to Comparable - hence, an unchecked > conversion is required here. > > The spec mandates that whenever an unchecked conversion occurs within a > method call, the signature of the method must be erased - this means that > the Comparators.comparing method will simply return a raw 'Comparator'. So > again, we are passing a raw type where a generic type is expected - again > unchecked conversion kicks in and the return type of 'Stream.sorted' is > erased leading to a raw 'Stream'. Now, accessing a member of a raw type > ('into' in this case) always cause the signature of the method to be > erased, which means the compiler will see that 'into' has the following > signature: > > Destination into(Destination) > > So, it's absolutely fine to pass in any implementation of the Destination > class (as ArrayList is) - but the problem is in the return type - which > will only be (a raw) Destination. So, trying to assign the return type of a > raw 'into' call to anithing but Destination will result in a type-mismatch. > > Maurizio > > > Here is the working version with the type parameter. > > List sortedFavs = albums.stream() > .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= 4))) > .sorted(comparing((Function) album -> album.name)) > .into(new ArrayList()); > > > - Arul > > > On Mon, Nov 19, 2012 at 3:37 AM, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> The problem is that, since you are using Comparable (note the absence of >> type-parameters) you are effectively triggering an uunchecked conversion >> there - the result would be that the erased signature of 'into' will be >> used instead - that is, the return type of into will be simply Destination >> - not the type inferred from the argument - hence the incompatible types >> error. >> >> Btw - I'm getting the error for both versions of the example you sent. >> >> Maurizio >> >> >> On 16/11/12 23:01, Arul Dhesiaseelan wrote: >> >>> This works, btw. >>> >>> List sortedFavs = new ArrayList(); >>> albums.stream() >>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >>> 4))) >>> .sorted(comparing((Mapper) album -> >>> album.name)) >>> .into(sortedFavs); >>> >>> >>> >>> On Fri, Nov 16, 2012 at 12:38 PM, Remi Forax wrote: >>> >>> On 11/16/2012 10:57 PM, Arul Dhesiaseelan wrote: >>>> >>>>> Hi, >>>>> >>>>> I am trying to run a slightly modified version from the latest State of >>>>> >>>> the >>>> >>>>> Lambda libraries edition. >>>>> >>>>> List sortedFavs = >>>>> albums.stream() >>>>> .filter(a -> a.tracks.stream().anyMatch(t -> (t.rating >= >>>>> >>>> 4))) >>>> >>>>> .sorted(comparing((Mapper) album -> >>>>> album.name)) >>>>> .into(new ArrayList()); >>>>> >>>>> java: incompatible types: java.util.stream.Stream.Destination cannot be >>>>> converted to java.util.List >>>>> >>>>> Any idea what could be wrong here? >>>>> >>>> the signature of the method into. >>>> >>>> -Arul >>>>> >>>>> R?mi >>>> >>>> >>>> >>>> >> > > From mike.duigou at oracle.com Tue Nov 20 12:37:39 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:37:39 +0000 Subject: hg: lambda/lambda/langtools: 3 new changesets Message-ID: <20121120203751.C5DF747A97@hg.openjdk.java.net> Changeset: b5d326a809a1 Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b5d326a809a1 Added tag jdk8-b65 for changeset 5f2faba89cac ! .hgtags Changeset: 90e6ed5ff873 Author: mduigou Date: 2012-11-19 17:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/90e6ed5ff873 Merge ! .hgtags Changeset: 6e3b99f6a08a Author: mcimadamore Date: 2012-11-20 10:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6e3b99f6a08a switch to generating v52 class files for java 8. ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh From mike.duigou at oracle.com Tue Nov 20 12:37:37 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:37:37 +0000 Subject: hg: lambda/lambda/corba: 17 new changesets Message-ID: <20121120203751.CC13247A98@hg.openjdk.java.net> Changeset: 2394155f9f9e Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/2394155f9f9e Added tag jdk8-b61 for changeset 0e08ba7648fb ! .hgtags Changeset: 0a5931be9176 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/0a5931be9176 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 08afb9c6f44f Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/08afb9c6f44f Merge Changeset: bbaef650c3d2 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/bbaef650c3d2 Added tag jdk8-b62 for changeset 08afb9c6f44f ! .hgtags Changeset: 679e8ad9874f Author: coffeys Date: 2012-10-09 20:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/679e8ad9874f 7196086: update copyright years for files in corba repository (JDK 8) Reviewed-by: lancea ! make/common/Defs-bsd.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Defs-bsd.gmk ! make/common/shared/Defs-utils.gmk ! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java ! make/tools/strip_properties/Makefile Changeset: 706684c5a058 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/706684c5a058 Merge Changeset: 23e0226a31ac Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/23e0226a31ac Merge Changeset: 9094cd4a614f Author: lana Date: 2012-10-25 20:05 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/9094cd4a614f Merge ! make/common/shared/Defs-utils.gmk Changeset: de2b8def2be5 Author: ohair Date: 2012-10-26 14:24 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/de2b8def2be5 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 6ccbf67b68bf Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/6ccbf67b68bf Merge Changeset: b450c07849ab Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/b450c07849ab Added tag jdk8-b63 for changeset 6ccbf67b68bf ! .hgtags Changeset: 643e7612cf6d Author: ohrstrom Date: 2012-10-29 14:10 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/643e7612cf6d 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Reviewed-by: alanb, wetmore ! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java + src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java Changeset: aac74d377a03 Author: lana Date: 2012-10-30 23:26 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/aac74d377a03 Merge Changeset: 54d599a5b4aa Author: lana Date: 2012-11-02 17:54 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/54d599a5b4aa Merge Changeset: 5132f7900a8f Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/5132f7900a8f Added tag jdk8-b64 for changeset 54d599a5b4aa ! .hgtags Changeset: 65771ad1ca55 Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/65771ad1ca55 Added tag jdk8-b65 for changeset 5132f7900a8f ! .hgtags Changeset: 409dc1a4647a Author: mduigou Date: 2012-11-19 15:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/409dc1a4647a Merge ! .hgtags From mike.duigou at oracle.com Tue Nov 20 12:37:39 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:37:39 +0000 Subject: hg: lambda/lambda/jaxws: 8 new changesets Message-ID: <20121120203759.DCA6F47A99@hg.openjdk.java.net> Changeset: d265b9b4c0f5 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d265b9b4c0f5 Added tag jdk8-b61 for changeset 97e5e74e2a34 ! .hgtags Changeset: c27ea8d489e8 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/c27ea8d489e8 Added tag jdk8-b62 for changeset d265b9b4c0f5 ! .hgtags Changeset: c30a7cb5c587 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/c30a7cb5c587 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: 86989f702267 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/86989f702267 Merge Changeset: 5ded18a14bcc Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/5ded18a14bcc Added tag jdk8-b63 for changeset 86989f702267 ! .hgtags Changeset: fbe54291c9d3 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/fbe54291c9d3 Added tag jdk8-b64 for changeset 5ded18a14bcc ! .hgtags Changeset: 3eb7f11cb4e0 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/3eb7f11cb4e0 Added tag jdk8-b65 for changeset fbe54291c9d3 ! .hgtags Changeset: a65e484c846f Author: mduigou Date: 2012-11-19 15:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/a65e484c846f Merge ! .hgtags From mike.duigou at oracle.com Tue Nov 20 12:38:04 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:38:04 +0000 Subject: hg: lambda/lambda: 25 new changesets Message-ID: <20121120203806.2A9D847A9A@hg.openjdk.java.net> Changeset: 8343ccdd63f1 Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/8343ccdd63f1 Added tag jdk8-b61 for changeset 20ff117b5090 ! .hgtags Changeset: c12e759ac4e8 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/c12e759ac4e8 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! README-builds.html + make/scripts/fixpath.pl ! make/scripts/vsvars.sh Changeset: 8a3fe0ae06a8 Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/8a3fe0ae06a8 Merge Changeset: 4e984be114bd Author: katleman Date: 2012-10-25 09:52 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/4e984be114bd Added tag jdk8-b62 for changeset 8a3fe0ae06a8 ! .hgtags Changeset: 4bde5640fb36 Author: alanb Date: 2012-10-09 13:25 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/rev/4bde5640fb36 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile Changeset: ce2b111ee869 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/ce2b111ee869 Merge Changeset: 744e165aaf33 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/744e165aaf33 Merge Changeset: ce212cd7ea69 Author: lana Date: 2012-10-25 20:04 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/ce212cd7ea69 Merge Changeset: e64f2cb57d05 Author: ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author: ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author: katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags Changeset: dd1a80efa7cf Author: anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author: lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/65dca75b2a26 Merge Changeset: e20ffc02e437 Author: erikj Date: 2012-11-03 16:15 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/e20ffc02e437 8002183: Increased max number of paths to list in ListPathsSafely to 16000. Reviewed-by: ohair ! common/makefiles/MakeBase.gmk Changeset: ed9e5635fc80 Author: erikj Date: 2012-11-03 16:28 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/rev/ed9e5635fc80 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/JavaCompilation.gmk Changeset: 1c8370a55b30 Author: katleman Date: 2012-11-07 15:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/1c8370a55b30 Merge Changeset: 838a64965131 Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/838a64965131 Added tag jdk8-b64 for changeset 1c8370a55b30 ! .hgtags Changeset: 8bbc72864a41 Author: ohrstrom Date: 2012-11-08 12:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/rev/8bbc72864a41 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! common/makefiles/JavaCompilation.gmk Changeset: 78bb27faf889 Author: tbell Date: 2012-11-12 12:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/78bb27faf889 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: f2ac4d0edaae Author: tbell Date: 2012-11-13 15:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/f2ac4d0edaae 8003274: build-infra: Makefile changes needed for sjavac Summary: changes left in build-infra that are related to sjavac Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeHelpers.gmk Changeset: b772de306dc2 Author: katleman Date: 2012-11-14 12:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/b772de306dc2 Merge Changeset: 0e1b5886b06c Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/0e1b5886b06c Added tag jdk8-b65 for changeset b772de306dc2 ! .hgtags Changeset: 5902ebdc1887 Author: mduigou Date: 2012-11-19 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/5902ebdc1887 Merge ! .hgtags ! common/autoconf/builddeps.m4 ! common/autoconf/configure - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c From mike.duigou at oracle.com Tue Nov 20 12:37:37 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:37:37 +0000 Subject: hg: lambda/lambda/jaxp: 12 new changesets Message-ID: <20121120203811.B9FD747A9B@hg.openjdk.java.net> Changeset: 5d0fa0108d02 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/5d0fa0108d02 Added tag jdk8-b61 for changeset 6b1db0b41d2f ! .hgtags Changeset: a96e34e038f5 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a96e34e038f5 Added tag jdk8-b62 for changeset 5d0fa0108d02 ! .hgtags Changeset: 53a2a4893c8f Author: joehw Date: 2012-10-09 14:19 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/53a2a4893c8f 8000172: 2 SAX features does not work properly Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Changeset: b545c99e4f5e Author: lana Date: 2012-10-12 14:50 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/b545c99e4f5e Merge Changeset: 23e1d537224b Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/23e1d537224b Merge Changeset: fc589819b335 Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/fc589819b335 Merge Changeset: 121fc928a361 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/121fc928a361 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: 192d8a244bc3 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/192d8a244bc3 Merge Changeset: 27ab79568c34 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/27ab79568c34 Added tag jdk8-b63 for changeset 192d8a244bc3 ! .hgtags Changeset: 5cf3c69a93d6 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/5cf3c69a93d6 Added tag jdk8-b64 for changeset 27ab79568c34 ! .hgtags Changeset: e6af1ad464e3 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/e6af1ad464e3 Added tag jdk8-b65 for changeset 5cf3c69a93d6 ! .hgtags Changeset: 01eb94a304c3 Author: mduigou Date: 2012-11-19 15:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/01eb94a304c3 Merge ! .hgtags From mike.duigou at oracle.com Tue Nov 20 12:39:55 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:39:55 +0000 Subject: hg: lambda/lambda/corba: Fix tags Message-ID: <20121120203956.63F8347A9C@hg.openjdk.java.net> Changeset: 114043892357 Author: mduigou Date: 2012-11-20 12:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/114043892357 Fix tags ! .hgtags From mike.duigou at oracle.com Tue Nov 20 12:39:01 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 20:39:01 +0000 Subject: hg: lambda/lambda/jdk: 168 new changesets Message-ID: <20121120211106.11A3647A9F@hg.openjdk.java.net> Changeset: 1ae6420126af Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1ae6420126af Added tag jdk8-b61 for changeset 61ddb3fd000a ! .hgtags Changeset: 61af38b8d4ff Author: twisti Date: 2012-10-19 17:04 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/61af38b8d4ff 8000989: smaller code changes to make future JSR 292 backports easier Reviewed-by: jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/PrivateInvokeTest.java Changeset: 7a7e49acadec Author: kamg Date: 2012-10-22 20:12 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7a7e49acadec 8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated Summary: Exclude java/lang/System/Versions.java test Reviewed-by: sspitsyn, coleenp ! test/ProblemList.txt Changeset: a0a2b186ae28 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a0a2b186ae28 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh ! make/tools/freetypecheck/Makefile + make/tools/msys_build_scripts/dospath.sh + make/tools/msys_build_scripts/dospath.vbs Changeset: 50b8b17449d2 Author: katleman Date: 2012-10-24 13:14 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/50b8b17449d2 Merge Changeset: 65d2c6726487 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/65d2c6726487 Added tag jdk8-b62 for changeset 50b8b17449d2 ! .hgtags Changeset: 117eed515e42 Author: bae Date: 2012-10-23 13:10 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/117eed515e42 7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144 Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: aeb96dec1c6b Author: lana Date: 2012-10-23 09:38 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aeb96dec1c6b Merge Changeset: 93e2669f1ac2 Author: leonidr Date: 2012-10-09 18:00 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/93e2669f1ac2 7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab Reviewed-by: anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 527f8eeb8e8d Author: leonidr Date: 2012-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/527f8eeb8e8d 7124321: [macosx] TrayIcon MouseListener is never triggered Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m Changeset: d4d0327e36e2 Author: kshefov Date: 2012-10-12 18:46 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d4d0327e36e2 7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Reviewed-by: anthony ! test/java/awt/Frame/7024749/bug7024749.java Changeset: 34d502d14a61 Author: lana Date: 2012-10-12 14:47 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/34d502d14a61 Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: f42d178f0452 Author: anthony Date: 2012-10-16 20:11 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f42d178f0452 6818083: When DISPLAY is bad, InternalError thrown, not AWTError Summary: Throw AWTError instead of InternalError if the DISPLAY is bad Reviewed-by: anthony, serb Contributed-by: Mikhail Cherkasov ! src/solaris/native/sun/awt/awt_GraphicsEnv.c + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 47cdc463b4b0 Author: kizune Date: 2012-10-17 14:32 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/47cdc463b4b0 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test Reviewed-by: serb, leonidr ! src/macosx/classes/sun/awt/CGraphicsDevice.java Changeset: e6a8ee65d248 Author: alexsch Date: 2012-10-17 17:33 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e6a8ee65d248 8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 29b7bd890d3a Author: alexsch Date: 2012-10-17 10:16 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/29b7bd890d3a 8000626: Implement dead key detection for KeyEvent on Linux Reviewed-by: kizune ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 9c6f60a4e996 Author: alexsch Date: 2012-10-18 17:50 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9c6f60a4e996 7199708: FileChooser crashs when opening large folder Reviewed-by: bagiras ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java Changeset: 8bbc6a5f1e92 Author: alexsch Date: 2012-10-18 18:28 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8bbc6a5f1e92 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6b16f6fc41c5 Author: serb Date: 2012-10-19 15:23 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6b16f6fc41c5 7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java + test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java Changeset: e0f91b40b8dd Author: alexsch Date: 2012-10-23 14:30 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e0f91b40b8dd 6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java Reviewed-by: rupashka + test/javax/swing/JMenuItem/4654927/bug4654927.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 37a6ead4a357 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/37a6ead4a357 Merge Changeset: fecba6a8b78e Author: coffeys Date: 2012-10-09 12:50 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fecba6a8b78e 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: 3b79177ebfef Author: alanb Date: 2012-10-09 13:28 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b79177ebfef 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt Changeset: 036c55976cef Author: lancea Date: 2012-10-09 08:58 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/036c55976cef 7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC Reviewed-by: alanb, smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: c725ce4bbf12 Author: naoto Date: 2012-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c725ce4bbf12 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java Changeset: 71de5e31d497 Author: coffeys Date: 2012-10-09 19:45 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/71de5e31d497 7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed Reviewed-by: alanb, chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/SocketGrowth.java Changeset: 3c4be36de073 Author: lancea Date: 2012-10-10 11:15 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c4be36de073 8000687: Correct javadoc typo for getLogWriter and setLogWriter Reviewed-by: alanb ! src/share/classes/java/sql/DriverManager.java Changeset: 6455182d2797 Author: alanb Date: 2012-10-10 20:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6455182d2797 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods Reviewed-by: mchung, lancea, chegar ! src/share/classes/java/util/logging/LogManager.java Changeset: 734ca9f4719c Author: lancea Date: 2012-10-10 17:34 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/734ca9f4719c 8000712: Remove unused fields in SyncFactory Reviewed-by: mchung ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: c2be39b27e1c Author: dxu Date: 2012-10-11 11:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c2be39b27e1c 7186817: Remove Windows 95/98/ME Support Reviewed-by: alanb ! make/java/java/Makefile ! makefiles/CompileNativeLibraries.gmk - src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/io/WinNTFileSystem.java ! src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/util/TimeZone_md.c ! test/java/io/pathNames/win32/bug6344646.java Changeset: 7c2f5e52863c Author: robm Date: 2012-10-11 18:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7c2f5e52863c 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java Changeset: daabaafd6798 Author: lancea Date: 2012-10-11 18:46 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/daabaafd6798 8000763: use XXX.valueOf methods instead of constructors Reviewed-by: mchung, forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java Changeset: e23f8e0a1d89 Author: lana Date: 2012-10-12 14:52 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e23f8e0a1d89 Merge Changeset: ff641c5b329b Author: jgish Date: 2012-10-13 10:15 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ff641c5b329b 7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java Changeset: fe28e0b035e7 Author: sflores Date: 2012-10-14 22:58 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fe28e0b035e7 7194449: String resources for Key Tool and Policy Tool should be in their respective packages Reviewed-by: alanb, weijun, mullan ! make/common/Release.gmk ! make/launchers/Makefile ! make/sun/security/tools/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java + src/share/classes/sun/security/tools/jarsigner/Main.java + src/share/classes/sun/security/tools/jarsigner/Resources.java + src/share/classes/sun/security/tools/jarsigner/Resources_ja.java + src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java + src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java + src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java + src/share/classes/sun/security/tools/keytool/Main.java + src/share/classes/sun/security/tools/keytool/Resources.java + src/share/classes/sun/security/tools/keytool/Resources_de.java + src/share/classes/sun/security/tools/keytool/Resources_es.java + src/share/classes/sun/security/tools/keytool/Resources_fr.java + src/share/classes/sun/security/tools/keytool/Resources_it.java + src/share/classes/sun/security/tools/keytool/Resources_ja.java + src/share/classes/sun/security/tools/keytool/Resources_ko.java + src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/keytool/Resources_sv.java + src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + src/share/classes/sun/security/tools/policytool/Resources.java + src/share/classes/sun/security/tools/policytool/Resources_de.java + src/share/classes/sun/security/tools/policytool/Resources_es.java + src/share/classes/sun/security/tools/policytool/Resources_fr.java + src/share/classes/sun/security/tools/policytool/Resources_it.java + src/share/classes/sun/security/tools/policytool/Resources_ja.java + src/share/classes/sun/security/tools/policytool/Resources_ko.java + src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/policytool/Resources_sv.java + src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/NewSize7.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Resources/Format.java ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/util/Resources/NewResourcesNames.java ! test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7055257a25c4 Author: robm Date: 2012-10-15 03:26 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7055257a25c4 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java Reviewed-by: alanb, martin ! test/java/lang/ProcessBuilder/Basic.java Changeset: c0736b62160e Author: robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java + test/com/sun/jndi/ldap/LdapTimeoutTest.java - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 32452042b781 Author: naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java Changeset: 3a6b76a468bd Author: khazra Date: 2012-10-16 15:23 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3a6b76a468bd 7198073: (prefs) user prefs not saved [macosx] Summary: Using class member field to get node instead of argument Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/CheckUserPrefFirst.java + test/java/util/prefs/CheckUserPrefLater.java + test/java/util/prefs/CheckUserPrefsStorage.sh Changeset: 14b9e294d049 Author: alanb Date: 2012-10-17 11:43 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/14b9e294d049 8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported Reviewed-by: mchung, chegar ! src/share/classes/java/util/Properties.java ! src/share/classes/sun/util/spi/XmlPropertiesProvider.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java Changeset: 5eed4a92ca8c Author: ngmr Date: 2012-10-17 13:35 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5eed4a92ca8c 8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour Reviewed-by: mduigou, alanb ! src/share/classes/java/util/Hashtable.java + test/java/util/Map/EntryHashCode.java Changeset: b2d8a99a049e Author: dsamersoff Date: 2012-10-17 18:34 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b2d8a99a049e 6809322: javax.management.timer.Timer does not fire all notifications Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method. Reviewed-by: dholmes, rbackman Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/timer/MissingNotificationTest.java Changeset: 6156b9235758 Author: mchung Date: 2012-10-17 12:03 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6156b9235758 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false Reviewed-by: alanb, ohair ! make/common/internal/Defs-jaxws.gmk Changeset: 586028bbf885 Author: psandoz Date: 2012-10-17 20:34 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/586028bbf885 7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ServiceLoader.java ! test/java/util/ServiceLoader/Basic.java ! test/java/util/ServiceLoader/basic.sh Changeset: b265ead7f331 Author: alanb Date: 2012-10-17 21:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b265ead7f331 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods Reviewed-by: lancea, chegar, mchung, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 60994591be6b Author: naoto Date: 2012-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/60994591be6b 8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing Reviewed-by: okutsu ! test/java/util/PluggableLocale/barprovider.jar Changeset: 3f62cfc4e83d Author: xuelei Date: 2012-10-18 01:14 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3f62cfc4e83d 7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server Reviewed-by: mullan, weijun, wetmore ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java + src/share/classes/javax/net/ssl/SNIHostName.java + src/share/classes/javax/net/ssl/SNIMatcher.java + src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java + src/share/classes/javax/net/ssl/StandardConstants.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SunJSSE.java + src/share/classes/sun/security/ssl/Utilities.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java + test/sun/security/ssl/templates/SSLCapabilities.java + test/sun/security/ssl/templates/SSLExplorer.java Changeset: 27f854a1e5c5 Author: chegar Date: 2012-10-19 11:43 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/27f854a1e5c5 8000206: Uninitialized variable in PlainDatagramSocketImpl.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/PlainDatagramSocketImpl.c Changeset: 21f1b88e68ce Author: xuelei Date: 2012-10-19 20:36 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/21f1b88e68ce 8000954: Add final keyword to new method in SSLParameters Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java Changeset: 93303f8a4a8e Author: alanb Date: 2012-10-20 21:07 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/93303f8a4a8e 8000941: Remove ftp from the required list of protocol handlers Reviewed-by: chegar ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html Changeset: a40b0f51613b Author: jjh Date: 2012-10-20 22:49 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a40b0f51613b 7197401: Add a subset of the org.objectweb.asm packages to jdk8 Reviewed-by: ohair, briangoetz, erikj, iris ! THIRD_PARTY_README ! make/Makefile + make/jdk/Makefile + make/jdk/asm/Makefile + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java + src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Edge.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/Handle.java + src/share/classes/jdk/internal/org/objectweb/asm/Handler.java + src/share/classes/jdk/internal/org/objectweb/asm/Item.java + src/share/classes/jdk/internal/org/objectweb/asm/Label.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java + src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile + test/jdk/asm/AsmSanity.java Changeset: b39ab9c6f4cb Author: weijun Date: 2012-10-22 09:59 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b39ab9c6f4cb 8001204: typo: Unable to obtain Princpal Name for authentication Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: e19dc885da0d Author: weijun Date: 2012-10-22 17:01 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e19dc885da0d 8000624: Move MaxRetries.java to ProblemList for the moment Reviewed-by: alanb ! test/ProblemList.txt Changeset: 2048ce5a12ff Author: twisti Date: 2012-10-22 14:22 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2048ce5a12ff 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp Reviewed-by: dholmes, mchung ! test/java/lang/ref/Basic.java Changeset: a1e77f7ed52b Author: weijun Date: 2012-10-23 10:02 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a1e77f7ed52b 8001208: Fix for KRB5CCNAME not complete Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: 29b58cb8e4fc Author: chegar Date: 2012-10-23 11:57 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/29b58cb8e4fc 8000204: Memory leak in com/sun/security/auth/module/Unix.c Reviewed-by: dsamersoff, wetmore, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/com/sun/security/auth/module/Unix.c Changeset: cdc7f9be3707 Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cdc7f9be3707 Merge - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 0582dc4674c9 Author: wetmore Date: 2012-05-21 15:42 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0582dc4674c9 7167656: Multiple Seeders are being created Reviewed-by: smarks, mduigou, ahgross ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: b4f35876d9b5 Author: mullan Date: 2012-06-08 11:02 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b4f35876d9b5 7163198: Tightened package accessibility 7169887: Tightened package accessibility Reviewed-by: vinnie, hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89a0551b98d8 Author: weijun Date: 2012-06-15 09:51 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/89a0551b98d8 6631398: FilePermission improved path checking Reviewed-by: mullan, skoivu, jdn ! src/share/classes/java/io/FilePermission.java Changeset: 7439e8007e09 Author: mullan Date: 2012-06-18 10:00 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7439e8007e09 7172522: Improve DomainCombiner checking Reviewed-by: vinnie, ahgross ! src/share/classes/java/security/AccessController.java Changeset: 2a98c51549a8 Author: smarks Date: 2012-06-21 00:20 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a98c51549a8 7093490: adjust package access in rmiregistry Reviewed-by: ahgross, coffeys, dmocek ! src/share/classes/sun/rmi/registry/RegistryImpl.java Changeset: 263f15439f4b Author: dsamersoff Date: 2012-06-22 16:22 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/263f15439f4b 7158796: Tighten properties checking in EnvHelp Summary: Move getProperty call out of computeBooleanFromString Reviewed-by: skoivu, sla ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java Changeset: 3a825f6cbc71 Author: dsamersoff Date: 2012-06-22 18:19 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3a825f6cbc71 7169888: Narrowing resource definitions in JMX RMI connector Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions. Reviewed-by: ahgross, fparain ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: 90498c1cc87c Author: xuelei Date: 2012-07-28 19:42 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/90498c1cc87c 7186286: TLS implementation to better adhere to RFC Summary: also reviewed by Alexander Fomin , Andrew Gross, Sean Coffey Reviewed-by: valeriep, wetmore ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 983c17aecdac Author: mullan Date: 2012-08-15 15:31 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/983c17aecdac 7189490: More improvements to DomainCombiner checking Reviewed-by: ahgross, jdn, vinnie ! src/share/classes/java/security/AccessController.java Changeset: 6cc28cc213b6 Author: chegar Date: 2012-08-16 15:02 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6cc28cc213b6 7189103: Executors needs to maintain state Reviewed-by: dholmes, hawtin ! src/share/classes/java/util/concurrent/Executors.java Changeset: a09b9ebb61b6 Author: chegar Date: 2012-08-29 14:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a09b9ebb61b6 7189567: java net obselete protocol Reviewed-by: alanb, ahgross ! make/sun/net/FILES_java.gmk - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! test/java/net/URL/Test.java Changeset: 2ac636f46c5b Author: alanb Date: 2012-09-08 20:31 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2ac636f46c5b 7169884: LogManager checks do not work correctly for sub-types Reviewed-by: mchung, ahgross ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 4488ea026532 Author: asaha Date: 2012-09-08 22:23 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4488ea026532 Merge Changeset: e869a8513cb7 Author: smarks Date: 2012-09-10 16:05 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e869a8513cb7 7195919: (sl) ServiceLoader can throw CCE without needing to create instance Reviewed-by: ahgross, alanb, dmeetry ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/misc/Service.java Changeset: 9a7e2fa3c9c5 Author: malenkov Date: 2012-09-11 12:57 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a7e2fa3c9c5 7195549: Better bean object persistence Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java Changeset: 1d1fcf0c1ce8 Author: rupashka Date: 2012-09-11 15:59 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1d1fcf0c1ce8 7195194: Better data validation for Swing Reviewed-by: art, ahgross ! src/share/classes/javax/swing/text/DefaultFormatter.java Changeset: 3b49bd3c392b Author: malenkov Date: 2012-09-19 21:42 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b49bd3c392b 7195917: XMLDecoder parsing at close-time should be improved Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java ! src/share/classes/java/beans/XMLDecoder.java Changeset: 762eee5e6e16 Author: jrose Date: 2012-09-20 14:02 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/762eee5e6e16 7196190: Improve method of handling MethodHandles Summary: Bind callers to caller-sensitive methods. Reviewed-by: twisti, jjh, vlivanov, ahgross ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/anon/AnonymousClassLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/7196190/ClassForNameTest.java + test/java/lang/invoke/7196190/GetUnsafeTest.java + test/java/lang/invoke/7196190/MHProxyTest.java + test/java/lang/invoke/7196190/jtreg.security.policy Changeset: e113ffde452a Author: dsamersoff Date: 2012-09-24 16:15 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e113ffde452a 7198296: Problem with classloader in JMX Summary: wb classes have to be available for hotspot tests Reviewed-by: ahgross, asaha Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: ca79b33a0731 Author: dsamersoff Date: 2012-09-24 17:00 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ca79b33a0731 7192975: Issue with JMX reflection Summary: Make security check unconditional Reviewed-by: ahgross, asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java Changeset: 74eec13c464e Author: asaha Date: 2012-09-25 11:48 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74eec13c464e Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk Changeset: e4ce54b79bb4 Author: asaha Date: 2012-10-10 14:31 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e4ce54b79bb4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 28fe37b50e3c Author: asaha Date: 2012-10-11 15:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/28fe37b50e3c Merge Changeset: d3b3fea7d1d7 Author: asaha Date: 2012-10-18 22:01 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d3b3fea7d1d7 Merge ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/ServiceLoader.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: e6fbbb2c610d Author: lana Date: 2012-10-23 11:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e6fbbb2c610d Merge ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: dfd509da3da6 Author: lana Date: 2012-10-25 20:32 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dfd509da3da6 Merge ! make/common/Release.gmk ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c ! test/ProblemList.txt - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 64dd2aba6d33 Author: ohair Date: 2012-10-26 14:23 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/64dd2aba6d33 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJdk.gmk + makefiles/Bundles.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/Tools.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 + makefiles/sun/awt/X11/ToBin.java + makefiles/sun/osxapp/ToBin.java - makefiles/sun/xawt/ToBin.java Changeset: 5b29d6157504 Author: erikj Date: 2012-10-29 13:04 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5b29d6157504 8001887: build-infra: Correct mapfiles in build-infra area Reviewed-by: ohair ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris Changeset: dcee387cde81 Author: ohrstrom Date: 2012-10-29 13:41 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dcee387cde81 8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and sizer compilation Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk ! makefiles/GensrcX11Wrappers.gmk Changeset: 524d1a705f7b Author: erikj Date: 2012-10-29 13:55 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/524d1a705f7b 8001898: build-infra: correct exclusion lists for mac jar builds 8001896: build-infra: UNLIMITED_CRYPTO changes Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: f117a3e06f78 Author: katleman Date: 2012-10-31 18:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f117a3e06f78 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: 7ac292e57b5a Author: katleman Date: 2012-11-01 14:12 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ac292e57b5a Added tag jdk8-b63 for changeset f117a3e06f78 ! .hgtags Changeset: cc998992dc32 Author: bae Date: 2012-10-24 05:30 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cc998992dc32 7053526: Upgrade JDK 8 to use Little CMS 2.4 Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c + src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: 00c8ea9ef1cf Author: lana Date: 2012-10-31 09:49 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/00c8ea9ef1cf Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: c9523d220bc3 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c9523d220bc3 Merge Changeset: 3b889d1218f5 Author: alitvinov Date: 2012-10-24 18:27 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b889d1218f5 7193219: JComboBox serialization fails in JDK 1.7 Reviewed-by: rupashka, anthony ! src/share/classes/javax/swing/AncestorNotifier.java + test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: c27efe7615f8 Author: bagiras Date: 2012-10-25 09:55 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c27efe7615f8 8000486: REGRESSION: Three java2d tests fail since jdk8b58 on Windows 7 with NullPointerException Reviewed-by: flar, art ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: 9fb5db444365 Author: bagiras Date: 2012-10-25 19:50 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9fb5db444365 7082294: nsk/regression/b4265661 crashes on windows Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 7ead109417f0 Author: serb Date: 2012-10-29 23:10 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ead109417f0 7198229: Painting during resizing of the frame should be more smooth Reviewed-by: anthony, denis, skovatch ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 884402437aad Author: kshefov Date: 2012-10-30 12:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/884402437aad 7072120: No mac os x support in several regression tests Reviewed-by: anthony, serb ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 6652efb69459 Author: lana Date: 2012-10-31 09:25 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6652efb69459 Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9b5c596a2920 Author: VKARNAUK Date: 2012-11-02 15:57 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b5c596a2920 2229575: Swing HTML parser can't properly decode codepoints outside the Unicode Plane 0 into a surrogate pair Reviewed-by: rupashka ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/6836089/bug6836089.java Changeset: 3d22bd7d6678 Author: alexp Date: 2012-11-02 16:14 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3d22bd7d6678 8001633: Wrong alt processing during switching between windows. Reviewed-by: ant, leonidr Contributed-by: Mikhail Cherkasov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java Changeset: 094c963dca1b Author: leonidr Date: 2012-11-02 19:20 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/094c963dca1b 7124310: [macosx] "opposite" seems always null in focus events Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: f4a11601680b Author: leonidr Date: 2012-11-02 19:47 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f4a11601680b 8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: serb ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 509b3b4910ef Author: kshefov Date: 2012-11-02 17:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/509b3b4910ef 8001808: Create a test for 8000327 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 706056a4a6d9 Author: kshefov Date: 2012-11-02 17:07 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/706056a4a6d9 8001876: Create regtest for 8000283 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ShortcutNotDiplayed/ShortcutNotDisplayedTest.java Changeset: ebd8f16bae1b Author: lana Date: 2012-11-02 17:34 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ebd8f16bae1b Merge Changeset: 940c8cc5a5c4 Author: wetmore Date: 2012-10-23 12:36 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/940c8cc5a5c4 7197071: Makefiles for various security providers aren't including the default manifest Reviewed-by: valeriep, mullan, katleman ! make/com/oracle/security/ucrypto/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile + test/javax/crypto/sanity/CheckManifestForRelease.java Changeset: 13b46e8eda33 Author: ohrstrom Date: 2012-10-23 15:51 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/13b46e8eda33 8001419: Build the JCE portion of JDK-8000970 Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/KeyProtector.java + src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java Changeset: e782f3c383fe Author: xuelei Date: 2012-10-24 08:25 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e782f3c383fe 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java Changeset: 8e8fcd44b963 Author: jbachorik Date: 2012-10-24 20:44 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8e8fcd44b963 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLTest.java Changeset: 909676adaefd Author: chegar Date: 2012-10-24 21:20 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/909676adaefd 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/net_util_md.c Changeset: 37a4b4892e8e Author: jgish Date: 2012-10-25 15:04 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/37a4b4892e8e 7159567: inconsistent configuration of MemoryHandler Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java + test/java/util/logging/MemoryHandlerTest.java + test/java/util/logging/MemoryHandlerTest.props Changeset: 27677928a937 Author: dxu Date: 2012-10-25 15:42 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/27677928a937 8001565: (fs) Typo Path.endsWith(String) javadoc Reviewed-by: mchung, jgish, lancea ! src/share/classes/java/nio/file/Path.java Changeset: 6302932b7380 Author: rfield Date: 2012-10-25 17:34 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6302932b7380 8000806: Implement runtime lambda metafactory Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface Reviewed-by: twisti + src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/LambdaConversionException.java + src/share/classes/java/lang/invoke/LambdaMetafactory.java + src/share/classes/java/lang/invoke/MagicLambdaImpl.java + src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java Changeset: 0b52c87c39da Author: dxu Date: 2012-10-26 11:21 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0b52c87c39da 4239752: FileSystem should be a platform-specific class to avoid native code Reviewed-by: alanb, dholmes, erikj, jgish ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/mapfile-vers ! makefiles/CompileJavaClasses.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileSystem.java + src/solaris/classes/java/io/DefaultFileSystem.java - src/solaris/native/java/io/FileSystem_md.c + src/windows/classes/java/io/DefaultFileSystem.java - src/windows/native/java/io/FileSystem_md.c Changeset: 3fc5457cf779 Author: dl Date: 2012-10-26 21:34 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3fc5457cf779 8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012 Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadFactory.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: 615af31cfccc Author: alanb Date: 2012-10-27 09:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/615af31cfccc 7176225: Remove JDBC-ODBC Bridge Reviewed-by: lancea, ohair, tbell ! make/common/Sanity.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Sanity.gmk ! make/sun/Makefile - make/sun/jdbc/Makefile ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 33e29fbc3e5b Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/33e29fbc3e5b 7184246: Simplify Config.get() of krb5 Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/MaxRetries.java + test/sun/security/krb5/config/Duplicates.java + test/sun/security/krb5/config/SCDynamicConfigTest.java + test/sun/security/krb5/config/k1.conf Changeset: cb70077c6370 Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb70077c6370 7195426: kdc_default_options not supported correctly Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/KDCOptions.java + test/sun/security/krb5/config/KdcDefaultOptions.java + test/sun/security/krb5/config/kdc_default_options.conf Changeset: d1ffbdf7e3c6 Author: sla Date: 2012-10-29 09:23 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d1ffbdf7e3c6 8001621: Update awk scripts that check output from jps/jcmd Reviewed-by: alanb ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: 17384fc6b31f Author: ohrstrom Date: 2012-10-29 14:12 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/17384fc6b31f 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, wetmore + make/tools/src/build/tools/generatenimbus/AbstractGradient.java + make/tools/src/build/tools/generatenimbus/Border.java + make/tools/src/build/tools/generatenimbus/Canvas.java + make/tools/src/build/tools/generatenimbus/ComponentColor.java + make/tools/src/build/tools/generatenimbus/Dimension.java + make/tools/src/build/tools/generatenimbus/Ellipse.java + make/tools/src/build/tools/generatenimbus/Gradient.java + make/tools/src/build/tools/generatenimbus/GradientStop.java + make/tools/src/build/tools/generatenimbus/Insets.java + make/tools/src/build/tools/generatenimbus/Layer.java + make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/Path.java + make/tools/src/build/tools/generatenimbus/Point.java + make/tools/src/build/tools/generatenimbus/RadialGradient.java + make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/Typeface.java + make/tools/src/build/tools/generatenimbus/UIColor.java + make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIFont.java + make/tools/src/build/tools/generatenimbus/UIIconRegion.java + make/tools/src/build/tools/generatenimbus/UIProperty.java + make/tools/src/build/tools/generatenimbus/UIRegion.java + make/tools/src/build/tools/generatenimbus/UIState.java + make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! src/share/classes/javax/management/timer/Timer.java + src/share/classes/javax/management/timer/TimerAlarmClock.java + src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputMethodManager.java + src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/net/httpserver/Event.java + src/share/classes/sun/net/httpserver/WriteFinishedEvent.java + src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java + src/share/classes/sun/security/ssl/ExtensionType.java + src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java + src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java + src/share/classes/sun/security/ssl/ServerNameExtension.java + src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java + src/share/classes/sun/security/ssl/UnknownExtension.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java + src/solaris/classes/sun/awt/X11/XChoicePeerListener.java + src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java + src/solaris/classes/sun/java2d/jules/TileTrapContainer.java Changeset: 7fa45c455034 Author: naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider Changeset: e2f976a73afb Author: jgish Date: 2012-10-29 16:51 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e2f976a73afb 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) Reviewed-by: chegar, alanb, mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java + test/java/lang/StringBuffer/AppendStringBuilder.java + test/java/lang/StringBuffer/BufferForwarding.java + test/java/lang/StringBuffer/TestSynchronization.java + test/java/lang/StringBuilder/AppendStringBuffer.java + test/java/lang/StringBuilder/BuilderForwarding.java Changeset: ac97b1cfc0ea Author: lana Date: 2012-10-31 08:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac97b1cfc0ea Merge ! make/common/shared/Sanity.gmk ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: 178618fb4300 Author: naoto Date: 2012-10-31 11:33 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/178618fb4300 8001231: Move locale data out of rt.jar (except the US locale) Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template Changeset: 8b944ebef8a7 Author: ohrstrom Date: 2012-11-01 10:33 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8b944ebef8a7 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, sla + src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java + src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Changeset: 6420fcd61c10 Author: naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 8748331f63cf Author: lancea Date: 2012-11-01 17:35 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8748331f63cf 8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob Reviewed-by: alanb, forax ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java Changeset: 79774104a1f4 Author: alanb Date: 2012-11-01 21:59 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/79774104a1f4 8002120: ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 9b3867244eec Author: dholmes Date: 2012-11-01 18:09 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b3867244eec 7198815: Add the minimal VM as "known" in jvm.cfg Reviewed-by: alanb, forax, mchung ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg Changeset: 36f962518499 Author: weijun Date: 2012-11-02 10:48 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/36f962518499 7110803: SASL service for multiple hostnames Reviewed-by: mullan ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + test/com/sun/security/sasl/digest/Unbound.java + test/sun/security/krb5/auto/SaslBasic.java Changeset: 98a47dc23296 Author: peytoia Date: 2012-11-02 23:17 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/98a47dc23296 8001209: Evaluate findbugs reprot for java.text.ChoiceFormat Reviewed-by: okutsu ! src/share/classes/java/text/ChoiceFormat.java + test/java/text/Format/ChoiceFormat/Bug8001209.java Changeset: cea72c2bf071 Author: alanb Date: 2012-11-02 15:50 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cea72c2bf071 7197491: update copyright year to match last edit in jdk8 jdk repository Reviewed-by: chegar, ksrini ! make/apple/Makefile ! make/apple/applescript/Makefile ! make/com/Makefile ! make/com/apple/Makefile ! make/com/apple/osx/Makefile ! make/com/apple/osxui/Makefile ! make/com/oracle/jfr/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/net/ssl/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/security/auth/module/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Exportedfiles.gmk ! make/com/sun/tools/attach/FILES_c.gmk ! make/com/sun/tools/attach/FILES_java.gmk ! make/com/sun/tools/attach/mapfile-bsd ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/common/Demo.gmk ! make/common/Mapfile-vers.gmk ! make/common/Release-macosx.gmk ! make/common/Rules.gmk ! make/common/Sanity.gmk ! make/common/internal/Defs-jaxws.gmk ! make/common/internal/NativeCompileRules.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-llvm.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/fdlibm/FILES_c.gmk ! make/java/java/genlocales.gmk ! make/java/java/reflect/Makefile ! make/java/jobjc/Makefile ! make/java/jvm/Makefile ! make/java/management/mapfile-vers ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/rmi/Makefile ! make/java/security/Makefile ! make/java/sun_nio/FILES_java.gmk ! make/java/text/bidi/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/mapfile-vers ! make/javax/accessibility/Makefile ! make/javax/crypto/Makefile ! make/javax/sound/FILES_c.gmk ! make/javax/sound/SoundDefs.gmk ! make/javax/sound/jsoundalsa/Makefile ! make/jdk_generic_profile.sh ! make/jpda/back/Makefile ! make/jpda/jdwp/jdwp.spec ! make/jprt.properties ! make/mksample/Makefile ! make/netbeans/common/architectures/name-Bsd.properties ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/jconsole/build.xml ! make/org/ietf/jgss/Makefile ! make/sun/Makefile ! make/sun/awt/FILES_c_macosx.gmk ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mawt.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! make/sun/jdga/Makefile ! make/sun/lwawt/FILES_c_macosx.gmk ! make/sun/lwawt/FILES_export_macosx.gmk ! make/sun/lwawt/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/spi/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/osxapp/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmi/mapfile-vers ! make/sun/rmi/rmid/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/other/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile ! make/sun/tools/Makefile ! make/sun/util/Makefile ! make/tools/CharsetMapping/DoubleByte-X.java.template ! make/tools/CharsetMapping/SingleByte-X.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template ! make/tools/freetypecheck/Makefile ! make/tools/reorder/Makefile ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/generatenimbus/AbstractGradient.java ! make/tools/src/build/tools/generatenimbus/Border.java ! make/tools/src/build/tools/generatenimbus/Canvas.java ! make/tools/src/build/tools/generatenimbus/ComponentColor.java ! make/tools/src/build/tools/generatenimbus/Dimension.java ! make/tools/src/build/tools/generatenimbus/Ellipse.java ! make/tools/src/build/tools/generatenimbus/Gradient.java ! make/tools/src/build/tools/generatenimbus/GradientStop.java ! make/tools/src/build/tools/generatenimbus/Insets.java ! make/tools/src/build/tools/generatenimbus/Layer.java ! make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java ! make/tools/src/build/tools/generatenimbus/Path.java ! make/tools/src/build/tools/generatenimbus/Point.java ! make/tools/src/build/tools/generatenimbus/RadialGradient.java ! make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java ! make/tools/src/build/tools/generatenimbus/Typeface.java ! make/tools/src/build/tools/generatenimbus/UIColor.java ! make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java ! make/tools/src/build/tools/generatenimbus/UIFont.java ! make/tools/src/build/tools/generatenimbus/UIIconRegion.java ! make/tools/src/build/tools/generatenimbus/UIProperty.java ! make/tools/src/build/tools/generatenimbus/UIRegion.java ! make/tools/src/build/tools/generatenimbus/UIState.java ! make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/stripproperties/StripProperties.java ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GensrcSwing.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/launchers/mapfile-amd64 ! makefiles/mapfiles/launchers/mapfile-i586 ! makefiles/mapfiles/launchers/mapfile-sparc ! makefiles/mapfiles/launchers/mapfile-sparcv9 ! makefiles/mapfiles/launchers/mapfile-x86 ! makefiles/mapfiles/launchers/mapfile-x86_64 ! makefiles/mapfiles/libattach/mapfile-linux ! makefiles/mapfiles/libattach/mapfile-solaris ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libdcpr/mapfile-vers ! makefiles/mapfiles/libdt_socket/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libhprof/mapfile-vers ! makefiles/mapfiles/libinstrument/mapfile-vers ! makefiles/mapfiles/libj2gss/mapfile-vers ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjaas/mapfile-vers ! makefiles/mapfiles/libjava_crw_demo/mapfile-vers ! makefiles/mapfiles/libjawt/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjdwp/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers-closed ! makefiles/mapfiles/libjsdt/mapfile-vers ! makefiles/mapfiles/libjsound/mapfile-vers ! makefiles/mapfiles/libjsoundalsa/mapfile-vers ! makefiles/mapfiles/libkcms/mapfile-vers ! makefiles/mapfiles/liblcms/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! makefiles/mapfiles/libmlib_image/mapfile-vers ! makefiles/mapfiles/libnet/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-bsd ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris ! makefiles/mapfiles/libnpt/mapfile-vers ! makefiles/mapfiles/libsctp/mapfile-vers ! makefiles/mapfiles/libsplashscreen/mapfile-vers ! makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libt2k/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers-unpack200 ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/mapfiles/libzip/mapfile-vers ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/xawt/ToBin.java ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/apt.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/ja/appletviewer.1 ! src/bsd/doc/man/ja/apt.1 ! src/bsd/doc/man/ja/extcheck.1 ! src/bsd/doc/man/ja/idlj.1 ! src/bsd/doc/man/ja/jar.1 ! src/bsd/doc/man/ja/jarsigner.1 ! src/bsd/doc/man/ja/java.1 ! src/bsd/doc/man/ja/javac.1 ! src/bsd/doc/man/ja/javadoc.1 ! src/bsd/doc/man/ja/javah.1 ! src/bsd/doc/man/ja/javap.1 ! src/bsd/doc/man/ja/javaws.1 ! src/bsd/doc/man/ja/jconsole.1 ! src/bsd/doc/man/ja/jdb.1 ! src/bsd/doc/man/ja/jhat.1 ! src/bsd/doc/man/ja/jinfo.1 ! src/bsd/doc/man/ja/jmap.1 ! src/bsd/doc/man/ja/jps.1 ! src/bsd/doc/man/ja/jrunscript.1 ! src/bsd/doc/man/ja/jsadebugd.1 ! src/bsd/doc/man/ja/jstack.1 ! src/bsd/doc/man/ja/jstat.1 ! src/bsd/doc/man/ja/jstatd.1 ! src/bsd/doc/man/ja/keytool.1 ! src/bsd/doc/man/ja/native2ascii.1 ! src/bsd/doc/man/ja/orbd.1 ! src/bsd/doc/man/ja/pack200.1 ! src/bsd/doc/man/ja/policytool.1 ! src/bsd/doc/man/ja/rmic.1 ! src/bsd/doc/man/ja/rmid.1 ! src/bsd/doc/man/ja/rmiregistry.1 ! src/bsd/doc/man/ja/schemagen.1 ! src/bsd/doc/man/ja/serialver.1 ! src/bsd/doc/man/ja/servertool.1 ! src/bsd/doc/man/ja/tnameserv.1 ! src/bsd/doc/man/ja/unpack200.1 ! src/bsd/doc/man/ja/wsgen.1 ! src/bsd/doc/man/ja/wsimport.1 ! src/bsd/doc/man/ja/xjc.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 ! src/bsd/doc/man/javaws.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 ! src/bsd/doc/man/jmap.1 ! src/bsd/doc/man/jps.1 ! src/bsd/doc/man/jrunscript.1 ! src/bsd/doc/man/jsadebugd.1 ! src/bsd/doc/man/jstack.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/native2ascii.1 ! src/bsd/doc/man/orbd.1 ! src/bsd/doc/man/pack200.1 ! src/bsd/doc/man/policytool.1 ! src/bsd/doc/man/rmic.1 ! src/bsd/doc/man/rmid.1 ! src/bsd/doc/man/rmiregistry.1 ! src/bsd/doc/man/schemagen.1 ! src/bsd/doc/man/serialver.1 ! src/bsd/doc/man/servertool.1 ! src/bsd/doc/man/tnameserv.1 ! src/bsd/doc/man/unpack200.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/jcmd.1 ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch ! src/macosx/bundle/JavaAppLauncher/src/main.m ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/AppleProvider.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/Dispatch.java ! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java ! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.h ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.m ! src/macosx/native/apple/applescript/AppleScriptEngine.m ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.h ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.h ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.m ! src/macosx/native/apple/launcher/JavaAppLauncher.m ! src/macosx/native/com/apple/concurrent/Dispatch.m ! src/macosx/native/com/apple/eio/CFileManager.m ! src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/macosx/native/java/util/MacOSXPreferencesFile.m ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser ! src/macosx/native/jobjc/README.txt ! src/macosx/native/jobjc/TODOS ! src/macosx/native/jobjc/bridgesupport.gmk ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/extract_classes.pl ! src/macosx/native/jobjc/run-and-write-if-okay ! src/macosx/native/jobjc/rungen ! src/macosx/native/jobjc/runjava ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CIF.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/core/native/CIF.m ! src/macosx/native/jobjc/src/core/native/Coder.m ! src/macosx/native/jobjc/src/core/native/FFIType.m ! src/macosx/native/jobjc/src/core/native/Function.m ! src/macosx/native/jobjc/src/core/native/ID.m ! src/macosx/native/jobjc/src/core/native/Invoke.m ! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m ! src/macosx/native/jobjc/src/core/native/MacOSXFramework.m ! src/macosx/native/jobjc/src/core/native/NSClass.m ! src/macosx/native/jobjc/src/core/native/NativeBuffer.h ! src/macosx/native/jobjc/src/core/native/NativeBuffer.m ! src/macosx/native/jobjc/src/core/native/NativeObjectLifecycleManager.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/jobjc/src/core/native/Subclassing.m ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/BootClassPathMinus.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassConsolidator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FileCopier.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FrameworkGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FunctionGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Generator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/MethodDisambiguator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/RestrictedKeywords.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Utils.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/AbstractObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CFTypeClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CopiedFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/GeneratedClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/MixedPrimitiveCoderClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OpaqueClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OutputFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/RootJObjCClass.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/StructClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Arg.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/CFType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Category.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Constant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Element.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ElementWType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Framework.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Function.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/FunctionAlias.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/InformalProtocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Method.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/NativeEnum.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Opaque.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/OutputFileGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Protocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ReturnValue.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/StringConstant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Struct.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/TypeElement.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/CoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/PrimitiveCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/JType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/NType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/Type.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeCache.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeToJType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/Fp.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/JavaLang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeMerger.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeParser.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypePrinter.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/ObjectInspector.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/QA.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StringStream.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolverBigBang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/SuperClassExtractor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/UnsafeRuntimeAccess.java ! src/macosx/native/jobjc/src/runtime-additions/java/com/apple/jobjc/Utils.java ! src/macosx/native/jobjc/src/runtime-additions/native/NativeNumber.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeString.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeThread.m ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BaseBench.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchFunCall.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchIDPop.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchStructCoding.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchUnsafe.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/CategoryTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/FunctionTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/GUIDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IBDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IntroTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NSClassTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeBufferTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeTypeTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/PooledTestCase.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SELTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/StructTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SubclassingTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/TestUtils.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/UtilsTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/VarArgsTest.java ! src/macosx/native/jobjc/src/tests/native/FunCallBench.m ! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c ! src/macosx/native/sun/osxapp/AWT_debug.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/PropertiesUtilities.h ! src/macosx/native/sun/osxapp/PropertiesUtilities.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/share/back/commonRef.c ! src/share/back/error_messages.h ! src/share/back/log_messages.h ! src/share/bin/emessages.h ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/package.html ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java ! src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jndi/toolkit/url/UrlUtil.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java ! src/share/classes/com/sun/rmi/rmid/ExecPermission.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/CharacterData.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/Void.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/BufferPoolMXBean.java ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InMemoryCookieStore.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketImpl.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/StandardWatchEventKinds.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/IllegalFormatConversionException.java ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListIterator.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Observable.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java ! src/share/classes/javax/management/timer/TimerAlarmClock.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java ! src/share/classes/org/ietf/jgss/Oid.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/MetaIndex.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/Signal.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/WriteFinishedEvent.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java ! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/cs/standard-charsets ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/newrmic/Main.java ! src/share/classes/sun/rmi/rmic/newrmic/Resources.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/ActivationGroupImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastRef2.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/server/WeakClassHashMap.java ! src/share/classes/sun/rmi/transport/ConnectionInputStream.java ! src/share/classes/sun/rmi/transport/DGCAckHandler.java ! src/share/classes/sun/rmi/transport/DGCClient.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Target.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/WeakRef.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/security/smartcardio/TerminalImpl.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/javac/resources/javac.properties ! src/share/classes/sun/tools/jcmd/Arguments.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/share/classes/sun/util/PreHashedMap.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/share/classes/sun/util/locale/LocaleUtils.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/ar/CalendarData_ar.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties ! src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties ! src/share/classes/sun/util/resources/be/CalendarData_be.properties ! src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties ! src/share/classes/sun/util/resources/be/LocaleNames_be.properties ! src/share/classes/sun/util/resources/bg/CalendarData_bg.properties ! src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties ! src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties ! src/share/classes/sun/util/resources/ca/CalendarData_ca.properties ! src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties ! src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties ! src/share/classes/sun/util/resources/cs/CalendarData_cs.properties ! src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties ! src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties ! src/share/classes/sun/util/resources/da/CalendarData_da.properties ! src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties ! src/share/classes/sun/util/resources/da/LocaleNames_da.properties ! src/share/classes/sun/util/resources/de/CalendarData_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/el/CalendarData_el.properties ! src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties ! src/share/classes/sun/util/resources/en/CalendarData_en.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties ! src/share/classes/sun/util/resources/es/CalendarData_es.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties ! src/share/classes/sun/util/resources/et/CalendarData_et.properties ! src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/et/LocaleNames_et.properties ! src/share/classes/sun/util/resources/fi/CalendarData_fi.properties ! src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties ! src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties ! src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties ! src/share/classes/sun/util/resources/hi/CalendarData_hi.properties ! src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties ! src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties ! src/share/classes/sun/util/resources/hr/CalendarData_hr.properties ! src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties ! src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties ! src/share/classes/sun/util/resources/hu/CalendarData_hu.properties ! src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties ! src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties ! src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties ! src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties ! src/share/classes/sun/util/resources/in/LocaleNames_in.properties ! src/share/classes/sun/util/resources/is/CalendarData_is.properties ! src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties ! src/share/classes/sun/util/resources/is/LocaleNames_is.properties ! src/share/classes/sun/util/resources/it/CalendarData_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/iw/CalendarData_iw.properties ! src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties ! src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties ! src/share/classes/sun/util/resources/ja/CalendarData_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/CalendarData_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/lt/CalendarData_lt.properties ! src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties ! src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties ! src/share/classes/sun/util/resources/lv/CalendarData_lv.properties ! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties ! src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties ! src/share/classes/sun/util/resources/mk/CalendarData_mk.properties ! src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties ! src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties ! src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties ! src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties ! src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties ! src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties ! src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties ! src/share/classes/sun/util/resources/nl/CalendarData_nl.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties ! src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/no/CalendarData_no.properties ! src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties ! src/share/classes/sun/util/resources/pl/CalendarData_pl.properties ! src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties ! src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! src/share/classes/sun/util/resources/ro/CalendarData_ro.properties ! src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties ! src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties ! src/share/classes/sun/util/resources/ru/CalendarData_ru.properties ! src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties ! src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties ! src/share/classes/sun/util/resources/sk/CalendarData_sk.properties ! src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties ! src/share/classes/sun/util/resources/sl/CalendarData_sl.properties ! src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties ! src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties ! src/share/classes/sun/util/resources/sq/CalendarData_sq.properties ! src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties ! src/share/classes/sun/util/resources/sv/CalendarData_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/th/CalendarData_th.properties ! src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties ! src/share/classes/sun/util/resources/th/LocaleNames_th.properties ! src/share/classes/sun/util/resources/tr/CalendarData_tr.properties ! src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties ! src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties ! src/share/classes/sun/util/resources/uk/CalendarData_uk.properties ! src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties ! src/share/classes/sun/util/resources/vi/CalendarData_vi.properties ! src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties ! src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties ! src/share/classes/sun/util/resources/zh/CalendarData_zh.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/gctest/sample.makefile.txt ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapTracker/sample.makefile.txt ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/heapViewer/sample.makefile.txt ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/minst/sample.makefile.txt ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/mtrace/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/sample.makefile.txt ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/MemoryMonitor/README.txt ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nbproject/project.xml ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js ! src/share/instrument/JPLISAssert.h ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jawt.h ! src/share/javavm/export/jmm.h ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.h ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/System.c ! src/share/native/java/lang/Thread.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/utf.h ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/share/transport/shmem/shmemBase.h ! src/share/transport/socket/socketTransport.c ! src/solaris/back/exec_md.c ! src/solaris/back/linker_md.c ! src/solaris/back/util_md.h ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg ! src/solaris/classes/com/sun/management/UnixOperatingSystem.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/lang/Terminator.java ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java ! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SendFailed.java ! src/solaris/classes/sun/nio/ch/sctp/Shutdown.java ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdFileSystem.java ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/security/smartcardio/PlatformPCSC.java ! src/solaris/classes/sun/tools/attach/BsdAttachProvider.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/instrument/EncodingSupport_md.c ! src/solaris/javavm/export/jvm_md.h ! src/solaris/native/com/sun/management/MacosxOperatingSystem.c ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/util/FileSystemPreferences.c ! src/solaris/native/sun/jdga/dgalock.c ! src/solaris/native/sun/management/FileSystemImpl.c ! src/solaris/native/sun/net/dns/ResolverConfigurationImpl.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! src/solaris/native/sun/nio/ch/sctp/Sctp.h ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpNet.c ! src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c ! src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/npt/npt_md.h ! src/solaris/transport/socket/socket_md.c ! src/windows/classes/com/sun/management/OperatingSystem.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/Terminator.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/management/FileSystemImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c ! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h ! src/windows/transport/shmem/shmem_md.c ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/jndi/ldap/LdapTimeoutTest.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test10.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/tools/attach/CommonSetup.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/MaxPathLength.java ! test/java/io/File/basic.sh ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/IOException/LastErrorString.java ! test/java/io/Serializable/badSubstByReplace/BadSubstByReplace.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java ! test/java/io/Serializable/replaceStringArray/ReplaceStringArray.java ! test/java/io/Serializable/replaceWithNull/ReplaceWithNull.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/verifyDynamicObjHandleTable/VerifyDynamicObjHandleTable.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/Double/ToHexString.java ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/lang/ThreadGroup/Stop.java ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/annotation/loaderLeak/Main.java ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/ref/Basic.java ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/NullUriCookieTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramPacket/ReuseBuf.java ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SendDatagramToBadAddress.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/NetworkInterface/NetParamsTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/Socks/SocksServer.java ! test/java/net/Socks/SocksV4Test.java ! test/java/net/URL/B5086147.sh ! test/java/net/URL/OpenStream.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URL/Test.java ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/MappedByteBuffer/Truncate.java ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java ! test/java/nio/channels/DatagramChannel/Refused.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/ClosedByInterrupt.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Open.sh ! test/java/nio/channels/SocketChannel/Shutdown.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/TestUtil.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/coders/Errors.java ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/CustomOptions.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/WatchService/WithSecurityManager.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/text/Bidi/Bug6850113.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/Locale/Bug6989440.java ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Map/Get.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/Timer/Args.java ! test/java/util/Timer/KillThread.java ! test/java/util/UUID/UUIDTest.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/naming/spi/DirectoryManager/GetContDirCtx.java ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java ! test/javax/security/auth/Subject/doAs/Test.sh ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/misc/Version/Version.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java ! test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java ! test/sun/nio/cs/OLD/PCK_OLD.java ! test/sun/nio/cs/OLD/SJIS_OLD.java ! test/sun/nio/cs/OLD/SingleByteDecoder.java ! test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/StrCodingBenchmark.java ! test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestCp834_SBCS.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestUTF8.java ! test/sun/nio/cs/TestX11JIS0201.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/Krb5NameEquals.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/TcpTimeout.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jcmd/jcmd-Defaults.sh ! test/sun/tools/jcmd/jcmd-f.sh ! test/sun/tools/jcmd/jcmd-help-help.sh ! test/sun/tools/jcmd/jcmd-help.sh ! test/sun/tools/jcmd/jcmd-pid.sh ! test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/tools/launcher/DefaultLocaleTest.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/TimeStamp.java Changeset: 6ffd64541a6c Author: lana Date: 2012-11-02 17:44 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6ffd64541a6c Merge - make/sun/jdbc/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcSwing.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 63726e5b90da Author: erikj Date: 2012-11-03 16:27 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63726e5b90da 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcJObjC.gmk Changeset: 26dbd73fb766 Author: katleman Date: 2012-11-07 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/26dbd73fb766 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: ad5c1d6b1e16 Author: katleman Date: 2012-11-08 11:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad5c1d6b1e16 Added tag jdk8-b64 for changeset 26dbd73fb766 ! .hgtags Changeset: bc09a1591629 Author: alanb Date: 2012-11-04 14:07 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bc09a1591629 8000330: (fc) FileChannel.truncate issues when given size > file size 8002180: (fc) FileChannel.map does not throw NPE if MapMode specified as null Reviewed-by: chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 46b24eb85b86 Author: mullan Date: 2012-11-05 10:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/46b24eb85b86 7171570: JEP 124 Potential API Changes Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 4770b0a49675 Author: mullan Date: 2012-11-05 10:33 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4770b0a49675 Merge - make/sun/jdbc/Makefile - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c Changeset: 510cb3671f14 Author: mullan Date: 2012-11-05 12:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/510cb3671f14 Merge Changeset: 519f4c9ebf8d Author: vinnie Date: 2012-11-05 20:18 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/519f4c9ebf8d 6383200: PBE: need new algorithm support in password based encryption Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java + src/share/classes/com/sun/crypto/provider/PBES1Core.java + src/share/classes/com/sun/crypto/provider/PBES2Core.java + src/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java + src/share/classes/com/sun/crypto/provider/PBKDF2Core.java + src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java + test/com/sun/crypto/provider/Cipher/PBE/PBES2Test.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/HmacSaltLengths.java Changeset: 798292c71419 Author: ksrini Date: 2012-11-05 14:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/798292c71419 8001191: use -source 8 -target 8 when compiling the JDK Reviewed-by: chegar, dholmes, erikj, jgish ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/invoke/Makefile ! makefiles/Setup.gmk ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/native/java/lang/System.c ! test/ProblemList.txt Changeset: 8222e6eac651 Author: ksrini Date: 2012-11-05 15:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8222e6eac651 7050936: (pack200) Support version 52.0 class files in langtools Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/native/com/sun/java/util/jar/pack/constants.h Changeset: cb65e3315b27 Author: jiangli Date: 2012-11-05 12:51 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb65e3315b27 7197210: java/lang/invoke/CallSiteTest.java failing on armsflt. Summary: Reduce work load and set longer timeout for java/lang/invoke tests. Reviewed-by: kvn, twisti ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java Changeset: d90714aec287 Author: lancea Date: 2012-11-06 14:59 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d90714aec287 8002212: adding read/writeObject to additional SerialXXX classes Reviewed-by: naoto, forax ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 157506182fa7 Author: chegar Date: 2012-11-06 21:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/157506182fa7 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Reviewed-by: alanb, dsamersoff ! test/sun/net/www/protocol/http/StackTraceTest.java Changeset: bff9db7ca352 Author: peytoia Date: 2012-11-07 09:58 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bff9db7ca352 7198195: Support Unicode 6.2.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/PropList.txt ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/lang/Character.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/PropList.txt ! test/java/lang/Character/PropertyValueAliases.txt ! test/java/lang/Character/Scripts.txt Changeset: c9fd61d23dbe Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c9fd61d23dbe Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: a1bbb8805e22 Author: weijun Date: 2012-11-07 14:13 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a1bbb8805e22 6355584: Introduce constrained Kerberos delegation Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/PAData.java + src/share/classes/sun/security/krb5/internal/PAForUserEnc.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/Basic.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java + test/sun/security/krb5/auto/S4U2proxy.java + test/sun/security/krb5/auto/S4U2proxyGSS.java + test/sun/security/krb5/auto/S4U2self.java + test/sun/security/krb5/auto/S4U2selfAsServer.java + test/sun/security/krb5/auto/S4U2selfAsServerGSS.java + test/sun/security/krb5/auto/S4U2selfGSS.java Changeset: 59e88d3b9b17 Author: jzavgren Date: 2012-11-07 10:49 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/59e88d3b9b17 8001579: Cleanup warnings in security native code Reviewed-by: chegar, alanb, vinnie ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 9e013ce42dd7 Author: dfuchs Date: 2012-11-07 13:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9e013ce42dd7 6720349: (ch) Channels tests depending on hosts inside Sun Summary: This changeset make the nio tests start small TCP or UDP servers from within the tests, instead of relying on external services. Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/IsBound.java ! test/java/nio/channels/DatagramChannel/IsConnected.java ! test/java/nio/channels/Selector/Alias.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Basic.java ! test/java/nio/channels/SocketChannel/BufferSize.java ! test/java/nio/channels/SocketChannel/Connect.java ! test/java/nio/channels/SocketChannel/ConnectState.java ! test/java/nio/channels/SocketChannel/FinishConnect.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/Stream.java ! test/java/nio/channels/SocketChannel/VectorParams.java + test/java/nio/channels/TestServers.java ! test/java/nio/channels/TestUtil.java Changeset: 7d50ff0e2d44 Author: coffeys Date: 2012-11-07 18:48 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7d50ff0e2d44 8002227: (tz) Support tzdata2012i Reviewed-by: peytoia, asaha ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! makefiles/GendataTimeZone.gmk Changeset: f51943263267 Author: andrew Date: 2012-11-07 16:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f51943263267 8003120: ResourceManager.getApplicationResources() does not close InputStreams Summary: Add finally blocks to close the InputStream instances Reviewed-by: lancea ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: cc325832469c Author: naoto Date: 2012-11-07 15:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cc325832469c 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation 8001562: Collator.getAvailableLocales() doesn't return all locales for which localized instances are available Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + test/java/util/Locale/Bug8001562.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java Changeset: 599f231cba97 Author: jfranck Date: 2012-11-07 17:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/599f231cba97 8001598: Augment ElementType enum for JSR 308 Reviewed-by: darcy ! src/share/classes/java/lang/annotation/ElementType.java Changeset: cdf02b372956 Author: sherman Date: 2012-11-07 20:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cdf02b372956 6282196: There should be Math.mod(number, modulo) methods Summary: added the requested methods Reviewed-by: darcy, emcmanus, alanb Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/DivModTests.java Changeset: 1e7dd9e05ce2 Author: mullan Date: 2012-11-08 12:51 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1e7dd9e05ce2 7198416: CertificateIssuerName and CertificateSubjectName are redundant Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/certAttributes.html ! test/sun/security/pkcs11/rsa/GenKeyStore.java ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/rsa/GenKeyStore.java Changeset: 9edfa0e761b9 Author: xuelei Date: 2012-11-09 01:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9edfa0e761b9 8001569: Regression test GetPeerHost uses static port number Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java Changeset: 220d2458ce4b Author: lana Date: 2012-11-09 14:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/220d2458ce4b Merge Changeset: 3717bcf9d7a7 Author: dholmes Date: 2012-11-07 23:12 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3717bcf9d7a7 8002040: Allow Full Debug Symbols when cross-compiling Reviewed-by: dcubed, erikj, tbell ! make/common/Defs-linux.gmk Changeset: 1e79fec4a01f Author: ohrstrom Date: 2012-11-08 12:25 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1e79fec4a01f 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 170e8ccfbc4f Author: tbell Date: 2012-11-12 10:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/170e8ccfbc4f 8002365: build-infra: Build-infra fails on solaris 11.1 on sparc. Summary: Add '-lc' to LDFLAGS for native libraries in CompileNativeLibraries.gmk Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileNativeLibraries.gmk Changeset: 2fc142843a93 Author: tbell Date: 2012-11-12 10:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2fc142843a93 8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class Summary: Remove spurious space in the locale lists Reviewed-by: naoto, ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcLocaleDataMetaInfo.gmk Changeset: e9e8a5852690 Author: tbell Date: 2012-11-12 12:35 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e9e8a5852690 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/Import.gmk Changeset: 84f0439ccaab Author: tbell Date: 2012-11-13 13:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/84f0439ccaab 8001965: build-infra: Large compare diffs between new and old on mac Summary: The wrong icon source file was used when building closed Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcIcons.gmk Changeset: 130d3a54d28b Author: katleman Date: 2012-11-14 12:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/130d3a54d28b Merge Changeset: c87df8b1f55e Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c87df8b1f55e Added tag jdk8-b65 for changeset 130d3a54d28b ! .hgtags Changeset: bd50944b07fa Author: mduigou Date: 2012-11-20 12:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bd50944b07fa Merge ! .hgtags ! make/Makefile ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/docs/CORE_PKGS.gmk ! make/java/invoke/Makefile ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/sun_nio/FILES_java.gmk ! make/netbeans/common/architectures/name-Macosx.properties - make/sun/jdbc/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/osxapp/Makefile ! make/sun/security/other/Makefile ! make/sun/util/Makefile ! make/tools/CharsetMapping/DoubleByte-X.java.template ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaConversionException.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandleProxyLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/classes/sun/util/PreHashedMap.java ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jvm.h ! src/share/native/common/check_code.c - src/solaris/native/java/io/FileSystem_md.c - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java From brian.goetz at oracle.com Tue Nov 20 13:29:58 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 20 Nov 2012 21:29:58 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121120213021.023E447AA0@hg.openjdk.java.net> Changeset: efc91616a15b Author: briangoetz Date: 2012-11-20 16:29 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/efc91616a15b Tests for exercising spliterators + test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java Changeset: 9a1c54defd94 Author: briangoetz Date: 2012-11-20 16:29 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9a1c54defd94 Merge - make/sun/jdbc/Makefile - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/solaris/native/java/io/FileSystem_md.c - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java From mike.duigou at oracle.com Tue Nov 20 13:31:34 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 Nov 2012 13:31:34 -0800 Subject: lambda/lambda sync against JDK8 Message-ID: <593D506A-77E7-475A-9982-4D0309EDEDCF@oracle.com> Hello Lambdonites; I have synced the lambda repositories against the JDK8 mainline. There have been a number of fixes to the new build process. It's recommended you delete your existing build directory and start fresh. With this sync the differences between the jdk8 and lambda repositories have begun to shrink substantially. The lambda hotspot and langtools repo now contain only experimental features. The jdk repo is now the focus of differences between jdk8 and lambda repos. Changesets have been proposed for inclusion in JDK (see http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006768.html) and more changesets are being prepared. Mike From mike.duigou at oracle.com Tue Nov 20 14:41:53 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 22:41:53 +0000 Subject: hg: lambda/lambda/jdk: Implements extension methods on Comparator (reverse and compose) as well as static combinator methods in Comparators for things like turning a T -> {Comparable, int, long, double} Message-ID: <20121120224205.2978847AA3@hg.openjdk.java.net> Changeset: 004364b207ff Author: henryjen Date: 2012-11-20 14:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/004364b207ff Implements extension methods on Comparator (reverse and compose) as well as static combinator methods in Comparators for things like turning a T -> {Comparable,int,long,double} into a Comparator. This allows things like: people.sort(Comparators.comparing(Person::getName)) Comparator byLastFirst = Comparators.comparing(Person::getLastName) .compose(Comparators.comparing(Person::getFirstName)) ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java - test-ng/tests/org/openjdk/tests/java/util/ComparatorsTest.java + test/java/util/ComparatorsTest.java From mike.duigou at oracle.com Tue Nov 20 15:37:05 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 23:37:05 +0000 Subject: hg: lambda/lambda: 8003300: build-infra: fails on solaris when objcopy is not found Message-ID: <20121120233705.C5EEE47AA5@hg.openjdk.java.net> Changeset: d99174856066 Author: mduigou Date: 2012-11-20 15:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/d99174856066 8003300: build-infra: fails on solaris when objcopy is not found Summary: Made call to fixup_path for objcopy conditional on objcopy being set. ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From mike.duigou at oracle.com Tue Nov 20 15:57:10 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Nov 2012 23:57:10 +0000 Subject: hg: lambda/lambda/jdk: add missing src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns file Message-ID: <20121120235721.BF1F947AA6@hg.openjdk.java.net> Changeset: b893b58d649a Author: mduigou Date: 2012-11-20 15:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b893b58d649a add missing src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns file + src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns From paul.sandoz at oracle.com Wed Nov 21 02:02:13 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 21 Nov 2012 10:02:13 +0000 Subject: hg: lambda/lambda/jdk: correct cast to avoid compiler warnings Message-ID: <20121121100225.7D43B47AB3@hg.openjdk.java.net> Changeset: c84f27e782f0 Author: psandoz Date: 2012-11-21 11:01 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c84f27e782f0 correct cast to avoid compiler warnings ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java From paul.sandoz at oracle.com Wed Nov 21 06:06:37 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 21 Nov 2012 14:06:37 +0000 Subject: hg: lambda/lambda/jdk: - a parent stream may only have one child stream i.e. linear pipeline. Message-ID: <20121121140659.9F5FF47AB6@hg.openjdk.java.net> Changeset: 170df812b0b2 Author: psandoz Date: 2012-11-21 15:06 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/170df812b0b2 - a parent stream may only have one child stream i.e. linear pipeline. - AbstractPipeline now holds an IntermediateOp[] and no longer holds a reference to an upstream AbstractPipeline instance. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntLimitOp.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From paul.sandoz at oracle.com Wed Nov 21 06:27:32 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 21 Nov 2012 14:27:32 +0000 Subject: hg: lambda/lambda/jdk: remove unused methods Message-ID: <20121121142743.7C09647AB7@hg.openjdk.java.net> Changeset: 0f7111a3ef65 Author: psandoz Date: 2012-11-21 15:27 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0f7111a3ef65 remove unused methods ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/primitive/IntNodes.java From aleksey.shipilev at oracle.com Wed Nov 21 13:37:05 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 22 Nov 2012 01:37:05 +0400 Subject: FJP update (again) Message-ID: <50AD4981.2010002@oracle.com> Hi, Please consider pushing the new revision of FJP into lambda/lambda [1]. The build is fine, parallel microbenchmarks work fine. Would be nice to see this sooner to get picked up in the nightly builds. Thanks! -Aleksey. [1] http://shipilev.net/pub/jdk/lambda/20121122-fjpwakeup/20121122-fjp-update-1.patch From howard.lovatt at gmail.com Wed Nov 21 13:55:10 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 22 Nov 2012 08:55:10 +1100 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <50AB23CE.2030104@oracle.com> References: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> <50AB23CE.2030104@oracle.com> Message-ID: <7E3666AA-8196-4B01-A749-B0A61979C155@gmail.com> Couple of quick comments: 1. I think the naming is inconsistent between class and method, e.g. IntFunction has an applyAsInt method. Why not either IntFunction and intApply or FunctionAsInt and applyAsInt? 2. It would be good to have a description of the stream library, perhaps an expanded for of Brian's State of Streams document referenced throughout the API like the Collections API has. Sent from my iPad On 20/11/2012, at 5:31 PM, David Holmes wrote: > Hi Mike, > > Minor typos and inconsistencies: > > DoubleBinaryOperator.java > > 28 * Combines two {@code double} operands producing an {@code double} > result. > > an -> a > > 51 * @param rightvalue used as the right operand > > Need space after right > > 52 * @return result value of the operation > > "result value" doesn't read right - just "@return the result of ..." - > as for BinaryOperator.operate > > General consistency: all like methods in a family of interfaces should > use the same wording. Eg BinaryOperator.operate says "upon the provided > operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto > across families ie UnaryOperator and BinaryOperator should use > consistent terminology for operands and results. > > --- > > DoubleBlock.java: > > 31 * @param The type of input objects to {@code accept}. > > DoubleBlock is not a generic type. (Surely this should be generating a > javadoc warning?) > > --- > > DoubleFunction.java > > 32 * @param the type of input objects to the {@code apply} operation. > > You now potentially have multiple operation methods, and T refers to the > input of all of them. > > ---- > > General consistency comments across everything: > - Use of operand versus provided operand versus input value etc > - Use of result vs computed result vs result value vs output etc > > --- > > Function.java > > 33 * @param the type of output objects from {@code apply} operation. > > from -> from the > > 43 * @param t the input object to be to which the function will > be applied. > > delete "to be" ? Or else re-word. > > --- > > UnaryOperator.java > > 28 * Operator on a single operand. > > Operator -> operate ? > > 30 * @param the type of input objects to {@code operate} and of > the result. > > objects -> object > > --- > > Cheers, > David > > > On 20/11/2012 2:55 PM, Mike Duigou wrote: >> I have posted another revision at >> >> http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ >> >> This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. >> >> The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. >> >> We don't anticipate many (any?) further changes to the naming before commit at this point. >> >> Mike >> >> On Nov 13 2012, at 17:19 , Mike Duigou wrote: >> >>> Hello all; >>> >>> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >>> >>> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >>> >>> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >>> >>> This update includes: >>> >>> - Block.apply renamed to Block.accept >>> - {Int|Long|Double}Block specializations added. >>> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >>> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >>> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >>> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >>> >>> Mike >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From mike.duigou at oracle.com Wed Nov 21 19:30:11 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 22 Nov 2012 03:30:11 +0000 Subject: hg: lambda/lambda/jdk: javadocs update Message-ID: <20121122033030.B6CAC47AD8@hg.openjdk.java.net> Changeset: fb387d8aeebe Author: mduigou Date: 2012-11-21 19:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fb387d8aeebe javadocs update ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java From paul.sandoz at oracle.com Thu Nov 22 02:28:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 22 Nov 2012 11:28:56 +0100 Subject: More on no-reuse streams In-Reply-To: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> References: <618AE578-8EC0-4ECE-A732-81E2EB2FB719@oracle.com> Message-ID: I pushed a change set yesterday that adds to the previous constraints: Stream s= ... s.map(); s.map(); // throws ISE Only linear streams are supported. Paul. On Nov 19, 2012, at 3:29 PM, Paul Sandoz wrote: > Hi, > > Brian and I just pushed a changeset that: > > - turns Stream/IntStream.iterator() into a terminal operation > > - only one terminal operation may be performed on at most one stream in the pipeline, > otherwise an ISE will be thrown. > > Based on feedback on stream iteration and terminal operation we decided to swing to the other end of the evaluation spectrum. > > No laissez-faire attitude to pulling and terminal operations. Streams are now very strict. > > Note that we pulled away from throwing ISEs with regards to infinite streams but in that case we don't think it possible to efficiently detect every scenario that will end up either looping indefinitely or result in a stack overflow or out of memory error. > > Paul. > From paul.sandoz at oracle.com Thu Nov 22 02:26:52 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 22 Nov 2012 10:26:52 +0000 Subject: hg: lambda/lambda/jdk: - Clarify the documentation of stream flags. Message-ID: <20121122102927.BFB2E47ADE@hg.openjdk.java.net> Changeset: 3e842393505f Author: psandoz Date: 2012-11-22 11:25 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e842393505f - Clarify the documentation of stream flags. - Improve methods and tests. - AbstractPipeline now combines stream flags at the start when evaluating or creating an iterator. ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java + src/share/classes/java/util/stream/StreamOpFlag.java - src/share/classes/java/util/stream/StreamOpFlags.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/CollectorOps.java ! src/share/classes/java/util/stream/op/ConcatOp.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/FilterOp.java ! src/share/classes/java/util/stream/op/FlatMapOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/MapOp.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntCollectorOps.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntLimitOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamOpFlagsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UnorderedStreamTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From paul.sandoz at oracle.com Thu Nov 22 03:01:57 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 22 Nov 2012 11:01:57 +0000 Subject: hg: lambda/lambda/jdk: Updates to j.u.c.CountedCompleter and ForkJoinPool. Message-ID: <20121122110226.A569547ADF@hg.openjdk.java.net> Changeset: 0eecd8778f85 Author: psandoz Date: 2012-11-22 11:59 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0eecd8778f85 Updates to j.u.c.CountedCompleter and ForkJoinPool. Patch provided by Aleksey Shipilev . Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java From paul.sandoz at oracle.com Thu Nov 22 03:03:46 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 22 Nov 2012 12:03:46 +0100 Subject: FJP update (again) In-Reply-To: <50AD4981.2010002@oracle.com> References: <50AD4981.2010002@oracle.com> Message-ID: On Nov 21, 2012, at 10:37 PM, Aleksey Shipilev wrote: > Hi, > > Please consider pushing the new revision of FJP into lambda/lambda [1]. > The build is fine, parallel microbenchmarks work fine. Would be nice to > see this sooner to get picked up in the nightly builds. > Pushed, Paul. > Thanks! > -Aleksey. > > [1] > http://shipilev.net/pub/jdk/lambda/20121122-fjpwakeup/20121122-fjp-update-1.patch > From aleksey.shipilev at oracle.com Thu Nov 22 03:07:07 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 22 Nov 2012 15:07:07 +0400 Subject: hg: lambda/lambda/jdk: Updates to j.u.c.CountedCompleter and ForkJoinPool. In-Reply-To: <20121122110226.A569547ADF@hg.openjdk.java.net> References: <20121122110226.A569547ADF@hg.openjdk.java.net> Message-ID: <50AE075B.4000500@oracle.com> Thanks! I think it's enough to list our OpenJDK handles: Contributed-by: dl, shade -Aleksey. On 11/22/2012 03:01 PM, paul.sandoz at oracle.com wrote: > Changeset: 0eecd8778f85 > Author: psandoz > Date: 2012-11-22 11:59 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0eecd8778f85 > > Updates to j.u.c.CountedCompleter and ForkJoinPool. > Patch provided by Aleksey Shipilev . > Contributed-by: Doug Lea
> > ! src/share/classes/java/util/concurrent/CountedCompleter.java > ! src/share/classes/java/util/concurrent/ForkJoinPool.java > ! src/share/classes/java/util/concurrent/ForkJoinTask.java > ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java > > From david.holmes at oracle.com Thu Nov 22 04:51:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Nov 2012 22:51:21 +1000 Subject: hg: lambda/lambda/jdk: Updates to j.u.c.CountedCompleter and ForkJoinPool. In-Reply-To: <50AE075B.4000500@oracle.com> References: <20121122110226.A569547ADF@hg.openjdk.java.net> <50AE075B.4000500@oracle.com> Message-ID: <50AE1FC9.6050706@oracle.com> On 22/11/2012 9:07 PM, Aleksey Shipilev wrote: > Thanks! > > I think it's enough to list our OpenJDK handles: > Contributed-by: dl, shade Actually for proper jdk8 changesets contributions have to be name and email address. David > -Aleksey. > > On 11/22/2012 03:01 PM, paul.sandoz at oracle.com wrote: >> Changeset: 0eecd8778f85 >> Author: psandoz >> Date: 2012-11-22 11:59 +0100 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0eecd8778f85 >> >> Updates to j.u.c.CountedCompleter and ForkJoinPool. >> Patch provided by Aleksey Shipilev. >> Contributed-by: Doug Lea
>> >> ! src/share/classes/java/util/concurrent/CountedCompleter.java >> ! src/share/classes/java/util/concurrent/ForkJoinPool.java >> ! src/share/classes/java/util/concurrent/ForkJoinTask.java >> ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java >> >> > > From elena.votchennikova at oracle.com Thu Nov 22 07:35:44 2012 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Thu, 22 Nov 2012 19:35:44 +0400 Subject: Behavior of concat(null) In-Reply-To: <50AABEC5.3050806@oracle.com> References: <50AA4D95.4060507@oracle.com> <50AA56FE.3040701@oracle.com> <50AAB960.10101@univ-mlv.fr> <50AABEC5.3050806@oracle.com> Message-ID: <50AE4650.9080909@oracle.com> Remi, Brian, I try to call stream.concat(null); - case (1). Thanks, Elena On 20.11.2012 3:20, Brian Goetz wrote: > Its pretty reasonable for (1) to throw NPE. > > On 11/19/2012 5:57 PM, Remi Forax wrote: >> Elena, >> just to understand do you try to call >> 1) stream.concat(null); >> or >> 2) stream.concate(stream2); // with some null in stream2 >> >> for case 1) concat should throw a NPE, for case 2) see the answer of >> Brian :) >> >> R?mi >> >> On 11/19/2012 04:57 PM, Brian Goetz wrote: >>> We do not guarantee that any given operation WILL or WILL NOT throw NPE >>> when present with nulls. We have made some efforts to avoid throwing >>> NPEs from within the Streams library code, but even that is not >>> guaranteed (put that in the "reasonable efforts" category.) We expect >>> most, but not all, NPEs resulting from null elements to come from code >>> outside java.util.stream, such as lambdas passed to the operation, >>> Arrays.sort(), the constructor of Optional, etc. >>> >>> On 11/19/2012 10:17 AM, elena votchennikova wrote: >>>> Hello, >>>> >>>> I'm trying to use method concat(Stream) of some Stream implementation >>>> with null-argument and currently it doesn't throw NullPointerException. >>>> Exception is thrown only when I call some method of the resulting >>>> Stream, for example iterator(). >>>> >>>> Could you please explain - is it an expected behavior or concat() with >>>> null-argument should throw NPE? >>>> >>>> >>>> Thanks a lot, >>>> Elena >>>> >> From mike.duigou at oracle.com Thu Nov 22 11:16:32 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 22 Nov 2012 19:16:32 +0000 Subject: hg: lambda/lambda/jdk: refactor apply -> accept Message-ID: <20121122191706.7498D47AE2@hg.openjdk.java.net> Changeset: 46befad6ec66 Author: mduigou Date: 2012-11-22 11:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/46befad6ec66 refactor apply -> accept ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/LongBlock.java From aruld at acm.org Thu Nov 22 13:44:30 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Thu, 22 Nov 2012 11:44:30 -1000 Subject: lambda/lambda sync against JDK8 In-Reply-To: <593D506A-77E7-475A-9982-4D0309EDEDCF@oracle.com> References: <593D506A-77E7-475A-9982-4D0309EDEDCF@oracle.com> Message-ID: I have been using the old build system on mac for some time. It looks like some thing got changed recently (since Nov 20), I am able to build the lambda project fine, but intellij is not recognizing the JDK from build/macosx-x86_64/j2sdk-image directory. I saved a local copy of an earlier build (as of Nov 19) which still works fine with intellij. Any clues on what could be happening? Is anyone able to build usable JDK on mac using old build system? -Arul On Tue, Nov 20, 2012 at 11:31 AM, Mike Duigou wrote: > Hello Lambdonites; > > I have synced the lambda repositories against the JDK8 mainline. There > have been a number of fixes to the new build process. It's recommended you > delete your existing build directory and start fresh. > > With this sync the differences between the jdk8 and lambda repositories > have begun to shrink substantially. The lambda hotspot and langtools repo > now contain only experimental features. The jdk repo is now the focus of > differences between jdk8 and lambda repos. Changesets have been proposed > for inclusion in JDK (see > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006768.html) > and more changesets are being prepared. > > Mike > > From mike.duigou at oracle.com Thu Nov 22 15:08:16 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 22 Nov 2012 15:08:16 -0800 Subject: lambda/lambda sync against JDK8 In-Reply-To: References: <593D506A-77E7-475A-9982-4D0309EDEDCF@oracle.com> Message-ID: The problem is most likely caused by the compiler switching to class file version 52. Intellij probably doesn't recognize that version yet. Mike On Nov 22 2012, at 13:44 , Arul Dhesiaseelan wrote: > I have been using the old build system on mac for some time. It looks like some thing got changed recently (since Nov 20), I am able to build the lambda project fine, but intellij is not recognizing the JDK from build/macosx-x86_64/j2sdk-image directory. I saved a local copy of an earlier build (as of Nov 19) which still works fine with intellij. Any clues on what could be happening? Is anyone able to build usable JDK on mac using old build system? > > -Arul > > On Tue, Nov 20, 2012 at 11:31 AM, Mike Duigou wrote: > Hello Lambdonites; > > I have synced the lambda repositories against the JDK8 mainline. There have been a number of fixes to the new build process. It's recommended you delete your existing build directory and start fresh. > > With this sync the differences between the jdk8 and lambda repositories have begun to shrink substantially. The lambda hotspot and langtools repo now contain only experimental features. The jdk repo is now the focus of differences between jdk8 and lambda repos. Changesets have been proposed for inclusion in JDK (see http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006768.html) and more changesets are being prepared. > > Mike > > From aruld at acm.org Thu Nov 22 17:57:54 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Thu, 22 Nov 2012 15:57:54 -1000 Subject: lambda/lambda sync against JDK8 In-Reply-To: References: <593D506A-77E7-475A-9982-4D0309EDEDCF@oracle.com> Message-ID: Ah, just saw this in their bug tracker http://youtrack.jetbrains.com/issue/IDEA-95473. Thanks Mike. On Thu, Nov 22, 2012 at 1:08 PM, Mike Duigou wrote: > The problem is most likely caused by the compiler switching to class file > version 52. Intellij probably doesn't recognize that version yet. > > Mike > > On Nov 22 2012, at 13:44 , Arul Dhesiaseelan wrote: > > I have been using the old build system on mac for some time. It looks like > some thing got changed recently (since Nov 20), I am able to build the > lambda project fine, but intellij is not recognizing the JDK from > build/macosx-x86_64/j2sdk-image directory. I saved a local copy of an > earlier build (as of Nov 19) which still works fine with intellij. Any > clues on what could be happening? Is anyone able to build usable JDK on mac > using old build system? > > -Arul > > On Tue, Nov 20, 2012 at 11:31 AM, Mike Duigou wrote: > >> Hello Lambdonites; >> >> I have synced the lambda repositories against the JDK8 mainline. There >> have been a number of fixes to the new build process. It's recommended you >> delete your existing build directory and start fresh. >> >> With this sync the differences between the jdk8 and lambda repositories >> have begun to shrink substantially. The lambda hotspot and langtools repo >> now contain only experimental features. The jdk repo is now the focus of >> differences between jdk8 and lambda repos. Changesets have been proposed >> for inclusion in JDK (see >> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006768.html) >> and more changesets are being prepared. >> >> Mike >> >> > > From mcnepp02 at googlemail.com Fri Nov 23 00:36:53 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Fri, 23 Nov 2012 09:36:53 +0100 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: <20121115221957.C5B23479C1@hg.openjdk.java.net> References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: Hi Brian, I do think that having factory methods 'empy()' and 'of(T)' and no public constructor is a good thing, I wonder whether it's necessary to make 'of(T)' is so restrictive: it throws NullPointerException if the supplied value is null. So why place the burdon of picking the correct factory method upon the user? Why not simply have: public static Optional of(T value) { return value == null ? empty() : new Optional(value); } 2012/11/15 > Changeset: ab258565c0c9 > Author: briangoetz > Date: 2012-11-15 17:19 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > > Cleanup in Optional > > ! src/share/classes/java/util/Optional.java > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > > > From ricky.clarkson at gmail.com Fri Nov 23 03:20:47 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Fri, 23 Nov 2012 08:20:47 -0300 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: That's a useful method but I'd suggest calling it 'option' or 'fromNullable'. You might be calling .of(T) thinking you do not have null and you'd rather have an exception than an empty Optional as the result. For reference, Scala calls it option, Guava calls it fromNullable, Functional Java calls it fromNull and all 3 make that a distinct method from the one that throws an exception if it's null (Some(t) in Scala, of in Guava, some(t) in Functional Java). On Fri, Nov 23, 2012 at 5:36 AM, Gernot Neppert wrote: > Hi Brian, > > I do think that having factory methods 'empy()' and 'of(T)' and no public > constructor is a good thing, I wonder whether it's necessary to make > 'of(T)' is so restrictive: it throws NullPointerException if the supplied > value is null. > So why place the burdon of picking the correct factory method upon the > user? > Why not simply have: > > public static Optional of(T value) { > return value == null ? empty() : new Optional(value); > } > > > > > 2012/11/15 > > > Changeset: ab258565c0c9 > > Author: briangoetz > > Date: 2012-11-15 17:19 -0500 > > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > > > > Cleanup in Optional > > > > ! src/share/classes/java/util/Optional.java > > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > > > > > > > > From mcnepp02 at googlemail.com Fri Nov 23 04:09:38 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Fri, 23 Nov 2012 13:09:38 +0100 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: I don't think it's realistic to be "thinking you do not have null and you'd rather have an exception". Either I know the value is null, then I may call empty(), or I don't know, in which case I wouldn't want to invoke a method that might throw an Exception. I'd rather get a valid 'Optional' instance, be it empty or not. Note that everything would be different if 'Optional' were allowed to have 'null' values. Then of course we'd need to be able to discriminate between 'No value at all' and 'The value null'. But since that has been voted down, the reason for having distinct factory methods has (IMO) gone away. > You might be calling .of(T) thinking you do not have null and you'd rather have an exception than an empty Optional as the result. 2012/11/23 Ricky Clarkson > That's a useful method but I'd suggest calling it 'option' or > 'fromNullable'. You might be calling .of(T) thinking you do not have null > and you'd rather have an exception than an empty Optional as the result. > For reference, Scala calls it option, Guava calls it fromNullable, > Functional Java calls it fromNull and all 3 make that a distinct method > from the one that throws an exception if it's null (Some(t) in Scala, of in > Guava, some(t) in Functional Java). > > > On Fri, Nov 23, 2012 at 5:36 AM, Gernot Neppert wrote: > >> Hi Brian, >> >> I do think that having factory methods 'empy()' and 'of(T)' and no public >> constructor is a good thing, I wonder whether it's necessary to make >> 'of(T)' is so restrictive: it throws NullPointerException if the supplied >> value is null. >> So why place the burdon of picking the correct factory method upon the >> user? >> Why not simply have: >> >> public static Optional of(T value) { >> return value == null ? empty() : new Optional(value); >> } >> >> >> >> >> 2012/11/15 >> >> > Changeset: ab258565c0c9 >> > Author: briangoetz >> > Date: 2012-11-15 17:19 -0500 >> > URL: >> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 >> > >> > Cleanup in Optional >> > >> > ! src/share/classes/java/util/Optional.java >> > ! src/share/classes/java/util/streams/ops/FindAnyOp.java >> > ! src/share/classes/java/util/streams/ops/FindFirstOp.java >> > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java >> > >> > >> > >> >> > From ricky.clarkson at gmail.com Fri Nov 23 04:12:47 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Fri, 23 Nov 2012 09:12:47 -0300 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: Actually I can think of plenty of times when that is exactly what I wanted. On Nov 23, 2012 9:09 AM, "Gernot Neppert" wrote: > I don't think it's realistic to be "thinking you do not have null and > you'd rather have an exception". > Either I know the value is null, then I may call empty(), or I don't know, > in which case I wouldn't want to invoke a method that might throw an > Exception. I'd rather get a valid 'Optional' instance, be it empty or not. > > Note that everything would be different if 'Optional' were allowed to have > 'null' values. Then of course we'd need to be able to discriminate between > 'No value at all' and 'The value null'. But since that has been voted down, > the reason for having distinct factory methods has (IMO) gone away. > > > > You might be calling .of(T) thinking you do not have null and you'd > rather have an exception than an empty Optional as the result. > > > 2012/11/23 Ricky Clarkson > >> That's a useful method but I'd suggest calling it 'option' or >> 'fromNullable'. You might be calling .of(T) thinking you do not have null >> and you'd rather have an exception than an empty Optional as the result. >> For reference, Scala calls it option, Guava calls it fromNullable, >> Functional Java calls it fromNull and all 3 make that a distinct method >> from the one that throws an exception if it's null (Some(t) in Scala, of in >> Guava, some(t) in Functional Java). >> >> >> On Fri, Nov 23, 2012 at 5:36 AM, Gernot Neppert wrote: >> >>> Hi Brian, >>> >>> I do think that having factory methods 'empy()' and 'of(T)' and no public >>> constructor is a good thing, I wonder whether it's necessary to make >>> 'of(T)' is so restrictive: it throws NullPointerException if the supplied >>> value is null. >>> So why place the burdon of picking the correct factory method upon the >>> user? >>> Why not simply have: >>> >>> public static Optional of(T value) { >>> return value == null ? empty() : new Optional(value); >>> } >>> >>> >>> >>> >>> 2012/11/15 >>> >>> > Changeset: ab258565c0c9 >>> > Author: briangoetz >>> > Date: 2012-11-15 17:19 -0500 >>> > URL: >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 >>> > >>> > Cleanup in Optional >>> > >>> > ! src/share/classes/java/util/Optional.java >>> > ! src/share/classes/java/util/streams/ops/FindAnyOp.java >>> > ! src/share/classes/java/util/streams/ops/FindFirstOp.java >>> > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java >>> > >>> > >>> > >>> >>> >> > From mcnepp02 at googlemail.com Fri Nov 23 07:23:03 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Fri, 23 Nov 2012 16:23:03 +0100 Subject: Evolving interfaces: source/binary compatibility issues Message-ID: <50AF94D7.8070507@googlemail.com> Hi all, when I browsed the Java 8 docs and found that java.util.List finally has a method "void sort(Comparator comparator)", I was quite happy at first. Unfortunately, that bliss lasted only until I found that one of my own implementations of java.util.List already has such a method - albeit "protected". This has at least two consequences: 1. I can't compile my old code against the JDK 8, since it tries to implement an interface method with weaker access privileges. 2. Even worse: if I link my old compiled code against a JDK 8, it may raise an "java.lang.IllegalAccessError" at Runtime, since code from the new codebase may innociously call back my "sort" method via the interface. Here are some other methods that are likely to cause trouble, because they are obvious extensions likely to be already present in user-code: java.util.Comparator.reverse() java.util.Collection.addAll(Iterable) Do you consider this a real danger or does it seem esoteric? From luolong at gmail.com Fri Nov 23 09:46:24 2012 From: luolong at gmail.com (Roland Tepp) Date: Fri, 23 Nov 2012 19:46:24 +0200 Subject: hg: lambda/lambda/jdk: Cleanup in Optional In-Reply-To: References: <20121115221957.C5B23479C1@hg.openjdk.java.net> Message-ID: I wonder, why use Optional, if you already know, if the value is either null on non-null? I'd use Optional only in the case I have a reasonable expectation that the value might be missing, but I still want to provide a fairly linear processing of this case. I can see no use case for using null checks and Optional side-by-side - either use one or the other. 2012/11/23 Ricky Clarkson > Actually I can think of plenty of times when that is exactly what I wanted. > On Nov 23, 2012 9:09 AM, "Gernot Neppert" wrote: > > > I don't think it's realistic to be "thinking you do not have null and > > you'd rather have an exception". > > Either I know the value is null, then I may call empty(), or I don't > know, > > in which case I wouldn't want to invoke a method that might throw an > > Exception. I'd rather get a valid 'Optional' instance, be it empty or > not. > > > > Note that everything would be different if 'Optional' were allowed to > have > > 'null' values. Then of course we'd need to be able to discriminate > between > > 'No value at all' and 'The value null'. But since that has been voted > down, > > the reason for having distinct factory methods has (IMO) gone away. > > > > > > > You might be calling .of(T) thinking you do not have null and you'd > > rather have an exception than an empty Optional as the result. > > > > > > 2012/11/23 Ricky Clarkson > > > >> That's a useful method but I'd suggest calling it 'option' or > >> 'fromNullable'. You might be calling .of(T) thinking you do not have > null > >> and you'd rather have an exception than an empty Optional as the result. > >> For reference, Scala calls it option, Guava calls it fromNullable, > >> Functional Java calls it fromNull and all 3 make that a distinct method > >> from the one that throws an exception if it's null (Some(t) in Scala, > of in > >> Guava, some(t) in Functional Java). > >> > >> > >> On Fri, Nov 23, 2012 at 5:36 AM, Gernot Neppert < > mcnepp02 at googlemail.com>wrote: > >> > >>> Hi Brian, > >>> > >>> I do think that having factory methods 'empy()' and 'of(T)' and no > public > >>> constructor is a good thing, I wonder whether it's necessary to make > >>> 'of(T)' is so restrictive: it throws NullPointerException if the > supplied > >>> value is null. > >>> So why place the burdon of picking the correct factory method upon the > >>> user? > >>> Why not simply have: > >>> > >>> public static Optional of(T value) { > >>> return value == null ? empty() : new Optional(value); > >>> } > >>> > >>> > >>> > >>> > >>> 2012/11/15 > >>> > >>> > Changeset: ab258565c0c9 > >>> > Author: briangoetz > >>> > Date: 2012-11-15 17:19 -0500 > >>> > URL: > >>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ab258565c0c9 > >>> > > >>> > Cleanup in Optional > >>> > > >>> > ! src/share/classes/java/util/Optional.java > >>> > ! src/share/classes/java/util/streams/ops/FindAnyOp.java > >>> > ! src/share/classes/java/util/streams/ops/FindFirstOp.java > >>> > ! src/share/classes/java/util/streams/ops/SeedlessFoldOp.java > >>> > > >>> > > >>> > > >>> > >>> > >> > > > > -- Roland From georgiy.rakov at oracle.com Mon Nov 26 02:10:08 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 26 Nov 2012 14:10:08 +0400 Subject: Specifying "abnormal" behavior Message-ID: <50B34000.1040701@oracle.com> Hello, now "abnormal" behavior could occur in some lambda API use cases. By "abnormal" I mean things like hanging, throwing OutOfMemory exception, etc. Such "abnormal" behavior now occurs while dealing with infinite streams. For instance following line of code causes hanging: *Streams.cycle(Arrays.asList(1, 2, 3)).filter(o -> o>4).iterator().hasNext();* So I wonder: 1) If spec is going to specify the circumstances which could cause such "abnormal" behavior, for instance "an attempt to sort infinite stream leads to unpredictable result". 2) Moreover whether spec is going to specify that behavior exactly. For instance instead of saying "an attempt to sort infinite stream leads to /unpredictable result/" it will say "an attempt to sort infinite stream causes /OutOfMemory exception/". Thanks, Georgiy. From sergey.kuksenko at oracle.com Mon Nov 26 04:40:43 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Mon, 26 Nov 2012 16:40:43 +0400 Subject: lambda explicit type declaration. Message-ID: <50B3634B.80803@oracle.com> Hi, I'd like to ask about lambda with explicit parameters type declaration. There is a difference between method reference and lambda. Method reference parameters should be assignable to types of functional interface method parameters, but lambda parameters should be the same as types of functional interface method parameters. Different rules leads to inconsistency between lambda & method references (it is my opinion - I understand that others may think such inconsistency is ok). I think such strict rule for lambda makes less value of the ability to declare lambda parameter types explicitly. Let's consider a couple examples. 1. Well known "boxed value equals" problem. Comparator wrong_comparator = (x, y) -> (x < y) ? -1 : ((x == y) ? 0 : 1); And I expecting more similar bugs in the new code with lambdas, especially in places where generic boxed and specialised primitive functional interfaces are used. Developers will misthink, misprint, misevaluate type inference .... The best (IMO) way to fix the problem is not allowed right now: Comparator fixed_comparator = (int x, int y) -> (x < y) ? -1 : ((x == y) ? 0 : 1); // won't compile. Other ways to fix it are not such simple like: Comparator fixed_comparator = (a,b) -> { int x = a; int y = b; return (x < y) ? -1 : ((x == y) ? 0 : 1); }; 2. Fields access. We have two classes: class A { public int foo = 42; } class B extends A { public int foo = 43; } and two mappers: Mapper defoogaringA0 = a -> a.foo; Mapper defoogaringB0 = a -> a.foo; Results are different: System.out.println( defoogaringA0.map(new B())); // print 42 System.out.println( defoogaringB0.map(new B())); // print 43 and it is the results should be. But we don't have a convenient way to manage it. Like lets create a method: static int defoo(A a) { return a.foo; } and two mappers: Mapper defoogaringB1 = Test::defoo; Mapper defoogaringA1 = Test::defoo; System.out.println( defoogaringA1.map(new B())); // print 42 System.out.println( defoogaringB1.map(new B())); // print 42 So if I have a stream of elements - I can't process them with lambda accepting type A, because of even explicitly declared type should be the same as inferred - . The only way is using method references or expressions like: Mapper defoogaringB2 = (B a) -> ((A)a).foo; System.out.println( defoogaringB2.map(new B())); // print 42 But again I can't write a simple expression: Mapper defoogaringB2 = (A a) -> a.foo; // won't compile -- Best regards, Sergey Kuksenko From maurizio.cimadamore at oracle.com Mon Nov 26 05:31:35 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 26 Nov 2012 13:31:35 +0000 Subject: lambda explicit type declaration. In-Reply-To: <50B3634B.80803@oracle.com> References: <50B3634B.80803@oracle.com> Message-ID: <50B36F37.2090605@oracle.com> Rules could be more flexible and match those used for method references - said that, some motivations behind current rules are: *) the current rules are clearer as to what types are being used in a lambda body in an implicit lambda (i.e. same types as the target type) - note that a method reference doesn't have an analogous of a 'body' - in the lambda it seems it's useful to know what the types of the parameters will be, so that you know which members will be available on them. If you add a lot of conversion rules, the type might be not immediately obvious to the user. *) More precise overload resolution - i.e. by putting explicit types you will have the ability to effectively select which (among the set of ambiguous methods) will be selected. I also believe that inner classes were a bit in the back of our minds when designing this - i.e. we basically wanted lambdas and anonymous inner classes to be inter-changeable - it is true that once you add method references to the picture you have another construct that behaves slightly different, and that can be confusing too. Maurizio On 26/11/12 12:40, Sergey Kuksenko wrote: > Hi, > > I'd like to ask about lambda with explicit parameters type declaration. > There is a difference between method reference and lambda. Method > reference parameters should be assignable to types of functional > interface method parameters, but lambda parameters should be the same as > types of functional interface method parameters. Different rules leads > to inconsistency between lambda & method references (it is my opinion - > I understand that others may think such inconsistency is ok). I think > such strict rule for lambda makes less value of the ability to declare > lambda parameter types explicitly. > > Let's consider a couple examples. > > 1. Well known "boxed value equals" problem. > > Comparator wrong_comparator > = (x, y) -> (x < y) ? -1 : ((x == y) ? 0 : 1); > > And I expecting more similar bugs in the new code with lambdas, > especially in places where generic boxed and specialised primitive > functional interfaces are used. Developers will misthink, misprint, > misevaluate type inference .... > > The best (IMO) way to fix the problem is not allowed right now: > > Comparator fixed_comparator > = (int x, int y) -> (x < y) ? -1 : ((x == y) ? 0 : 1); > // won't compile. > > Other ways to fix it are not such simple like: > > Comparator fixed_comparator = (a,b) -> { > int x = a; > int y = b; > return (x < y) ? -1 : ((x == y) ? 0 : 1); > }; > > > 2. Fields access. > > We have two classes: > > class A { > public int foo = 42; > } > > class B extends A { > public int foo = 43; > } > > and two mappers: > > Mapper defoogaringA0 = a -> a.foo; > Mapper defoogaringB0 = a -> a.foo; > > Results are different: > System.out.println( defoogaringA0.map(new B())); // print 42 > System.out.println( defoogaringB0.map(new B())); // print 43 > > and it is the results should be. But we don't have a convenient way to > manage it. Like lets create a method: > > static int defoo(A a) { > return a.foo; > } > > and two mappers: > > Mapper defoogaringB1 = Test::defoo; > Mapper defoogaringA1 = Test::defoo; > > System.out.println( defoogaringA1.map(new B())); // print 42 > System.out.println( defoogaringB1.map(new B())); // print 42 > > So if I have a stream of elements - I can't process them with lambda > accepting type A, because of even explicitly declared type should be the > same as inferred - . The only way is using method references or > expressions like: > > Mapper defoogaringB2 = (B a) -> ((A)a).foo; > > System.out.println( defoogaringB2.map(new B())); // print 42 > > But again I can't write a simple expression: > > Mapper defoogaringB2 = (A a) -> a.foo; // won't compile > > > > > > From paul.sandoz at oracle.com Mon Nov 26 05:36:52 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 26 Nov 2012 14:36:52 +0100 Subject: Specifying "abnormal" behavior In-Reply-To: <50B34000.1040701@oracle.com> References: <50B34000.1040701@oracle.com> Message-ID: <30FD8E65-AF8A-40AF-94C4-183B6B79F893@oracle.com> On Nov 26, 2012, at 11:10 AM, Georgiy Rakov wrote: > Hello, > > now "abnormal" behavior could occur in some lambda API use cases. By > "abnormal" I mean things like hanging, throwing OutOfMemory exception, > etc. Such "abnormal" behavior now occurs while dealing with infinite > streams. For instance following line of code causes hanging: > > *Streams.cycle(Arrays.asList(1, 2, 3)).filter(o -> > o>4).iterator().hasNext();* > > So I wonder: > 1) If spec is going to specify the circumstances which could cause such > "abnormal" behavior, for instance "an attempt to sort infinite stream > leads to unpredictable result". > 2) Moreover whether spec is going to specify that behavior exactly. For > instance instead of saying "an attempt to sort infinite stream leads to > /unpredictable result/" it will say "an attempt to sort infinite stream > causes /OutOfMemory exception/". > I think we most likely have to talk in general terms with some non-normative examples. Those general terms should refer to the use of the limit operation and possibly that related to I/O sources. For example, if a "uniqueElements" occurs before "sorted" there might be cases, depending on the input, where evaluation does not terminate and other cases where evaluation may result in an OOM either from "uniqueElements" or "sorted". Paul. From paul.sandoz at oracle.com Mon Nov 26 05:54:24 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 26 Nov 2012 13:54:24 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121126135541.A83AB47B21@hg.openjdk.java.net> Changeset: 663bf5f037d5 Author: psandoz Date: 2012-11-26 14:49 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/663bf5f037d5 - iteration or evaluation can only be performed on the tail stream - a stream cannot be added to the tail stream if the stream source is already consumed i.e. the tail stream has already been evaluated or iterated on. ! src/share/classes/java/util/stream/AbstractPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java Changeset: 7aea433e840f Author: psandoz Date: 2012-11-26 14:50 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7aea433e840f Automated merge with http://hg.openjdk.java.net/lambda/lambda//jdk From alexander.zuev at oracle.com Mon Nov 26 06:33:04 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 26 Nov 2012 18:33:04 +0400 Subject: Problem with the exception. Message-ID: <50B37DA0.3030900@oracle.com> Hi, just bumped into the problem with the new compiler - for some reason it does not compile the simple construction such as: public static void init(String str) throws IndexOutOfBoundsException { throw (str == null ? new IndexOutOfBoundsException("String is null") : new IndexOutOfBoundsException("String is not null")); } This method is being compiled just fine using the jdk7 or jdk8 compilers but Lambda compiler issues an error Tester.java:3: error: incompatible types: Object cannot be converted to Throwable throw (str == null ? new IndexOutOfBoundsException("String is null") ^ 1 error Is this a known issue? With best regards, Alex From maurizio.cimadamore at oracle.com Mon Nov 26 06:42:30 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 26 Nov 2012 14:42:30 +0000 Subject: Problem with the exception. In-Reply-To: <50B37DA0.3030900@oracle.com> References: <50B37DA0.3030900@oracle.com> Message-ID: <50B37FD6.6030202@oracle.com> Yep - this issue has been addressed while porting the lambda code into JDK 8 - now we are awaiting a promotion to pull bits from JDK 8 master to lambda, so that we'll pull this fix too. Meanwhile, you may want to cast the whole operand of the 'throw' statement to 'IndexOutOfBoundsException'. Maurizio On 26/11/12 14:33, Alexander Zuev wrote: > Hi, > > just bumped into the problem with the new compiler - for some reason > it does not compile the simple construction such as: > > public static void init(String str) throws IndexOutOfBoundsException { > throw (str == null ? new IndexOutOfBoundsException("String is > null") > : new IndexOutOfBoundsException("String is not null")); > } > > This method is being compiled just fine using the jdk7 or jdk8 compilers > but Lambda compiler issues an error > > Tester.java:3: error: incompatible types: Object cannot be converted to > Throwable > throw (str == null ? new IndexOutOfBoundsException("String is > null") > ^ > 1 error > > Is this a known issue? > > With best regards, > Alex > From brian.goetz at oracle.com Mon Nov 26 07:42:49 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 26 Nov 2012 10:42:49 -0500 Subject: Specifying "abnormal" behavior In-Reply-To: <50B34000.1040701@oracle.com> References: <50B34000.1040701@oracle.com> Message-ID: <50B38DF9.8030308@oracle.com> I don't think we want to try and spec that, any more than we want to specify when the for-loop can result in an infinite loop. I think something like "the programmer is responsible for ensuring the loop can terminate" is more appropriate; trying to do much better generally sets you on a slippery slope towards the halting problem. We will absolutely definitely not try to specify exact behavor as you ask in (2); this gives us implementation constraints and a bug tail for no benefit. On 11/26/2012 5:10 AM, Georgiy Rakov wrote: > Hello, > > now "abnormal" behavior could occur in some lambda API use cases. By > "abnormal" I mean things like hanging, throwing OutOfMemory exception, > etc. Such "abnormal" behavior now occurs while dealing with infinite > streams. For instance following line of code causes hanging: > > *Streams.cycle(Arrays.asList(1, 2, 3)).filter(o -> > o>4).iterator().hasNext();* > > So I wonder: > 1) If spec is going to specify the circumstances which could cause such > "abnormal" behavior, for instance "an attempt to sort infinite stream > leads to unpredictable result". > 2) Moreover whether spec is going to specify that behavior exactly. For > instance instead of saying "an attempt to sort infinite stream leads to > /unpredictable result/" it will say "an attempt to sort infinite stream > causes /OutOfMemory exception/". > > Thanks, Georgiy. > From mike.duigou at oracle.com Mon Nov 26 12:24:24 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 26 Nov 2012 20:24:24 +0000 Subject: hg: lambda/lambda/jdk: doc improvements and cleanups Message-ID: <20121126202445.6EE9347B2A@hg.openjdk.java.net> Changeset: 95fbc3044c96 Author: mduigou Date: 2012-11-26 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/95fbc3044c96 doc improvements and cleanups ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Predicates.java From pbenedict at apache.org Mon Nov 26 12:32:01 2012 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 26 Nov 2012 14:32:01 -0600 Subject: hg: lambda/lambda/jdk: doc improvements and cleanups In-Reply-To: <20121126202445.6EE9347B2A@hg.openjdk.java.net> References: <20121126202445.6EE9347B2A@hg.openjdk.java.net> Message-ID: Mike, one suggestion I have is from the Javadocs how-to page: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html "Use 3rd person (descriptive) not 2nd person (prescriptive). The description is in 3rd person declarative rather than 2nd person imperative. Gets the label. (preferred) Get the label. (avoid)" So rather saying this for Function#compose()... "Combine with another function returning a function which preforms both functions." ...say... "Combines with another function returning a function which preforms both functions." I think you are using the 2nd person everywhere at the moment. Paul On Mon, Nov 26, 2012 at 2:24 PM, wrote: > Changeset: 95fbc3044c96 > Author: mduigou > Date: 2012-11-26 12:04 -0800 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/95fbc3044c96 > > doc improvements and cleanups > > ! src/share/classes/java/util/function/BiBlock.java > ! src/share/classes/java/util/function/BiFunction.java > ! src/share/classes/java/util/function/BinaryOperator.java > ! src/share/classes/java/util/function/DoubleBinaryOperator.java > ! src/share/classes/java/util/function/DoubleBlock.java > ! src/share/classes/java/util/function/DoubleFunction.java > ! src/share/classes/java/util/function/DoubleUnaryOperator.java > ! src/share/classes/java/util/function/Function.java > ! src/share/classes/java/util/function/IntBinaryOperator.java > ! src/share/classes/java/util/function/IntBlock.java > ! src/share/classes/java/util/function/IntFunction.java > ! src/share/classes/java/util/function/IntUnaryOperator.java > ! src/share/classes/java/util/function/LongBinaryOperator.java > ! src/share/classes/java/util/function/LongBlock.java > ! src/share/classes/java/util/function/LongFunction.java > ! src/share/classes/java/util/function/LongUnaryOperator.java > ! src/share/classes/java/util/function/Predicate.java > ! src/share/classes/java/util/function/Predicates.java > > > From mike.duigou at oracle.com Mon Nov 26 18:12:40 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 26 Nov 2012 18:12:40 -0800 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces Message-ID: Hello all; In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. The patch to add parent interfaces and default methods can be found here: http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html Mike [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 From paul.sandoz at oracle.com Tue Nov 27 02:31:23 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 27 Nov 2012 10:31:23 +0000 Subject: hg: lambda/lambda/jdk: - remove debugging capture point Message-ID: <20121127103303.5AEC247B3B@hg.openjdk.java.net> Changeset: 87fc8b692437 Author: psandoz Date: 2012-11-27 11:30 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/87fc8b692437 - remove debugging capture point - consolidate throwing ISE into fail* methods ! src/share/classes/java/util/stream/AbstractPipeline.java From paul.sandoz at oracle.com Tue Nov 27 03:06:36 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 27 Nov 2012 11:06:36 +0000 Subject: hg: lambda/lambda/jdk: - move inner {Int}Node.SpinedList to outer {Int}SpinedList Message-ID: <20121127110659.716A447B3C@hg.openjdk.java.net> Changeset: a296f32dd813 Author: psandoz Date: 2012-11-27 12:04 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a296f32dd813 - move inner {Int}Node.SpinedList to outer {Int}SpinedList - added to stream and spliterator data sources ! src/share/classes/java/util/stream/op/FlatMapOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/Nodes.java + src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/primitive/IntNodes.java + src/share/classes/java/util/stream/primitive/IntSpinedList.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From maurizio.cimadamore at oracle.com Tue Nov 27 03:35:37 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 27 Nov 2012 11:35:37 +0000 Subject: hg: lambda/lambda/langtools: Fix: revert temporary changes to langtools build files Message-ID: <20121127113549.9633E47B3F@hg.openjdk.java.net> Changeset: e5380900874a Author: mcimadamore Date: 2012-11-27 11:34 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e5380900874a Fix: revert temporary changes to langtools build files Enhancement: expression lambda returning an expression statement should be void compatible This code did not work: Set = ... Runnable r = ()->s.add("Hello!"); //add returns boolean, while the descriptor for Runnable is void Now the above code works, as an expression statement (in the context of an expression lambda) is always void-compatible. ! makefiles/Makefile ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.java ! test/tools/javac/lambda/VoidCompatibility.out From scolebourne at joda.org Tue Nov 27 03:56:31 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 27 Nov 2012 11:56:31 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: On 27 November 2012 02:12, Mike Duigou wrote: > In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. > > Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. > > The patch to add parent interfaces and default methods can be found here: > > http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html Each of the default methods is formatted on a single line. I consider this to be bad style, they should be formatted as per "normal" methods: @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } It is vitally important to get this kind of formatting/style correct. Developers the world over will be copying what the style is in these classes. There is also no Javadoc on the default method override. In this case, passing a null to either parameter will result in an NPE. This should be documented. More generally, you/Oracle should define a standard form of words for describing what a default method does. Interfaces have not had them before, and their behaviour needs documenting (even if it seems obvious). /** * An operation upon two operands yielding a result. * The operands and the result are all of the same type. *

* The default implementation calls {@link operate(double,double)}, * throwing NullPointerException if either input is null. * * @param left the first operand, not null * @param left the first operand, not null * @return the result, not null */ @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } Stephen From maurizio.cimadamore at oracle.com Tue Nov 27 06:43:36 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 27 Nov 2012 14:43:36 +0000 Subject: hg: lambda/lambda/langtools: Conformance fixes: Message-ID: <20121127144341.A967447B43@hg.openjdk.java.net> Changeset: 0e5c0977f50b Author: mcimadamore Date: 2012-11-27 14:43 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0e5c0977f50b Conformance fixes: *) disallow static bound method references (i.e. new Foo()::staticBar) *) disallow static method references with parameterized qualifiers (i.e. Foo::staticBar) ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToInnerClass.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/sqe/methodReference/MethodRef1.java ! test/tools/javac/lambda/sqe/methodReference/SamConversion.java From brian.goetz at oracle.com Tue Nov 27 07:16:09 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 27 Nov 2012 10:16:09 -0500 Subject: Evolving interfaces: source/binary compatibility issues In-Reply-To: <50AF94D7.8070507@googlemail.com> References: <50AF94D7.8070507@googlemail.com> Message-ID: <50B4D939.5070801@oracle.com> Yes, this is a known risk. Note that this is not a new problem introduced by default methods; this risk has been around since day 1, in that adding a method to a superclass (such as AbstractList) carries this exact same risk. What is new is that we are turning down the conservatism knob on adding methods to commonly used supertypes. This is a tradeoff between making the platform more usable for everyone, and causing some source incompatibilities. Unless we're willing to freeze the platform in concrete (we're not), what we can do is try and reduce the surface area of potential conflicts. One way we've already done this is by not adding filter/map/etc to Collection, but instead adding a stream() method to Collection which is less likely to conflict. Conflicts are also more likely to occur on nilary methods; List.sort() is more likely to conflict than List.reduce(Supplier, BinaryOperator). Similarly, conflicts are more likely to occur on the "obvious" short names like "sort". The comment about Comparator.reverse() is well-taken and I'll bring that up in our next round of bikeshedding. On 11/23/2012 10:23 AM, Gernot Neppert wrote: > Hi all, > > when I browsed the Java 8 docs and found that java.util.List finally has > a method "void sort(Comparator comparator)", > I was quite happy at first. > Unfortunately, that bliss lasted only until I found that one of my own > implementations of java.util.List already has such a method - albeit > "protected". > This has at least two consequences: > > 1. I can't compile my old code against the JDK 8, since it tries to > implement an interface method with weaker access privileges. > > 2. Even worse: if I link my old compiled code against a JDK 8, it may > raise an "java.lang.IllegalAccessError" at Runtime, since code from the > new codebase may innociously call back my "sort" method via the interface. > > Here are some other methods that are likely to cause trouble, because > they are obvious extensions likely to be already present in user-code: > > java.util.Comparator.reverse() > > java.util.Collection.addAll(Iterable) > > Do you consider this a real danger or does it seem esoteric? > > > > > > > > From georgiy.rakov at oracle.com Tue Nov 27 08:00:38 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 27 Nov 2012 20:00:38 +0400 Subject: User control over splitting granularity while parallel processing In-Reply-To: <5093B596.2000100@oracle.com> References: <5093B266.2030806@oracle.com> <5093B596.2000100@oracle.com> Message-ID: <50B4E3A6.2@oracle.com> Hi Aleksey. The only useful thing I see is to enable user to specify computational resources to be excluded while processing pipelines or to assign particular set of resources to the given pipeline. I mean something like following: List cores = System.getCPUs(); Stream s1, s2; .... s1.cpuExclude(cores.get(0)).filter(f).map(m). .... s2.cpuAssign(cores.get(1), cores.get(2)).filter(f).map(m). where cpuExclude, cpuAssign return *this*. And some static methods controlling the default behavior: class System { ... public static List getDefaultParallelCPUs(); public static List setDefaultParallelCPUs(List cpus); //returns prior CPUs } Also system properties could be engaged for managing default behavior. What do you think? Georgiy. On 02.11.2012 15:59, Aleksey Shipilev wrote: > Hi Georgiy, > > On 11/02/2012 03:45 PM, Georgiy Rakov wrote: >> It seems to be useful because the computational complexity of supplied >> functors (predicates, blocks, ... , etc) is known by nobody but user >> who's created it. > Exactly. There is some freedom for automatic optimization though. > >> I wonder whether such means are going to be introduced. And if they are >> not why? > It is being discussed. If you have the concrete suggestions about the > API you would see useful, please shoot them here. > > -Aleksey. > From brian.goetz at oracle.com Tue Nov 27 08:32:19 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 27 Nov 2012 16:32:19 +0000 Subject: hg: lambda/lambda/jdk: Adjust lambda syntax in tests now that compiler restriction has been lifted on value-bearing bodies in void lambdas; remove tests of bound static method references now that these are disallowed Message-ID: <20121127163240.2B3B047B47@hg.openjdk.java.net> Changeset: a269130fad70 Author: briangoetz Date: 2012-11-27 11:32 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a269130fad70 Adjust lambda syntax in tests now that compiler restriction has been lifted on value-bearing bodies in void lambdas; remove tests of bound static method references now that these are disallowed ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/javac/MethodReferenceTestKinds.java ! test-ng/tests/org/openjdk/tests/separate/Compiler.java ! test-ng/tests/org/openjdk/tests/vm/FDSeparateCompilationTest.java From aleksey.shipilev at oracle.com Tue Nov 27 08:52:05 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Nov 2012 20:52:05 +0400 Subject: User control over splitting granularity while parallel processing In-Reply-To: <50B4E3A6.2@oracle.com> References: <5093B266.2030806@oracle.com> <5093B596.2000100@oracle.com> <50B4E3A6.2@oracle.com> Message-ID: <50B4EFB5.7010609@oracle.com> Hi Georgiy, On 11/27/2012 08:00 PM, Georgiy Rakov wrote: > The only useful thing I see is to enable user to specify computational > resources to be excluded while processing pipelines or to assign > particular set of resources to the given pipeline. At this point, you can only limit the number of workers in FJP serving the requests (which will have drastic impact on performance in lots of other places). > What do you think? I think this requires: a) the exposure of CPU layout to Java code, which is need for multitude of other stuff in JDK, including ProcessorLocals, NUMA-aware stuff, and whatnot. I don't think it would be ready for JDK8, we can consider that for JDK9 and retrofit the Stream API to leverage this Processor API. b) FJP to respect the affinity you describe, this probably is best solved by applying the affinity to worker threads via Processor API. Again, not in the scope of JDK8. Thanks, -Aleksey. From peter.levart at gmail.com Tue Nov 27 09:16:43 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 27 Nov 2012 18:16:43 +0100 Subject: User control over splitting granularity while parallel processing In-Reply-To: <5093B596.2000100@oracle.com> References: <5093B266.2030806@oracle.com> <5093B596.2000100@oracle.com> Message-ID: <50B4F57B.6030802@gmail.com> On 11/02/2012 12:59 PM, Aleksey Shipilev wrote: > Hi Georgiy, > > On 11/02/2012 03:45 PM, Georgiy Rakov wrote: >> It seems to be useful because the computational complexity of supplied >> functors (predicates, blocks, ... , etc) is known by nobody but user >> who's created it. > Exactly. There is some freedom for automatic optimization though. Either this, or just tune it for the "typical case" and provide a means to specify a "granularity factor" hint. For example a factor of 2.0 would try to make final splits twice as large as by default. The user will then use this to perform his own tuning. Regards, Peter > >> I wonder whether such means are going to be introduced. And if they are >> not why? > It is being discussed. If you have the concrete suggestions about the > API you would see useful, please shoot them here. > > -Aleksey. > > From georgiy.rakov at oracle.com Tue Nov 27 09:25:53 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 27 Nov 2012 21:25:53 +0400 Subject: Stream allMatch issue Message-ID: <50B4F7A1.2040406@oracle.com> Hello, the code below causes ConcurrentModificationException to be thrown with following stack trace: Exception in thread "main" java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:818) at java.util.ArrayList$Itr.next(ArrayList.java:790) at AllMatchBehaviour.main(AllMatchBehaviour.java:34) Obviously the emphasized piece of code is one part of the cause (see below). import java.util.ArrayList; import java.util.Arrays; import java.util.List; import java.util.functions.Predicate; public class AllMatchBehavior { public static void main(String[] args) { ArrayList calledObjects = new ArrayList<>(); List streamContent = new ArrayList<>(); for (int i = 0; i < 10000; ++i) { streamContent.add(i); } Predicate p = i -> { synchronized (calledObjects) { calledObjects.add(i); } return i < 5000; }; boolean result = Arrays.parallel(streamContent.toArray(new Integer[]{})).allMatch(p); String asStr = ""; * for (Integer i : calledObjects) {* * asStr += " " + i;* * }* System.out.println("called objects: " + asStr); } } I could guess that exception is thrown because some stream chunks are still processed after the result have been received from allMatch. Is such behavior considered to be faulty? Please give your comments. The same things happen to noneMatch and anyMatch methods by the way. The source code is attached for your convenience. Thanks, Georgiy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AllMatchBehavior.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121127/d5ac8919/AllMatchBehavior.java From mike.duigou at oracle.com Tue Nov 27 09:32:06 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 27 Nov 2012 09:32:06 -0800 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > On 27 November 2012 02:12, Mike Duigou wrote: >> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >> >> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >> >> The patch to add parent interfaces and default methods can be found here: >> >> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html > > Each of the default methods is formatted on a single line. I consider > this to be bad style, they should be formatted as per "normal" > methods: > @Override > public default Double operate(Double left, Double right) { > return operateAsDouble((double) left, (double) right); > } > > It is vitally important to get this kind of formatting/style correct. > Developers the world over will be copying what the style is in these > classes. I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? > There is also no Javadoc on the default method override. That was intentional. The goal was to inherit from the original definition. > In this case, > passing a null to either parameter will result in an NPE. This should > be documented. Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. My inclination is to add the description regarding null behaviour to the class javadoc at the same point where it's described that IntBlock can be used for Block. ie. This is the primitive type specialization of Block for int and also may be used as a Block provided that the parameter to accept(Integer) always is non-null. > > More generally, you/Oracle should define a standard form of words for > describing what a default method does. Interfaces have not had them > before, and their behaviour needs documenting (even if it seems > obvious). > > /** > * An operation upon two operands yielding a result. > * The operands and the result are all of the same type. > *

> * The default implementation calls {@link operate(double,double)}, > * throwing NullPointerException if either input is null. > * > * @param left the first operand, not null > * @param left the first operand, not null > * @return the result, not null > */ > @Override > public default Double operate(Double left, Double right) { > return operateAsDouble((double) left, (double) right); > } > > Stephen > From brian.goetz at oracle.com Tue Nov 27 09:47:43 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 27 Nov 2012 12:47:43 -0500 Subject: Stream allMatch issue In-Reply-To: <50B4F7A1.2040406@oracle.com> References: <50B4F7A1.2040406@oracle.com> Message-ID: <50B4FCBF.5090108@oracle.com> I think it is reasonable for users to expect that when the bulk operation returns, we are finished with the stream and its lambdas. So, I would count this as an error. On 11/27/2012 12:25 PM, Georgiy Rakov wrote: > Hello, > > the code below causes ConcurrentModificationException to be thrown with > following stack trace: > > Exception in thread "main" java.util.ConcurrentModificationException > at > java.util.ArrayList$Itr.checkForComodification(ArrayList.java:818) > at java.util.ArrayList$Itr.next(ArrayList.java:790) > at AllMatchBehaviour.main(AllMatchBehaviour.java:34) > > Obviously the emphasized piece of code is one part of the cause (see > below). > > import java.util.ArrayList; > import java.util.Arrays; > import java.util.List; > import java.util.functions.Predicate; > > public class AllMatchBehavior { > public static void main(String[] args) { > ArrayList calledObjects = new ArrayList<>(); > List streamContent = new ArrayList<>(); > for (int i = 0; i < 10000; ++i) { > streamContent.add(i); > } > > Predicate p = i -> { > synchronized (calledObjects) { > calledObjects.add(i); > } > return i < 5000; > }; > > boolean result = Arrays.parallel(streamContent.toArray(new > Integer[]{})).allMatch(p); > > String asStr = ""; > * for (Integer i : calledObjects) {* > * asStr += " " + i;* > * }* > System.out.println("called objects: " + asStr); > } > } > > I could guess that exception is thrown because some stream chunks are > still processed after the result have been received from allMatch. > Is such behavior considered to be faulty? Please give your comments. > > The same things happen to noneMatch and anyMatch methods by the way. > > The source code is attached for your convenience. > > Thanks, Georgiy. > > > From eric.caspole at amd.com Tue Nov 27 09:51:33 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 27 Nov 2012 12:51:33 -0500 Subject: Lambda does not compile against JDK8 binary snapshot as boot JDK In-Reply-To: <50A512DC.4000205@univ-mlv.fr> References: <50A512DC.4000205@univ-mlv.fr> Message-ID: <50B4FDA5.30905@amd.com> Hi everybody, As Remi said, this problem does not happen anymore, but I fixed the javac imports anyway which seemed worthwhile. I am not sure if this is the right list for javac mods but maybe you can suggest how to proceed. http://cr.openjdk.java.net/~ecaspole/javac_imports/webrev.00/ Thanks, Eric On 11/15/2012 11:05 AM, Remi Forax wrote: > On 11/15/2012 04:55 PM, Caspole, Eric wrote: >> Hi lambda people, >> I seem to have found a problem when using the last week's lamdba binary snapshot as the boot JDK for the build. The build works fine if the boot JDK is 7u9. I don't think I ever tried this combination before. >> >> Looks like there is a new java.util.Mapping in 8. So I think the guilty thing is use of java.util.* in src/share/classes/com/sun/tools/javac/code/Types.java? >> >> 26 package com.sun.tools.javac.code; >> 27 >> 28 import java.lang.ref.SoftReference; >> 29 import java.util.*; >> 30 >> >> Regards, >> Eric > > Classical import * bug. > BTW, java.util.Mapping was removed very recently, so it should work again. > > R?mi > >> >> Here is my build output: >> >> ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ java -version >> openjdk version "1.8.0-ea" >> OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) >> OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) >> >> ==================================================== >> A new configuration has been successfully created in >> /home/ecaspole/Documents/121115/lambda/build/linux-x86_64-normal-server-release >> using default settings. >> >> Configuration summary: >> * Debug level: release >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 >> * Boot JDK: /opt/jdk1.8.0 >> >> Build performance summary: >> * Cores to use: 4 >> * Memory limit: 7986 MB >> * ccache status: not installed (consider installing) >> >> ... >> >> ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ make images >> Building OpenJDK for target 'images' in configuration 'linux-x86_64-normal-server-release' >> >> >> ######################################################################## >> ######################################################################## >> ##### Entering langtools for target(s) all ##### >> ######################################################################## >> >> Compiling 2 files for BUILD_TOOLS >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous >> private final Mapping lowerBoundMapping = new Mapping("lowerBound") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous >> private Mapping elemTypeFun = new Mapping ("elemTypeFun") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous >> private Mapping erasureFun = new Mapping ("erasure") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous >> private Mapping erasureRecFun = new Mapping ("erasureRecursive") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous >> static private Mapping newInstanceFun = new Mapping("newInstanceFun") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous >> private final Mapping lowerBoundMapping = new Mapping("lowerBound") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous >> private Mapping elemTypeFun = new Mapping ("elemTypeFun") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous >> private Mapping erasureFun = new Mapping ("erasure") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous >> private Mapping erasureRecFun = new Mapping ("erasureRecursive") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous >> static private Mapping newInstanceFun = new Mapping("newInstanceFun") { >> ^ >> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >> 10 errors >> make[1]: *** No rule to make target `all', needed by `default'. Stop. >> make: *** [langtools-only] Error 2 >> >> > > > From scolebourne at joda.org Tue Nov 27 09:55:36 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 27 Nov 2012 17:55:36 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> Message-ID: On 27 November 2012 17:32, Mike Duigou wrote: >> It is vitally important to get this kind of formatting/style correct. > >> Developers the world over will be copying what the style is in these >> classes. > > I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? These are just methods. There isn't anything different about them other than the default keyword. They act as per a method on an abstract class in most of the ways that a developer cares about. They should therefore look like a normal method. Normal methods are almost always formatted over multiple lines in java/OpenJDK: default void foo() { // body } Default method implementations are not lambdas, so no logic from lambda syntax formatting applies here. >> There is also no Javadoc on the default method override. > That was intentional. The goal was to inherit from the original definition. But where in the specification does it say what the default method implementation does? Sure, you can argue it is obvious, but thats not really sufficient IMO. I proposed a clear way of expressing it in my last email. I really want to see a form of words, such as "The default implementation ..." or similar. That way, the rest of the world can copy the form of words, saving learning and effort in comprehension. It might be argued that a separate Javadoc tag could describe what the default implementation does, but since methods in abtsract classes don't have that, it doesn't seem necessary. >> In this case, >> passing a null to either parameter will result in an NPE. This should >> be documented. > > Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. I don't accept that how it may be used in lambda is an excuse for lack of documentation/specification. These are regular JDK interfaces that can be used by anybody in any way. BTW, my Javadoc standards are here if you didn't see it http://blog.joda.org/2012/11/javadoc-coding-standards.html Stephen From brian.goetz at oracle.com Tue Nov 27 09:59:44 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 27 Nov 2012 17:59:44 +0000 Subject: hg: lambda/lambda/jdk: Test that .sequential() is lazy Message-ID: <20121127180005.C297847B4B@hg.openjdk.java.net> Changeset: 10b4ad05eafe Author: briangoetz Date: 2012-11-27 12:59 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/10b4ad05eafe Test that .sequential() is lazy ! test-ng/tests/org/openjdk/tests/java/util/stream/CollectionModifyStreamTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java From david.lloyd at redhat.com Tue Nov 27 10:19:15 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 27 Nov 2012 12:19:15 -0600 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B4FBA0.9060204@redhat.com> References: <50B4FBA0.9060204@redhat.com> Message-ID: <50B50423.3000406@redhat.com> On 11/27/2012 11:42 AM, David M. Lloyd wrote: > On 11/27/2012 05:56 AM, Stephen Colebourne wrote: >> There is also no Javadoc on the default method override. In this case, >> passing a null to either parameter will result in an NPE. This should >> be documented. >> >> More generally, you/Oracle should define a standard form of words for >> describing what a default method does. Interfaces have not had them >> before, and their behaviour needs documenting (even if it seems >> obvious). > > I think we could/should introduce a JavaDoc taglet to support default > method implementations specifically. For example: > > /** > * ... > * @default Calls operate(double, double) throwing NPE if either input > is null. > */ > > IDEs can use their existing inspection infrastructure to warn if a > default method implementation exists without a corresponding @default > taglet, just as they might for a missing @param/@return/@throws etc. Somehow reply-to-list has failed me, so I'm sending this to the right list manually... -- - DML From pbenedict at apache.org Tue Nov 27 10:23:18 2012 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 27 Nov 2012 12:23:18 -0600 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B50423.3000406@redhat.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> Message-ID: Default methods are interface methods after all. There needs to be an explicit stated contract what the default method (and any overriding method) must adhere to for it to function as expected. Paul On Tue, Nov 27, 2012 at 12:19 PM, David M. Lloyd wrote: > On 11/27/2012 11:42 AM, David M. Lloyd wrote: > > On 11/27/2012 05:56 AM, Stephen Colebourne wrote: > >> There is also no Javadoc on the default method override. In this case, > >> passing a null to either parameter will result in an NPE. This should > >> be documented. > >> > >> More generally, you/Oracle should define a standard form of words for > >> describing what a default method does. Interfaces have not had them > >> before, and their behaviour needs documenting (even if it seems > >> obvious). > > > > I think we could/should introduce a JavaDoc taglet to support default > > method implementations specifically. For example: > > > > /** > > * ... > > * @default Calls operate(double, double) throwing NPE if either input > > is null. > > */ > > > > IDEs can use their existing inspection infrastructure to warn if a > > default method implementation exists without a corresponding @default > > taglet, just as they might for a missing @param/@return/@throws etc. > > Somehow reply-to-list has failed me, so I'm sending this to the right > list manually... > > -- > - DML > > From brian.goetz at oracle.com Tue Nov 27 10:36:14 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 27 Nov 2012 13:36:14 -0500 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> Message-ID: <50B5081E.7080002@oracle.com> I think what Stephen meant (and I agree) is that in addition to defining the contract for the interface method, there should be a standardized place (or at least convention) for implementation notes about the default implementation. For example, the default implementation of List.parallelSort() might in fact be a serial sort. While that conforms to the spec ("sort the list"), it may well be a crappy implementation, and there should be a sensible place to put such information. On 11/27/2012 1:23 PM, Paul Benedict wrote: > Default methods are interface methods after all. There needs to be an > explicit stated contract what the default method (and any overriding > method) must adhere to for it to function as expected. > > Paul > > On Tue, Nov 27, 2012 at 12:19 PM, David M. Lloyd wrote: > >> On 11/27/2012 11:42 AM, David M. Lloyd wrote: >>> On 11/27/2012 05:56 AM, Stephen Colebourne wrote: >>>> There is also no Javadoc on the default method override. In this case, >>>> passing a null to either parameter will result in an NPE. This should >>>> be documented. >>>> >>>> More generally, you/Oracle should define a standard form of words for >>>> describing what a default method does. Interfaces have not had them >>>> before, and their behaviour needs documenting (even if it seems >>>> obvious). >>> >>> I think we could/should introduce a JavaDoc taglet to support default >>> method implementations specifically. For example: >>> >>> /** >>> * ... >>> * @default Calls operate(double, double) throwing NPE if either input >>> is null. >>> */ >>> >>> IDEs can use their existing inspection infrastructure to warn if a >>> default method implementation exists without a corresponding @default >>> taglet, just as they might for a missing @param/@return/@throws etc. >> >> Somehow reply-to-list has failed me, so I'm sending this to the right >> list manually... >> >> -- >> - DML >> >> > From jonathan.gibbons at oracle.com Tue Nov 27 10:56:41 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 27 Nov 2012 10:56:41 -0800 Subject: Lambda does not compile against JDK8 binary snapshot as boot JDK In-Reply-To: <50B4FDA5.30905@amd.com> References: <50A512DC.4000205@univ-mlv.fr> <50B4FDA5.30905@amd.com> Message-ID: <50B50CE9.8070501@oracle.com> Eric, Please post a request for review for your patch on compiler-dev at openjdk.java.net. -- Jon On 11/27/2012 09:51 AM, Eric Caspole wrote: > Hi everybody, > As Remi said, this problem does not happen anymore, but I fixed the > javac imports anyway which seemed worthwhile. I am not sure if this is > the right list for javac mods but maybe you can suggest how to proceed. > > http://cr.openjdk.java.net/~ecaspole/javac_imports/webrev.00/ > > Thanks, > Eric > > > > On 11/15/2012 11:05 AM, Remi Forax wrote: >> On 11/15/2012 04:55 PM, Caspole, Eric wrote: >>> Hi lambda people, >>> I seem to have found a problem when using the last week's lamdba binary snapshot as the boot JDK for the build. The build works fine if the boot JDK is 7u9. I don't think I ever tried this combination before. >>> >>> Looks like there is a new java.util.Mapping in 8. So I think the guilty thing is use of java.util.* in src/share/classes/com/sun/tools/javac/code/Types.java? >>> >>> 26 package com.sun.tools.javac.code; >>> 27 >>> 28 import java.lang.ref.SoftReference; >>> 29 import java.util.*; >>> 30 >>> >>> Regards, >>> Eric >> Classical import * bug. >> BTW, java.util.Mapping was removed very recently, so it should work again. >> >> R?mi >> >>> Here is my build output: >>> >>> ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ java -version >>> openjdk version "1.8.0-ea" >>> OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) >>> OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) >>> >>> ==================================================== >>> A new configuration has been successfully created in >>> /home/ecaspole/Documents/121115/lambda/build/linux-x86_64-normal-server-release >>> using default settings. >>> >>> Configuration summary: >>> * Debug level: release >>> * JDK variant: normal >>> * JVM variants: server >>> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 >>> * Boot JDK: /opt/jdk1.8.0 >>> >>> Build performance summary: >>> * Cores to use: 4 >>> * Memory limit: 7986 MB >>> * ccache status: not installed (consider installing) >>> >>> ... >>> >>> ecaspole at ecaspole-desktop:~/Documents/121115/lambda/common/makefiles$ make images >>> Building OpenJDK for target 'images' in configuration 'linux-x86_64-normal-server-release' >>> >>> >>> ######################################################################## >>> ######################################################################## >>> ##### Entering langtools for target(s) all ##### >>> ######################################################################## >>> >>> Compiling 2 files for BUILD_TOOLS >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous >>> private final Mapping lowerBoundMapping = new Mapping("lowerBound") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous >>> private Mapping elemTypeFun = new Mapping ("elemTypeFun") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous >>> private Mapping erasureFun = new Mapping ("erasure") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous >>> private Mapping erasureRecFun = new Mapping ("erasureRecursive") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous >>> static private Mapping newInstanceFun = new Mapping("newInstanceFun") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1519: error: reference to Mapping is ambiguous >>> private final Mapping lowerBoundMapping = new Mapping("lowerBound") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1633: error: reference to Mapping is ambiguous >>> private Mapping elemTypeFun = new Mapping ("elemTypeFun") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1943: error: reference to Mapping is ambiguous >>> private Mapping erasureFun = new Mapping ("erasure") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:1947: error: reference to Mapping is ambiguous >>> private Mapping erasureRecFun = new Mapping ("erasureRecursive") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> /home/ecaspole/Documents/121115/lambda/langtools/src/share/classes/com/sun/tools/javac/code/Types.java:2802: error: reference to Mapping is ambiguous >>> static private Mapping newInstanceFun = new Mapping("newInstanceFun") { >>> ^ >>> both class com.sun.tools.javac.code.Type.Mapping in Type and interface java.util.Mapping in java.util match >>> 10 errors >>> make[1]: *** No rule to make target `all', needed by `default'. Stop. >>> make: *** [langtools-only] Error 2 >>> >>> >> >> > From brian.goetz at oracle.com Tue Nov 27 13:42:44 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 27 Nov 2012 21:42:44 +0000 Subject: hg: lambda/lambda/jdk: More Spliterator test code; set correct flags in Collection.stream(); first part of spliterator implementation for arbitrary iterators Message-ID: <20121127214306.11BEA47B53@hg.openjdk.java.net> Changeset: 956b0f5d580b Author: briangoetz Date: 2012-11-27 16:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/956b0f5d580b More Spliterator test code; set correct flags in Collection.stream(); first part of spliterator implementation for arbitrary iterators ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterators.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java From michael.hixson at gmail.com Tue Nov 27 17:48:44 2012 From: michael.hixson at gmail.com (Michael Hixson) Date: Tue, 27 Nov 2012 17:48:44 -0800 Subject: When lambdas become objects Message-ID: Hello, I have a few questions about when lambdas are converted into objects, and how often. 1. Non-capturing, but inferring generic type: public static Predicate nonNull() { return t -> t != null; } Does every invocation of nonNull() return the same Predicate instance? 2. Capturing methods or member variables from the enclosing class: class FunDetector { private boolean isFun(Activity activity) { ... } public Predicate isFunAcitivity() { return activity -> isFun(activity); } } Does every invocation of isFunActivity() return a separate Predicate instance? Or, would a given FunDetector instance always return the same Predicate instance? 3. Lambda within a lambda, both capturing a variable from the calling method: (This example uses the ComparisonChain class from Guava: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/index.html?com/google/common/collect/ComparisonChain.html) void weirdSort(List list, boolean flag) { list.sort((a, b) -> ComparisonChain.start() .compare( a.charAt(0), b.charAt(0), (x, y) -> Character.compare( flag ? Character.toLowerCase(x) : Character.toTitleCase(x), flag ? Character.toLowerCase(y) : Character.toTitleCase(y))) .compare( flag ? a.length() : a.hashCode(), flag ? b.length() : b.hashCode()) .result()); } Does every invocation of weirdSort(list, flag) cause the creation of exactly two Comparators? Or does every comparison made by the outer Comparator lambda cause the creation of an additional Comparator (for the inner lambda)? -Michael From brian.goetz at oracle.com Tue Nov 27 19:38:44 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 27 Nov 2012 22:38:44 -0500 Subject: When lambdas become objects In-Reply-To: References: Message-ID: <50B58744.8030505@oracle.com> > I have a few questions about when lambdas are converted into objects, and > how often. > > 1. Non-capturing, but inferring generic type: > > public static Predicate nonNull() { > return t -> t != null; > } At first capture, a single instance is created; thereafter, the same instance may be returned again on next capture. > Does every invocation of nonNull() return the same Predicate instance? Implementations are permitted to do so, and ours (mostly) does. But this is not guaranteed and you should not assume that it does. > 2. Capturing methods or member variables from the enclosing class: > > class FunDetector { > private boolean isFun(Activity activity) { ... } > > public Predicate isFunAcitivity() { > return activity -> isFun(activity); > } > } > > Does every invocation of isFunActivity() return a separate Predicate > instance? Or, would a given FunDetector instance always return the same > Predicate instance? Because isFun is an instance method, you have to capture the receiver variable 'this', so each capture is likely to result in a new object. (Note you could have written this both more compactly and more explicitly as "return this::isFun".) > 3. Lambda within a lambda, both capturing a variable from the calling > method: > > (This example uses the ComparisonChain class from Guava: > http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/index.html?com/google/common/collect/ComparisonChain.html) > > void weirdSort(List list, boolean flag) { > list.sort((a, b) -> ComparisonChain.start() > .compare( > a.charAt(0), > b.charAt(0), > (x, y) -> Character.compare( > flag ? Character.toLowerCase(x) : Character.toTitleCase(x), > flag ? Character.toLowerCase(y) : Character.toTitleCase(y))) > .compare( > flag ? a.length() : a.hashCode(), > flag ? b.length() : b.hashCode()) > .result()); > } > > Does every invocation of weirdSort(list, flag) cause the creation of > exactly two Comparators? Or does every comparison made by the outer > Comparator lambda cause the creation of an additional Comparator (for the > inner lambda)? The latter. The inner lambda is captured when the outer lambda is executed, and the inner lambda captures the 'flag' variable. You could rewrite it to not do so, by pulling the inner lambda out to the top level of weirdSort, and capturing that. From brian.goetz at oracle.com Tue Nov 27 20:21:39 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 28 Nov 2012 04:21:39 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121128042215.1701647B5E@hg.openjdk.java.net> Changeset: cb93b3229345 Author: briangoetz Date: 2012-11-27 18:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb93b3229345 More spliterator tests and fixes ! src/share/classes/java/util/stream/op/SpinedList.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java Changeset: 44fd54f2a41d Author: briangoetz Date: 2012-11-27 23:21 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/44fd54f2a41d Specialized implementations of Collection.forEach, Collection.removeAll, List.replaceAll, List.sort, Map.replaceAll, Map.forEach in Vector, ArrayList, CopyOnWriteArrayList Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java + test-ng/tests/org/openjdk/tests/java/util/CollectionTest.java ! test-ng/tests/org/openjdk/tests/java/util/IterableTest.java + test-ng/tests/org/openjdk/tests/java/util/ListTest.java + test-ng/tests/org/openjdk/tests/java/util/MapTest.java From aruld at acm.org Tue Nov 27 20:29:41 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Tue, 27 Nov 2012 18:29:41 -1000 Subject: cannot find symbol on identity operation in lambda Message-ID: Arrays.asList(1, 2, 3, 4, 5).stream().map(i -> i).sum();//compile error java: cannot find symbol symbol: method sum() location: interface java.util.stream.Stream Arrays.asList(1, 2, 3, 4, 5).stream().map((IntFunction)i -> i).sum();//works fine with a cast on identity Arrays.asList(1, 2, 3, 4, 5).stream().map(i -> i * 2).sum();//works fine without a cast, but not identity Is this expected behavior on an identity operation in a lambda and requires explicit typing? -Arul From michael.hixson at gmail.com Tue Nov 27 20:34:50 2012 From: michael.hixson at gmail.com (Michael Hixson) Date: Tue, 27 Nov 2012 20:34:50 -0800 Subject: When lambdas become objects In-Reply-To: <50B58744.8030505@oracle.com> References: <50B58744.8030505@oracle.com> Message-ID: Thank you, that clears things up a lot. >> Does every invocation of nonNull() return the same Predicate instance? > > > Implementations are permitted to do so, and ours (mostly) does. But this is not guaranteed and you should not assume that it does. When you say I shouldn't assume that it does, you mean that I shouldn't rely on that behavior for my program's correctness, right? I would like to be able to assume it performs this way because the code is cleaner than the strategy used in the real j.u.f.Predicates.nonNull -- returning a casted static Predicate. >> Does every invocation of isFunActivity() return a separate Predicate >> instance? Or, would a given FunDetector instance always return the same >> Predicate instance? > > > Because isFun is an instance method, you have to capture the receiver variable 'this', so each capture is likely to result in a new object. (Note you could have written this both more compactly and more explicitly as "return this::isFun".) Are there plans to eventually do some sort of instance-level caching & reuse of these lambdas, when the lambdas only capture 'this', either later in the JDK8 development cycle or else in a future version of Java? I've found that kind of lambda to be extremely common in the code I ported. I realize I could convert the inline lambdas to member variables to avoid the extra objects if I wanted to. I probably wouldn't bother (because the inline versions tend to be more readable), but if you told me a near-future version of Java would have this 'this'-capturing-lambda-cache optimization then I wouldn't think about the issue at all. >> Does every invocation of weirdSort(list, flag) cause the creation of >> exactly two Comparators? Or does every comparison made by the outer >> Comparator lambda cause the creation of an additional Comparator (for the >> inner lambda)? > > > The latter. The inner lambda is captured when the outer lambda is executed, and the inner lambda captures the 'flag' variable. > > You could rewrite it to not do so, by pulling the inner lambda out to the top level of weirdSort, and capturing that. > Right, makes sense. -Michael From brian.goetz at oracle.com Tue Nov 27 21:03:18 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 28 Nov 2012 00:03:18 -0500 Subject: cannot find symbol on identity operation in lambda In-Reply-To: References: Message-ID: <50B59B16.3030101@oracle.com> The problem is that the type of the stream returned by map() is Stream, not IntStream. If you wanted an IntStream, you'd want to explicitly convert to ints: ...stream().map(i -> (int) i).sum() Given the overloaded map methods: map(T -> T) and map(T -> int) the former is a more applicable match for i->i than the latter, since it does not require unboxing. On 11/27/2012 11:29 PM, Arul Dhesiaseelan wrote: > Arrays.asList(1, 2, 3, 4, 5).stream().map(i -> i).sum();//compile error > > java: cannot find symbol > symbol: method sum() > location: interface java.util.stream.Stream > > > Arrays.asList(1, 2, 3, 4, 5).stream().map((IntFunction)i -> > i).sum();//works fine with a cast on identity > Arrays.asList(1, 2, 3, 4, 5).stream().map(i -> i * 2).sum();//works fine > without a cast, but not identity > > Is this expected behavior on an identity operation in a lambda and requires > explicit typing? > > -Arul > From brian.goetz at oracle.com Tue Nov 27 21:05:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 28 Nov 2012 00:05:57 -0500 Subject: When lambdas become objects In-Reply-To: References: <50B58744.8030505@oracle.com> Message-ID: <50B59BB5.5040508@oracle.com> >> Implementations are permitted to do so, and ours (mostly) does. But this is not guaranteed and you should not assume that it does. > > When you say I shouldn't assume that it does, you mean that I > shouldn't rely on that behavior for my program's correctness, right? Correct. >>> Does every invocation of isFunActivity() return a separate Predicate >>> instance? Or, would a given FunDetector instance always return the same >>> Predicate instance? >> >> Because isFun is an instance method, you have to capture the receiver variable 'this', so each capture is likely to result in a new object. (Note you could have written this both more compactly and more explicitly as "return this::isFun".) > > Are there plans to eventually do some sort of instance-level caching & > reuse of these lambdas, when the lambdas only capture 'this', either > later in the JDK8 development cycle or else in a future version of > Java? It's definitely out of scope for 8. While its possible we might consider things like this in the future, realistically there are much higher-leverage optimizations where we'd likely put our efforts first. (Such as, reducing the cost of lambda capture in the first place.) From talden at gmail.com Wed Nov 28 00:09:42 2012 From: talden at gmail.com (Talden) Date: Wed, 28 Nov 2012 21:09:42 +1300 Subject: cannot find symbol on identity operation in lambda In-Reply-To: <50B59B16.3030101@oracle.com> References: <50B59B16.3030101@oracle.com> Message-ID: On Wed, Nov 28, 2012 at 6:03 PM, Brian Goetz wrote: > The problem is that the type of the stream returned by map() is > Stream, not IntStream. > > If you wanted an IntStream, you'd want to explicitly convert to ints: > > ...stream().map(i -> (int) i).sum() > Would it be correct (and possibly more expressive) to use a method reference for the unboxing in this case? ...stream().map(Integer::intValue).sum(); (I'm aware you were really illustrating why it didn't resolve to Integer -> int but thought it worth noting the another representation of the solution) -- Aaron Scott-Boddendijk From maurizio.cimadamore at oracle.com Wed Nov 28 02:32:02 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 28 Nov 2012 10:32:02 +0000 Subject: hg: lambda/lambda/langtools: Fix: Add extra checks when lambda/method ref is converted to intersection type Message-ID: <20121128103215.E2D0947B6F@hg.openjdk.java.net> Changeset: 7fa8e7c02baa Author: mcimadamore Date: 2012-11-28 10:31 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7fa8e7c02baa Fix: Add extra checks when lambda/method ref is converted to intersection type A lambda/methdod reference can be converted to an intersection type provided that: *) All types in the intersection are interface types *) The first type of the intersection is a functional interface *) The additional bounds of the intersection are marker interfaces ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java From forax at univ-mlv.fr Wed Nov 28 03:36:31 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Nov 2012 12:36:31 +0100 Subject: When lambdas become objects In-Reply-To: <50B59BB5.5040508@oracle.com> References: <50B58744.8030505@oracle.com> <50B59BB5.5040508@oracle.com> Message-ID: <50B5F73F.70809@univ-mlv.fr> On 11/28/2012 06:05 AM, Brian Goetz wrote: >>> Implementations are permitted to do so, and ours (mostly) does. But this is not guaranteed and you should not assume that it does. >> When you say I shouldn't assume that it does, you mean that I >> shouldn't rely on that behavior for my program's correctness, right? > Correct. Technically the implementation may create two lambda objects if two threads reach at the same time the code that creates the lambda object once but the implementation will always return only one of the two. Because creating a lambda object has no side effect it's not a problem. That's a reason why we don't support lambda that implements abstract class, because in that case, the constructor of the abstract class should have been called twice. > >>>> Does every invocation of isFunActivity() return a separate Predicate >>>> instance? Or, would a given FunDetector instance always return the same >>>> Predicate instance? >>> Because isFun is an instance method, you have to capture the receiver variable 'this', so each capture is likely to result in a new object. (Note you could have written this both more compactly and more explicitly as "return this::isFun".) >> Are there plans to eventually do some sort of instance-level caching & >> reuse of these lambdas, when the lambdas only capture 'this', either >> later in the JDK8 development cycle or else in a future version of >> Java? > It's definitely out of scope for 8. While its possible we might > consider things like this in the future, realistically there are much > higher-leverage optimizations where we'd likely put our efforts first. > (Such as, reducing the cost of lambda capture in the first place.) > yes, caching objects is so 2000 :) There are better optimizations based on the idea that the VM should not create the lambda object if not necessary, so a call to the lambda method through the lambda object will be replaced by a direct call to the lambda method without creating the lambda object, reducing the cost of the lambda capture to zero. R?mi From maurizio.cimadamore at oracle.com Wed Nov 28 06:14:59 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 28 Nov 2012 14:14:59 +0000 Subject: hg: lambda/lambda/langtools: Conformance fix: Add support for generic functional descriptors Message-ID: <20121128141504.A160D47B74@hg.openjdk.java.net> Changeset: c72ca936299c Author: mcimadamore Date: 2012-11-28 14:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c72ca936299c Conformance fix: Add support for generic functional descriptors A generic functional descriptor is a valid target for a method reference. The following code now compiles: interface F { void m(X x); } class Test { void g(Z z) { ... } void test() { F f = this::g; f.m(1); //ok X inferred as Integer f.m(""); //ok X inferred as String } } Note: generic methods are still _not_ legal target for lambda expressions, as per EDR. ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out From paul.sandoz at oracle.com Wed Nov 28 06:42:14 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 28 Nov 2012 14:42:14 +0000 Subject: hg: lambda/lambda/jdk: - rename {Int}NodeBuilder/{Int}SpinedList.forEachUpdate to replaceAll Message-ID: <20121128144235.071DB47B77@hg.openjdk.java.net> Changeset: 1cc041212527 Author: psandoz Date: 2012-11-28 15:41 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1cc041212527 - rename {Int}NodeBuilder/{Int}SpinedList.forEachUpdate to replaceAll Synchronizes with recent method additions to the collections API. - remove {Int}NodeBuilder.Fixed - synchronize IntSpinedList spliterator impl with SpinedList impl ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/primitive/IntNodeBuilder.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSpinedList.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java From mcnepp02 at googlemail.com Wed Nov 28 06:54:20 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Wed, 28 Nov 2012 15:54:20 +0100 Subject: Simplified version of Stream.fold? Message-ID: Hello, I propose to add a simplified version of Stream.fold. The current "fold" version is very sophisticated and covers all possible scenarios, but my experience with a similar expression-driven framework indicates that a simpler version suffices in the vast majority of usecases: U fold(U base, Combiner reducer); Note that this would make T reduce(T base, BinaryOperator op); redundant, so it could possible be removed from the interface. example: int totalOrders = customers.stream().fold(0, (s, c) -> s + c.getOrders()); As a sidenote, I'm curious why wildcard types on the Functor arguments have been used in some, but not all of Stream's methods. "fold" and "reduce", for example, do not use wildcard arguments, whereas "reduceBy" uses them to its advantage. From zhong.j.yu at gmail.com Wed Nov 28 07:18:42 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 28 Nov 2012 09:18:42 -0600 Subject: When lambdas become objects In-Reply-To: References: <50B58744.8030505@oracle.com> Message-ID: On Tue, Nov 27, 2012 at 10:34 PM, Michael Hixson wrote: > Thank you, that clears things up a lot. > >>> Does every invocation of nonNull() return the same Predicate instance? >> >> >> Implementations are permitted to do so, and ours (mostly) does. But this is not guaranteed and you should not assume that it does. > > When you say I shouldn't assume that it does, you mean that I > shouldn't rely on that behavior for my program's correctness, right? > I would like to be able to assume it performs this way because the > code is cleaner than the strategy used in the real > j.u.f.Predicates.nonNull -- returning a casted static > Predicate. > >>> Does every invocation of isFunActivity() return a separate Predicate >>> instance? Or, would a given FunDetector instance always return the same >>> Predicate instance? >> >> >> Because isFun is an instance method, you have to capture the receiver variable 'this', so each capture is likely to result in a new object. (Note you could have written this both more compactly and more explicitly as "return this::isFun".) > > Are there plans to eventually do some sort of instance-level caching & > reuse of these lambdas, when the lambdas only capture 'this', either > later in the JDK8 development cycle or else in a future version of > Java? If the caching increases object size, it's a big concern. > I've found that kind of lambda to be extremely common in the code I > ported. I realize I could convert the inline lambdas to member > variables to avoid the extra objects if I wanted to. I probably > wouldn't bother (because the inline versions tend to be more > readable), but if you told me a near-future version of Java would have > this 'this'-capturing-lambda-cache optimization then I wouldn't think > about the issue at all. > >>> Does every invocation of weirdSort(list, flag) cause the creation of >>> exactly two Comparators? Or does every comparison made by the outer >>> Comparator lambda cause the creation of an additional Comparator (for the >>> inner lambda)? >> >> >> The latter. The inner lambda is captured when the outer lambda is executed, and the inner lambda captures the 'flag' variable. >> >> You could rewrite it to not do so, by pulling the inner lambda out to the top level of weirdSort, and capturing that. >> > > Right, makes sense. > > -Michael > From brian.goetz at oracle.com Wed Nov 28 10:30:12 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 28 Nov 2012 18:30:12 +0000 Subject: hg: lambda/lambda/jdk: Add static min, max, sum methods to primitive numeric wrappers, and and/or/xor to Boolean. Message-ID: <20121128183035.DFF5947B8F@hg.openjdk.java.net> Changeset: 26850733b930 Author: briangoetz Date: 2012-11-28 13:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/26850733b930 Add static min, max, sum methods to primitive numeric wrappers, and and/or/xor to Boolean. Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java From pbenedict at apache.org Wed Nov 28 10:36:52 2012 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 28 Nov 2012 12:36:52 -0600 Subject: hg: lambda/lambda/jdk: Add static min, max, sum methods to primitive numeric wrappers, and and/or/xor to Boolean. In-Reply-To: <20121128183035.DFF5947B8F@hg.openjdk.java.net> References: <20121128183035.DFF5947B8F@hg.openjdk.java.net> Message-ID: I am not doing the work so it's easy for me to comment, but I recommend renaming and() and or() to logicalAnd() and logicalOr() so you can, if you choose one day in the future, to introduce bitwiseAnd() and bitwiseOr(). Paul On Wed, Nov 28, 2012 at 12:30 PM, wrote: > Changeset: 26850733b930 > Author: briangoetz > Date: 2012-11-28 13:30 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/26850733b930 > > Add static min, max, sum methods to primitive numeric wrappers, and and/or/xor to Boolean. > Contributed-by: akhil.arora at oracle.com > > ! src/share/classes/java/lang/Boolean.java > ! src/share/classes/java/lang/Byte.java > ! src/share/classes/java/lang/Character.java > ! src/share/classes/java/lang/Double.java > ! src/share/classes/java/lang/Float.java > ! src/share/classes/java/lang/Integer.java > ! src/share/classes/java/lang/Long.java > ! src/share/classes/java/lang/Short.java > ! test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java > > From boaznahum at gmail.com Wed Nov 28 10:41:52 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Wed, 28 Nov 2012 20:41:52 +0200 Subject: hg: lambda/lambda/langtools: Fix: Add extra checks when lambda/method ref is converted to intersection type In-Reply-To: <20121128103215.E2D0947B6F@hg.openjdk.java.net> References: <20121128103215.E2D0947B6F@hg.openjdk.java.net> Message-ID: Can you explain why? If I1 and I2 have same SAM why (I1 & I2) is not valid? Can also explain why the order does matter? Thx (sorry foy English ) Boaz On Nov 28, 2012 12:34 PM, wrote: > Changeset: 7fa8e7c02baa > Author: mcimadamore > Date: 2012-11-28 10:31 +0000 > URL: > http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7fa8e7c02baa > > Fix: Add extra checks when lambda/method ref is converted to intersection > type > > A lambda/methdod reference can be converted to an intersection type > provided that: > > *) All types in the intersection are interface types > *) The first type of the intersection is a functional interface > *) The additional bounds of the intersection are marker interfaces > > ! src/share/classes/com/sun/tools/javac/code/Type.java > ! src/share/classes/com/sun/tools/javac/code/Types.java > ! src/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > ! test/tools/javac/diags/examples.not-yet.txt > + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java > > > From brian.goetz at oracle.com Wed Nov 28 11:08:10 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 28 Nov 2012 19:08:10 +0000 Subject: hg: lambda/lambda/jdk: Small addition to recent Vector patch Message-ID: <20121128190822.D352647B97@hg.openjdk.java.net> Changeset: 6f329acab6ff Author: briangoetz Date: 2012-11-28 14:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f329acab6ff Small addition to recent Vector patch ! src/share/classes/java/util/Vector.java From forax at univ-mlv.fr Wed Nov 28 11:07:18 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Nov 2012 20:07:18 +0100 Subject: hg: lambda/lambda/langtools: Fix: Add extra checks when lambda/method ref is converted to intersection type In-Reply-To: References: <20121128103215.E2D0947B6F@hg.openjdk.java.net> Message-ID: <50B660E6.3000101@univ-mlv.fr> On 11/28/2012 07:41 PM, Boaz Nahum wrote: > Can you explain why? > If I1 and I2 have same SAM why (I1 & I2) is not valid? The main issue is that the current implementation relies on the fact that there is only one SAM descriptor. And trying to support more than one SAM descriptor will likely to reduce our chance to optimize the object lambda creation in the VM. > Can also explain why the order does matter? When the compiler erase an intersection type, the first type is used as primary type by the compiler By example, Collections.max is written > max(Collection collection) (1) and not > max(Collection collection) (2) once erased the return type of (1) is Object, the return type of (2) is Comparable. > > Thx > (sorry foy English ) > Boaz cheers, R?mi > On Nov 28, 2012 12:34 PM, wrote: > >> Changeset: 7fa8e7c02baa >> Author: mcimadamore >> Date: 2012-11-28 10:31 +0000 >> URL: >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7fa8e7c02baa >> >> Fix: Add extra checks when lambda/method ref is converted to intersection >> type >> >> A lambda/methdod reference can be converted to an intersection type >> provided that: >> >> *) All types in the intersection are interface types >> *) The first type of the intersection is a functional interface >> *) The additional bounds of the intersection are marker interfaces >> >> ! src/share/classes/com/sun/tools/javac/code/Type.java >> ! src/share/classes/com/sun/tools/javac/code/Types.java >> ! src/share/classes/com/sun/tools/javac/comp/Attr.java >> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties >> ! test/tools/javac/diags/examples.not-yet.txt >> + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java >> >> >> From aruld at acm.org Wed Nov 28 11:17:57 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Wed, 28 Nov 2012 09:17:57 -1000 Subject: cannot find symbol on identity operation in lambda In-Reply-To: References: <50B59B16.3030101@oracle.com> Message-ID: Yeah, another option is using reduce :-) ...stream().reduce(Integer::sum).get() [1] https://github.com/aruld/java-oneliners/blob/master/src/oneliners/Item2.java On Tue, Nov 27, 2012 at 10:09 PM, Talden wrote: > On Wed, Nov 28, 2012 at 6:03 PM, Brian Goetz wrote: > >> The problem is that the type of the stream returned by map() is >> Stream, not IntStream. >> >> If you wanted an IntStream, you'd want to explicitly convert to ints: >> >> ...stream().map(i -> (int) i).sum() >> > > Would it be correct (and possibly more expressive) to use a method > reference for the unboxing in this case? > > ...stream().map(Integer::intValue).sum(); > > (I'm aware you were really illustrating why it didn't resolve to Integer > -> int but thought it worth noting the another representation of the > solution) > > -- > Aaron Scott-Boddendijk > From r.spilker at gmail.com Wed Nov 28 11:41:56 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 28 Nov 2012 20:41:56 +0100 Subject: Feedback on the implementation of StringJoiner Message-ID: Hi all, On June 25 I sent some feedback on the implementation of StringJoiner. Most of it is still relevant, none of it is addressed. Is there anything I can do to get the implementation to a higher level? Roel Thread containing the feedback http://mail.openjdk.java.net/pipermail/lambda-dev/2012-June/005078.html Link to the current implementation http://hg.openjdk.java.net/lambda/lambda/jdk/file/83923cc50252/src/share/classes/java/util/StringJoiner.java From brian.goetz at oracle.com Wed Nov 28 14:25:41 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 28 Nov 2012 22:25:41 +0000 Subject: hg: lambda/lambda/jdk: Expose Stream.spliterator(); move concat() out of Stream and into a static helper in Streams. Additional spliterator tests. Message-ID: <20121128222602.1E44747B9F@hg.openjdk.java.net> Changeset: 804584b3ef6a Author: briangoetz Date: 2012-11-28 17:25 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/804584b3ef6a Expose Stream.spliterator(); move concat() out of Stream and into a static helper in Streams. Additional spliterator tests. Contributed-by: paul.sandoz at oracle.com Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/Streams.java - src/share/classes/java/util/stream/op/ConcatOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From scolebourne at joda.org Wed Nov 28 16:25:38 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 29 Nov 2012 00:25:38 +0000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B5081E.7080002@oracle.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> Message-ID: On 27 November 2012 18:36, Brian Goetz wrote: > I think what Stephen meant (and I agree) is that in addition to defining > the contract for the interface method, there should be a standardized > place (or at least convention) for implementation notes about the > default implementation. > > For example, the default implementation of List.parallelSort() might in > fact be a serial sort. While that conforms to the spec ("sort the > list"), it may well be a crappy implementation, and there should be a > sensible place to put such information. Yes, thats what I'm getting at. I don't overly care if it is a form of words or a Javadoc annotation (or some other idea), so long as it is easy to identify that the text refers to what the default implementation does. Stephen From david.holmes at oracle.com Wed Nov 28 21:50:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 15:50:57 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> Message-ID: <50B6F7C1.4080606@oracle.com> Mike, On 28/11/2012 3:32 AM, Mike Duigou wrote: > On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > >> On 27 November 2012 02:12, Mike Duigou wrote: >>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >>> >>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >>> >>> The patch to add parent interfaces and default methods can be found here: >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >> >> Each of the default methods is formatted on a single line. I consider >> this to be bad style, they should be formatted as per "normal" >> methods: >> @Override >> public default Double operate(Double left, Double right) { >> return operateAsDouble((double) left, (double) right); >> } >> >> It is vitally important to get this kind of formatting/style correct. > >> Developers the world over will be copying what the style is in these >> classes. > > I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? I have to concur with Stephen - these are just method definitions and should follow the same style that is used for method definitions in classes. No need to contemplate introducing a new style just for default methods. >> There is also no Javadoc on the default method override. > > That was intentional. The goal was to inherit from the original definition. I don't think we can just leave it at that. If we are introducing additional constraints over that specified in base method then they need to be documented. We should be able to use implicit doc inheritance plus @{inheritDoc} to bring down what is unchanged and then add what is needed. I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The "default" simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. Cheers, David ----- >> In this case, >> passing a null to either parameter will result in an NPE. This should >> be documented. > > Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. My inclination is to add the description regarding null behaviour to the class javadoc at the same point where it's described that IntBlock can be used for Block. ie. > > This is the primitive type specialization of Block for int and also may be used as a Block provided that the parameter to accept(Integer) always is non-null. > >> >> More generally, you/Oracle should define a standard form of words for >> describing what a default method does. Interfaces have not had them >> before, and their behaviour needs documenting (even if it seems >> obvious). >> >> /** >> * An operation upon two operands yielding a result. >> * The operands and the result are all of the same type. >> *

>> * The default implementation calls {@link operate(double,double)}, >> * throwing NullPointerException if either input is null. >> * >> * @param left the first operand, not null >> * @param left the first operand, not null >> * @return the result, not null >> */ >> @Override >> public default Double operate(Double left, Double right) { >> return operateAsDouble((double) left, (double) right); >> } >> >> Stephen >> > > From david.holmes at oracle.com Wed Nov 28 22:06:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 16:06:13 +1000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> Message-ID: <50B6FB55.8010801@oracle.com> On 29/11/2012 10:25 AM, Stephen Colebourne wrote: > On 27 November 2012 18:36, Brian Goetz wrote: >> I think what Stephen meant (and I agree) is that in addition to defining >> the contract for the interface method, there should be a standardized >> place (or at least convention) for implementation notes about the >> default implementation. >> >> For example, the default implementation of List.parallelSort() might in >> fact be a serial sort. While that conforms to the spec ("sort the >> list"), it may well be a crappy implementation, and there should be a >> sensible place to put such information. > > Yes, thats what I'm getting at. I don't overly care if it is a form of > words or a Javadoc annotation (or some other idea), so long as it is > easy to identify that the text refers to what the default > implementation does. As I wrote in reply to the original thread: I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The "default" simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. --- I will add that there may be times when we want to say something about "this default implementation" if it is noteworthy enough - like doing a parallel sort sequentially. But that should be the exception not the rule. David > Stephen > From kevinb at google.com Wed Nov 28 23:36:52 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Thu, 29 Nov 2012 02:36:52 -0500 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B6FB55.8010801@oracle.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: On Thu, Nov 29, 2012 at 1:06 AM, David Holmes wrote: On 29/11/2012 10:25 AM, Stephen Colebourne wrote: > > On 27 November 2012 18:36, Brian Goetz wrote: > >> I think what Stephen meant (and I agree) is that in addition to defining > >> the contract for the interface method, there should be a standardized > >> place (or at least convention) for implementation notes about the > >> default implementation. > >> > >> For example, the default implementation of List.parallelSort() might in > >> fact be a serial sort. While that conforms to the spec ("sort the > >> list"), it may well be a crappy implementation, and there should be a > >> sensible place to put such information. > > > > Yes, thats what I'm getting at. I don't overly care if it is a form of > > words or a Javadoc annotation (or some other idea), so long as it is > > easy to identify that the text refers to what the default > > implementation does. > > As I wrote in reply to the original thread: > > I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. If the type is subclassable and the method makes any calls to overrideable methods on its own type, they certainly do need to specify how they're implemented (see e.g. Effective Java). And (a) interfaces are always subtypable, and (b) it's hard to imagine many default implementations *not *invoking any methods on the same instance (what else is there to do?), and those methods are of course always overrideable. So this seems like an open and shut case to me. 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. > This would leave a library author having no clue whether they can depend on "inheriting" the default or not. Default method implementations are not like other implementations; they're extremely leaky, and I think they must be specified. Side note: it would be nice if whatever javadoc taglet we use would be usable for regular class methods as well, where it would mean "don't inheritDoc from me." We've had a constant problem with extending things like AbstractSet and having "This implementation..." javadoc get copied into our own classes' docs, where it becomes simply false. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From david.holmes at oracle.com Wed Nov 28 23:49:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 17:49:23 +1000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: <50B71383.8080109@oracle.com> On 29/11/2012 5:36 PM, Kevin Bourrillion wrote: > On Thu, Nov 29, 2012 at 1:06 AM, David Holmes > wrote: > > On 29/11/2012 10:25 AM, Stephen Colebourne wrote: > > On 27 November 2012 18:36, Brian Goetz > wrote: > >> I think what Stephen meant (and I agree) is that in addition to > defining > >> the contract for the interface method, there should be a > standardized > >> place (or at least convention) for implementation notes about the > >> default implementation. > >> > >> For example, the default implementation of List.parallelSort() > might in > >> fact be a serial sort. While that conforms to the spec ("sort the > >> list"), it may well be a crappy implementation, and there should > be a > >> sensible place to put such information. > > > > Yes, thats what I'm getting at. I don't overly care if it is a > form of > > words or a Javadoc annotation (or some other idea), so long as it is > > easy to identify that the text refers to what the default > > implementation does. > > As I wrote in reply to the original thread: > > I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. > > > If the type is subclassable and the method makes any calls to > overrideable methods on its own type, they certainly do need to specify > how they're implemented (see e.g. Effective Java). And (a) interfaces > are always subtypable, and (b) it's hard to imagine many default > implementations /not /invoking any methods on the same instance (what > else is there to do?), and those methods are of course always > overrideable. So this seems like an open and shut case to me. Okay. In that sense all default methods are like concrete methods in the AbstractXXX classes. Which are described as "This implementation ..." > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. > > > This would leave a library author having no clue whether they can depend > on "inheriting" the default or not. Default method implementations are > not like other implementations; they're extremely leaky, and I think > they must be specified. I don't see that they are any different to abstract class method implementations in that regard. The JDK doesn't mandate how the non-abstract methods in the AbstractXXX classes are implemented. > Side note: it would be nice if whatever javadoc taglet we use would be > usable for regular class methods as well, where it would mean "don't > inheritDoc from me." We've had a constant problem with extending things > like AbstractSet and having "This implementation..." javadoc get copied > into our own classes' docs, where it becomes simply false. Yes we definitely need a distinction between the normative and non-normative text. David ----- > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From pdoubleya at gmail.com Wed Nov 28 23:54:12 2012 From: pdoubleya at gmail.com (Patrick Wright) Date: Thu, 29 Nov 2012 08:54:12 +0100 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: I agree that one should write the documentation in such a way as to not over-specify and force the hand of all implementors down the line. At the same time, if the default method is implemented by calling other methods on the interface, it seems reasonable for that to be documented. Perhaps the guideline should be - "in the documentation of a default method, specify as little about the implementation as is necessary for a consumer of the interface to use it safely (e.g. commit to as little as possible in the implementation)." Alternately, one could introduce a sort of note in the JavaDoc, specifically referring to the OpenJDK implementation. But the principle should be that either future versions of the JDK, or others who take and modify (or tune) the JDK for their platforms, be allowed to provide alternate implementations for the method while still remaining true to the specification in the JavaDoc. Patrick On Thu, Nov 29, 2012 at 8:36 AM, Kevin Bourrillion wrote: > On Thu, Nov 29, 2012 at 1:06 AM, David Holmes >wrote: > > On 29/11/2012 10:25 AM, Stephen Colebourne wrote: > > > On 27 November 2012 18:36, Brian Goetz wrote: > > >> I think what Stephen meant (and I agree) is that in addition to > defining > > >> the contract for the interface method, there should be a standardized > > >> place (or at least convention) for implementation notes about the > > >> default implementation. > > >> > > >> For example, the default implementation of List.parallelSort() might > in > > >> fact be a serial sort. While that conforms to the spec ("sort the > > >> list"), it may well be a crappy implementation, and there should be a > > >> sensible place to put such information. > > > > > > Yes, thats what I'm getting at. I don't overly care if it is a form of > > > words or a Javadoc annotation (or some other idea), so long as it is > > > easy to identify that the text refers to what the default > > > implementation does. > > > > As I wrote in reply to the original thread: > > > > I don't agree that we need to describe what the default implementation > > does, for two reasons: > > > > 1. Normal methods don't usually specify how they are implemented - it is > > an implementation detail. > > > If the type is subclassable and the method makes any calls to overrideable > methods on its own type, they certainly do need to specify how they're > implemented (see e.g. Effective Java). And (a) interfaces are always > subtypable, and (b) it's hard to imagine many default implementations > *not *invoking > any methods on the same instance (what else is there to do?), and those > methods are of course always overrideable. So this seems like an open and > shut case to me. > > > 2. It is not obvious to me that the JDK's choice for a default > > implementation has to be _the_ only possible implementation choice. In > > many/most cases there will be a very obvious choice, but that doesn't > > mean that all suppliers of OpenJDK classes have to be locked in to that > > choice. > > > > This would leave a library author having no clue whether they can depend on > "inheriting" the default or not. Default method implementations are not > like other implementations; they're extremely leaky, and I think they must > be specified. > > Side note: it would be nice if whatever javadoc taglet we use would be > usable for regular class methods as well, where it would mean "don't > inheritDoc from me." We've had a constant problem with extending things > like AbstractSet and having "This implementation..." javadoc get copied > into our own classes' docs, where it becomes simply false. > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > > From talden at gmail.com Thu Nov 29 00:21:40 2012 From: talden at gmail.com (Talden) Date: Thu, 29 Nov 2012 21:21:40 +1300 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B6F7C1.4080606@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> Message-ID: On Thu, Nov 29, 2012 at 6:50 PM, David Holmes wrote: > Mike, > > On 28/11/2012 3:32 AM, Mike Duigou wrote: > > On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > > > >> On 27 November 2012 02:12, Mike Duigou wrote: > >>> In the original patch which added the basic lambda functional > interfaces, CR#8001634 [1], none of the interfaces extended other > interfaces. The reason was primarily that the javac compiler did not, at > the time that 8001634 was proposed, support extension methods. The compiler > now supports adding of method defaults so this patch improves the > functional interfaces by filing in the inheritance hierarchy. > >>> > >>> Adding the parent interfaces and default methods allows each > functional interface to be used in more places. It is especially important > for the functional interfaces which support primitive types, IntSupplier, > IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that > eventually standard implementations of these interfaces will be provided > for functions like max, min, sum, etc. By extending the reference oriented > functional interfaces such as Function, the primitive implementations can > be used with the boxed primitive types along with the primitive types for > which they are defined. > >>> > >>> The patch to add parent interfaces and default methods can be found > here: > >>> > >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ > >>> > http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html > >> > >> Each of the default methods is formatted on a single line. I consider > >> this to be bad style, they should be formatted as per "normal" > >> methods: > >> @Override > >> public default Double operate(Double left, Double right) { > >> return operateAsDouble((double) left, (double) right); > >> } > >> > >> It is vitally important to get this kind of formatting/style correct. > > > >> Developers the world over will be copying what the style is in these > >> classes. > > > > I totally agree that we should be consistent but I don't believe that > there's a consensus yet on what good style is for these cases. What's your > rationale for it being "bad style"? > > I have to concur with Stephen - these are just method definitions and > should follow the same style that is used for method definitions in > classes. No need to contemplate introducing a new style just for default > methods. > I've personally never a one-style-to-rule-them-all kinda guy and I usual format trivial methods this way - that is, trivial getters, setters and delegating implementations. I've considered the vertical brevity a readability benefit in these cases and the absence of 'abstract' (for class methods) or the presence of default (for interfaces) seems cue enough. Still, at least it's not the opposite extreme. While I'm happy with (though 2-space vs 4-space indentations are my preference)... @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } I've worked with those that think this is necessary (assume a fixed width font to understand the indentation)... @Override public default Double operate( Double left, Double right ) { return operateAsDouble( ( double ) left, ( double ) right ); } Monitor aspects are getting relatively wider and screens larger overall. IMO longer lines and fewer content-less lines simply fits the medium better. >> There is also no Javadoc on the default method override. > > That was intentional. The goal was to inherit from the original definition. I don't think we can just leave it at that. If we are introducing > additional constraints over that specified in base method then they need > to be documented. We should be able to use implicit doc inheritance plus > @{inheritDoc} to bring down what is unchanged and then add what is needed. > Agreed. Don't put superfluous {@inheritDoc} in there but please don't omit the Javadoc entirely if the contract is further constrained. I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. The "default" simply indicates that this > method does have an implementation and you should expect that > implementation to obey the contract of the method. > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. > I have a dilemma, I disagree with the first point but not the second. Describing the complexity of the algorithm selected by default is useful information - It's saying how it scales, not how it's implemented. Documentation on how methods scale in a library is definitely beneficial. However, you're right, that documentation should be specific to the JavaSEimplementation not the JavaSE spec. It should state that the behaviour could vary with the supplier and the documentation for another JavaSE implementation should be checked or the behaviour tested. The spec could specify that it's the reference implementation and note that other implementations might use alternate implementations with different scaling characteristics - then it's easy, implementers need only alter that documentation when they deviate from the reference algorithm (though that opens a small future compatibility can-o-worms if the spec wants to use a different reference implementation in future releases). Surely the JDK has precedent for this in overridable methods of classes expecting to be extended. I'm guessing such details are omitted which makes for some potentially confusing performance differences Java implementations. -- Aaron Scott-Boddendijk From robert.field at oracle.com Thu Nov 29 00:29:26 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 29 Nov 2012 08:29:26 +0000 Subject: hg: lambda/lambda/jdk: 8003881: possible fix for potential unauthorized indirect access to lambda method Message-ID: <20121129082943.1296F47BB9@hg.openjdk.java.net> Changeset: b4107f9b4330 Author: rfield Date: 2012-11-29 00:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b4107f9b4330 8003881: possible fix for potential unauthorized indirect access to lambda method ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java From scolebourne at joda.org Thu Nov 29 02:23:52 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 29 Nov 2012 10:23:52 +0000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: On 29 November 2012 07:54, Patrick Wright wrote: > I agree that one should write the documentation in such a way as to not > over-specify and force the hand of all implementors down the line. At the > same time, if the default method is implemented by calling other methods on > the interface, it seems reasonable for that to be documented. Perhaps the > guideline should be - "in the documentation of a default method, specify as > little about the implementation as is necessary for a consumer of the > interface to use it safely (e.g. commit to as little as possible in the > implementation)." I also agree with not over-specifying and blocking future changes (and I agree with Kevin's comments more generally). While verbose perhaps this is more like what is needed: "The default implementation (in this implementation and this release) ..." Stephen From paul.sandoz at oracle.com Thu Nov 29 02:58:52 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 29 Nov 2012 10:58:52 +0000 Subject: hg: lambda/lambda/jdk: Remove unused stream related methods on node. Message-ID: <20121129110416.9C2AB47BC0@hg.openjdk.java.net> Changeset: 3511cfe8925d Author: psandoz Date: 2012-11-29 11:58 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3511cfe8925d Remove unused stream related methods on node. ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java From kevinb at google.com Thu Nov 29 06:01:14 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Thu, 29 Nov 2012 09:01:14 -0500 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B71383.8080109@oracle.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> <50B71383.8080109@oracle.com> Message-ID: On Thu, Nov 29, 2012 at 2:49 AM, David Holmes wrote: If the type is subclassable and the method makes any calls to >> overrideable methods on its own type, they certainly do need to specify >> how they're implemented (see e.g. Effective Java). And (a) interfaces >> are always subtypable, and (b) it's hard to imagine many default >> implementations /not /invoking any methods on the same instance (what >> >> else is there to do?), and those methods are of course always >> overrideable. So this seems like an open and shut case to me. >> > > Okay. In that sense all default methods are like concrete methods in the > AbstractXXX classes. Which are described as "This implementation ..." > > > 2. It is not obvious to me that the JDK's choice for a default >> implementation has to be _the_ only possible implementation choice. In >> many/most cases there will be a very obvious choice, but that doesn't >> mean that all suppliers of OpenJDK classes have to be locked in to >> that >> choice. >> >> This would leave a library author having no clue whether they can depend >> on "inheriting" the default or not. Default method implementations are >> not like other implementations; they're extremely leaky, and I think >> they must be specified. >> > > I don't see that they are any different to abstract class method > implementations in that regard. The JDK doesn't mandate how the > non-abstract methods in the AbstractXXX classes are implemented. I'm not following. How is the "This implementation..." text you referred to above *not* a case of the JDK mandating how they're implemented? Guava absolutely relies heavily on those specifications of how those methods are implemented. If we couldn't, we would no longer derive any value from the classes at all! Side note: it would be nice if whatever javadoc taglet we use would be >> usable for regular class methods as well, where it would mean "don't >> inheritDoc from me." We've had a constant problem with extending things >> like AbstractSet and having "This implementation..." javadoc get copied >> into our own classes' docs, where it becomes simply false. >> > > Yes we definitely need a distinction between the normative and > non-normative text. > Any thoughts on how to make this feature cover both cases? Seems like "@default" would not be the right tag anymore. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From kevinb at google.com Thu Nov 29 06:04:42 2012 From: kevinb at google.com (Kevin Bourrillion) Date: Thu, 29 Nov 2012 09:04:42 -0500 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: On Thu, Nov 29, 2012 at 2:54 AM, Patrick Wright wrote: Perhaps the guideline should be - "in the documentation of a default > method, specify as little about the implementation as is necessary for a > consumer of the interface to use it safely (e.g. commit to as little as > possible in the implementation)." I think most users are already inclined to commit to as little as possible, so this seems overstated or misstated to me. Hopefully we can just make that developer aware of the implications of either committing or not committing to an implementation. Either they'll have the freedom to change, or their users will have the freedom to actually depend on the behavior, performance, etc. they are presently getting. And of course there's middle ground too. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From paul.sandoz at oracle.com Thu Nov 29 06:14:49 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 29 Nov 2012 14:14:49 +0000 Subject: hg: lambda/lambda/jdk: - pipeline wrapping spliterators should conform to spliterator contract Message-ID: <20121129141511.E986147BC7@hg.openjdk.java.net> Changeset: 2f52eeca15e5 Author: psandoz Date: 2012-11-29 15:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2f52eeca15e5 - pipeline wrapping spliterators should conform to spliterator contract - obtain the size, if known, from a spliterator before traversing operations are performed as such operations may be greedy and consume elements thus affecting the size. - when obtaining a spliterator for a depth 0 i.e. the source spliterator try to return the best spliterator for use with parallel streams. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/StreamShapeFactory.java From pbenedict at apache.org Thu Nov 29 06:47:02 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 29 Nov 2012 08:47:02 -0600 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: I am very use to reading methods from abstract classes stating "The default implementation of this method does XYZ..." which is actually pretty important to know if you want to chain/add-on to the default behavior. IIRC, default methods can overridden and invoked via super, so it's important to explicitly say what to do if you want to compose behavior. Paul On Thu, Nov 29, 2012 at 8:04 AM, Kevin Bourrillion wrote: > On Thu, Nov 29, 2012 at 2:54 AM, Patrick Wright wrote: > > Perhaps the guideline should be - "in the documentation of a default >> method, specify as little about the implementation as is necessary for a >> consumer of the interface to use it safely (e.g. commit to as little as >> possible in the implementation)." > > > I think most users are already inclined to commit to as little as possible, > so this seems overstated or misstated to me. Hopefully we can just make > that developer aware of the implications of either committing or not > committing to an implementation. Either they'll have the freedom to > change, or their users will have the freedom to actually depend on the > behavior, performance, etc. they are presently getting. And of course > there's middle ground too. > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > From georgiy.rakov at oracle.com Thu Nov 29 07:20:00 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 29 Nov 2012 19:20:00 +0400 Subject: Sorting streams containing nulls In-Reply-To: <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> Message-ID: <50B77D20.7090503@oracle.com> Hello, could you please provide more explicit answer. Details: You've said that nulls are allowed so imagine we have a stream containing some nulls. Than we want to sort it. Here I see following contradiction. From the one hand if nulls are allowed they should be treated properly. It means when the sequence is sorted nulls should honestly be passed to supplied comparator and moved to its place in accordance with the result returned by comparator. This could not be done if NPE is thrown by implementation. From another hand you've said that nulls should be filtered out otherwise NPE is thrown. So could you please answer explicitly: - if this situation is considered as a bug and is going to be fixed; by "this situation" I mean the fact that NPE is thrown while sorting the stream containing nulls as described in my original message below; - or whether this situation is considered as expected behavior. Thanks, Georgiy. On 13.11.2012 21:15, Howard Lovatt wrote: > The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. > > Sent from my iPad > > On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: > >> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>> But it is sorted stream. >>> How should we compare null with other values? >> The supplied comparator could treat nulls in a special way. There are >> some ways to do it for instance: >> - comparator could consider null as the lowest value; >> - when sorting integers comparator could consider null being equal to >> some integer value for instance 5; >> >> Georgiy >> >>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>> so it's an implementation bug ? >>>> All Queue don't accept null so either null need to be masked/unmasked or >>>> the implementation has to be changed. >>>> >>>> R?mi >>>> >>>>> >>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>> >>>>>> Hello. >>>>>> >>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>> >>>>>> java.lang.NullPointerException >>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>> at >>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>> ... >>>>>> >>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>> going to be fixed somehow. >>>>>> >>>>>> Georgiy. >>>>>> From pbenedict at apache.org Thu Nov 29 07:29:18 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 29 Nov 2012 09:29:18 -0600 Subject: Sorting streams containing nulls In-Reply-To: <50B77D20.7090503@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> <50B77D20.7090503@oracle.com> Message-ID: To sort streams with nulls, I think all you would need is a filter that translates nulls to some sentinel object. Maybe the JDK should provide something like that. On Thu, Nov 29, 2012 at 9:20 AM, Georgiy Rakov wrote: > Hello, > > could you please provide more explicit answer. > > Details: > You've said that nulls are allowed so imagine we have a stream > containing some nulls. Than we want to sort it. > > Here I see following contradiction. > From the one hand if nulls are allowed they should be treated properly. > It means when the sequence is sorted nulls should honestly be passed to > supplied comparator and moved to its place in accordance with the result > returned by comparator. This could not be done if NPE is thrown by > implementation. > From another hand you've said that nulls should be filtered out > otherwise NPE is thrown. > > So could you please answer explicitly: > - if this situation is considered as a bug and is going to be fixed; by > "this situation" I mean the fact that NPE is thrown while sorting the > stream containing nulls as described in my original message below; > - or whether this situation is considered as expected behavior. > > Thanks, > Georgiy. > > On 13.11.2012 21:15, Howard Lovatt wrote: >> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. >> >> Sent from my iPad >> >> On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: >> >>> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>>> But it is sorted stream. >>>> How should we compare null with other values? >>> The supplied comparator could treat nulls in a special way. There are >>> some ways to do it for instance: >>> - comparator could consider null as the lowest value; >>> - when sorting integers comparator could consider null being equal to >>> some integer value for instance 5; >>> >>> Georgiy >>> >>>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>>> so it's an implementation bug ? >>>>> All Queue don't accept null so either null need to be masked/unmasked or >>>>> the implementation has to be changed. >>>>> >>>>> R?mi >>>>> >>>>>> >>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>>> >>>>>>> java.lang.NullPointerException >>>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>>> at >>>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>>> ... >>>>>>> >>>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>>> going to be fixed somehow. >>>>>>> >>>>>>> Georgiy. >>>>>>> > From brian.goetz at oracle.com Thu Nov 29 07:44:12 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 29 Nov 2012 10:44:12 -0500 Subject: Sorting streams containing nulls In-Reply-To: <50B77D20.7090503@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> <50B77D20.7090503@oracle.com> Message-ID: <50B782CC.5030709@oracle.com> At a minimum, the comparator you provide to the sort would have to be explicitly written to handle nulls, since most comparators immediately dereference their arguments. It would be nice if NPEs were not thrown from *within* the library in this case. But we're not ready to commit to that in the spec yet. So I would put the current behavior wrt nulls in sorting as "unfortunate" but not erroneous behavior. We may tighten this later, but for now, I think this is allowable. On 11/29/2012 10:20 AM, Georgiy Rakov wrote: > Hello, > > could you please provide more explicit answer. > > Details: > You've said that nulls are allowed so imagine we have a stream > containing some nulls. Than we want to sort it. > > Here I see following contradiction. > From the one hand if nulls are allowed they should be treated properly. > It means when the sequence is sorted nulls should honestly be passed to > supplied comparator and moved to its place in accordance with the result > returned by comparator. This could not be done if NPE is thrown by > implementation. > From another hand you've said that nulls should be filtered out > otherwise NPE is thrown. > > So could you please answer explicitly: > - if this situation is considered as a bug and is going to be fixed; by > "this situation" I mean the fact that NPE is thrown while sorting the > stream containing nulls as described in my original message below; > - or whether this situation is considered as expected behavior. > > Thanks, > Georgiy. > > On 13.11.2012 21:15, Howard Lovatt wrote: >> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. >> >> Sent from my iPad >> >> On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: >> >>> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>>> But it is sorted stream. >>>> How should we compare null with other values? >>> The supplied comparator could treat nulls in a special way. There are >>> some ways to do it for instance: >>> - comparator could consider null as the lowest value; >>> - when sorting integers comparator could consider null being equal to >>> some integer value for instance 5; >>> >>> Georgiy >>> >>>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>>> so it's an implementation bug ? >>>>> All Queue don't accept null so either null need to be masked/unmasked or >>>>> the implementation has to be changed. >>>>> >>>>> R?mi >>>>> >>>>>> >>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>>> >>>>>>> java.lang.NullPointerException >>>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>>> at >>>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>>> ... >>>>>>> >>>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>>> going to be fixed somehow. >>>>>>> >>>>>>> Georgiy. >>>>>>> > From elena.votchennikova at oracle.com Thu Nov 29 07:45:39 2012 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Thu, 29 Nov 2012 19:45:39 +0400 Subject: isParallel of sequential representation of parallel Stream Message-ID: <50B78323.2030300@oracle.com> Hi, method isParallel() returns true, if I call it from sequential representation of parallel Stream. For example, Arrays.parallel(new Object[]{1, 2, 3}).sequential().isParallel() returns true. I think it should return false, isn't it? Best regards, Lena From luolong at gmail.com Thu Nov 29 07:52:23 2012 From: luolong at gmail.com (Roland Tepp) Date: Thu, 29 Nov 2012 17:52:23 +0200 Subject: Sorting streams containing nulls In-Reply-To: <50B782CC.5030709@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> <50B77D20.7090503@oracle.com> <50B782CC.5030709@oracle.com> Message-ID: I think something should be provided that would address this issue in a standard and easily understandable manner. Google guava has Ordering.nullsFirst() and Ordering.nullsLast() methods for building such comparators. I think lambda should have something similar. 2012/11/29 Brian Goetz > At a minimum, the comparator you provide to the sort would have to be > explicitly written to handle nulls, since most comparators immediately > dereference their arguments. > > It would be nice if NPEs were not thrown from *within* the library in > this case. But we're not ready to commit to that in the spec yet. So I > would put the current behavior wrt nulls in sorting as "unfortunate" but > not erroneous behavior. We may tighten this later, but for now, I think > this is allowable. > > On 11/29/2012 10:20 AM, Georgiy Rakov wrote: > > Hello, > > > > could you please provide more explicit answer. > > > > Details: > > You've said that nulls are allowed so imagine we have a stream > > containing some nulls. Than we want to sort it. > > > > Here I see following contradiction. > > From the one hand if nulls are allowed they should be treated properly. > > It means when the sequence is sorted nulls should honestly be passed to > > supplied comparator and moved to its place in accordance with the result > > returned by comparator. This could not be done if NPE is thrown by > > implementation. > > From another hand you've said that nulls should be filtered out > > otherwise NPE is thrown. > > > > So could you please answer explicitly: > > - if this situation is considered as a bug and is going to be fixed; by > > "this situation" I mean the fact that NPE is thrown while sorting the > > stream containing nulls as described in my original message below; > > - or whether this situation is considered as expected behavior. > > > > Thanks, > > Georgiy. > > > > On 13.11.2012 21:15, Howard Lovatt wrote: > >> The expert groups has decided to go with allowing nulls and using an > Option type and as a result if you don't filter out nulls > [.filter(x->x!=null)] then you will get NPE. My preference would be for > nulls to be banned, like ConcurrentHashMap does. But it is hardly the end > of the world, just annoying that you have to put filters in if in doubt. > >> > >> Sent from my iPad > >> > >> On 13/11/2012, at 4:08 PM, Georgiy Rakov > wrote: > >> > >>> On 07.11.2012 18:08, Sergey Kuksenko wrote: > >>>> But it is sorted stream. > >>>> How should we compare null with other values? > >>> The supplied comparator could treat nulls in a special way. There are > >>> some ways to do it for instance: > >>> - comparator could consider null as the lowest value; > >>> - when sorting integers comparator could consider null being equal to > >>> some integer value for instance 5; > >>> > >>> Georgiy > >>> > >>>> On 11/07/2012 05:43 PM, Remi Forax wrote: > >>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: > >>>>>> The exact specification is not yet written, but we are not > expecting stream implementations or operations to do anything special with > nulls. This means nulls may be passed to lambdas or inserted into > collections that do not support them, resulting in NPE. > >>>>> so it's an implementation bug ? > >>>>> All Queue don't accept null so either null need to be > masked/unmasked or > >>>>> the implementation has to be changed. > >>>>> > >>>>> R?mi > >>>>> > >>>>>> > >>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: > >>>>>> > >>>>>>> Hello. > >>>>>>> > >>>>>>> When we make sorted(...).iterator() on Stream instance containing > one > >>>>>>> ore more nulls we receive NPE. The example of stack trace is below: > >>>>>>> > >>>>>>> java.lang.NullPointerException > >>>>>>> at > java.util.PriorityQueue.offer(PriorityQueue.java:320) > >>>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) > >>>>>>> at > java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) > >>>>>>> at > java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) > >>>>>>> at > >>>>>>> > java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) > >>>>>>> ... > >>>>>>> > >>>>>>> Could you please tell if it is considered as expected behavior or > it's > >>>>>>> going to be fixed somehow. > >>>>>>> > >>>>>>> Georgiy. > >>>>>>> > > > > -- Roland From paul.sandoz at oracle.com Thu Nov 29 08:01:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 29 Nov 2012 17:01:15 +0100 Subject: isParallel of sequential representation of parallel Stream In-Reply-To: <50B78323.2030300@oracle.com> References: <50B78323.2030300@oracle.com> Message-ID: On Nov 29, 2012, at 4:45 PM, elena votchennikova wrote: > Hi, > > method isParallel() returns true, if I call it from sequential > representation of parallel Stream. > > For example, > Arrays.parallel(new Object[]{1, 2, 3}).sequential().isParallel() > > returns true. > I think it should return false, isn't it? > What source revision did build from? Should now be fixed in the tip. Paul. From elena.votchennikova at oracle.com Thu Nov 29 08:29:31 2012 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Thu, 29 Nov 2012 20:29:31 +0400 Subject: isParallel of sequential representation of parallel Stream In-Reply-To: References: <50B78323.2030300@oracle.com> Message-ID: <50B78D6B.6000709@oracle.com> I use promoted build 64, from here: http://jdk8.java.net/lambda/ Lena On 29.11.2012 20:01, Paul Sandoz wrote: > On Nov 29, 2012, at 4:45 PM, elena votchennikova wrote: > >> Hi, >> >> method isParallel() returns true, if I call it from sequential >> representation of parallel Stream. >> >> For example, >> Arrays.parallel(new Object[]{1, 2, 3}).sequential().isParallel() >> >> returns true. >> I think it should return false, isn't it? >> > What source revision did build from? > > Should now be fixed in the tip. > > Paul. > From paul.sandoz at oracle.com Thu Nov 29 09:15:21 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 29 Nov 2012 18:15:21 +0100 Subject: isParallel of sequential representation of parallel Stream In-Reply-To: <50B78D6B.6000709@oracle.com> References: <50B78323.2030300@oracle.com> <50B78D6B.6000709@oracle.com> Message-ID: On Nov 29, 2012, at 5:29 PM, elena votchennikova wrote: > I use promoted build 64, from here: http://jdk8.java.net/lambda/ > OK, unfortunately it is not possible to tell from that page what revision the promoted build is associated with :-( But i definitely know that the fix you want is not in that build, because the issue was fixed with in the last day. Paul. > > Lena > > > On 29.11.2012 20:01, Paul Sandoz wrote: >> On Nov 29, 2012, at 4:45 PM, elena votchennikova wrote: >> >>> Hi, >>> >>> method isParallel() returns true, if I call it from sequential >>> representation of parallel Stream. >>> >>> For example, >>> Arrays.parallel(new Object[]{1, 2, 3}).sequential().isParallel() >>> >>> returns true. >>> I think it should return false, isn't it? >>> >> What source revision did build from? >> >> Should now be fixed in the tip. >> >> Paul. >> From forax at univ-mlv.fr Thu Nov 29 10:05:25 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Nov 2012 19:05:25 +0100 Subject: Sorting streams containing nulls In-Reply-To: <50B782CC.5030709@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> <50B77D20.7090503@oracle.com> <50B782CC.5030709@oracle.com> Message-ID: <50B7A3E5.9000009@univ-mlv.fr> [private] On 11/29/2012 04:44 PM, Brian Goetz wrote: > At a minimum, the comparator you provide to the sort would have to be > explicitly written to handle nulls, since most comparators immediately > dereference their arguments. > > It would be nice if NPEs were not thrown from *within* the library in > this case. But we're not ready to commit to that in the spec yet. So I > would put the current behavior wrt nulls in sorting as "unfortunate" but > not erroneous behavior. We may tighten this later, but for now, I think > this is allowable. NPE in middle of JDK code is a bug not a feature. we have to mask/unmask null in the implementation. R?mi > > On 11/29/2012 10:20 AM, Georgiy Rakov wrote: >> Hello, >> >> could you please provide more explicit answer. >> >> Details: >> You've said that nulls are allowed so imagine we have a stream >> containing some nulls. Than we want to sort it. >> >> Here I see following contradiction. >> From the one hand if nulls are allowed they should be treated properly. >> It means when the sequence is sorted nulls should honestly be passed to >> supplied comparator and moved to its place in accordance with the result >> returned by comparator. This could not be done if NPE is thrown by >> implementation. >> From another hand you've said that nulls should be filtered out >> otherwise NPE is thrown. >> >> So could you please answer explicitly: >> - if this situation is considered as a bug and is going to be fixed; by >> "this situation" I mean the fact that NPE is thrown while sorting the >> stream containing nulls as described in my original message below; >> - or whether this situation is considered as expected behavior. >> >> Thanks, >> Georgiy. >> >> On 13.11.2012 21:15, Howard Lovatt wrote: >>> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. >>> >>> Sent from my iPad >>> >>> On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: >>> >>>> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>>>> But it is sorted stream. >>>>> How should we compare null with other values? >>>> The supplied comparator could treat nulls in a special way. There are >>>> some ways to do it for instance: >>>> - comparator could consider null as the lowest value; >>>> - when sorting integers comparator could consider null being equal to >>>> some integer value for instance 5; >>>> >>>> Georgiy >>>> >>>>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>>>> so it's an implementation bug ? >>>>>> All Queue don't accept null so either null need to be masked/unmasked or >>>>>> the implementation has to be changed. >>>>>> >>>>>> R?mi >>>>>> >>>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>>>> >>>>>>>> java.lang.NullPointerException >>>>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>>>> at >>>>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>>>> ... >>>>>>>> >>>>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>>>> going to be fixed somehow. >>>>>>>> >>>>>>>> Georgiy. >>>>>>>> From louis.tribble at oracle.com Thu Nov 29 10:10:04 2012 From: louis.tribble at oracle.com (Louis Tribble) Date: Thu, 29 Nov 2012 10:10:04 -0800 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> Message-ID: <37B2EF1E-2674-42BC-9F94-DDCC33367BAC@oracle.com> On Nov 28, 2012, at 11:36 PM, Kevin Bourrillion wrote: > > Side note: it would be nice if whatever javadoc taglet we use would be > usable for regular class methods as well, where it would mean "don't > inheritDoc from me." We've had a constant problem with extending things > like AbstractSet and having "This implementation..." javadoc get copied > into our own classes' docs, where it becomes simply false. Using something like "The {@link AbstractSet} implementation..." works better after replication to a subclass, but it would great if javadoc could explicitly support the specification/implementation distinction. Louis > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > From forax at univ-mlv.fr Thu Nov 29 10:15:27 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Nov 2012 19:15:27 +0100 Subject: isParallel of sequential representation of parallel Stream In-Reply-To: References: <50B78323.2030300@oracle.com> <50B78D6B.6000709@oracle.com> Message-ID: <50B7A63F.90707@univ-mlv.fr> On 11/29/2012 06:15 PM, Paul Sandoz wrote: > On Nov 29, 2012, at 5:29 PM, elena votchennikova wrote: > >> I use promoted build 64, from here: http://jdk8.java.net/lambda/ >> > OK, unfortunately it is not possible to tell from that page what revision the promoted build is associated with :-( Here is the corresponding java version. /usr/jdk/jdk1.8.0-lambda/bin/java -version openjdk version "1.8.0-ea" OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h1745-20121105-b64-b00) OpenJDK 64-Bit Server VM (build 25.0-b05, mixed mode) not sure it helps. > > But i definitely know that the fix you want is not in that build, because the issue was fixed with in the last day. > > Paul. R?mi > >> Lena >> >> >> On 29.11.2012 20:01, Paul Sandoz wrote: >>> On Nov 29, 2012, at 4:45 PM, elena votchennikova wrote: >>> >>>> Hi, >>>> >>>> method isParallel() returns true, if I call it from sequential >>>> representation of parallel Stream. >>>> >>>> For example, >>>> Arrays.parallel(new Object[]{1, 2, 3}).sequential().isParallel() >>>> >>>> returns true. >>>> I think it should return false, isn't it? >>>> >>> What source revision did build from? >>> >>> Should now be fixed in the tip. >>> >>> Paul. >>> > From jonathan.gibbons at oracle.com Thu Nov 29 10:44:47 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 29 Nov 2012 10:44:47 -0800 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <37B2EF1E-2674-42BC-9F94-DDCC33367BAC@oracle.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> <37B2EF1E-2674-42BC-9F94-DDCC33367BAC@oracle.com> Message-ID: <50B7AD1F.7070909@oracle.com> On 11/29/2012 10:10 AM, Louis Tribble wrote: > Using something like "The {@link AbstractSet} implementation..." works better after replication to a subclass, but it would great if javadoc could explicitly support the specification/implementation distinction. This would be a good topic for discussion on javadoc-dev in the "after JDK 8" timeframe. -- Jon From forax at univ-mlv.fr Thu Nov 29 10:44:23 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Nov 2012 19:44:23 +0100 Subject: Sorting streams containing nulls In-Reply-To: <50B782CC.5030709@oracle.com> References: <509A3651.8020602@oracle.com> <509A658A.2040206@univ-mlv.fr> <509A6B59.7040307@oracle.com> <50A27084.2040805@oracle.com> <0E928CEB-8AC3-4073-B1F6-3BF264938D75@gmail.com> <50B77D20.7090503@oracle.com> <50B782CC.5030709@oracle.com> Message-ID: <50B7AD07.4000709@univ-mlv.fr> On 11/29/2012 04:44 PM, Brian Goetz wrote: > At a minimum, the comparator you provide to the sort would have to be > explicitly written to handle nulls, since most comparators immediately > dereference their arguments. > > It would be nice if NPEs were not thrown from *within* the library in > this case. But we're not ready to commit to that in the spec yet. So I > would put the current behavior wrt nulls in sorting as "unfortunate" but > not erroneous behavior. We may tighten this later, but for now, I think > this is allowable. I've just checked the current implementation, and I think there is no NPE anymore. R?mi > On 11/29/2012 10:20 AM, Georgiy Rakov wrote: >> Hello, >> >> could you please provide more explicit answer. >> >> Details: >> You've said that nulls are allowed so imagine we have a stream >> containing some nulls. Than we want to sort it. >> >> Here I see following contradiction. >> From the one hand if nulls are allowed they should be treated properly. >> It means when the sequence is sorted nulls should honestly be passed to >> supplied comparator and moved to its place in accordance with the result >> returned by comparator. This could not be done if NPE is thrown by >> implementation. >> From another hand you've said that nulls should be filtered out >> otherwise NPE is thrown. >> >> So could you please answer explicitly: >> - if this situation is considered as a bug and is going to be fixed; by >> "this situation" I mean the fact that NPE is thrown while sorting the >> stream containing nulls as described in my original message below; >> - or whether this situation is considered as expected behavior. >> >> Thanks, >> Georgiy. >> >> On 13.11.2012 21:15, Howard Lovatt wrote: >>> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt. >>> >>> Sent from my iPad >>> >>> On 13/11/2012, at 4:08 PM, Georgiy Rakov wrote: >>> >>>> On 07.11.2012 18:08, Sergey Kuksenko wrote: >>>>> But it is sorted stream. >>>>> How should we compare null with other values? >>>> The supplied comparator could treat nulls in a special way. There are >>>> some ways to do it for instance: >>>> - comparator could consider null as the lowest value; >>>> - when sorting integers comparator could consider null being equal to >>>> some integer value for instance 5; >>>> >>>> Georgiy >>>> >>>>> On 11/07/2012 05:43 PM, Remi Forax wrote: >>>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote: >>>>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls. This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE. >>>>>> so it's an implementation bug ? >>>>>> All Queue don't accept null so either null need to be masked/unmasked or >>>>>> the implementation has to be changed. >>>>>> >>>>>> R?mi >>>>>> >>>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote: >>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> When we make sorted(...).iterator() on Stream instance containing one >>>>>>>> ore more nulls we receive NPE. The example of stack trace is below: >>>>>>>> >>>>>>>> java.lang.NullPointerException >>>>>>>> at java.util.PriorityQueue.offer(PriorityQueue.java:320) >>>>>>>> at java.util.PriorityQueue.add(PriorityQueue.java:306) >>>>>>>> at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105) >>>>>>>> at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97) >>>>>>>> at >>>>>>>> java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329) >>>>>>>> ... >>>>>>>> >>>>>>>> Could you please tell if it is considered as expected behavior or it's >>>>>>>> going to be fixed somehow. >>>>>>>> >>>>>>>> Georgiy. >>>>>>>> From david.holmes at oracle.com Thu Nov 29 17:50:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 11:50:32 +1000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> <50B71383.8080109@oracle.com> Message-ID: <50B810E8.4090300@oracle.com> On 30/11/2012 12:01 AM, Kevin Bourrillion wrote: > On Thu, Nov 29, 2012 at 2:49 AM, David Holmes > wrote: > > If the type is subclassable and the method makes any calls to > overrideable methods on its own type, they certainly do need to > specify > how they're implemented (see e.g. Effective Java). And (a) > interfaces > are always subtypable, and (b) it's hard to imagine many default > implementations /not /invoking any methods on the same instance > (what > > else is there to do?), and those methods are of course always > overrideable. So this seems like an open and shut case to me. > > > Okay. In that sense all default methods are like concrete methods in > the AbstractXXX classes. Which are described as "This implementation > ..." > > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation > choice. In > many/most cases there will be a very obvious choice, but > that doesn't > mean that all suppliers of OpenJDK classes have to be > locked in to that > choice. > > This would leave a library author having no clue whether they > can depend > on "inheriting" the default or not. Default method > implementations are > not like other implementations; they're extremely leaky, and I think > they must be specified. > > > I don't see that they are any different to abstract class method > implementations in that regard. The JDK doesn't mandate how the > non-abstract methods in the AbstractXXX classes are implemented. > > > I'm not following. How is the "This implementation..." text you referred > to above /not/ a case of the JDK mandating how they're implemented? Because such statements are non-normative implementation notes. If somebody else wants to implement the Java APIs and provide their own class library then they are not required to match what is written in implementation notes. > Yes we definitely need a distinction between the normative and > non-normative text. > > > Any thoughts on how to make this feature cover both cases? Seems like > "@default" would not be the right tag anymore. To me @default would by definition be non-normative text. But maybe we are kidding ourselves to think this facilitates alternative implementations. David ----- > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com > > From david.holmes at oracle.com Thu Nov 29 18:03:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 12:03:34 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B774D8.60403@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> Message-ID: <50B813F6.6040602@oracle.com> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > On 11/29/2012 05:50 AM, David Holmes wrote: >> ... >> >> I don't agree that we need to describe what the default implementation >> does, for two reasons: >> >> 1. Normal methods don't usually specify how they are implemented - it is >> an implementation detail. The "default" simply indicates that this >> method does have an implementation and you should expect that >> implementation to obey the contract of the method. >> >> 2. It is not obvious to me that the JDK's choice for a default >> implementation has to be _the_ only possible implementation choice. In >> many/most cases there will be a very obvious choice, but that doesn't >> mean that all suppliers of OpenJDK classes have to be locked in to that >> choice. > > This is certainly interesting, and something I've wondered for a while > now. If java.util.Iterator is to ever be fitted with a default > implementation of remove ( to throw UnsupportedOperationException ), > then it would clearly need to be part of the spec, and not an > implementation detail of OpenJDK. Otherwise, what's the point, every > developer will still have to implement it because they cannot be > guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David > -Chris. From pbenedict at apache.org Thu Nov 29 19:01:51 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 29 Nov 2012 21:01:51 -0600 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: <50B810E8.4090300@oracle.com> References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> <50B71383.8080109@oracle.com> <50B810E8.4090300@oracle.com> Message-ID: Can someone please clarify if I implement a default method in a concrete class, I can still call the default method via super? Because if that's true, documenting the default method's behavior is absolutely imperative. They function like methods in abstract classes; their implementation will always be available for delegation like any other superclass method. Paul On Thu, Nov 29, 2012 at 7:50 PM, David Holmes wrote: > On 30/11/2012 12:01 AM, Kevin Bourrillion wrote: >> On Thu, Nov 29, 2012 at 2:49 AM, David Holmes > > wrote: >> >> If the type is subclassable and the method makes any calls to >> overrideable methods on its own type, they certainly do need to >> specify >> how they're implemented (see e.g. Effective Java). And (a) >> interfaces >> are always subtypable, and (b) it's hard to imagine many default >> implementations /not /invoking any methods on the same instance >> (what >> >> else is there to do?), and those methods are of course always >> overrideable. So this seems like an open and shut case to me. >> >> >> Okay. In that sense all default methods are like concrete methods in >> the AbstractXXX classes. Which are described as "This implementation >> ..." >> >> >> 2. It is not obvious to me that the JDK's choice for a default >> implementation has to be _the_ only possible implementation >> choice. In >> many/most cases there will be a very obvious choice, but >> that doesn't >> mean that all suppliers of OpenJDK classes have to be >> locked in to that >> choice. >> >> This would leave a library author having no clue whether they >> can depend >> on "inheriting" the default or not. Default method >> implementations are >> not like other implementations; they're extremely leaky, and I think >> they must be specified. >> >> >> I don't see that they are any different to abstract class method >> implementations in that regard. The JDK doesn't mandate how the >> non-abstract methods in the AbstractXXX classes are implemented. >> >> >> I'm not following. How is the "This implementation..." text you referred >> to above /not/ a case of the JDK mandating how they're implemented? > > Because such statements are non-normative implementation notes. If > somebody else wants to implement the Java APIs and provide their own > class library then they are not required to match what is written in > implementation notes. > >> Yes we definitely need a distinction between the normative and >> non-normative text. >> >> >> Any thoughts on how to make this feature cover both cases? Seems like >> "@default" would not be the right tag anymore. > > To me @default would by definition be non-normative text. > > But maybe we are kidding ourselves to think this facilitates alternative > implementations. > > David > ----- > >> >> -- >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com >> >> > From david.holmes at oracle.com Thu Nov 29 19:49:22 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 13:49:22 +1000 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: <50B4FBA0.9060204@redhat.com> <50B50423.3000406@redhat.com> <50B5081E.7080002@oracle.com> <50B6FB55.8010801@oracle.com> <50B71383.8080109@oracle.com> <50B810E8.4090300@oracle.com> Message-ID: <50B82CC2.6010107@oracle.com> On 30/11/2012 1:01 PM, Paul Benedict wrote: > Can someone please clarify if I implement a default method in a > concrete class, I can still call the default method via super? Because Yes if it is immediate supertype. > if that's true, documenting the default method's behavior is > absolutely imperative. They function like methods in abstract classes; > their implementation will always be available for delegation like any > other superclass method. The behaviour is documented - the method has a contract that it honours. How it honours that contract is what is under dispute. Generally methods don't specify how they do things. But when it involves calling methods that may/must be overridden in the implementation then they tend to document that in some way - AFAIK there are three main variants of this: - This method does ... - This method acts as-if ... - In this implementation ... Default methods don't add anything new to the question of what level of specification/documentation is appropriate on a concrete method. David ----- > > Paul > > On Thu, Nov 29, 2012 at 7:50 PM, David Holmes wrote: >> On 30/11/2012 12:01 AM, Kevin Bourrillion wrote: >>> On Thu, Nov 29, 2012 at 2:49 AM, David Holmes>> > wrote: >>> >>> If the type is subclassable and the method makes any calls to >>> overrideable methods on its own type, they certainly do need to >>> specify >>> how they're implemented (see e.g. Effective Java). And (a) >>> interfaces >>> are always subtypable, and (b) it's hard to imagine many default >>> implementations /not /invoking any methods on the same instance >>> (what >>> >>> else is there to do?), and those methods are of course always >>> overrideable. So this seems like an open and shut case to me. >>> >>> >>> Okay. In that sense all default methods are like concrete methods in >>> the AbstractXXX classes. Which are described as "This implementation >>> ..." >>> >>> >>> 2. It is not obvious to me that the JDK's choice for a default >>> implementation has to be _the_ only possible implementation >>> choice. In >>> many/most cases there will be a very obvious choice, but >>> that doesn't >>> mean that all suppliers of OpenJDK classes have to be >>> locked in to that >>> choice. >>> >>> This would leave a library author having no clue whether they >>> can depend >>> on "inheriting" the default or not. Default method >>> implementations are >>> not like other implementations; they're extremely leaky, and I think >>> they must be specified. >>> >>> >>> I don't see that they are any different to abstract class method >>> implementations in that regard. The JDK doesn't mandate how the >>> non-abstract methods in the AbstractXXX classes are implemented. >>> >>> >>> I'm not following. How is the "This implementation..." text you referred >>> to above /not/ a case of the JDK mandating how they're implemented? >> >> Because such statements are non-normative implementation notes. If >> somebody else wants to implement the Java APIs and provide their own >> class library then they are not required to match what is written in >> implementation notes. >> >>> Yes we definitely need a distinction between the normative and >>> non-normative text. >>> >>> >>> Any thoughts on how to make this feature cover both cases? Seems like >>> "@default" would not be the right tag anymore. >> >> To me @default would by definition be non-normative text. >> >> But maybe we are kidding ourselves to think this facilitates alternative >> implementations. >> >> David >> ----- >> >>> >>> -- >>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com >>> >>> >> From david.holmes at oracle.com Thu Nov 29 20:09:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 14:09:57 +1000 Subject: Confusing javac error :) Message-ID: <50B83195.1090805@oracle.com> javac -J-showversion -source 8 TestLambda.java java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) TestLambda.java:13: error: lambda expressions are not supported in -source 1.8 Runnable r = () -> System.out.println("Run") ; ^ (use -source 8 or higher to enable lambda expressions) 1 error ---- This is a mainline build of jdk8-b65 so this may already be fixed. David From robert.field at oracle.com Thu Nov 29 22:25:07 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 30 Nov 2012 06:25:07 +0000 Subject: hg: lambda/lambda/jdk: 8003881: proposed fix for potential unauthorized indirect access to lambda method, including in applet Message-ID: <20121130062528.A831C47C20@hg.openjdk.java.net> Changeset: 4d1f68c59366 Author: rfield Date: 2012-11-29 22:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4d1f68c59366 8003881: proposed fix for potential unauthorized indirect access to lambda method, including in applet ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleProxyLambdaMetafactory.java From forax at univ-mlv.fr Thu Nov 29 23:15:33 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Fri, 30 Nov 2012 08:15:33 +0100 Subject: =?utf-8?B?UmU6IENvbmZ1c2luZyBqYXZhYyBlcnJvciA6KQ==?= Message-ID: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> Yes, the default version should be 8. R?mi Sent from my Phone ----- Reply message ----- From: "David Holmes" To: "lambda-dev at openjdk.java.net" Subject: Confusing javac error :) Date: Fri, Nov 30, 2012 05:09 javac -J-showversion -source 8 TestLambda.java java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) TestLambda.java:13: error: lambda expressions are not supported in -source 1.8 Runnable r = () -> System.out.println("Run") ; ^ (use -source 8 or higher to enable lambda expressions) 1 error ---- This is a mainline build of jdk8-b65 so this may already be fixed. David From david.holmes at oracle.com Fri Nov 30 02:06:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 20:06:10 +1000 Subject: Confusing javac error :) In-Reply-To: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> Message-ID: <50B88512.5060800@oracle.com> On 30/11/2012 5:15 PM, Remi Forax wrote: > Yes, the default version should be 8. ?? I specified: -source 8 ;-) Hence the confusion regarding the error. David > R?mi > > Sent from my Phone > > ----- Reply message ----- > From: "David Holmes" > To: "lambda-dev at openjdk.java.net" > Subject: Confusing javac error :) > Date: Fri, Nov 30, 2012 05:09 > > > javac -J-showversion -source 8 TestLambda.java > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) > > TestLambda.java:13: error: lambda expressions are not supported in > -source 1.8 > Runnable r = () -> System.out.println("Run") ; > ^ > (use -source 8 or higher to enable lambda expressions) > 1 error > > ---- > > This is a mainline build of jdk8-b65 so this may already be fixed. > > David > From david.holmes at oracle.com Fri Nov 30 02:09:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 20:09:29 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B88361.7060705@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> Message-ID: <50B885D9.5060008@oracle.com> On 30/11/2012 7:58 PM, Chris Hegarty wrote: > On 30/11/2012 02:03, David Holmes wrote: >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>> ... >>>> >>>> I don't agree that we need to describe what the default implementation >>>> does, for two reasons: >>>> >>>> 1. Normal methods don't usually specify how they are implemented - >>>> it is >>>> an implementation detail. The "default" simply indicates that this >>>> method does have an implementation and you should expect that >>>> implementation to obey the contract of the method. >>>> >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. In >>>> many/most cases there will be a very obvious choice, but that doesn't >>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>> choice. >>> >>> This is certainly interesting, and something I've wondered for a while >>> now. If java.util.Iterator is to ever be fitted with a default >>> implementation of remove ( to throw UnsupportedOperationException ), >>> then it would clearly need to be part of the spec, and not an >>> implementation detail of OpenJDK. Otherwise, what's the point, every >>> developer will still have to implement it because they cannot be >>> guaranteed of it's behavior. >> >> I think optional methods are a bit of a special case here because they >> don't have to work. >> >> It's the end user of a class that needs to understand if they can use >> remove() to actually do a removal. The developer of the class can >> inherit whatever default implementations Iterator provides, as long as >> they don't mind what they get. If they do mind ie they need a real >> remove(), then they will have to implement it themselves and in the >> process document that fact. The end user has to look at the docs for the >> concrete class and follow through to determine whether it's >> iterator().remove() is optional or not. >> >> Put another way, a default method is great for adding a new method to >> types that have not yet been revised to handle the new method. As a >> developer once you revise your class you should make a conscious >> implementation choice in my opinion and not rely on the default unless >> you truly don't care what it does. > > Sorry David, I've not been following lambda that closely, but (in my > opinion) if default methods do not, or cannot, have defined semantics > then I really think it is limiting. Maybe Iterator is a bad example, but > I will continue with it anyway. In many cases developers of > iterator().remove() want it to throw, if this is not defined in > Iterator's default remove method then every Iterator subclass will still > have to define its own remove that throws. For this particular case at > least (if it were to ever happen), I would like to see specification > added to remove that defines the default implementation. The supplied default implementation will document that it throws. But does that mean it is the only possible default implementation, ever? Again Iterator.remove() is not a great example. default methods are no different to other concrete methods in my opinion. David ------ > -Chris. > >> >> But maybe we kid ourselves when we give this illusion of flexibility in >> implementation. >> >> David >> >>> -Chris. From forax at univ-mlv.fr Fri Nov 30 02:30:05 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Nov 2012 11:30:05 +0100 Subject: Confusing javac error :) In-Reply-To: <50B88512.5060800@oracle.com> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> Message-ID: <50B88AAD.2090903@univ-mlv.fr> On 11/30/2012 11:06 AM, David Holmes wrote: > On 30/11/2012 5:15 PM, Remi Forax wrote: >> Yes, the default version should be 8. > > ?? I specified: > > -source 8 > > ;-) Hence the confusion regarding the error. > > David doh, I see really weird. R?mi > >> R?mi >> >> Sent from my Phone >> >> ----- Reply message ----- >> From: "David Holmes" >> To: "lambda-dev at openjdk.java.net" >> Subject: Confusing javac error :) >> Date: Fri, Nov 30, 2012 05:09 >> >> >> javac -J-showversion -source 8 TestLambda.java >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >> Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) >> >> TestLambda.java:13: error: lambda expressions are not supported in >> -source 1.8 >> Runnable r = () -> System.out.println("Run") ; >> ^ >> (use -source 8 or higher to enable lambda expressions) >> 1 error >> >> ---- >> >> This is a mainline build of jdk8-b65 so this may already be fixed. >> >> David >> From forax at univ-mlv.fr Fri Nov 30 02:45:43 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Nov 2012 11:45:43 +0100 Subject: Confusing javac error :) In-Reply-To: <50B88AAD.2090903@univ-mlv.fr> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> Message-ID: <50B88E57.2000205@univ-mlv.fr> On 11/30/2012 11:30 AM, Remi Forax wrote: > On 11/30/2012 11:06 AM, David Holmes wrote: >> On 30/11/2012 5:15 PM, Remi Forax wrote: >>> Yes, the default version should be 8. >> ?? I specified: >> >> -source 8 >> >> ;-) Hence the confusion regarding the error. >> >> David > doh, I see really weird. > > R?mi Ok, got it, The version of the compiler shipped with b65 has lambda disabled with a non standard flag /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java changeset 01c9d4161882 enable lambda by default: http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java so b66 will have lambda enabled by default. R?mi > >>> R?mi >>> >>> Sent from my Phone >>> >>> ----- Reply message ----- >>> From: "David Holmes" >>> To: "lambda-dev at openjdk.java.net" >>> Subject: Confusing javac error :) >>> Date: Fri, Nov 30, 2012 05:09 >>> >>> >>> javac -J-showversion -source 8 TestLambda.java >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>> Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) >>> >>> TestLambda.java:13: error: lambda expressions are not supported in >>> -source 1.8 >>> Runnable r = () -> System.out.println("Run") ; >>> ^ >>> (use -source 8 or higher to enable lambda expressions) >>> 1 error >>> >>> ---- >>> >>> This is a mainline build of jdk8-b65 so this may already be fixed. >>> >>> David >>> > From peter.levart at gmail.com Fri Nov 30 04:08:56 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 30 Nov 2012 13:08:56 +0100 Subject: Confusing javac error :) In-Reply-To: <50B88E57.2000205@univ-mlv.fr> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> Message-ID: <50B8A1D8.7050704@gmail.com> On 11/30/2012 11:45 AM, Remi Forax wrote: > On 11/30/2012 11:30 AM, Remi Forax wrote: >> On 11/30/2012 11:06 AM, David Holmes wrote: >>> On 30/11/2012 5:15 PM, Remi Forax wrote: >>>> Yes, the default version should be 8. >>> ?? I specified: >>> >>> -source 8 >>> >>> ;-) Hence the confusion regarding the error. >>> >>> David >> doh, I see really weird. >> >> R?mi > Ok, got it, > The version of the compiler shipped with b65 has lambda disabled with a > non standard flag > /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java > > changeset 01c9d4161882 enable lambda by default: > http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java > so b66 will have lambda enabled by default. > > R?mi Hi Remi, Do you happen to know the switch for default methods too? java: default methods are not supported in -source 1.8 (use -source 8 or higher to enable default methods) Regards, Peter > > >>>> R?mi >>>> >>>> Sent from my Phone >>>> >>>> ----- Reply message ----- >>>> From: "David Holmes" >>>> To: "lambda-dev at openjdk.java.net" >>>> Subject: Confusing javac error :) >>>> Date: Fri, Nov 30, 2012 05:09 >>>> >>>> >>>> javac -J-showversion -source 8 TestLambda.java >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>> Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) >>>> >>>> TestLambda.java:13: error: lambda expressions are not supported in >>>> -source 1.8 >>>> Runnable r = () -> System.out.println("Run") ; >>>> ^ >>>> (use -source 8 or higher to enable lambda expressions) >>>> 1 error >>>> >>>> ---- >>>> >>>> This is a mainline build of jdk8-b65 so this may already be fixed. >>>> >>>> David >>>> > From david.holmes at oracle.com Fri Nov 30 04:20:35 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 22:20:35 +1000 Subject: Confusing javac error :) In-Reply-To: <50B88E57.2000205@univ-mlv.fr> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> Message-ID: <50B8A493.2000505@oracle.com> On 30/11/2012 8:45 PM, Remi Forax wrote: > On 11/30/2012 11:30 AM, Remi Forax wrote: >> On 11/30/2012 11:06 AM, David Holmes wrote: >>> On 30/11/2012 5:15 PM, Remi Forax wrote: >>>> Yes, the default version should be 8. >>> ?? I specified: >>> >>> -source 8 >>> >>> ;-) Hence the confusion regarding the error. >>> >>> David >> doh, I see really weird. >> >> R?mi > > Ok, got it, > The version of the compiler shipped with b65 has lambda disabled with a > non standard flag > /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java > > changeset 01c9d4161882 enable lambda by default: > http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java > so b66 will have lambda enabled by default. Ah! Thanks Remi. The person (who shall remain nameless) who told me I could use a regular build to test lambdas failed to mention that :) Cheers, David > R?mi > > >> >>>> R?mi >>>> >>>> Sent from my Phone >>>> >>>> ----- Reply message ----- >>>> From: "David Holmes" >>>> To: "lambda-dev at openjdk.java.net" >>>> Subject: Confusing javac error :) >>>> Date: Fri, Nov 30, 2012 05:09 >>>> >>>> >>>> javac -J-showversion -source 8 TestLambda.java >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>> Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) >>>> >>>> TestLambda.java:13: error: lambda expressions are not supported in >>>> -source 1.8 >>>> Runnable r = () -> System.out.println("Run") ; >>>> ^ >>>> (use -source 8 or higher to enable lambda expressions) >>>> 1 error >>>> >>>> ---- >>>> >>>> This is a mainline build of jdk8-b65 so this may already be fixed. >>>> >>>> David >>>> >> > > From maurizio.cimadamore at oracle.com Fri Nov 30 04:21:37 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 30 Nov 2012 12:21:37 +0000 Subject: Confusing javac error :) In-Reply-To: <50B8A1D8.7050704@gmail.com> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> <50B8A1D8.7050704@gmail.com> Message-ID: <50B8A4D1.809@oracle.com> On 30/11/12 12:08, Peter Levart wrote: > On 11/30/2012 11:45 AM, Remi Forax wrote: >> On 11/30/2012 11:30 AM, Remi Forax wrote: >>> On 11/30/2012 11:06 AM, David Holmes wrote: >>>> On 30/11/2012 5:15 PM, Remi Forax wrote: >>>>> Yes, the default version should be 8. >>>> ?? I specified: >>>> >>>> -source 8 >>>> >>>> ;-) Hence the confusion regarding the error. >>>> >>>> David >>> doh, I see really weird. >>> >>> R?mi >> Ok, got it, >> The version of the compiler shipped with b65 has lambda disabled with a >> non standard flag >> /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java >> >> changeset 01c9d4161882 enable lambda by default: >> http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java >> so b66 will have lambda enabled by default. >> >> R?mi > Hi Remi, > > Do you happen to know the switch for default methods too? > > java: default methods are not supported in -source 1.8 > (use -source 8 or higher to enable default methods) > > Regards, Peter Please do not rely on those internal flags. There's a reason why lambda/default methods are not enabled by default in b65 - first and foremost because hotspot and JDK changes are not there yet. Let's all wait for next promotion, or use the lambda repo, shall we? ;-) Maurizio > >> >>>>> R?mi >>>>> >>>>> Sent from my Phone >>>>> >>>>> ----- Reply message ----- >>>>> From: "David Holmes" >>>>> To: "lambda-dev at openjdk.java.net" >>>>> Subject: Confusing javac error :) >>>>> Date: Fri, Nov 30, 2012 05:09 >>>>> >>>>> >>>>> javac -J-showversion -source 8 TestLambda.java >>>>> java version "1.8.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>>> Java HotSpot(TM) Client VM (build 25.0-b09, mixed mode) >>>>> >>>>> TestLambda.java:13: error: lambda expressions are not supported in >>>>> -source 1.8 >>>>> Runnable r = () -> System.out.println("Run") ; >>>>> ^ >>>>> (use -source 8 or higher to enable lambda expressions) >>>>> 1 error >>>>> >>>>> ---- >>>>> >>>>> This is a mainline build of jdk8-b65 so this may already be fixed. >>>>> >>>>> David >>>>> > From chris.hegarty at oracle.com Thu Nov 29 06:44:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Nov 2012 14:44:40 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B6F7C1.4080606@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> Message-ID: <50B774D8.60403@oracle.com> On 11/29/2012 05:50 AM, David Holmes wrote: > ... > > I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. The "default" simply indicates that this > method does have an implementation and you should expect that > implementation to obey the contract of the method. > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. -Chris. From chris.hegarty at oracle.com Fri Nov 30 01:58:57 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 30 Nov 2012 09:58:57 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B813F6.6040602@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> Message-ID: <50B88361.7060705@oracle.com> On 30/11/2012 02:03, David Holmes wrote: > On 30/11/2012 12:44 AM, Chris Hegarty wrote: >> On 11/29/2012 05:50 AM, David Holmes wrote: >>> ... >>> >>> I don't agree that we need to describe what the default implementation >>> does, for two reasons: >>> >>> 1. Normal methods don't usually specify how they are implemented - it is >>> an implementation detail. The "default" simply indicates that this >>> method does have an implementation and you should expect that >>> implementation to obey the contract of the method. >>> >>> 2. It is not obvious to me that the JDK's choice for a default >>> implementation has to be _the_ only possible implementation choice. In >>> many/most cases there will be a very obvious choice, but that doesn't >>> mean that all suppliers of OpenJDK classes have to be locked in to that >>> choice. >> >> This is certainly interesting, and something I've wondered for a while >> now. If java.util.Iterator is to ever be fitted with a default >> implementation of remove ( to throw UnsupportedOperationException ), >> then it would clearly need to be part of the spec, and not an >> implementation detail of OpenJDK. Otherwise, what's the point, every >> developer will still have to implement it because they cannot be >> guaranteed of it's behavior. > > I think optional methods are a bit of a special case here because they > don't have to work. > > It's the end user of a class that needs to understand if they can use > remove() to actually do a removal. The developer of the class can > inherit whatever default implementations Iterator provides, as long as > they don't mind what they get. If they do mind ie they need a real > remove(), then they will have to implement it themselves and in the > process document that fact. The end user has to look at the docs for the > concrete class and follow through to determine whether it's > iterator().remove() is optional or not. > > Put another way, a default method is great for adding a new method to > types that have not yet been revised to handle the new method. As a > developer once you revise your class you should make a conscious > implementation choice in my opinion and not rely on the default unless > you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. -Chris. > > But maybe we kid ourselves when we give this illusion of flexibility in > implementation. > > David > >> -Chris. From Lance.Andersen at oracle.com Fri Nov 30 04:50:39 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 07:50:39 -0500 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B88361.7060705@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> Message-ID: <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > On 30/11/2012 02:03, David Holmes wrote: >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>> ... >>>> >>>> I don't agree that we need to describe what the default implementation >>>> does, for two reasons: >>>> >>>> 1. Normal methods don't usually specify how they are implemented - it is >>>> an implementation detail. The "default" simply indicates that this >>>> method does have an implementation and you should expect that >>>> implementation to obey the contract of the method. >>>> >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. In >>>> many/most cases there will be a very obvious choice, but that doesn't >>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>> choice. >>> >>> This is certainly interesting, and something I've wondered for a while >>> now. If java.util.Iterator is to ever be fitted with a default >>> implementation of remove ( to throw UnsupportedOperationException ), >>> then it would clearly need to be part of the spec, and not an >>> implementation detail of OpenJDK. Otherwise, what's the point, every >>> developer will still have to implement it because they cannot be >>> guaranteed of it's behavior. >> >> I think optional methods are a bit of a special case here because they >> don't have to work. >> >> It's the end user of a class that needs to understand if they can use >> remove() to actually do a removal. The developer of the class can >> inherit whatever default implementations Iterator provides, as long as >> they don't mind what they get. If they do mind ie they need a real >> remove(), then they will have to implement it themselves and in the >> process document that fact. The end user has to look at the docs for the >> concrete class and follow through to determine whether it's >> iterator().remove() is optional or not. >> >> Put another way, a default method is great for adding a new method to >> types that have not yet been revised to handle the new method. As a >> developer once you revise your class you should make a conscious >> implementation choice in my opinion and not rely on the default unless >> you truly don't care what it does. > > Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. > > -Chris. > >> >> But maybe we kid ourselves when we give this illusion of flexibility in >> implementation. >> >> David >> >>> -Chris. -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Fri Nov 30 04:52:50 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Nov 2012 13:52:50 +0100 Subject: Confusing javac error :) In-Reply-To: <50B8A4D1.809@oracle.com> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> <50B8A1D8.7050704@gmail.com> <50B8A4D1.809@oracle.com> Message-ID: <50B8AC22.9000307@univ-mlv.fr> On 11/30/2012 01:21 PM, Maurizio Cimadamore wrote: > On 30/11/12 12:08, Peter Levart wrote: >> On 11/30/2012 11:45 AM, Remi Forax wrote: >>> On 11/30/2012 11:30 AM, Remi Forax wrote: >>>> On 11/30/2012 11:06 AM, David Holmes wrote: >>>>> On 30/11/2012 5:15 PM, Remi Forax wrote: >>>>>> Yes, the default version should be 8. >>>>> ?? I specified: >>>>> >>>>> -source 8 >>>>> >>>>> ;-) Hence the confusion regarding the error. >>>>> >>>>> David >>>> doh, I see really weird. >>>> >>>> R?mi >>> Ok, got it, >>> The version of the compiler shipped with b65 has lambda disabled with a >>> non standard flag >>> /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java >>> >>> changeset 01c9d4161882 enable lambda by default: >>> http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java >>> >>> so b66 will have lambda enabled by default. >>> >>> R?mi >> Hi Remi, >> >> Do you happen to know the switch for default methods too? >> >> java: default methods are not supported in -source 1.8 >> (use -source 8 or higher to enable default methods) >> >> Regards, Peter > Please do not rely on those internal flags. There's a reason why > lambda/default methods are not enabled by default in b65 - first and > foremost because hotspot and JDK changes are not there yet. Let's all > wait for next promotion, or use the lambda repo, shall we? ;-) so I will not answer to Peter that he can just follow the link of the changeset above which show the name of the switch. > > Maurizio R?mi From maurizio.cimadamore at oracle.com Fri Nov 30 05:01:31 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 30 Nov 2012 13:01:31 +0000 Subject: Confusing javac error :) In-Reply-To: <50B8AC22.9000307@univ-mlv.fr> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> <50B8A1D8.7050704@gmail.com> <50B8A4D1.809@oracle.com> <50B8AC22.9000307@univ-mlv.fr> Message-ID: <50B8AE2B.5040503@oracle.com> On 30/11/12 12:52, Remi Forax wrote: > On 11/30/2012 01:21 PM, Maurizio Cimadamore wrote: >> On 30/11/12 12:08, Peter Levart wrote: >>> On 11/30/2012 11:45 AM, Remi Forax wrote: >>>> On 11/30/2012 11:30 AM, Remi Forax wrote: >>>>> On 11/30/2012 11:06 AM, David Holmes wrote: >>>>>> On 30/11/2012 5:15 PM, Remi Forax wrote: >>>>>>> Yes, the default version should be 8. >>>>>> ?? I specified: >>>>>> >>>>>> -source 8 >>>>>> >>>>>> ;-) Hence the confusion regarding the error. >>>>>> >>>>>> David >>>>> doh, I see really weird. >>>>> >>>>> R?mi >>>> Ok, got it, >>>> The version of the compiler shipped with b65 has lambda disabled >>>> with a >>>> non standard flag >>>> /usr/jdk/jdk1.8.0/bin/javac -XDallowLambda Test.java >>>> >>>> changeset 01c9d4161882 enable lambda by default: >>>> http://hg.openjdk.java.net/jdk8/jdk8/langtools/diff/01c9d4161882/src/share/classes/com/sun/tools/javac/parser/JavacParser.java >>>> >>>> so b66 will have lambda enabled by default. >>>> >>>> R?mi >>> Hi Remi, >>> >>> Do you happen to know the switch for default methods too? >>> >>> java: default methods are not supported in -source 1.8 >>> (use -source 8 or higher to enable default methods) >>> >>> Regards, Peter >> Please do not rely on those internal flags. There's a reason why >> lambda/default methods are not enabled by default in b65 - first and >> foremost because hotspot and JDK changes are not there yet. Let's all >> wait for next promotion, or use the lambda repo, shall we? ;-) > > so I will not answer to Peter that he can just follow the link of the > changeset above which show the name of the switch. If you like to play to unstable bits go ahead ;-) Maurizio > >> >> Maurizio > > R?mi > From ricky.clarkson at gmail.com Fri Nov 30 05:14:46 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Fri, 30 Nov 2012 10:14:46 -0300 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> Message-ID: What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? On Nov 30, 2012 9:54 AM, "Lance Andersen - Oracle" < Lance.Andersen at oracle.com> wrote: > > On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > > > > > On 30/11/2012 02:03, David Holmes wrote: > >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > >>> On 11/29/2012 05:50 AM, David Holmes wrote: > >>>> ... > >>>> > >>>> I don't agree that we need to describe what the default implementation > >>>> does, for two reasons: > >>>> > >>>> 1. Normal methods don't usually specify how they are implemented - it > is > >>>> an implementation detail. The "default" simply indicates that this > >>>> method does have an implementation and you should expect that > >>>> implementation to obey the contract of the method. > >>>> > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation choice. In > >>>> many/most cases there will be a very obvious choice, but that doesn't > >>>> mean that all suppliers of OpenJDK classes have to be locked in to > that > >>>> choice. > >>> > >>> This is certainly interesting, and something I've wondered for a while > >>> now. If java.util.Iterator is to ever be fitted with a default > >>> implementation of remove ( to throw UnsupportedOperationException ), > >>> then it would clearly need to be part of the spec, and not an > >>> implementation detail of OpenJDK. Otherwise, what's the point, every > >>> developer will still have to implement it because they cannot be > >>> guaranteed of it's behavior. > >> > >> I think optional methods are a bit of a special case here because they > >> don't have to work. > >> > >> It's the end user of a class that needs to understand if they can use > >> remove() to actually do a removal. The developer of the class can > >> inherit whatever default implementations Iterator provides, as long as > >> they don't mind what they get. If they do mind ie they need a real > >> remove(), then they will have to implement it themselves and in the > >> process document that fact. The end user has to look at the docs for the > >> concrete class and follow through to determine whether it's > >> iterator().remove() is optional or not. > >> > >> Put another way, a default method is great for adding a new method to > >> types that have not yet been revised to handle the new method. As a > >> developer once you revise your class you should make a conscious > >> implementation choice in my opinion and not rely on the default unless > >> you truly don't care what it does. > > > > Sorry David, I've not been following lambda that closely, but (in my > opinion) if default methods do not, or cannot, have defined semantics then > I really think it is limiting. Maybe Iterator is a bad example, but I will > continue with it anyway. In many cases developers of iterator().remove() > want it to throw, if this is not defined in Iterator's default remove > method then every Iterator subclass will still have to define its own > remove that throws. For this particular case at least (if it were to ever > happen), I would like to see specification added to remove that defines the > default implementation. > > I had wondered about this as well and had a brief email exchange with > Mike. I thought a new javadoc tag might also be something to consider. > > For JDBC, I am thinking of leveraging default methods to throw a > specific exception (maybe IllegalStateException?) if the method must be > implemented by the driver vendor or a SQLFeatureNotSupportedException for > methods which may be optional based on the backend support. > > > > -Chris. > > > >> > >> But maybe we kid ourselves when we give this illusion of flexibility in > >> implementation. > >> > >> David > >> > >>> -Chris. > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > From Lance.Andersen at oracle.com Fri Nov 30 05:20:24 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 08:20:24 -0500 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> Message-ID: <89DF6D6C-5D12-4A1B-9A74-EDD2525451C6@oracle.com> The problem for an API such as JDBC is that the implementation is going to be specific to the driver and backend so providing a default implementation just won't work. This allows existing drivers to compile as they finish their implementation and complete their migration to the new version of the API. On Nov 30, 2012, at 8:14 AM, Ricky Clarkson wrote: > What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? > > On Nov 30, 2012 9:54 AM, "Lance Andersen - Oracle" wrote: > > On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > > > > > On 30/11/2012 02:03, David Holmes wrote: > >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > >>> On 11/29/2012 05:50 AM, David Holmes wrote: > >>>> ... > >>>> > >>>> I don't agree that we need to describe what the default implementation > >>>> does, for two reasons: > >>>> > >>>> 1. Normal methods don't usually specify how they are implemented - it is > >>>> an implementation detail. The "default" simply indicates that this > >>>> method does have an implementation and you should expect that > >>>> implementation to obey the contract of the method. > >>>> > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation choice. In > >>>> many/most cases there will be a very obvious choice, but that doesn't > >>>> mean that all suppliers of OpenJDK classes have to be locked in to that > >>>> choice. > >>> > >>> This is certainly interesting, and something I've wondered for a while > >>> now. If java.util.Iterator is to ever be fitted with a default > >>> implementation of remove ( to throw UnsupportedOperationException ), > >>> then it would clearly need to be part of the spec, and not an > >>> implementation detail of OpenJDK. Otherwise, what's the point, every > >>> developer will still have to implement it because they cannot be > >>> guaranteed of it's behavior. > >> > >> I think optional methods are a bit of a special case here because they > >> don't have to work. > >> > >> It's the end user of a class that needs to understand if they can use > >> remove() to actually do a removal. The developer of the class can > >> inherit whatever default implementations Iterator provides, as long as > >> they don't mind what they get. If they do mind ie they need a real > >> remove(), then they will have to implement it themselves and in the > >> process document that fact. The end user has to look at the docs for the > >> concrete class and follow through to determine whether it's > >> iterator().remove() is optional or not. > >> > >> Put another way, a default method is great for adding a new method to > >> types that have not yet been revised to handle the new method. As a > >> developer once you revise your class you should make a conscious > >> implementation choice in my opinion and not rely on the default unless > >> you truly don't care what it does. > > > > Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. > > I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. > > For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. > > > > -Chris. > > > >> > >> But maybe we kid ourselves when we give this illusion of flexibility in > >> implementation. > >> > >> David > >> > >>> -Chris. > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From georgiy.rakov at oracle.com Fri Nov 30 06:26:40 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 30 Nov 2012 18:26:40 +0400 Subject: uniqueElements in parallel mode - encounter order Message-ID: <50B8C220.6030909@oracle.com> Hello, * uniqueElements()* method working in parallel mode does not preserve encounter order now. Consider following code. *result *will always contain sorted numbers in spite of shuffling, i. e. [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]. I could suppose this is the used algorithm artifact. import java.util.ArrayList; import java.util.Arrays; import java.util.Collections; public class UniqueElementsIssue1 { public static void main(String arg[]) { ArrayList data = new ArrayList<>(); for (int i = 0; i<10; ++i) { for (int k = 0; k<30; ++k) { data.add(i); } } Collections.shuffle(data); ArrayList result = new ArrayList<>(); Arrays.parallel(data.toArray(new Integer[0])).uniqueElements().into(result); } } While for sequential mode (Arrays.asStream) the encounter order is preserved. Could you please tell if this is considered as expected behavior and will be showed in spec; for instance something like following could be there. /Having been called on stream in sequential mode, UniqueElements preserve encounter order. Having been called on stream in parallel mode, UniqueElements doesn't preserve encounter order. / The code above is attached for your convenience. Thanks, Georgiy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: UniqueElementsIssue1.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121130/c34b7056/UniqueElementsIssue1.java From paul.sandoz at oracle.com Fri Nov 30 06:54:09 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 30 Nov 2012 15:54:09 +0100 Subject: uniqueElements in parallel mode - encounter order In-Reply-To: <50B8C220.6030909@oracle.com> References: <50B8C220.6030909@oracle.com> Message-ID: What revision are you working from? I don't observe such behaviour from the tip, encounter order is preserved for both sequential and parallel streams. Example output: [testng] [1, 1, 8, 0, 1, 3, 5, 6, 5, 3, 9, 1, 5, 9, 8, 6, 6, 4, 7, 4, 4, 2, 7, 6, 7, 5, 0, 4, 0, 9, 7, 4, 1, 2, 5, 4, 4, 4, 5, 4, 3, 5, 4, 1, 9, 2, 2, 4, 0, 3, 6, 8, 0, 3, 6, 3, 1, 3, 2, 8, 7, 8, 2, 6, 5, 8, 2, 4, 4, 4, 0, 8, 3, 0, 2, 5, 0, 3, 8, 0, 9, 6, 7, 5, 1, 6, 5, 1, 0, 0, 9, 7, 1, 9, 7, 4, 3, 8, 8, 9, 8, 7, 1, 1, 7, 6, 0, 2, 3, 8, 2, 9, 7, 6, 1, 1, 5, 4, 9, 8, 3, 8, 2, 5, 9, 3, 1, 5, 3, 8, 5, 5, 3, 1, 3, 4, 7, 5, 9, 8, 8, 7, 8, 1, 2, 3, 2, 1, 9, 7, 1, 0, 2, 3, 0, 5, 3, 1, 6, 7, 3, 6, 3, 7, 7, 4, 4, 2, 9, 5, 7, 9, 2, 6, 5, 5, 4, 0, 0, 9, 0, 0, 8, 3, 7, 2, 8, 0, 6, 9, 3, 9, 8, 3, 8, 0, 8, 8, 1, 6, 5, 2, 0, 5, 1, 8, 8, 7, 5, 3, 0, 9, 1, 0, 2, 6, 0, 4, 0, 6, 9, 9, 8, 4, 4, 4, 2, 8, 2, 2, 9, 9, 0, 6, 3, 4, 7, 9, 2, 4, 4, 2, 1, 6, 6, 2, 6, 5, 4, 2, 6, 7, 1, 5, 6, 6, 9, 2, 9, 9, 2, 9, 5, 1, 5, 7, 7, 9, 3, 6, 5, 3, 4, 7, 7, 2, 6, 7, 1, 6, 1, 1, 3, 8, 0, 6, 4, 2, 0, 9, 0, 7, 1, 6, 7, 0, 5, 3, 8, 7] [testng] [1, 8, 0, 3, 5, 6, 9, 4, 7, 2] Assuming that the input to the uniqueElements operation is not already sorted and declared as such then the implementation uses a LinkedHashSet or Set (if order is to be preserved or not respectively) to hold unique elements. It never explicitly sorts the input. Paul. On Nov 30, 2012, at 3:26 PM, Georgiy Rakov wrote: > Hello, > * > uniqueElements()* method working in parallel mode does not preserve encounter order now. Consider following code. *result *will always contain sorted numbers in spite of shuffling, i. e. [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]. I could suppose this is the used algorithm artifact. > > import java.util.ArrayList; > import java.util.Arrays; > import java.util.Collections; > > public class UniqueElementsIssue1 { > public static void main(String arg[]) { > ArrayList data = new ArrayList<>(); > for (int i = 0; i<10; ++i) { > for (int k = 0; k<30; ++k) { > data.add(i); > } > } > Collections.shuffle(data); > ArrayList result = new ArrayList<>(); > Arrays.parallel(data.toArray(new > Integer[0])).uniqueElements().into(result); > } > } > > > While for sequential mode (Arrays.asStream) the encounter order is preserved. > > Could you please tell if this is considered as expected behavior and will be showed in spec; for instance something like following could be there. > /Having been called on stream in sequential mode, UniqueElements preserve encounter order. > Having been called on stream in parallel mode, UniqueElements doesn't preserve encounter order. > / > The code above is attached for your convenience. > > Thanks, > Georgiy. > From brian.goetz at oracle.com Fri Nov 30 07:10:25 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 15:10:25 +0000 Subject: hg: lambda/lambda/jdk: Merge AbstractShortCircuitTask and AbstractCancelableTask; migrate away from using CC.setRawResult Message-ID: <20121130151038.0C17047C37@hg.openjdk.java.net> Changeset: e7bed11092a5 Author: briangoetz Date: 2012-11-30 10:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e7bed11092a5 Merge AbstractShortCircuitTask and AbstractCancelableTask; migrate away from using CC.setRawResult ! src/share/classes/java/util/stream/op/AbstractTask.java ! src/share/classes/java/util/stream/op/FindFirstOp.java ! src/share/classes/java/util/stream/op/OpUtils.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/primitive/IntTreeUtils.java From brian.goetz at oracle.com Fri Nov 30 06:53:12 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 14:53:12 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121130145405.0294B47C35@hg.openjdk.java.net> Changeset: cbef342202eb Author: briangoetz Date: 2012-11-30 09:52 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cbef342202eb Reintroduce StreamSource abstraction to provide delayed binding to underlying stream data; remove numerous utility implementations of Spliterator including ProxySpliterator; move int-array methods into Arrays; add parallel spliterator for iterator-backed streams ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleProxyLambdaMetafactory.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java + src/share/classes/java/util/stream/StreamSource.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedList.java + src/share/classes/java/util/stream/primitive/IntStreamSource.java ! src/share/classes/java/util/stream/primitive/IntTreeUtils.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/lang/CharSequenceStreamTest.java ! test-ng/tests/org/openjdk/tests/java/util/StringJoinerTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java Changeset: 5b10db63e38d Author: briangoetz Date: 2012-11-30 09:53 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5b10db63e38d Merge From georgiy.rakov at oracle.com Fri Nov 30 07:21:49 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 30 Nov 2012 19:21:49 +0400 Subject: uniqueElements().iterator() filters nulls out Message-ID: <50B8CF0D.3050803@oracle.com> Hello, if s is a sequential stream than s.uniqueElements().iterator() returns iterator which filters nulls out. Consider following code. import java.util.ArrayList; import java.util.Arrays; import java.util.Iterator; import java.util.List; public class UniqueElementsIssue2 { public static void main(String arg[]) { Iterator it = Arrays.asStream(1, 2, 3, null, 4, 5).uniqueElements().iterator(); Integer i = null; List result1 = new ArrayList<>(); while (it.hasNext()) { i = it.next(); result1.add(i); } List result2 = new ArrayList<>(); Arrays.asStream(1, 2, 3, null, 4, 5).uniqueElements().into(result2); System.out.println("resul1=" + Arrays.toString(result1.toArray())); System.out.println("resul2=" + Arrays.toString(result2.toArray())); } } It produces following output: resul1=[1, 2, 3, 4, 5] resul2=[1, 2, 3, null, 4, 5] result1 seems to be faulty while result2 is ok (into() works fine). As for me it's a bug but anyway could you please confirm that it is. Code above is attached for your convenience. Thanks, Georgiy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: UniqueElementsIssue2.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121130/d1c80aff/UniqueElementsIssue2.java From brian.goetz at oracle.com Fri Nov 30 07:49:50 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 15:49:50 +0000 Subject: hg: lambda/lambda/jdk: Remove Sized Message-ID: <20121130155003.3E23347C3B@hg.openjdk.java.net> Changeset: b23bf7b019ba Author: briangoetz Date: 2012-11-30 10:49 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b23bf7b019ba Remove Sized ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java - src/share/classes/java/util/Sized.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/Node.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSpinedList.java ! test-ng/build.xml ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From jim.gish at oracle.com Fri Nov 30 07:58:10 2012 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 30 Nov 2012 10:58:10 -0500 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: Message-ID: <50B8D792.9060601@oracle.com> Hi Roel, I'll take a look. Sorry for the delay -- got pulled into other things. Jim On 11/28/2012 02:41 PM, Roel Spilker wrote: > Hi all, > > On June 25 I sent some feedback on the implementation of StringJoiner. Most > of it is still relevant, none of it is addressed. Is there anything I can > do to get the implementation to a higher level? > > Roel > > Thread containing the feedback > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-June/005078.html > > Link to the current implementation > http://hg.openjdk.java.net/lambda/lambda/jdk/file/83923cc50252/src/share/classes/java/util/StringJoiner.java > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From paul.sandoz at oracle.com Fri Nov 30 08:05:50 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 30 Nov 2012 17:05:50 +0100 Subject: uniqueElements().iterator() filters nulls out In-Reply-To: <50B8CF0D.3050803@oracle.com> References: <50B8CF0D.3050803@oracle.com> Message-ID: Thanks for sending code as well, very helpful! I can reproduce on the tip. When pulling null is currently used as a sentinel value, easy to fix. However, you are gonna run into NPEs when going parallel and order is not preserved because ConcurrentHashMap is used. We need to decide on a consistent behaviour for nulls e.g. throw NPE under all case. Paul. On Nov 30, 2012, at 4:21 PM, Georgiy Rakov wrote: > Hello, > > if s is a sequential stream than s.uniqueElements().iterator() returns iterator which filters nulls out. > > Consider following code. > > import java.util.ArrayList; > import java.util.Arrays; > import java.util.Iterator; > import java.util.List; > > public class UniqueElementsIssue2 { > public static void main(String arg[]) { > Iterator it = Arrays.asStream(1, 2, 3, null, 4, > 5).uniqueElements().iterator(); > Integer i = null; > List result1 = new ArrayList<>(); > while (it.hasNext()) { > i = it.next(); > result1.add(i); > } > List result2 = new ArrayList<>(); > Arrays.asStream(1, 2, 3, null, 4, > 5).uniqueElements().into(result2); > System.out.println("resul1=" + > Arrays.toString(result1.toArray())); > System.out.println("resul2=" + > Arrays.toString(result2.toArray())); > } > } > > It produces following output: > > resul1=[1, 2, 3, 4, 5] > resul2=[1, 2, 3, null, 4, 5] > > result1 seems to be faulty while result2 is ok (into() works fine). > > As for me it's a bug but anyway could you please confirm that it is. > > Code above is attached for your convenience. > > Thanks, > Georgiy. > From georgiy.rakov at oracle.com Fri Nov 30 08:28:27 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Fri, 30 Nov 2012 20:28:27 +0400 Subject: uniqueElements().iterator() returns broken iterator Message-ID: <50B8DEAB.7080201@oracle.com> Hello again, when executing uniqueElements() on stream consisting of null elements broken iterator is returned. Consider following code. import java.util.ArrayList; import java.util.Arrays; import java.util.Iterator; import java.util.List; public class UniqueElementsIssue3 { public static void main(String arg[]) { Iterator it = Arrays.asStream(new Integer[]{null, null, null}).uniqueElements().iterator(); Integer i = null; List result1 = new ArrayList<>(); while (it.hasNext()) { i = it.next(); result1.add(i); } System.out.println("resul1=" + Arrays.toString(result1.toArray())); } } This code throws the exception with following stacktrace. Exception in thread "main" java.util.NoSuchElementException at java.util.streams.ops.UniqOp$2.next(UniqOp.java:118) at UniqueElementsIssue3.main(UniqueElementsIssue3.java:19) The reason is obvious: it.next() fails while it.hasNext() returns true. This occurs for stream in parallel mode as well. Could you please tell when we could expect this bug to be fixed (and others on uniqueElements - see two my previous letters). Source code is attached for your convenience. Thanks, Georgiy, -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: UniqueElementsIssue3.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121130/59e5a5f1/UniqueElementsIssue3.java From brian.goetz at oracle.com Fri Nov 30 09:14:49 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 17:14:49 +0000 Subject: hg: lambda/lambda/jdk: Get rid of type Spliterator.Sequential; limited merging in WrappingSpliterator Message-ID: <20121130171505.3B7AB47C40@hg.openjdk.java.net> Changeset: 55ce0f66ce3b Author: briangoetz Date: 2012-11-30 12:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55ce0f66ce3b Get rid of type Spliterator.Sequential; limited merging in WrappingSpliterator ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/primitive/IntSpliterator.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/function/IntUnaryOperatorTest.java From paul.sandoz at oracle.com Fri Nov 30 09:21:57 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 30 Nov 2012 18:21:57 +0100 Subject: uniqueElements().iterator() returns broken iterator In-Reply-To: <50B8DEAB.7080201@oracle.com> References: <50B8DEAB.7080201@oracle.com> Message-ID: <753F15A2-8D9F-43B4-8E40-4641B6E7EFB4@oracle.com> Thanks. Note that the EG is still cogitating on what to be about nulls. Until agreement is reached this area is up for change. However, i will fix things next week so nulls are not ignored and java.util.NoSuchElementException is not thrown on iteration. Paul. On Nov 30, 2012, at 5:28 PM, Georgiy Rakov wrote: > Hello again, > > when executing uniqueElements() on stream consisting of null elements broken iterator is returned. > > Consider following code. > > import java.util.ArrayList; > import java.util.Arrays; > import java.util.Iterator; > import java.util.List; > > public class UniqueElementsIssue3 { > public static void main(String arg[]) { > Iterator it = Arrays.asStream(new Integer[]{null, > null, null}).uniqueElements().iterator(); > Integer i = null; > List result1 = new ArrayList<>(); > while (it.hasNext()) { > i = it.next(); > result1.add(i); > } > System.out.println("resul1=" + > Arrays.toString(result1.toArray())); > } > } > > This code throws the exception with following stacktrace. > > Exception in thread "main" java.util.NoSuchElementException > at java.util.streams.ops.UniqOp$2.next(UniqOp.java:118) > at UniqueElementsIssue3.main(UniqueElementsIssue3.java:19) > > The reason is obvious: it.next() fails while it.hasNext() returns true. > This occurs for stream in parallel mode as well. > > Could you please tell when we could expect this bug to be fixed (and others on uniqueElements - see two my previous letters). > > Source code is attached for your convenience. > > Thanks, > Georgiy, > From paul.sandoz at oracle.com Fri Nov 30 09:30:58 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 30 Nov 2012 17:30:58 +0000 Subject: hg: lambda/lambda/jdk: Intermediate node for parallel evaluation or spliterator should Message-ID: <20121130173111.3478D47C43@hg.openjdk.java.net> Changeset: 5262dcc62fd0 Author: psandoz Date: 2012-11-30 18:30 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5262dcc62fd0 Intermediate node for parallel evaluation or spliterator should only inject SIZED. ! src/share/classes/java/util/stream/AbstractPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java From akhil.arora at oracle.com Fri Nov 30 10:44:26 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Fri, 30 Nov 2012 10:44:26 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers Message-ID: <50B8FE8A.2030403@oracle.com> Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks From vitalyd at gmail.com Fri Nov 30 10:59:39 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 13:59:39 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50B8FE8A.2030403@oracle.com> References: <50B8FE8A.2030403@oracle.com> Message-ID: Hi Akhil, At least for Integer.min/max you may want to use Math.min/max - these are jit intrinsics. I'd probably use the Math methods for all matching types (int, long, float, double) to cover the bases. Thanks Sent from my phone On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: > Hi > > Requesting review for some basic functionality related to lambdas - > > Add min, max, sum methods to the primitive wrapper classes - Byte, Short, > Integer, Long, Float, Double and Character so as to be able to use them as > reducers in lambda expressions. Add and, or, xor methods to Boolean. > > http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 > > Thanks > From paul.sandoz at oracle.com Fri Nov 30 11:09:29 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 30 Nov 2012 19:09:29 +0000 Subject: hg: lambda/lambda/jdk: Streams.repeat defers to Streams.repeatedly Message-ID: <20121130190940.BA17047C44@hg.openjdk.java.net> Changeset: 1e85112dff65 Author: psandoz Date: 2012-11-30 20:09 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1e85112dff65 Streams.repeat defers to Streams.repeatedly ! src/share/classes/java/util/stream/Streams.java From vitalyd at gmail.com Fri Nov 30 11:22:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 14:22:35 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50B906D2.9050408@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50B906D2.9050408@oracle.com> Message-ID: Yup, exactly. I specifically called out the int version as the one to at least change over to Math since I know that's intrinsified. Thanks Kris Sent from my phone On Nov 30, 2012 2:19 PM, "Krystal Mo" wrote: > Hi Vitaly, > > Right now HotSpot only declares and implements the (int,int)->int version > of Math.min/max as intrinsics. > Nevertheless, it wouldn't hurt to use the Math methods, in hope that > they'll get more love in the future :-) > > - Kris > > On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: > >> Hi Akhil, >> >> At least for Integer.min/max you may want to use Math.min/max - these are >> jit intrinsics. I'd probably use the Math methods for all matching types >> (int, long, float, double) to cover the bases. >> >> Thanks >> >> Sent from my phone >> On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: >> >> Hi >>> >>> Requesting review for some basic functionality related to lambdas - >>> >>> Add min, max, sum methods to the primitive wrapper classes - Byte, Short, >>> Integer, Long, Float, Double and Character so as to be able to use them >>> as >>> reducers in lambda expressions. Add and, or, xor methods to Boolean. >>> >>> http://cr.openjdk.java.net/~****akhil/8004201.0/webrev/ >>> >>> > >>> http://bugs.sun.com/****bugdatabase/view_bug.do?bug_****id=8004201 >>> >>> > >>> >>> Thanks >>> >>> > From krystal.mo at oracle.com Fri Nov 30 11:19:46 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Sat, 01 Dec 2012 03:19:46 +0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: References: <50B8FE8A.2030403@oracle.com> Message-ID: <50B906D2.9050408@oracle.com> Hi Vitaly, Right now HotSpot only declares and implements the (int,int)->int version of Math.min/max as intrinsics. Nevertheless, it wouldn't hurt to use the Math methods, in hope that they'll get more love in the future :-) - Kris On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: > Hi Akhil, > > At least for Integer.min/max you may want to use Math.min/max - these are > jit intrinsics. I'd probably use the Math methods for all matching types > (int, long, float, double) to cover the bases. > > Thanks > > Sent from my phone > On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: > >> Hi >> >> Requesting review for some basic functionality related to lambdas - >> >> Add min, max, sum methods to the primitive wrapper classes - Byte, Short, >> Integer, Long, Float, Double and Character so as to be able to use them as >> reducers in lambda expressions. Add and, or, xor methods to Boolean. >> >> http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ >> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 >> >> Thanks >> From brian.goetz at oracle.com Fri Nov 30 12:56:54 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 20:56:54 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121130205719.0EEA847C48@hg.openjdk.java.net> Changeset: 96f7957e8b39 Author: briangoetz Date: 2012-11-30 15:55 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/96f7957e8b39 Make all sizes in Streams 64 bits ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/StreamSource.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SeedlessFoldOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSeedlessFoldOp.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedList.java ! src/share/classes/java/util/stream/primitive/IntStreamSource.java ! src/share/classes/java/util/stream/primitive/IntTreeUtils.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java Changeset: 6a8f5382f238 Author: briangoetz Date: 2012-11-30 15:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6a8f5382f238 Merge ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/Streams.java From dmitry.bessonov at oracle.com Fri Nov 30 13:39:06 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Sat, 01 Dec 2012 01:39:06 +0400 Subject: NPEs Re: uniqueElements().iterator() returns broken iterator In-Reply-To: <753F15A2-8D9F-43B4-8E40-4641B6E7EFB4@oracle.com> References: <50B8DEAB.7080201@oracle.com> <753F15A2-8D9F-43B4-8E40-4641B6E7EFB4@oracle.com> Message-ID: <50B9277A.6000703@oracle.com> On 30.11.2012 21:21, Paul Sandoz wrote: > Thanks. > > Note that the EG is still cogitating on what to be about nulls. Until agreement is reached this area is up for change. BTW, I have bumped once again into NPE thrown from Arrays.asStream(null, null, null).findFirst(); Arrays.asStream(null, null, null).findAny(); And the previous answer for the this question was that it's an expected NPE. However as it was pointed out recently - a "bare" NPE thrown from inside the implementation might not be a great thing: Exception in thread "main" java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:201) at java.util.Optional.(Optional.java:53) at java.util.streams.ops.FindAnyOp.evaluate(FindAnyOp.java:56) at java.util.streams.ops.FindAnyOp.evaluateSequential(FindAnyOp.java:51) at java.util.streams.ops.FindAnyOp.evaluateSequential(FindAnyOp.java:36) at java.util.streams.AbstractPipeline.evaluateSequential(AbstractPipeline.java:206) at java.util.streams.AbstractPipeline.evaluate(AbstractPipeline.java:134) at java.util.streams.AbstractPipeline.pipeline(AbstractPipeline.java:487) at java.util.streams.ValuePipeline.findAny(ValuePipeline.java:157) -Dmitry > > However, i will fix things next week so nulls are not ignored and java.util.NoSuchElementException is not thrown on iteration. > > Paul. > > > On Nov 30, 2012, at 5:28 PM, Georgiy Rakov wrote: > >> Hello again, >> >> when executing uniqueElements() on stream consisting of null elements broken iterator is returned. >> >> Consider following code. >> >> import java.util.ArrayList; >> import java.util.Arrays; >> import java.util.Iterator; >> import java.util.List; >> >> public class UniqueElementsIssue3 { >> public static void main(String arg[]) { >> Iterator it = Arrays.asStream(new Integer[]{null, >> null, null}).uniqueElements().iterator(); >> Integer i = null; >> List result1 = new ArrayList<>(); >> while (it.hasNext()) { >> i = it.next(); >> result1.add(i); >> } >> System.out.println("resul1=" + >> Arrays.toString(result1.toArray())); >> } >> } >> >> This code throws the exception with following stacktrace. >> >> Exception in thread "main" java.util.NoSuchElementException >> at java.util.streams.ops.UniqOp$2.next(UniqOp.java:118) >> at UniqueElementsIssue3.main(UniqueElementsIssue3.java:19) >> >> The reason is obvious: it.next() fails while it.hasNext() returns true. >> This occurs for stream in parallel mode as well. >> >> Could you please tell when we could expect this bug to be fixed (and others on uniqueElements - see two my previous letters). >> >> Source code is attached for your convenience. >> >> Thanks, >> Georgiy, >> > From brian.goetz at oracle.com Fri Nov 30 15:15:06 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 30 Nov 2012 18:15:06 -0500 Subject: Bikeshed opportunity: filter/map/reduce naming Message-ID: <50B93DFA.3050907@oracle.com> Hey, kids, its bikeshed time again! The topic today is: filter, map, reduce. Should they be called something else? (No, Don, we're not going with the Dr. Seuss names. :) But, people have complained about filter because they can't tell whether we are filtering OUT the elements matching the predicate, or including them. Some of these people have suggested "where(Predicate)" as an alternative. Which seems OK to me. Others find "map" too math-y. (The alternatives I can think of are also math-y; project, transform, apply). Further, "reduce" and "fold" are unfamiliar to many Java developers. The .NET folks went with "aggregate" to describe their reduction/folding operations. From brian.goetz at oracle.com Fri Nov 30 15:25:50 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 30 Nov 2012 23:25:50 +0000 Subject: hg: lambda/lambda/jdk: More 64 bit Message-ID: <20121130232637.261A947C50@hg.openjdk.java.net> Changeset: 93ad4413f0ce Author: briangoetz Date: 2012-11-30 18:25 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/93ad4413f0ce More 64 bit ! src/share/classes/java/util/stream/primitive/IntLimitOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java From brian.goetz at oracle.com Fri Nov 30 15:26:51 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 30 Nov 2012 18:26:51 -0500 Subject: Bikeshed opportunity: filter/map/reduce naming In-Reply-To: <50B93DFA.3050907@oracle.com> References: <50B93DFA.3050907@oracle.com> Message-ID: <50B940BB.8030804@oracle.com> [ actually, this was aimed at the EG list (dang prefill); this topic is decidedly off-topic for lambda-dev, so please take responses to the EG observers list. ] On 11/30/2012 6:15 PM, Brian Goetz wrote: > Hey, kids, its bikeshed time again! > > The topic today is: filter, map, reduce. Should they be called > something else? > > (No, Don, we're not going with the Dr. Seuss names. :) > > But, people have complained about filter because they can't tell whether > we are filtering OUT the elements matching the predicate, or including > them. Some of these people have suggested "where(Predicate)" as an > alternative. Which seems OK to me. > > Others find "map" too math-y. (The alternatives I can think of are also > math-y; project, transform, apply). > > Further, "reduce" and "fold" are unfamiliar to many Java developers. > The .NET folks went with "aggregate" to describe their reduction/folding > operations. > > From mike.duigou at oracle.com Fri Nov 30 17:05:47 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 01 Dec 2012 01:05:47 +0000 Subject: hg: lambda/lambda/jdk: minor cleanups and javadoc in functional interfaces Message-ID: <20121201010600.AC51A47C61@hg.openjdk.java.net> Changeset: 684d9206e9fa Author: mduigou Date: 2012-11-30 17:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/684d9206e9fa minor cleanups and javadoc in functional interfaces ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/package-info.java