Make value member of @Named optional

[GoogleCodeExporter]

If we really are going to keep @Named, at least we should make the value
member optional, since I don't want to see people having to write stuff like:

   @Inject @Named("foo") Foo foo;

Or in 299:

   @Named("foo")
   public class Foo { ... }

Just like with the EE 5 style injection annotations, the name of the
qualifier should be defaultable from the name of the field (or type), so
that we would get:

   @Inject @Named Foo foo;

   @Named
   public class Foo { ... }

Original issue reported on code.google.com by gavin.k...@gmail.com on 24 Jun 2009 at 1:32

[GoogleCodeExporter]

I'm not too sure about using parameter names for configuration. It's nice and 
concise, but the data isn't available 
reflectively (you need to use paranamer) and there's no JDK precedent of its 
use. 

Paul, you've got some experience with this. Any advice? Does use of parameter 
names lead to happy 
programmers?

Original comment by limpbizkit on 24 Jun 2009 at 7:22

[GoogleCodeExporter]

Much as I love parameter name leverage and how much of a no-brainer it is for 
binding to web methods, 
Gavin is not proposing parameter name leverage here.  Field names are 
retrievable via vanilla reflection, and 
there's some redundancy between the actual field name versus the annotation's 
mandatory value. I'm inclined 
to agree that it should be optional for fields (while mandatory for param names 
to ctors/methods), not that 
we can code it to differentiate declaratively. 

Paranamer can leverage debug tables, or post-compilation added (QDox/Asm) meta 
info on classes.  Its not 
ideal obviously.  Paranamer is OT for this JSR however much I'd like Sun to 
allow parameter name leverage in 
Java per se, it'll get vetoed when ever it is suggested I suspect.

Original comment by PaulHamm...@gmail.com on 24 Jun 2009 at 10:55

[GoogleCodeExporter]

Right, I'm not proposing that we support the defaulted version on 
method/constructor
parameters *in this release*. If this problem is someday fixed in the JDK, we 
can
also support it there. But for now what I'm talking about is field injection 
and the
use of @Named to *declare* a bean name in 299.

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 4:47

[GoogleCodeExporter]

Strictly speaking, you can provide default values for annotation attributes, 
but you
can't make them optional (i.e. you can't differentiate between not setting the 
value
and explicitly setting the value to the default value). If we were to define a
default value, I don't think we should try to specify how injectors should 
interpret
that value (we're short on time, and I can imagine interpreting it in different 
ways
in different contexts). We would also want to pick a default value that doesn't
conflict with a value a user would likely use (maybe "").

That said, I prefer not to do this. I don't want to encourage use of string
identifiers. I don't like the inconsistency of being able to look up field but 
not
parameter names. I also think users would be better of using purpose-built
annotations for this sort of thing. If a user is reading code with @Named in it 
and
they click through to read the docs on @Named, the docs won't help them much 
compared
to docs on a more specific annotation type that could explain how the default 
name is
calculated and used in an expression language, for example. Of course, we could
always specify a default value later without breaking compatibility.

Original comment by crazybob...@gmail.com on 24 Jun 2009 at 9:34

[GoogleCodeExporter]

All the other specs (starting with JPA, and common annotations) are using "" as 
the
default value, which is perfectly appropriate in this case, since it's not a 
value
that the user would ever want to use.

We should do this, since it is what all the other specs are already doing, and I
don't want to have to deal with the complaints of users who don't like the 
verbosity
of "@Inject @Named("foo") Foo foo". Trust me, they will complain.

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 9:40

[GoogleCodeExporter]

If we don't want to make this change, we should remove @Named from 330. I 
continue to
think that this is the best solution.

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 9:43

[GoogleCodeExporter]

"I also think users would be better of using purpose-built annotations for this 
sort
of thing. If a user is reading code with @Named in it and they click through to 
read
the docs on @Named, the docs won't help them much compared to docs on a more 
specific
annotation type that could explain how the default name is calculated and used 
in an
expression language, for example."

Actually, given this comment, we should definitely go ahead and remove @Named 
from
the spec. If @Named is not going to be a completely general-purpose solution, 
and we
still envisage that other frameworks and applications will be defining their own
special versions of @Named, then @Named definitely doesn't belong in the spec.

I had been assuming that @Named was truly general-purpose and could subsume the 
role
of the existing @Named annotation in 299 (which is used to specify or default 
the
Unified EL name). Since that's not what is envisaged here, we should definitely 
just
remove it.

As it is, it looks like 330 and 299 would each need to define their own @Named
annotation, one (in 330) as a qualifier, for use by people who don't like 
typesafety,
and the other (in 299) for expressing that a bean (or all beans with a certain
stereotype) is accessible via Unified EL. That's horrible, can you imagine the 
user
complaints about there being two different ways to give a name two a bean?! 
What a mess!

Let's just ditch it.

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 9:53

[GoogleCodeExporter]

I think we certainly need to avoid having 2 distinct annotations 
with "approximately" the same (apparent) semantics.

Also, since 299 has already used @Named, if we wanted to include a similar (but 
different) annotation into 330, it cannot be named @Named.

I agree with Gavin that where defaulting can be introduced and redundancy 
avoided
it should be, so I support the notion of

@Inject @Named Foo foo;

So can we agree on a single "naming" annotation that can be specificed (or not) 
to 
accomodate its usage as defined in 299 and its imagined uses in 330?

Original comment by Larry.Ca...@gmail.com on 25 Jun 2009 at 3:39

[GoogleCodeExporter]

I don't think we can ditch this annotation as that would inevitably lead to two 
different but similar annotations -- exactly what people absolutely don't want 
to 
see.

Can we not just define it as:

@Qualifier
@Documented
@Retention(RUNTIME)
@interface Named {
  String value() default "";
}

and say that when annotating a field, method, or type the default value will be 
assumed to be the name of the respective field, method or type? In all other 
cases 
the value must be specified.

Original comment by michael....@gmail.com on 25 Jun 2009 at 4:02

[GoogleCodeExporter]

OK. We'll make "" the default.

Original comment by crazybob...@gmail.com on 25 Jun 2009 at 7:00

[GoogleCodeExporter]

Great, thanks :-)

Original comment by gavin.k...@gmail.com on 25 Jun 2009 at 7:01

[GoogleCodeExporter]

"" is the default value as of r6. The spec won't say anything about how an 
injector
should interpret the default value. For the foreseeable future, Guice will treat
@Named like any other qualifier. This could change once parameter names become 
more
readily available.

If these annotations ever make it into SE, maybe we could specify that parameter
names are always retained (and accessible at run time) when @Named is present.
Chances are this would appease the embedded folks who just want to minimize 
class
file sizes.

Original comment by crazybob...@gmail.com on 26 Jun 2009 at 11:14

• Changed state: Fixed

[GoogleCodeExporter]

I'm fine with "" as the default. 

Original comment by johnsonr...@gmail.com on 26 Jun 2009 at 11:19