Generics and the spec interfaces

[Mark Thomas-18]

All,

As you have probably noticed I am doing some clean-up of the trunk codebase
as and when the opportunity arises. So far the clean has identified the odd
copy/paste error or casting problem as well as (hopefully) making the code
easier to read. The fixes for the errors are getting ported to 6.0.x.

I am currently pondering what to do with lines like this:
Enumeration e = request.getHeaderNames();

As I see it the options are:
1. Leave it as it is.
2. Use
Enumeration<?> e = request.getHeaderNames();
3. Use
Enumeration<String> e = request.getHeaderNames();
4. Use
Enumeration<String> e = request.getHeaderNames();
and modify HttpServletRequest to use generics
5. Something else.

I am leaning towards 4 on the basis that
a) This is trunk, not a release branch
b) This option generates no warnings
c) I assume the spec will start using generics at some point (maybe in 3.0?)
If modifying the spec interfaces seems like a step too far then 3 would be
my next choice.

Thoughts?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Henri Gomez]

I'm for 3 since I wonder if the option 4 follow the specs.

2008/5/6 Mark Thomas <markt@...>:

> All,
>
>  As you have probably noticed I am doing some clean-up of the trunk codebase
> as and when the opportunity arises. So far the clean has identified the odd
> copy/paste error or casting problem as well as (hopefully) making the code
> easier to read. The fixes for the errors are getting ported to 6.0.x.
>
>  I am currently pondering what to do with lines like this:
>  Enumeration e = request.getHeaderNames();
>
>  As I see it the options are:
>  1. Leave it as it is.
>  2. Use
>  Enumeration<?> e = request.getHeaderNames();
>  3. Use
>  Enumeration<String> e = request.getHeaderNames();
>  4. Use
>  Enumeration<String> e = request.getHeaderNames();
>  and modify HttpServletRequest to use generics
>  5. Something else.
>
>  I am leaning towards 4 on the basis that
>  a) This is trunk, not a release branch
>  b) This option generates no warnings
>  c) I assume the spec will start using generics at some point (maybe in
> 3.0?)
>  If modifying the spec interfaces seems like a step too far then 3 would be
> my next choice.
>
>  Thoughts?
>
>  Mark
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[remm]

On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote:
> I am leaning towards 4 on the basis that
> a) This is trunk, not a release branch
> b) This option generates no warnings
> c) I assume the spec will start using generics at some point (maybe in 3.0?)
> If modifying the spec interfaces seems like a step too far then 3 would be
> my next choice.

There are signature tests in the TCK :( I don't think that will pass.

Rémy



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

And if the TCK signature tests pass - that's a bug in the tests :-).
We shouldn't touch the method signatures in servlet API.

Costin

On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat <remm@...> wrote:

> On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote:
> > I am leaning towards 4 on the basis that
> > a) This is trunk, not a release branch
> > b) This option generates no warnings
> > c) I assume the spec will start using generics at some point (maybe in
> 3.0?)
> > If modifying the spec interfaces seems like a step too far then 3 would
> be
> > my next choice.
>
> There are signature tests in the TCK :( I don't think that will pass.
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Mark Thomas-18]

Costin Manolache wrote:
> And if the TCK signature tests pass - that's a bug in the tests :-).
> We shouldn't touch the method signatures in servlet API.

Having read everyone's comments and having thought some more about this
during today, my current plan is:
- fix any non-generics warnings in the spec code
- commit the fixes
- fix the generics warnings but don't commit - I can make a patch available
on p.o.a if anyone is interested
- fix the warnings in the rest of the code base.

Mark

> Costin
>
> On Tue, May 6, 2008 at 2:03 AM, Remy Maucherat <remm@...> wrote:
>
>> On Tue, 2008-05-06 at 08:27 +0100, Mark Thomas wrote:
>>> I am leaning towards 4 on the basis that
>>> a) This is trunk, not a release branch
>>> b) This option generates no warnings
>>> c) I assume the spec will start using generics at some point (maybe in
>> 3.0?)
>>> If modifying the spec interfaces seems like a step too far then 3 would
>> be
>>> my next choice.
>> There are signature tests in the TCK :( I don't think that will pass.
>>
>> Rémy
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jan.Luehe]

Mark Thomas wrote:

> Costin Manolache wrote:
>
>> And if the TCK signature tests pass - that's a bug in the tests :-).
>> We shouldn't touch the method signatures in servlet API.
>
>
> Having read everyone's comments and having thought some more about
> this during today, my current plan is:
> - fix any non-generics warnings in the spec code
> - commit the fixes
> - fix the generics warnings but don't commit - I can make a patch
> available on p.o.a if anyone is interested
> - fix the warnings in the rest of the code base.

Can you please send a proposal (including diffs) to the JSR-315 EG?
"Generification" of the Servlet APIs is being considered for Servlet 3.0.

Thanks,

Jan



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mark Thomas-18]

Jan.Luehe@... wrote:
> Can you please send a proposal (including diffs) to the JSR-315 EG?
> "Generification" of the Servlet APIs is being considered for Servlet 3.0.
>
> Thanks,
>
> Jan

Jan,

Patches are available (under the AL2) from:
http://people.apache.org/~markt/patches/

I also fixed a couple of other bits. See the NOTES for full details.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[irshad gehlot]

Hi All,
   
  Please exclude me from this mailing list.
   
  Thanks.
 
Mark Thomas <markt@...> wrote:
  Jan.Luehe@... wrote:
> Can you please send a proposal (including diffs) to the JSR-315 EG?
> "Generification" of the Servlet APIs is being considered for Servlet 3.0.
>
> Thanks,
>
> Jan

Jan,

Patches are available (under the AL2) from:
http://people.apache.org/~markt/patches/

I also fixed a couple of other bits. See the NOTES for full details.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...



       
---------------------------------
 Meet people who discuss and share your passions.  Join them now.

[Pid-2]

irshad gehlot wrote:
> Hi All,
>    
>   Please exclude me from this mailing list.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

^^^^^^^
|||||||


Clues above.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...