tatic Test newInstance() {
>return new Test();
>}
> }
>
> As you can see, there is only one case when you get a compile error when
> using the > generic type, and that is a case where there
> is on the user side an incorrect generic type: Test. The us
}
public static Test newInstance() {
return new Test();
}
}
As you can see, there is only one case when you get a compile error when
using the > generic type, and that is a case where
there is on the user side an incorrect generic type: Test. The
user
t;
> >>
> >> -igor
> >
> > I don't understand how that changes any of my points. The first is
> incorrect
> > (from a generics point of view) since you're referencing an
> unparameterized
> > generic type.
> >
> > So the second give
t; extends Component> or >
>>
>> -igor
>
> I don't understand how that changes any of my points. The first is incorrect
> (from a generics point of view) since you're referencing an unparameterized
> generic type.
>
> So the second gives warnings onl
yeah, generics are pretty damn viral
-igor
On Wed, May 14, 2008 at 2:28 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
> <[EMAIL PROTECTED]> wrote:
>>> the whole generics thing turned out to be
>>> quiet a
Igor Vaynberg wrote:
since then the thread has evolved into whether or not we should use or >
-igor
I don't understand how that changes any of my points. The first is
incorrect (from a generics point of view) since you're referencing an
unparameterized generic type.
So the
wicket 1.6 = scala-based ? *lol*
Am 14.05.2008 um 23:28 schrieb Eelco Hillenius:
On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
:-)
Generics for models: great. Ge
On Wed, May 14, 2008 at 2:25 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
>> the whole generics thing turned out to be
>> quiet a lot crappier then i thought it would.
>
> :-)
Generics for models: great. Generics for components: awful. Too bad
that stu
since then the thread has evolved into whether or not we should use or >
-igor
On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg wrote:
>
>> i do like generics. did i ever say otherwise? the problem here is that
>> if
> the whole generics thing turned out to be
> quiet a lot crappier then i thought it would.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Igor Vaynberg wrote:
i do like generics. did i ever say otherwise? the problem here is that
if we scope something as Class then even though
you ARE using generics in your code you will still get a warning
because we did not scope the class as Class>.
on the other hand if we do scope it
that's exactly what I am saying...
It always pisses me off to see developers checking in code
that delivers like 50-100 warnings and they don't care.
warnings are a good thing.
not so sure about generics (just kidding :-)
Am 14.05.2008 um 22:41 schrieb Igor Vaynberg:
well, may
well, maybe you get used to warnings, i tend to do something about
them and clean up my code. i do not want to turn this warning off,
because as you said yourself it is a very useful warning, if i turn it
off i might as well not be using generics...
-igor
On Wed, May 14, 2008 at 1:38 PM, Peter
On Wed, May 14, 2008 at 1:20 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg wrote:
>>
>> then our users have to suppress warnings in their code, which is
>> unacceptable at least to me. the whole generics thing turned out to be
>> quiet a lot
pe there
johan
On Wed, May 14, 2008 at 9:53 PM, Igor Vaynberg <[EMAIL PROTECTED]
>
wrote:
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to
be
quiet a lot crappier then i thought it would.
-igor
On We
9:53 PM, Igor Vaynberg <[EMAIL PROTECTED]>
> wrote:
>
>> then our users have to suppress warnings in their code, which is
>> unacceptable at least to me. the whole generics thing turned out to be
>> quiet a lot crappier then i thought it would.
>>
>> -igor
>
s have to suppress warnings in their code, which is
> unacceptable at least to me. the whole generics thing turned out to be
> quiet a lot crappier then i thought it would.
>
> -igor
>
>
> On Wed, May 14, 2008 at 12:48 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
&
Igor Vaynberg wrote:
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
I actually like having the generics better than not having it. In both
cases sometimes
then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.
-igor
On Wed, May 14, 2008 at 12:48 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yes then all th
Component should be parameterized
>
> so that means we have to change our sig to >
> but then we are back to the problem described in this thread.
>
> generics suck.
>
> -igor
>
> On Wed, May 14, 2008 at 12:12 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
sig to >
but then we are back to the problem described in this thread.
generics suck.
-igor
On Wed, May 14, 2008 at 12:12 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> I dont think that user gets a warning if a param is of raw type. But
> we have a warning there.
> The pro
;>
>>> >> please, and will be these classes later generified ?
>>> >> Or should I make a RFE, or can I help anyway-for example attach a
>>> >> patch
>>> ?
>>> >>
>>> >> I love your work and Wicket, so I do my b
ch
>> ?
>> >>
>> >> I love your work and Wicket, so I do my best, to make it better ;)
>> >>
>> >> Stefan Simik
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Joh
uot;)));
> >>
> >> Sure, it seems like a small difference and a saving of two
> >> characters, but
> >> here is what I believe are the benefits of doing this:
> >>
> >> 1) I can more easily use the features of my IDE such as auto-
> >> c
gt; >> Stefan Simik
> >>
> >>
> >>
> >>
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > yes thats the reason
> >> >
> >> > you are calling the method add with a generified
mpagner wrote:
>> >
>> > yes thats the reason
>> >
>> > you are calling the method add with a generified component but that
>> > container itself is not generified
>> >
>> > i dont like this about generics expecially the onces like th
> here is what I believe are the benefits of doing this:
>>
>> 1) I can more easily use the features of my IDE such as auto-
>> completion
>>
>> 2) Find Usages is more accurate (at least in IntelliJ, where I'm not
>> aware
>> of a find-usages that scop
nefits of doing this:
1) I can more easily use the features of my IDE such as auto-
completion
2) Find Usages is more accurate (at least in IntelliJ, where I'm not
aware
of a find-usages that scopes to a particular generic type)
3) Let's face it, Generics clutters up your code and mak
ure, it seems like a small difference and a saving of two characters, but
here is what I believe are the benefits of doing this:
1) I can more easily use the features of my IDE such as auto-completion
2) Find Usages is more accurate (at least in IntelliJ, where I'm not aware
of a find-usages
I can save you the trouble of generating the patch. I don't want
FooBar where Foo iterates over all the types in Java and Bar iterates
over all the Components, Behaviors, Sessions, Requests, Providers in
Wicket. Totally unnecessary and completely negates the idea of
generics.
Martijn
On 5/
generics with some non-generic classes in Wicket
Somewhat related to this thread, when I moved to generics win Wicket
1.4, I created some utility classes such as:
public class VoidContainer extends WebMarkupContainer<Void> public
class VoidPanel extends Panel<Void> public class StringL
Somewhat related to this thread, when I moved to generics win Wicket 1.4, I
created some utility classes such as:
public class VoidContainer extends WebMarkupContainer<Void>
public class VoidPanel extends Panel<Void>
public class StringLabel extends Label<String>
public
. Not
> > to mention that in that area eclipse and javac accept different
> > things
> >
>
> The reason it warns you to use generics when generics are wanted is
> because Sun wants to be able to make it *required* (in a future release) to
> use generics where gen
d be using
the generic type.
Johan Compagner wrote:
I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying. Not
to mention that in that area eclipse and javac accept different
things
The reason it warns you
es thats the reason
> > > >
> > > > you are calling the method add with a generified component but that
> > > > container itself is not generified
> > > >
> > > > i dont like this about generics expecially the onces like this:
> > > >
ing the method add with a generified component but that
> > > container itself is not generified
> > >
> > > i dont like this about generics expecially the onces like this:
> > >
> > > add(MarkupContainer container)
> > >
> > > then sudd
ontainer itself is not generified
> >
> > i dont like this about generics expecially the onces like this:
> >
> > add(MarkupContainer container)
> >
> > then suddenly a none generified component cant be added...
> > thats really stupid should mean anything
Johan Compagner wrote:
yes thats the reason
you are calling the method add with a generified component but that
container itself is not generified
i dont like this about generics expecially the onces like this:
add(MarkupContainer container)
then suddenly a none generified component cant be
this.stringProvider = stringProvider;
> >> >> }
> >> >>
> >> >> public ExtendedLabel(String id, String text) {
> >> >>this(id, new Model(text), new BasicStringProvider());
> >> >>//this(id, new Model<T>(text), new
>
ringProvider;
>> >> }
>> >>
>> >> public ExtendedLabel(String id, String text) {
>> >>this(id, new Model(text), new BasicStringProvider());
>> >>//this(id, new Model<T>(text), new
>> BasicStringProvider()
> you are calling the method add with a generified component but that
> > container itself is not generified
> >
> > i dont like this about generics expecially the onces like this:
> >
> > add(MarkupContainer container)
> >
> > then suddenly a none generifie
g the method add with a generified component but that
> container itself is not generified
>
> i dont like this about generics expecially the onces like this:
>
> add(MarkupContainer container)
>
> then suddenly a none generified component cant be added...
> thats
yes thats the reason
you are calling the method add with a generified component but that
container itself is not generified
i dont like this about generics expecially the onces like this:
add(MarkupContainer container)
then suddenly a none generified component cant be added...
thats really
id, new Model(text), new BasicStringProvider());
> >>//this(id, new Model<T>(text), new BasicStringProvider());
> >> //error
> >> }
> >>
> >> }
> >>
> >>
> >>
> >>
> >> The problematic part, is
rror
>> }
>>
>> }
>>
>>
>>
>>
>> The problematic part, is the second constructor, which calls this. Its
>> second parameter - "new Model(text)",
>>
>> which I cannot generify. If I write "new Model(text)",
omponent...) belongs to the raw type
> MarkupContainer.
> References to generic type MarkupContainer should be parameterized"
>
> I cannot find out, what's the warning reason, because ListView self is
> parameterized.
>
>
--
View this message in context:
http:/
e parameterized"
I cannot find out, what's the warning reason, because ListView self is
parameterized.
--
View this message in context:
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17211948.html
Sent from the Wicket - User mailing l
works ! Thx.
>
> But, is not String something Serializable ?
> I cannot understand where was the problem,
> but I know, this is more about Java Generics, not about Wicket.
>
>
>
>
> Johan Compagner wrote:
> >
> > the only thing i can quickly come up with is t
Uuf, great :) It works ! Thx.
But, is not String something Serializable ?
I cannot understand where was the problem,
but I know, this is more about Java Generics, not about Wicket.
Johan Compagner wrote:
>
> the only thing i can quickly come up with is this
>
>
Its
> second parameter - "new Model(text)",
>
> which I cannot generify. If I write "new Model(text)", I get an error:
> "The
> constructor Model(String) is undefined."
>
>
> I can't find out, what I am doing wrong.
>
>
> Thx
>
"new Model(text)", I get an error: "The
constructor Model(String) is undefined."
I can't find out, what I am doing wrong.
Thx
Stefan Simik
--
View this message in context:
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208
It is generified in trunk, but it might be possible that it was not
yet at the time of the 1.4-m1 release.
Maurice
On Tue, May 13, 2008 at 3:47 PM, Stefan Simik <[EMAIL PROTECTED]> wrote:
>
> Hi boys,
>
> I would like to ask something about wicket generics. I have a warnin
Hi boys,
I would like to ask something about wicket generics. I have a warning, that
I don't know, how to solve.
For example in such a line:
IModel model = new StringResourceModel( ... );
I have a warning, which I cannot r
we have the wicket-examples project that demonstrates various
components. you can browse live here http://wicketstuff.org/wicket13
wicket 1.4 is basically the same as wicket 1.3 but with generics support.
-igor
On Mon, May 12, 2008 at 9:53 PM, Andre Prasetya
<[EMAIL PROTECTED]> wrote:
&g
Thanks, I'm still new to Wicket, is there any examples in using 1.4 ? a
best practices maybe ?
-andre-
Igor Vaynberg wrote:
there is no need for a separate annots project since the entire
codebase is now on java5, so annots was merged into wicket-spring
-igor
--
there is no need for a separate annots project since the entire
codebase is now on java5, so annots was merged into wicket-spring
-igor
On Mon, May 12, 2008 at 2:30 AM, Andre Prasetya
<[EMAIL PROTECTED]> wrote:
> thanks, how about the wicket-spring-annot ?
>
> http://repo1.maven.org/maven2/org/
merged
On Mon, May 12, 2008 at 11:30 AM, Andre Prasetya <[EMAIL PROTECTED]>
wrote:
> thanks, how about the wicket-spring-annot ?
>
> http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring-annot/
>
> is the 1.3.3 version compatible with the 1.4-m1 ?
>
> Frank Bille wrote:
>
> > http://repo1
thanks, how about the wicket-spring-annot ?
http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring-annot/
is the 1.3.3 version compatible with the 1.4-m1 ?
Frank Bille wrote:
http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring/1.4-m1/
---
Andre Prasetya
> > <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Doug Donohoe wrote:
> > >
> > >
> > >
> > > > I just migrated to 1.4-M1 and converted all my classes to use the new
> > > > generics support. It cleaned up
Sun, May 11, 2008 at 8:10 PM, Andre Prasetya
<[EMAIL PROTECTED]> wrote:
Doug Donohoe wrote:
I just migrated to 1.4-M1 and converted all my classes to use the new
generics support. It cleaned up my code quite nicely - I got to remove a
lot of casting and cured many unchecked/raw me
spring support has been there since 1.2, see wicket-spring and spring examples.
-igor
On Sun, May 11, 2008 at 8:10 PM, Andre Prasetya
<[EMAIL PROTECTED]> wrote:
> Doug Donohoe wrote:
>
> > I just migrated to 1.4-M1 and converted all my classes to use the new
> > generics
Doug Donohoe wrote:
I just migrated to 1.4-M1 and converted all my classes to use the new
generics support. It cleaned up my code quite nicely - I got to remove a
lot of casting and cured many unchecked/raw messages.
It also make the code much more readable - especially in list views, etc
I just migrated to 1.4-M1 and converted all my classes to use the new
generics support. It cleaned up my code quite nicely - I got to remove a
lot of casting and cured many unchecked/raw messages.
It also make the code much more readable - especially in list views, etc.
Excellent work, Wicket
nded approach is.
>
> Thanks,
>
> -Doug
>
--
View this message in context:
http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115478.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You are correct, WebPage is for the model type of your page. This allows
you to do MyObject getObject(), etc. I, too, am trying to deal with all of
the generics warnings right now and figure out what my strategy will be for
pages without a model.
One suggestion that has been made on the list is
;
> -Doug
> --
> View this message in context:
> http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115357.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> --
hecked' and 'raw use' warnings now, so I'd like to know
what the recommended approach is.
Thanks,
-Doug
--
View this message in context:
http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115357.html
Sent from the Wicket -
(Iterator source) {
...
}
abstract IModel map(T sourceElement);
}
-
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
View this message in context:
http://www.nabble.com/VOTE%3A-Generics-
ider
> [ x ] Iterator> , drop model
> [ ] Leave as is.
>
> Looks most elegant to me, and it is immediately clear what T is for.
> Also, I think that generics are bloody verbose anyway, so I'm not much
> in favor of shortening things up - and not support some of the use
I would have a better idea if I would have had the chance to actually
play with it, but here is mine:
[ ] IDataProvider
[ x ] Iterator> , drop model
[ ] Leave as is.
Looks most elegant to me, and it is immediately clear what T is for.
Also, I think that generics are bloody verbose anyway, so
> VOTE:
>
> [ ] IDataProvider
> [ ] Iterator> , drop model
> [X] Leave as is.
>
>
-Matej
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> [ ] IDataProvider
> [ ] Iterator> , drop model
> [X] Leave as is.
- --
Philip A. Chapman
Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.
e integer -> object mapping usecase is
not common and could lead to performance problems. However, I'm
somewhat torn between the last two options. Having that model method
there was somewhat confusing in the first place when I was learning
about it, but that could just be because generic
On 4/24/08, Jan Kriesten <[EMAIL PROTECTED]> wrote:
> [ ] IDataProvider
> [ ] Iterator> , drop model
> [X] Leave as is.
I don't see the additional benefit of removing the model method. It
only breaks API for nothing much gained.
Martijn
[ ] IDataProvider
[X] Iterator> , drop model
[X] Leave as is.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ ] IDataProvider
[ X ] Iterator> , drop model
[ ] Leave as is.
Thijs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ped within
> iterator and no extra lookups would be necessary. Implementation code of
> iterator might get a bit uglier, though.
>
> - add a second type as shown with example above
>
> Would lead to "redundant" type definitions for many usecases wh
definitions for many usecases where
iterator + model actually return the same type.
I'd really like to see support for generics with these cases as well.
Best regards, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For a
ra lookups would be necessary. Implementation code of
iterator might get a bit uglier, though.
- add a second type as shown with example above
Would lead to "redundant" type definitions for many usecases where iterator +
model actually return the same type.
I'd really like t
t a matter of time that
> > Johan can invest in it :)
> >
> > -Matej
> >
> > On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson
> > <[EMAIL PROTECTED]> wrote:
> > > Maybes it's simple and I missed it, but why don't Page and WebPage
>
[EMAIL PROTECTED]> wrote:
> > Maybes it's simple and I missed it, but why don't Page and WebPage
> implement
> > generics? (Or maybe it's just coming in next milestone?)
> >
> > It would ensure that I don't pass an IModel to a page that needs
>
5:03 PM, Jeremy Thomerson
> <[EMAIL PROTECTED]> wrote:
> > Maybes it's simple and I missed it, but why don't Page and WebPage
> implement
> > generics? (Or maybe it's just coming in next milestone?)
> >
> > It would ensure that I don't pass an IMod
Hi,
Of course page will be generified, it's just a matter of time that
Johan can invest in it :)
-Matej
On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson
<[EMAIL PROTECTED]> wrote:
> Maybes it's simple and I missed it, but why don't Page and WebPage implement
> gen
Maybes it's simple and I missed it, but why don't Page and WebPage implement
generics? (Or maybe it's just coming in next milestone?)
It would ensure that I don't pass an IModel to a page that needs an
IModel for it's model. Also, from any anonymous subclass of
Time to call this vote...
This thread has collected according to my best calculations the
following statistics:
-1 : 2
-0 : 1
+1 : 6 non-votes in 100 messages : 100 - 6 - 2 - 1 = 91
I think we can safely say that with the next release Wicket will
finally be Java 5 based, will be generics only
ur opinion or asking questions. This makes counting the votes much
>> easier.
>>
>> The discussion on our development list makes it clear that a lot of
>> folks are anxious for generified models. Most users if not all wish us
>> to release a quick release which is 1
lot of
> folks are anxious for generified models. Most users if not all wish us
> to release a quick release which is 1.3 + generics. The consequence is
> that the core team will stop to support 1.3, and that everybody that
> wishes updates will have to migrate to 1.4, and upgrade to Jav
gt;> > > This thread is for voting only. Use the [discuss] thread for voicing
>> > > your opinion or asking questions. This makes counting the votes much
>> > > easier.
>> > >
>> > > The discussion on our development list makes it clear th
> > >
> > > The discussion on our development list makes it clear that a lot of
> > > folks are anxious for generified models. Most users if not all wish us
> > > to release a quick release which is 1.3 + generics. The consequence is
> > > that the core
for voicing
> > your opinion or asking questions. This makes counting the votes much
> > easier.
> >
> > The discussion on our development list makes it clear that a lot of
> > folks are anxious for generified models. Most users if not all wish us
> > to release a
nxious for generified models. Most users if not all wish us
> to release a quick release which is 1.3 + generics. The consequence is
> that the core team will stop to support 1.3, and that everybody that
> wishes updates will have to migrate to 1.4, and upgrade to Java 5.
>
> Ever
h
> > easier.
> >
> > The discussion on our development list makes it clear that a lot of
> > folks are anxious for generified models. Most users if not all wish us
> > to release a quick release which is 1.3 + generics. The consequence is
> > that the core tea
nxious for generified models. Most users if not all wish us
> to release a quick release which is 1.3 + generics. The consequence is
> that the core team will stop to support 1.3, and that everybody that
> wishes updates will have to migrate to 1.4, and upgrade to Java 5.
>
> Ever
lot of
> folks are anxious for generified models. Most users if not all wish us
> to release a quick release which is 1.3 + generics. The consequence is
> that the core team will stop to support 1.3, and that everybody that
> wishes updates will have to migrate to 1.4, and upgrade t
would be pretty up to date.
> > --
> > View this message in context:
> http://www.nabble.com/-vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-tp16090054p16136628.html
> >
+1
On Wed, Mar 19, 2008 at 12:58 AM, Antony Stubbs <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Most people who use Wicket, I imagine, would be pretty up to date.
> --
> View this message in context:
> http://www.nabble.com/-vote--Release-1.4-with-only-generi
+1
Most people who use Wicket, I imagine, would be pretty up to date.
--
View this message in context:
http://www.nabble.com/-vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-tp16090054p16136628.html
Sent from the Wicket - User mailing list archive at Nabble.com
+1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
-Markus
+1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 definitely
On Tue, Mar 18, 2008 at 12:30 PM, Piller Sébastien <[EMAIL PROTECTED]>
wrote:
> +1 for the generics. One of the best things in JDK5 ;)
>
> [*X*] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
> [ ] -1, I need a supported version running on Java 1.4
>
501 - 600 of 678 matches
Mail list logo
