Warning about single underscore identifier

Roel Spilker r.spilker at gmail.com
Fri Aug 2 02:52:28 PDT 2013


Thanks for the answers. About the "I don't want to give this variable a name"
past, that's quite similar to the scenarios where I now get a warning :-)

Inside lombok we want to allow the user to put an annotation (any
annotation) as a value of an annotation. That is currently not valid java.
In java 6 we could get away with it by removing the value from the AST
after parsing. Since java 7 we couldn't do it anymore since the parser
would also do some basic type checking and already error. Our current
workaround involved using a non-existing annotation type, so the parser
wasn't able to do the type-checking. By convention, we chose this type to
be the '_'.

For example, to generate a getter with the @Id and the
@Column(name="unique-id") the programmer would have to write

@Getter(onMethod=@_({@Id, @Column(name="unique-id")}))

Ironically, we investigated what would be involved to change the java
compiler, specification and runtime to allow for any annotation, removing
the need for this workaround. The modifications were tiny, so we created a a
proposal for inclusion in java
8<http://mail.openjdk.java.net/pipermail/coin-dev/2012-February/003461.html>,
that was rejected because java 8 was supposedly "about to be shipped".

Proposed syntax:

@interface Getter {
    Annotation[] onMethod() default {};
}

I guess it is still "about to be shipped", but if there is any chance in
getting this in I love to spend quite some time on it.



On Thu, Aug 1, 2013 at 5:08 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> No.  The EG specifically discussed this and decided to stop at _.
>
> On Aug 1, 2013, at 6:54 AM, Paul Benedict wrote:
>
> > Personally, I hope so. It would be nice to retain $ for the JVM but
> exclude
> > it from the Java language. (I've read some interesting Eclipse tickets
> > about that symbol over the years.)
> >
> >
> > On Thu, Aug 1, 2013 at 7:57 AM, Matthew Adams <matthew at matthewadams.me
> >wrote:
> >
> >> Brian, will the same policy hold for "$"?
> >>
> >> -matthew
> >>
> >>
> >> On Wed, Jul 31, 2013 at 1:52 PM, Brian Goetz <brian.goetz at oracle.com>
> >> wrote:
> >>
> >>> Yes, we are "reclaiming" the syntactic real estate of "_" from the
> space
> >>> of identifiers for use in future language features.  However, because
> >> there
> >>> are existing programs that might use it, it is a warning for
> identifiers
> >>> that occur in existing syntactic positions for 8, and an error for
> lambda
> >>> formals (since there is no existing code with lambdas.)
> >>>
> >>> Your suspicion is mostly right, except that we are certainly NOT going
> to
> >>> do Scala's "wunderbar".  However, things it might be used for include
> >>> things like "I don't want to give this variable a name" (such as catch
> >>> parameters that are never used.)
> >>>
> >>>
> >>> On Jul 29, 2013, at 6:59 AM, Roel Spilker wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> If I compile a java program containing an identifier consisting of
> >> just a
> >>>> single underscore using the java 8 compiler, I get the following
> >> warning:
> >>>>
> >>>> warning: '_' used as an identifier
> >>>> (use of '_' as an identifier might not be supported in releases after
> >>> Java
> >>>> SE 8)
> >>>>
> >>>> I suspect this is to allow for scalaesc parameters in lambdas.
> >>>>
> >>>> Can someone confirm my suspicion? Is this still relevant or is this a
> >>>> left-over from an early design? Is there a valid reason to not support
> >>> '_'
> >>>> for all identifiers, or can it be only restricted for identifiers
> >> inside
> >>>> lambdas, and therefore guaranteed new code, to maintain backwards
> >> source
> >>>> compatibility.
> >>>>
> >>>> Roel
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> mailto:matthew at matthewadams.me <matthew at matthewadams.me>
> >> skype:matthewadams12
> >> googletalk:matthew at matthewadams.me
> >> http://matthewadams.me
> >> http://www.linkedin.com/in/matthewadams
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Paul
> >
>
>
>


More information about the lambda-dev mailing list