Re: Generics and the spec interfaces
Hi All, Please exclude me from this mailing list. Thanks. Mark Thomas [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Meet people who discuss and share your passions. Join them now.
Re: Generics and the spec interfaces
irshad gehlot wrote: Hi All, Please exclude me from this mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ^^^ ||| Clues above. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
I'm for 3 since I wonder if the option 4 follow the specs. 2008/5/6 Mark Thomas [EMAIL PROTECTED]: 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 EnumerationString e = request.getHeaderNames(); 4. Use EnumerationString 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics and the spec interfaces
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
