Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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 i
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.ander...@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.ander...@oracle.com > > > > >
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.ander...@oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On Nov 30, 2012, at 7:56 AM, Remi Forax wrote: > On 11/30/2012 01:50 PM, 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. > > @implementation ? > >> >> 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 > > an UnsupportedOperationException is better for that. Agree that could be a better choice > >> or a SQLFeatureNotSupportedException for methods which may be optional based >> on the backend support. > > Rémi > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 11/30/2012 01:50 PM, 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. @implementation ? 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 an UnsupportedOperationException is better for that. or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. Rémi
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.ander...@oracle.com
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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.
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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
JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces)
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. -- - DML
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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
>
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 11/27/2012 03:12 AM, 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.
+public interface DoubleBinaryOperator extends BinaryOperator {
Doesn't the extends go in the wrong direction? Not every
BinaryOperator can be be used as a DoubleBinaryOperator because
of null values. I think the documentation should reflect that.
--
Florian Weimer / Red Hat Product Security Team
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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
Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
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
