[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] STILL a compilation error with generics
|
I deliberately didnt check case4 into CVS until I had it working ;)
Because I knew you'd see it. However, I've fixed it now and its in.
Andy.
On 17/11/05, Alexandru Popescu <the.mindstorm.mailinglist@xxxxxxxxx> wrote:
> #: Andy Clement changed the world a bit at a time by saying on 11/17/2005 10:41 AM :#
> > *sigh* we really should have handled this in a bug report given the
> > amount of mail its generating ... oh well.
> >
> >
> >> 1/ about org.aspectj\modules\tests\java5\generics\bugs\lists\case1:
> >>
> >> The current CVS version of Bean and the aspect look:
> >>
> >> [code]
> >> public class Bean implements LongIdentifiable {
> >>
> >> public Long getId() {
> >> return null;
> >> }
> >>
> >> public void setId(Long t) {
> >> }
> >>
> >> }
> >>
> >> public aspect IdentifiableAspect {
> >> declare parents: Bean implements LongIdentifiable;
> >>
> >> private Long LongIdentifiable.m_id;
> >>
> >> public Long LongIdentifiable.getId() {
> >> return m_id;
> >> }
> >>
> >> public void LongIdentifiable.setId(Long id) {
> >> m_id= id;
> >> }
> >>
> >> public static void main(String []argv) {
> >> new Bean();
> >> }
> >> }
> >> [/code]
> >>
> >> as far as I can say: this test case may be used only to proove that the aspect will not replace the
> >> original methods in the bean. Is this the correct interpretation?
> >
> > This tests that bridge methods are handled correctly - the testcase
> > revealed a problem with their creation which I fixed.
> >
> >
> >> On the same scenario: try replacing the aspect main method with this main method:
> >>
> >> [code]
> >> public static void main(String []argv) {
> >> Bean b = new Bean();
> >> b.setId(37L);
> >> long l = b.getId();
> >> if (l!=37L) throw new RuntimeException("id should be 37");
> >> }
> >> [/code]
> >>
> >> and you will have a surprize: a NPE thrown on the statement b.getId();
> >
> > Its not surprising. ITDs on interfaces provide a default
> > implementation that is picked up by an implementor of the interface
> > that doesn't provide their own version of those methods. Bean
> > provides a version that returns null - so it doesn't get the ITD
> > versions and you get null. You get the null at the b.getId() line
> > because getId() returns a 'Long' object and the variable is of type
> > 'long' - the internal autoboxing call added by the compiler to unbox
> > the Long into a long blows up NPE.
> >
> >
> >> 2/ about org.aspectj\modules\tests\java5\generics\bugs\lists\case2:
> >>
> >> The current CVS version of Bean and the aspect look:
> >>
> >> [code]
> >> public class Bean implements LongIdentifiable {
> >> }
> >>
> >> public aspect IdentifiableAspect {
> >> declare parents: Bean implements LongIdentifiable;
> >>
> >> private Long LongIdentifiable.m_id;
> >>
> >> public Long LongIdentifiable.getId() {
> >> return m_id;
> >> }
> >>
> >> public void LongIdentifiable.setId(Long id) {
> >> m_id= id;
> >> }
> >>
> >> public static void main(String []argv) {
> >> Bean b = new Bean();
> >> b.setId(37L);
> >> long l = b.getId();
> >> if (l!=37L) throw new RuntimeException("id should be 37");
> >> }
> >> }
> >> [/code]
> >>
> >> With the AJ M5 and the AJDT incorporating it, the compilation of the above code failes with 2
> >> reported errors:
> >>
> >> Severity Description Resource In Folder Location Creation Time Id
> >> 2 can't override java.lang.Long org.noco.generics.LongIdentifiable.getId() with java.lang.Object
> >> org.noco.generics.Bean.getId() return types don't match Bean.java
> >> aj5_examples/src/main/org/noco/generics line 1 November 17, 2005 1:49:03 AM 27541
> >>
> >> Severity Description Resource In Folder Location Creation Time Id
> >> 2 can't override java.lang.Long org.noco.generics.LongIdentifiable.getId() with java.lang.Object
> >> org.noco.generics.Bean.getId() return types don't match IdentifiableAspect.aj
> >> aj5_examples/src/main/org/noco/generics line 8 November 17, 2005 1:49:03 AM 27532
> >
> > Doesnt look like the fix for these problems made it into M5. Have you
> > tried compiling this program with the latest from HEAD?
> >
> >> Another thing is that the above code would be pretty strange:
> >> - Bean declares as implementing the LongIdentifiable interface
> >> - the aspect has a declare parents for the same thing
> >
> > I put any testcase in the suite that demonstrates a failure -
> > regardless of how sensible it might be... you should see some of the
> > bizarre programs that are checked in ;)
> >
> >>
> >> 3/ the correct scenario I am looking for is:
> >>
> >> [code]
> >> public class Bean {}
> >>
> >> public aspect IdentifiableAspect {
> >> declare parents: Bean implements LongIdentifiable;
> >>
> >> private Long LongIdentifiable.m_id;
> >>
> >> public Long LongIdentifiable.getId() {
> >> return m_id;
> >> }
> >>
> >> public void LongIdentifiable.setId(Long id) {
> >> m_id= id;
> >> }
> >>
> >> public static void main(String []argv) {
> >> Bean b = new Bean();
> >> b.setId(37L);
> >> long l = b.getId();
> >> if (l!=37L) throw new RuntimeException("id should be 37");
> >> }
> >> }
> >> [/code]
> >>
> >> In the same env (M5 and AJDT incorporating it), this fails exactly the same way it failed from the
> >> beginning.
> >
> > This demonstrates yet a *third* case of bridge methods causing a
> > problem - and I was silly not to spot that it could happen. Because
> > the interface isn't on Bean from the beginning the binary weaving of
> > declare parents code that verifies rules about what can override what
> > was confused by a bridge method. So, you will now find a 'case3' in
> > the tree and this is fixed too.
> >
> > All 3 cases in the tree compile and run for me with the HEAD version
> > of the compiler.
> >
> >
> >> I really hope we can get this issue solved soon, as my proof of concept is getting on the wrong
> >> direction :-(.
> >
> > The cases you've raised are exactly the kind of testing I want to see
> > of the generics support we have - and I thank you for that. Generics
> > introduces a whole new range of possibilities and although we've added
> > 1400 tests in AspectJ5 beyond what was in AspectJ1.2.1, there are many
> > more 1000s of testcases that could be written to exercise the compiler
> > and weaver.
> >
> > There is a 'case4' of your program, but I'm not going to tell you what
> > it is until I have it working ;)
> >
> > Andy.
>
>
> But you probably forgot that I am updated, so I just can take a look ;-).
>
> I will give a try with the CVS HEAD, and report it back.
>
> thanks a lot,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
