Re: Shouldn't Optional be Serializable?
Amplifying Mike's observations: this exploration is already covered ground. The JSR-335 EG felt fairly strongly that Optional should not be on any more than needed to support the optional-return idiom only. (Someone suggested maybe even renaming it to OptionalReturn to beat users over the head with this design orientation; perhaps we should have taken that suggestion.) I get that lots of people want Optional to be something else. But, its not simply the case that the EG "forgot" to make it serializable; they explicitly chose not to. And there's certainly been no new data that has come to light that would motivate us to set that choice aside at this point. On Sep 28, 2013, at 2:15 AM, Mike Duigou wrote: > > On Sep 17 2013, at 16:32 , Vitaly Davidovich wrote: > >> Presumably because you may want to have class fields that express >> nullability via Optional rather than null. > > Using Optional as a field type doesn't seem to offer much. > > Would the Optional field be wrapped in accessors? > > If it's not wrapped, the result is that orElse(default) gets spread across > the usage of the field which is a poor way to apply a default. > > If if it is wrapped, why not apply the default in the accessor or in the > setter and not bother with Optional? > >> Whether that's a good design or >> not is a separate question; > > That's not generally how JDK expert groups think. Adding any feature to > intentionally support bad design wouldn't make much sense. Understanding the > dimensions of how a feature might be used is certainly something that the EG > spends a lot of time on. The choice of semantics, methods offered and > interfaces implemented isn't ever separated from the expected use cases. > Optional is a new class/feature to the JDK and it seemed appropriate to start > with a minimal implementation. Concern that Optional would be misused in > other use cases threatened to derail it's inclusion in Java entirely! > Optional is being added for the value it offers in "fluent" sequences of > statements. In this context use of Optional as a visible type or for > serialization isn't relevant. > >> conceptually, I don't see a reason why Optional >> cannot support that. For "reference", Google Guava's version is >> serializable. > > Guava's Optional certainly proves that it is technically possible (which was > probably already known anyway) but that doesn't address whether doing so with > the Java Optional would be a good idea or not. > >> If someone were to replace their use with jdk's Optional >> then they will hit exceptions if the owner class is serialized. > > While the incompatibility is certainly unfortunate this is probably not a > sufficient reason by itself to make Java's Optional serializable. > > Mike > >> Sent from my phone >> On Sep 17, 2013 6:06 PM, "Remi Forax" wrote: >> >>> On 09/17/2013 11:44 PM, Pete Poulos wrote: >>> Shouldn't java.util.Optional be Serializable? Is there a good reason for it not be? >>> >>> wrong question. >>> the right one is why do you want Optional to be Serializable. >>> >>> Thanks, Pete >>> >>> cheers, >>> Rémi >>> >>> >
Re: Shouldn't Optional be Serializable?
> It sounds like this should have been named something else entirely then, > not Optional. Perhaps. But we're not going to consume infinite time (and every experience we've had so far with Optional suggests that it truly is unbounded) correcting this mistake. Anyway, I won't comment further on Optional because there's little value in continuing the discussion. Just one correction: > I buy this argument if there's some > non-negligible cost to adding a feature (perf loss, code maintenance, back > compat issues, complexity, etc) but that's not the case here. You would be incorrect. Making something in the JDK serializable makes a dramatic increase in our maintenance costs, because it means that the representation is frozen for all time. This constrains our ability to evolve implementations in the future, and the number of cases where we are unable to easily fix a bug or provide an enhancement, which would otherwise be simple, is enormous. So, while it may look like a simple matter of "implements Serializable" to you, it is more than that. The amount of effort consumed by working around an earlier choice to make something serializable is staggering. (You can always argue "but this case is different", and it might be, but that still would presuppose that we think its a good idea.)
Re: CFV: New jdk8 Reviewer: Staffan Larsen
Vote: yes Sent from my iPhone On Oct 2, 2013, at 7:13 AM, Alan Bateman wrote: > I hereby nominate Staffan Larsen to jdk8 Reviewer. > > Staffan leads the serviceability area in Oracle's JDK team and has been > contributing changes to OpenJDK since Dec 2010. He has Reviewer role on the > hsx project and is author of ~80 changes in the jdk8 forest. He has also > co-reviewed ~100 other changes in the jdk8 forest. > > Votes are due by Oct 17, 2013, 06:00 PDT. > > Only current jdk8 Reviewers[1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote
Re: Javadoc for default methods of an interface
There are some new javadoc tags to let you separate normative from non-normative, and how it applies separately to the interface vs the default implementation. They are: @implSpec -- *specification* about what the default implementation does, such as "the default implementation throws UOE". This can be counted on by subclasses to make decisions about "should I override this or not". @implNote -- non-normative notes about the implementation, which historically have been prefaced by "implementation note". @apiNote -- non-normative notes about the API, such as examples of how to use it. The fourth quadrant, normative spec about the interface, needs no tag since that's what the spec is for. On 2/5/2014 12:42 PM, Behrooz N wrote: Hi, I was wondering if there is a way to specify the "default" value returned by a defender method of an interface that would be processed specifically by javadoc of Java 8? And, how fair this expectation is or what is the argument not to have it? Thanks in advance, Behrooz
Re: JEP 138: Autoconf-Based Build System
The JEP explicitly states that these would be follow-on projects, presumably to narrow the scope of this project so that it can get deployed more quickly. Once the build system has a model of the project, it will be possible generate projects configurations for popular IDEs at autoconfig time, eliminating the need to keep IDE projects in sync with the project layout. On 2/21/2012 5:35 PM, Jonathan Gibbons wrote: On 02/21/2012 02:10 PM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/138 - Mark Many developers use IDEs. It would seem to be a regressive step for "Support IDE projects" to be a Non Goal. -- Jon
Re: First build-infra push to jdk8 -- try out the new build system!
Is there a list of "features" that can be turned on and off? With the old build, I customize it with environment variables like SKIP_FASTDEBUG_BUILD, NO_DOCS, NO_SAMPLES, and NO_DEMOS, which shaves lots of time off the build. Are there equivalent configure flags for these? On 4/12/2012 5:47 AM, Magnus Ihse Bursie wrote: The build-infra project [1] has been working for a while with creating a new build system. The goals of the project include, but are not limited to, improved build performance and improved ease of use. The first part of this project has now been pushed to the jdk8 master forest. This means that the new build system is available for you to try out! The old build system is still there, and if you want to continue to use it, you will notice no difference (for now...). But if you are interested in trying the new build system, we welcome you to experiment with it! The basic operation is: cd common/makefiles ../autoconf/configure make More information is available in the new build README [2]. If you want to try the new build system, please read it first. Please note that the new build system is not yet complete. We do not yet have full platform support, nor are all parts of the old build converted (but then we fall back on the old build system), and there are likely to be bugs. Most of all, we need to have exposure on a wide range of different build systems, since the reality is always so much messier than you'd want to believe. :-) Please help us to resolve such issues early by trying the new build system! Any questions or discussions on the new build system should be sent to build-...@openjdk.java.net. /Magnus [1] http://openjdk.java.net/projects/build-infra/index.html [2] http://openjdk.java.net/projects/build-infra/guide.html
Re: CFV: New JDK8 Committer: Robert Field
Vote: Yes On 10/5/2012 5:21 AM, Maurizio Cimadamore wrote: I hereby nominate Robert Field to JDK8 Committer. Robert works in the Langtools team at Oracle, and has already contributed several change sets to the Lambda repository. Robert will be contributing to the integration effort aimed at porting bits from the lambda repository back to the main JDK 8 repository. Previously, Robert has made significant contributions in several Java-related projects, such as JDI, Doclets and JavaFX. He was also spec lead in JSR 45 (Debugging Support for Other Languages) and JSR 163 (JavaTM Platform Profiling Architecture). Votes are due by October 18, 2012. Only current JDK8 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Maurizio Cimadamore [1]http://openjdk.java.net/census [2]http://openjdk.java.net/projects/#committer-vote
Re: What is the type of a "method reference"?
(sorry for slow reply)
Method references, and lambda expressions, have no intrinsic type; their
type depends on their context. Their type will *always* be a functional
interface, which is an interface with a single abstract method.
The compiler will enforce that the arity, argument types, return type,
and exceptions are compatible (modulo allowable adaptations such as
boxing, unboxing, or widening).
Here's an example where the "same" method ref could take on different types:
interface Predicate {
boolean test(T arg);
}
interface Function {
U apply(T arg);
}
Predicate p = String::isEmpty;
Function f = String::isEmpty;
So, we see here that the method ref String::isEmpty (which refers to the
nilary boolean-returning instance method) is compatible with either
Predicate or Function (the latter entails
boxing.)
The type of a method reference depends on its context. It could pick up
type information from assignment context (as above), method invocation
context, cast context, etc.
The following is illegal:
Object o = String::isEmpty;
because we don't know what functional interface to convert
String.isEmpty() to. But the following is legal:
Object o = (Predicate) String::isEmpty;
Block was renamed to Consumer.
On 6/11/2013 5:50 PM, Behrooz Nobakht wrote:
Hi,
I have a question regarding the method references in Java 8. Let's say that
I have a class:
class MyClass {
Object doSomething(Object o);
}
And, I'm using the method reference MyClass::doSomething in a call
such as SomeOtherClass.doAnotherThing(p,
MyClass::doSomething). In this call, let's assume that p is an arbitrary
parameter and doAnotherThing method knows how to provide the parameter for
doSomething.
My question is that how should the method doAnotherThing be declared?
Studying the source code of Java 8, I found out that before Java 8 version
b75, there was an abstraction java.util.function.Block which was removed
from further revisions.
So, maybe, another question is that since Block is not available what is
its best replacement in the current version of Java 8? What is the
top-level abstraction that represents a block of code such as a method
reference? Or, in other words, if using lambdas, what is the type that
could replace a lambda in method definitions?
Having Block allowed to use define methods with parameters that are as
general as a block of code (a method reference). Now, what should be used
instead?
I would appreciate your answers and explanations.
Best,
Behrooz
Re: CFV: New JDK8 Committer: Henry Jen
Vote: Yes On 7/12/2013 5:45 PM, Mike Duigou wrote: I hereby nominate Henry Jen (henryjen) to JDK8 Committer. In addition to providing important contributions to the lambdafication and streams effort Henry has shepherded a number of changesets for others through the OpenJDK process and is ably qualified and experienced for the committer role. Authored changesets: 8017141: java.util/stream Spliterators from sequential sources should not catch OOME 8009736: Comparator API cleanup 8016448: java/util/BitSet/BitSetStreamTest.java no longer compiles, missed by 8015895 8015522: CharSequence.codePoints can be faster 8006884: (fs) Add Files.list, lines and find 8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE Contributed-by changesets: 8015315: Stream.concat methods 8015317: Optional.filter, map, and flatMap 8017231: Add StringJoiner.merge 8015522: CharSequence.codePoints can be faster 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported 8014731: j.u.stream.StreamSupport class has default constructor generated 8006884: (fs) Add Files.list, lines and find 8003258: BufferedReader.lines() 8012665: add CharSequence.chars, CharSequence.codePoints 8004518: Add in-place operations to Map 8001667: Comparator combinators and extension methods 8005632: Extend java.util.Logger to use Supplier for messages Votes are due by 2013-07-26T2359PDT. Only current JDK8 Committers and Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. Mike [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote
Re: CFV: New JDK8 Committer: Roger Riggs
Vote: Yes On Jul 29, 2013, at 2:21 PM, Xueming Shen wrote: > I hereby nominate Roger Riggs to JDK8 Committer. > > Roger Riggs has contributed 8 patches to the JDK 8 repositories. Roger > is the co-spec lead of the JSR310 and one of the main code contributors > of jdk8 JSR310 project. > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/log?rev=roger.riggs > http://hg.openjdk.java.net/jdk8/tl/jdk/log?rev=roger.riggs > > Votes are due by 02:10:00 PDT, August 12, 2013. > > Only current jdk8 Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > - Xueming Shen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote
