Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4764045
Votes 2
Synopsis javadoc inline tag {@value} should be available everywhere
Category doclet:tbd
Reported Against 1.4 , 1.4.1
Release Fixed 1.5(tiger)
State 10-Fix Delivered, request for enhancement
Priority: 4-Low
Related Bugs 4753737
Submit Date 16-OCT-2002
Description
I agree that the {@value} tag should be available everywhere.  Why make the user navagate to the field to vi the constant value?  The @value inline tag now takes an optional field name in the same format as the @see tag (<fully qualified class name>#<field name>).  This enhancement request asks for a label parameter.  I see no use for this.  The label of the inline tag is the value of the constant.  If @value is not used with the constant, it is linked ot the constant value so that the user will know where the value came from.




FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

A DESCRIPTION OF THE PROBLEM :
It is only possible to use the javadoc inline tag @value
inside the documentation of the constant field. It should be
possible to use it everywhere and extend the syntax of this
tag to

{@value package.class#member  label}

The idea is to have the constant values available in every javadoc comment. 
This is just for convenience

Example:

public static final String SCRIPT_START = "<script>";
public static final String SCRIPT_END = "</script>";


Currently with the actual version, you have to navigate two times, click on 
the link for this method and click on the values link of the constant,
like this:

/**
 * Evaluates scripts given in the specified script string. 
 * Every script included in {@link #SCRIPT_START} and 
 * {@link #SCRIPT_END} is evaluated and the result is inserted 
 * in the string. 
 */
public String evalScripts(String script) {
}


Method doc I suggest

Just include the value (with a link to the constant)

/**
 * Evaluates scripts given in the specified script string. 
 * Every script included in {@value #SCRIPT_START} and 
 * {@value #SCRIPT_END} is evaluated and the result is inserted 
 * in the string. 
 */
public String evalScripts(String script) {

}

(Review ID: 164665) 
======================================================================
Here is an example from duplicate 4753737:

/**
 * Names the property file.
 */
public static final String NAME_OF_PROPERTY_FILE = "db2.properties";

/**
 * This method reads the properties out of {@value NAME_OF_PROPERTY_FILE}
 */
 public void readProperties() {
 ...
 }

/**
 * This method writes the properties into {@value NAME_OF_PROPERTY_FILE}
 */
 public void writeProperties() {
 ...
 }

So if I need to change the value of the constant to
"cloudscape.properties" I wouldn't have to redo all the Javadoc
comments. (I came to this while doing a lot of Search/Replace)!
Work Around
N/A
Evaluation
This is very nearly a duplicate of 4753737: Allow {@value} to take field name arg and be used in any doc comment.  The only difference is that this 
request allows for a label.

One question:  Is the given example a misuse of @value?  That is,
do we want to encourage the use of a value in a doc comment rather than
its field name?
 xxxxx@xxxxx  2002-10-16

The form of this tag would be:

  {@value package.class#member  label}

>  xxxxx@xxxxx  wrote:
> Question:  Are these examples legitimate uses for displaying the value?
> That is, are developers likely to be led to mistakenly use the value rather 
> than the field?  
> 
> Shall we allow/encourage developers to do this?

 xxxxx@xxxxx  wrote:
I share your concerns.  It isn't evil, but it's open to abuse.  I'm 
not sure whether I'd do this.

===========
I added an optional field name paramenter to the @value inline tag.  I see no reason why we should not add this.  It is inconvienent for the user to have to paste constant values in their documentation.

This bug fix will be integrated with the doclet toolkit.

 xxxxx@xxxxx  2003-05-07
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang