Last time I tried to give JRebel some love this issue made me drop it again (If
I remember the situation correctly):
Imagine you are developing a new page "HomePage" which has a single component
public HomePage()
{
add(new Label("foo", ...) { });
}
later on add another component
public HomePage()
{
add(new TextField("bar", ...) { });
add(new Label("foo", ...) { });
}
--> JRebel throws a "SuperClassChangedError" when trying to replace HomePage$1
This also happens when you change a component type (e.g. Link -->
BookmarkableLink) or in similar situations.
It's a known limitation (and no change in sight)
http://www.zeroturnaround.com/forum/topic.php?id=875
:-(
Am 18.11.2010 um 15:19 schrieb Carl-Eric Menzel:
> On Thu, 18 Nov 2010 14:25:40 +0100
> Martijn Dashorst <[email protected]> wrote:
>
>> Relaxing the add() method has been proposed before (by Eelco). It is
>> not something new, and if it helps people using jrebel to improve
>> their productivity, that would be a great side effect.
>
> I agree it would be a good side effect, but not a change worth doing
> just for the benefit of JRebel :) - only if the change adds something
> worthwhile on its own.
>
> I just googled for Eelco's original proposal to give add() the
> semantics of addOrReplace(), since I didn't even know about that
> proposal.
>
> I agree with what you say about "final" and the clear semantics of
> add() and addOrReplace(). I like the fact that with the current
> semantics I can choose whether I want to definitely add (and get an
> exception in case of a bug) or whether I want to, well, add or
> replace :-)
>
> Usually I prefer a slight bit of additional typing over an
> ambiguous/unclear API.
>
> Maybe someone who uses JRebel (I don't) can ask the JRebel guys about
> better support for this.
>
> Carl-Eric
> www.wicketbuch.de
