Bug 11312

Actually, I thought you were talking about something different on the taglibs-
user list.   The tag

 <c:set var="param.Name" value="new" />

is perfectly valid; it sets the scoped variable named 'param.Name' to the 
value 'new'.  Scoped variables' names can cetainly have '.' in them; in fact, 
I believe this is recommended by the Servlet specification.

The case that you're filing a report against is

  <c:set target="${param}" property="name" value="foo" />

and this indeed does already throw an UnsupportedOperationException.

I am talkiing about:-<c:set var="param.Name" value="new" />and it does NOT work.  I use param.Name to access the value of an HTML fieldPOSTed into my JSP script.  If I test its value, using say:-<c:if test="${param.Name == 'Fred'}">and the value was Fred, the test works.  If I then set the value to "Jim" asabove and then do the test again, the value is STILL Fred, the set had not worked.

Please read over what I wrote carefully; the JSTL implementation is behaving as 
intended, and as specified, here.  "param.Name" is a perfectly valid name for a 
scoped variable, and while you can set it as "param.Name", you cannot read it 
with "${param.Name}" or test it with expressions like "${param.Name == foo}"; 
these experssions refer to the request parameter named "Name".

When a scoped variable contains characters that aren't valid in Java 
identifiers (like "."), you must use the "[]" operator to access it; otherwise, 
the expression language thinks you're accessing (in the case of ".") a 
property.  So just say ${pageScope["param.Name"]} if you want to access the 
parameter; note that this is NOT the "Name" parameter, but a scoped variable 
named "param.Name".  If you have further questions, please take them up on the 
taglibs-user@jakarta.apache.org mailing list; this is not a bug.

I am sorry that you can not see that it is entirely unacceptable to be ableto write to something and not read back from it.  Either the EL syntax istoo permissive, and using param.Name should be stopped, or setting param.Nameshould mean that next time you read param.Name you get back the value to set or that you get an indication that this value is read-only.To have a language where the same expression means two entirely separate thingsis the road to confusion.If this is not an implementation bug, it is certainly a design bug and needsto be fixed, I therefore am reopening this bug as bug it certinaly is.

David, you are reporting a bug against an implementation that follows a 
specification; if you have complaints about the specification, you should mail 
jsr-52-comments@jcp.org.  Suggestions sent to that address will be considered 
for future versions of JSTL.  The implementation is, on this subject, 
compliant with the specification; you have not reported a valid bug, so I am 
marking it "invalid" again.

As far as the behavior, I think you are misunderstand my response.  Consider 
the following:

  <c:set var="param.Name" value="1" />
  <c:out value="${pageScope['param.Name']}" />

This will, per specification, output "1".

The text you specify in a "var" attribute does NOT use the expression 
language; I believe you are under the mistaken impression that it does.  
Instead, the text "param.Name" is the literal name of a scoped variable,
which can be accessed in expressions like ${pageScope['param.Name']}.
By contrast, the expression ${param.Name} accesses a request parameter
named "Name", not the scoped variable named "param.Name".

Perhaps an analogy would be in order.  Consider the following:

  <c:set var="param-Name" value="1" />
  <c:out value="${pageScope['param-Name']}" />

This, too, outputs 1.  However, the expression ${param-Name} means "param 
minus Name", not "the scoped variable with the name 'param-Name'.  The fact 
that there is also an implicit object named "param" is irrelevant in both 
cases.

Please read over the JSTL specification (or a book on the topic) before 
opening the bug again!  We take bug reports seriously, and reopening this one 
is a distraction.  Thanks.