Field and Method Literals
Neal Gafter
neal at gafter.com
Mon Nov 21 15:47:06 PST 2011
Brian-
I think we'd all feel more comfortable if we could review for ourselves *how
*the issues have been considered by the expert group. Oracle long ago
promised to provide a public mailing list where subscribers could see the
expert groups deliberations. Hearing your periodic assurances that the
expert group is on top of things doesn't really serve the same purpose.
Cheers,
Neal
On Mon, Nov 21, 2011 at 2:35 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> You "caution the expert group to carefully consider the syntax", because
> of possible ambiguities between features that are currently on the
> requirements list (method refs) and features that are on various
> people's wish list but not under active development (field refs).
>
> I was merely saying we're well aware of these issues, so you can sleep
> well knowing that they've already occurred to us and have been part of
> the discussion, and that while field refs are not on our requirements
> list, we realize that it would be stupid to inadvertently close the door
> on them, and therefore have to be included in our analysis.
>
>
>
> On 11/21/2011 4:59 PM, Matthew Adams wrote:
> > I'm not quite sure what that means. Can you please elaborate?
> >
> > On Mon, Nov 21, 2011 at 11:39 AM, Brian Goetz <brian.goetz at oracle.com
> > <mailto:brian.goetz at oracle.com>> wrote:
> >
> > Don't worry, this road is already well explored.
> >
> >
> > On 11/21/2011 10:34 AM, Matthew Adams wrote:
> >
> > I reiterate Chris's suggestion for method and field literals,
> > and caution
> > Project Lambda to carefully consider the syntax. There is an
> > ambiguity
> > that I want to make sure that we're not overlooking here that
> > would cause
> > problems with various proposed method/field literal syntaxes.
> >
> > Currently, Chris's examples and Project Lambda's "::" method
> > reference
> > syntax introduce an ambiguity when referring to a method that
> > has the same
> > name as a field. See my post on this at
> >
> http://mail.openjdk.java.net/__pipermail/jdk8-dev/2011-__November/000293.html
> > <
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000293.html>
> > for
> > more detail on my suggestion. In short, though, here's the jist
> > (I'll use
> > "::", but I still prefer "#" as the method/field literal
> operator).
> > Consider the following class:
> >
> > public class Foo {
> > private boolean close;
> > @Goo(hoo="loo") public Foo() { /* ... */ }
> > /* A */ public void close() { /* ... */ }
> > /* B */ public void close(int timeout) { /* ... */ }
> > }
> >
> > If member literal syntax is to be supported now or in the future,
> > "Foo::close" is ambiguous. What should the compiler do here?
> > Interpret
> > the expression as a field or method reference if it's not
> > ambiguous? I
> > think I'd prefer a syntax that requires parens for method
> > references:
> >
> > Foo::close // field
> > Foo::close() // refers to method A above
> > Foo::close(int) // refers to method B above
> >
> > This also allows me to refer to constructors, BTW:
> >
> > Foo::()
> >
> > And annotations:
> >
> > Foo::()@Goo
> >
> > And annotation properties:
> >
> > Foo::()@Goo(hoo)
> >
> > I reiterate also that the persistence specifications JDO& JPA
> > can benefit
> > from such constructor, method& field literals. In their
> > absence, projects
> >
> > like QueryDsl, Hibernate's Criteria, JPA's Criteria, and JDO's
> > proposed
> > typesafe query APIs have been created, using generated classes
> > to provide
> > the typesafe references that are needed.
> >
> > -matthew
> >
> >
> > On Mon, Apr 18, 2011 at 3:40 AM, Chris Beams<cbeams at vmware.com
> > <mailto:cbeams at vmware.com>> wrote:
> >
> > On Sun, Apr 17, 2011 at 8:14 PM, Collin Fagan<collin.fagan
> > at gmail.com <http://gmail.com>> wrote:
> >
> > But more to the point what is Chris actually asking for? Is
> > it just to be able to use static method references with
> > annotations?
> >
> >
> > This thread originated on coin-dev (thanks Rémi for
> > cross-posting here),
> > but I believe my original use case didn't make it over. Let
> > me reiterate
> > and expand.
> >
> > Many will associate Spring with XML-based application
> > configuration, but
> > since Spring 3.0 we also offer a 100% Java-based solution
> > for configuring
> > dependency injection, application of advice, and the myriad
> > other services
> > and features of the Spring container. The central artifacts
> > in this
> > support are user-defined "@Configuration classes". A brief
> > but practical
> > example follows to provide context for our use cases.
> >
> > package com.myco.app.config;
> >
> > import
> org.springframework.context.__annotation.Configuration;
> > import org.springframework.context.__annotation.Bean;
> > import
> >
> org.springframework.jdbc.__datasource.embedded.__EmbeddedDatabaseBuilder;
> > import
> >
> org.springframework.jdbc.__datasource.embedded.__EmbeddedDatabaseType;
> > import
> >
> org.springframework.orm.__hibernate3.annotation.__AnnotationSessionFactoryBuilde__r;
> >
> > import org.hibernate.SessionFactory;
> >
> > import javax.sql.DataSource;
> >
> > import com.myco.app.domain.Foo;
> > import com.myco.app.service.__FooService;
> > import com.myco.app.service.__SimpleFooService;
> > import com.myco.app.data.__FooRepository;
> > import com.myco.app.data.__HibernateFooRepository;
> >
> > @Configuration
> > public class MyApplicationConfig {
> >
> > @Bean
> > public FooService fooService() {
> > return new SimpleFooService(__fooRepository());
> > }
> >
> > @Bean
> > public FooRepsitory fooRepository() {
> > return new
> HibernateFooRepository(__sessionFactory());
> > }
> >
> > @Bean
> > public SessionFactory sessionFactory() {
> > return new AnnotationSessionFactoryBuilde__r()
> > .setDataSource(dataSource())
> > .setSchemaUpdate(true)
> > .setAnnotatedClasses(Foo.__class)
> > .buildSessionFactory();
> > }
> >
> > @Bean
> > public DataSource dataSource() {
> > return new EmbeddedDatabaseBuilder()
> > .setType(EmbeddedDatabaseType.__HSQL)
> > .build();
> > }
> >
> > }
> >
> >
> > Such a @Configuration class may then used to bootstrap the
> > application.
> > If we're dealing with a simple standalone Java
> > application, doing so
> > within a main method will suffice:
> >
> > package com.myco.app;
> >
> > import
> >
> org.springframework.context.__annotation.__AnnotationConfigApplicationCon__text;
> >
> > import com.myco.domain.Foo;
> > import com.myco.app.service.__FooService;
> > import com.myco.app.config.__MyApplicationConfig;
> >
> > public class Bootstrap {
> > public static void main(String... args) {
> > AnnotationConfigApplicationCon__text ctx = new
> > AnnotationConfigApplicationCon__text();
> > ctx.register(__MyApplicationConfig.class);
> > ctx.refresh();
> >
> > FooService fooService =
> ctx.getBean(FooService.class);
> > Foo foo1234 = fooService.findById(1234);
> > System.out.println(foo1234);
> > }
> > }
> >
> >
> > Now let's get to the business of method literals. Notice
> > again the
> > Hibernate SessionFactory @Bean definition:
> >
> > @Bean
> > public SessionFactory sessionFactory() {
> > // ...
> > }
> >
> >
> > The SessionFactory is being created by Spring here, and will
> > be managed by
> > the Spring container for the lifetime of the
> ApplicationContext
> > bootstrapped in our main method. Note however that its
> > configuration is
> > not yet complete - it is important to call a
> > SessionFactory's close()
> > method on application shutdown in order to manage resources
> > properly, and
> > Spring provides a mechanism to allow users to specify this
> > with the
> > 'destroyMethod' attribute of the @Bean annotation:
> >
> > @Bean(destroyMethod="close")
> > public SessionFactory sessionFactory() {
> > // ...
> > }
> >
> > You can see the problem - 'close' must be specified as a
> > string due to
> > lack of method literal support in the language. Far more
> > desirable would
> > be:
> >
> > @Bean(destroyMethod=__SessionFactory#close)
> > public SessionFactory sessionFactory() {
> > // ...
> > }
> >
> > Whether the user is referring to an instance method or
> > static method is,
> > from the framework's point of view, immaterial. We simply
> > wish to provide
> > the user with an IDE-friendly mechanism to execute a method
> > during the
> > destruction phase of the bean lifecycle. We can do this
> > already, but it
> > requires stringification of method names.
> >
> > This is certainly not our only use case, but in the interest
> > of brevity
> > I'll leave it here, noting that our use cases are not
> > limited to method
> > literals within annotations; such syntax would be useful
> > within many
> > contexts. For a non-Spring example, consider the case of
> > JPA 2's Criteria
> > API, which is crippled by the lack of field literals in the
> > language. Its
> > use is so cumbersome that the QueryDSL project has become
> > quite popular in
> > conjunction with JPA, as they take an APT-based code gen
> > approach that
> > effectively approximates the functionality of field literals
> > [1]. Again, I
> > find the utility of field and method literals self-evident,
> > even obvious.
> > It is certainly not a Spring-specific itch we wish to
> > scratch here, but
> > rather to champion a generally useful addition to the
> language.
> >
> > Are there fundamental objections to such support? Does
> > prior art in
> > Project Lambda already encompass these use cases? We'd be
> > interested in
> > hearing what next steps are necessary to help make this a
> > reality in JDK 8
> > and how we can help.
> >
> > Thanks,
> >
> > - Chris
> >
> > [1]:
> >
> http://source.mysema.com/__forum/mvnforum/viewthread___thread,49
> > <
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49>
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > @matthewadams12
> > mailto:matthew at matthewadams.me <mailto:matthew at matthewadams.me>
> > skype:matthewadams12
> > yahoo:matthewadams
> > aol:matthewadams12
> > google-talk:matthewadams12 at gmail.com
> > <mailto:google-talk%3Amatthewadams12 at gmail.com>
> > msn:matthew at matthewadams.me <mailto:msn%3Amatthew at matthewadams.me>
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> >
>
>
More information about the lambda-dev
mailing list