jdk-dev Digest, Vol 17, Issue 21
Mary Rose de Vega
susmaryosep80 at gmail.com
Fri Feb 22 02:51:50 UTC 2019
what else do you want me to do there it said close fro development they
still investigating i wonder what those research team are doing this time
why they getting that long to find me to its funny to think of them to be
sitting and let me do their job
On Fri, Feb 22, 2019 at 9:16 AM <jdk-dev-request at openjdk.java.net> wrote:
> Send jdk-dev mailing list submissions to
> jdk-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.openjdk.java.net/mailman/listinfo/jdk-dev
> or, via email, send a message with subject or body 'help' to
> jdk-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> jdk-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of jdk-dev digest..."
>
>
> Today's Topics:
>
> 1. Is it a feature abuse to introduce default methods in new
> interfaces? (Jaikiran Pai)
> 2. Re: Is it a feature abuse to introduce default methods in new
> interfaces? (Daniel Fuchs)
> 3. jtreg 4.2-b14 (Jonathan Gibbons)
> 4. Re: RFR(S) : 8219417 : bump jtreg requiredVersion to b14
> (Igor Ignatyev)
> 5. Re: Is it a feature abuse to introduce default methods in new
> interfaces? (Joseph D. Darcy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Feb 2019 20:05:25 +0530
> From: Jaikiran Pai <jai.forums2013 at gmail.com>
> To: jdk-dev at openjdk.java.net
> Subject: Is it a feature abuse to introduce default methods in new
> interfaces?
> Message-ID: <cb6c754b-9f8a-2a6a-6c97-1af504d60e64 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> I have been trying to find some authoritative answer on when _not_ to
> use default methods on interfaces (a feature introduced in Java 8). The
> official documentation in Java, about this feature, talks about the
> motivation[1] behind introducing this feature and explains how
> _existing_ interfaces can be changed to add default methods without
> breaking binary compatibility:
>
> "Default methods enable you to add new functionality to the interfaces
> of your libraries and ensure binary compatibility with code written for
> older versions of those interfaces."
>
> This and some other docs don't mention whether it's an accepted practice
> or abuse of default methods feature, when dealing with new interfaces.
> Is it fine to introduce new interfaces with default methods? I have
> tried searching the mailing list archives to see if it's discussed
> previously but my search terms haven't found anything relevant. Any
> previous authoritative answer, similar to Stuart Mark's reply on
> stackoverflow (on a different topic) about Optional usage[2], is also
> good enough.
>
> [1] https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
>
> [2]
>
> https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794
>
> -Jaikiran
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Feb 2019 14:54:41 +0000
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> To: Jaikiran Pai <jai.forums2013 at gmail.com>, jdk-dev at openjdk.java.net
> Subject: Re: Is it a feature abuse to introduce default methods in new
> interfaces?
> Message-ID: <50d78e39-407a-4f1c-5107-8e6f8b8ab1f3 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Jaikiran,
>
> I don't think this is an abuse, and I'd say that the decision on
> whether to provide a default implementation for a new interface
> probably depends on how well you estimate that the default
> implementation will match what concrete subclass would have to
> implement. Even if that's not an authoritative answer ;-)
>
> I don't know if that's representative but Stream.Builder for
> instance, came with a default add( ) method:
>
>
> https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html
>
> best regards,
>
> -- daniel
>
> On 21/02/2019 14:35, Jaikiran Pai wrote:
> > I have been trying to find some authoritative answer on when _not_ to
> > use default methods on interfaces (a feature introduced in Java 8). The
> > official documentation in Java, about this feature, talks about the
> > motivation[1] behind introducing this feature and explains how
> > _existing_ interfaces can be changed to add default methods without
> > breaking binary compatibility:
> >
> > "Default methods enable you to add new functionality to the interfaces
> > of your libraries and ensure binary compatibility with code written for
> > older versions of those interfaces."
> >
> > This and some other docs don't mention whether it's an accepted practice
> > or abuse of default methods feature, when dealing with new interfaces.
> > Is it fine to introduce new interfaces with default methods? I have
> > tried searching the mailing list archives to see if it's discussed
> > previously but my search terms haven't found anything relevant. Any
> > previous authoritative answer, similar to Stuart Mark's reply on
> > stackoverflow (on a different topic) about Optional usage[2], is also
> > good enough.
> >
> > [1]
> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
> >
> > [2]
> >
> https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794
> >
> > -Jaikiran
> >
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Feb 2019 09:08:10 -0800
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> To: "jdk-dev at openjdk.java.net" <jdk-dev at openjdk.java.net>,
> "jtreg-use at openjdk.java.net" <jtreg-use at openjdk.java.net>
> Subject: jtreg 4.2-b14
> Message-ID: <12528e93-df6e-6bb9-3d45-82c067b18c0b at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Some of you may have noticed that a new version of jtreg is available
> (jtreg4.2-b14) and is now being required in various JDK test suites.
>
> There are two note-worthy features in this update.
>
> 1. Action tags (like `@compile` or `@run main`) now support variable
> substitution in command arguments, using the syntax `${name}`. The
> set of names is the same as that for the `@requires` tag.? The
> feature is enabled by default for test suites that specify the use
> of jtreg4.2-b14 or later.
>
> 2. Support is now available for using Windows Subsystem for Linux (WSL)
> as an alternative to Cygwin to run shell tests on Windows 10. This
> complements the recent new ability to build OpenJDK using WSL. Note
> that shell tests will also need to be updated in order to use this
> feature: a discussion of the issues and some recommendations have
> been posted on the OpenJDK website:
> https://openjdk.java.net/jtreg/shellTests.html
>
> Many of the updates have been changes to the documentation, such as the
> jtreg FAQ:
> https://openjdk.java.net/jtreg/faq.html
>
> A full list of changes can be found here:
>
> http://hg.openjdk.java.net/code-tools/jtreg/search/?rev=%22jtreg4.2-b13%22%3A%22jtreg4.2-b14%22&revcount=80
>
> -- Jon
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Feb 2019 14:07:05 -0800
> From: Igor Ignatyev <igor.ignatyev at oracle.com>
> To: David Holmes <david.holmes at oracle.com>
> Cc: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: RFR(S) : 8219417 : bump jtreg requiredVersion to b14
> Message-ID: <F44830EC-4382-4E06-ADC0-A125D0A54610 at oracle.com>
> Content-Type: text/plain; charset=us-ascii
>
> David,
>
> I tend to agree w/ Alan here, I'd also prefer us to have required version
> bumped in all test suites together as it decreases differences in observed
> test behavior and simplifies test failure analyses. w/ that being,
> test/jdk/sanity/client/ is a different beast, it's not a real test suite,
> it's unclear if TEST.ROOT.template is ever used, and requiredVersion is
> commented out in TEST.properties. I've filed 8219552 [1] and assigned it to
> Muneer(cc'ed), who runs and maintains these tests, to deal w/ these files
> separately.
>
> [2] is the webrev w/ TEST.ROOT files updated in all the test suites.
> unless there are other comments, suggestions, objections, I'd like to
> process w/ reviewing of this patch.
>
> Side note: all (two) well-known publishers of jtreg builds have been
> notified about the new version and have already created and published
> binaries at their usual location.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8219552 <
> https://bugs.openjdk.java.net/browse/JDK-8219552>
> [2] http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html <
> http://cr.openjdk.java.net/~iignatyev//8219417/webrev.01/index.html>
>
> Thanks,
> -- Igor
>
> > On Feb 20, 2019, at 1:10 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > On 20/02/2019 08:44, David Holmes wrote:
> >>
> >> On 20/02/2019 5:25 pm, Alan Bateman wrote:
> >>> I think it's important that everyone is using the same minium version
> of jtreg when running the tests. If some people are using b14 (by way of
> using jib) then they may end up pushing test changes that fail for the
> those of us that run jtreg directly. So I think it is better to just bump
> the required version everywhere, after socialization of course as it takes
> a bit of time to build or find a pre-built jtreg.
> >> I don't really care either way, but that's not what has been happening
> to-date. Client area in particular still seems to be requiring only 4.1.
> > It can be tricky to track down issues that stem from using different
> versions of the test runner so I think we should fix that and have both
> infrastructure and local testing use the same min version if possible. The
> tests for client-libs are under test/jdk where the TEST.ROOT has 4.2 b13 as
> the required version. There are a sanity tests that gatekeepers use to run
> SwingSet demos as sanity tests - Phil might be able to saw more about those
> and whether those tests care about the jtreg version or not.
> >
> > -Alan
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 Feb 2019 17:15:33 -0800
> From: "Joseph D. Darcy" <joe.darcy at oracle.com>
> To: Daniel Fuchs <daniel.fuchs at oracle.com>, Jaikiran Pai
> <jai.forums2013 at gmail.com>, jdk-dev at openjdk.java.net
> Subject: Re: Is it a feature abuse to introduce default methods in new
> interfaces?
> Message-ID: <5C6F4D35.6090605 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> FWIW, I wouldn't necessarily consider default methods on a new interface
> an abuse. The existence of default methods on interfaces changes the
> trade-offs between having an interface paired with an abstract helper
> implementation vs an interface with default methods.
>
> HTH,
>
> -Joe
>
>
> On 2/21/2019 6:54 AM, Daniel Fuchs wrote:
> > Hi Jaikiran,
> >
> > I don't think this is an abuse, and I'd say that the decision on
> > whether to provide a default implementation for a new interface
> > probably depends on how well you estimate that the default
> > implementation will match what concrete subclass would have to
> > implement. Even if that's not an authoritative answer ;-)
> >
> > I don't know if that's representative but Stream.Builder for
> > instance, came with a default add( ) method:
> >
> >
> https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.Builder.html
> >
> >
> > best regards,
> >
> > -- daniel
> >
> > On 21/02/2019 14:35, Jaikiran Pai wrote:
> >> I have been trying to find some authoritative answer on when _not_ to
> >> use default methods on interfaces (a feature introduced in Java 8). The
> >> official documentation in Java, about this feature, talks about the
> >> motivation[1] behind introducing this feature and explains how
> >> _existing_ interfaces can be changed to add default methods without
> >> breaking binary compatibility:
> >>
> >> "Default methods enable you to add new functionality to the interfaces
> >> of your libraries and ensure binary compatibility with code written for
> >> older versions of those interfaces."
> >>
> >> This and some other docs don't mention whether it's an accepted practice
> >> or abuse of default methods feature, when dealing with new interfaces.
> >> Is it fine to introduce new interfaces with default methods? I have
> >> tried searching the mailing list archives to see if it's discussed
> >> previously but my search terms haven't found anything relevant. Any
> >> previous authoritative answer, similar to Stuart Mark's reply on
> >> stackoverflow (on a different topic) about Optional usage[2], is also
> >> good enough.
> >>
> >> [1]
> >> https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
> >>
> >> [2]
> >>
> https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >
>
>
>
> End of jdk-dev Digest, Vol 17, Issue 21
> ***************************************
>
--
Hot Momma
More information about the jdk-dev
mailing list