Inner classes.

[Stephane Le Dorze]

While trying to use a XX_Base.class generated in one project from an another one we stumble on a weird issue.

After investigation, Damiand and I found that it is related to the absence of an InnerClasse annotation in modified classes (via ASM) which generate a bug in the scala compiler.

Indeed, the scala compiler cannot read correctly the inner OID class of the DomainObjectAllocator when compiling the added constructor because it rely on the hint of InnerClasses annotation to do so.

So a fix would be to introduce such annotation during the addition of the constructor.

We're not (yet) fluent with the ASM framework and would be like to be enlightned and/or have an updated version of Fenix which fix the issue.

Thanks!

Stephane & Damian

[Stephane Le Dorze]

We've added the generation of a fake method in the dml -> java code generator.

This method take a pt.ist.fenixframework.pstm.DomainObjectAllocator.OID  as a dummy parameter and does nothing more.

This simple hack introduce the requiered InnerClasse annotation which enables the scala compiler to find the inner classes.

So we confirm that this is really the issue and that this quick hack could be done safely while waiting for a real fix.

We'll using the hack until a fix is done on the Fenix Trunk (We need it to split our projects).

Can someone do the temporary hack/fix on the trunk?

Thanks

Stephane

2009/11/19 Stephane Le Dorze <stephane...@gmail.com>

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> After investigation, Damiand and I found that it is related to the
> absence of an InnerClasse annotation in modified classes (via ASM)
> which generate a bug in the scala compiler.

I don't know which annotation are you talking about.
Is that Scala specific?

If so, can you give some pointers where I can read more about it (or
else, explain it a little bit better)?

> Indeed, the scala compiler cannot read correctly the inner OID class
> of the DomainObjectAllocator when compiling the added constructor
> because it rely on the hint of InnerClasses annotation to do so.

But the constructor that receives an OID is generated at the bytecode
level (via ASM), so how is scala compiler trying to compile it? Does
the scala compiler processes the bytecode also?

--
João Cachopo

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> We've added the generation of a fake method in the dml -> java code generator.
> This method take a
> pt.ist.fenixframework.pstm.DomainObjectAllocator.OID as a dummy
> parameter and does nothing more.
> This simple hack introduce the requiered InnerClasse annotation which
> enables the scala compiler to find the inner classes.

Are you saying that when the javac compiler compiles that file, that the
bytecode that it generates includes the InnerClasse annotation?

I've never seen such a thing, but then again it may be something new in
the latest Java version...

--
João Cachopo

[Stephane Le Dorze]

In fact scala is not compiling this code but using it.

I'll try to give the explanation:

Here's some classes definition:

class A {

  class B {

  }

}

here's a usage:

class C {

   void foo(A.B x) {

 ...

   }

}

When compiling C; the output byte code representing C will contain an Inner class annotations which indicates that A.B is an inner class of A.

Scala use it for class loading; if it is not present, loading could fail.

The issue with the ASM code modification (replace A.B by DomainObjectAllocator.OID) is that the Inner Classe annotation is not present.

By adding at the java generator phase a fake method; We artificially for the compiler to add such a annotation.

I think we can find documentation on this in the ASM doc..

Was it clear or not enough?

Stephane

--

You received this message because you are subscribed to the Google Groups "Fénix Framework" group.
To post to this group, send email to fenix-f...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fenix-framework?hl=.

[Stephane Le Dorze]

This is not new but it does not create any issue (as far as I know for javac) scalac however rely on this information (even if it is the same person which designed the two compiler..)

--
João Cachopo

[Stephane Le Dorze]

this is the issue which bring light to us:

https://lampsvn.epfl.ch/trac/scala/ticket/1879

this bug appeared some time ago in eclipse also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=171184

I think it is self explaning.

[Stephane Le Dorze]

and this JVM spec:

http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#79996

[Joao Cachopo]

Stephane Le Dorze <stephane...@gmail.com> writes:

> and this JVM spec:
> http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#79996

I wasn't aware of this. Thanks for pointing this out.
I just learned something new today ;)

Meanwhile, I've committed a fix to the fenix-framework. I hope that it
works as expected, as I was not able to reproduce the problem myself.
Please, check it out and report back.

Best regards,
--
João Cachopo

[Stephane Le Dorze]

Great!

I've learnt it also yersterday (now) :)
Thanks!

Stephane

João Cachopo

[Stephane Le Dorze]

The fix works fine.

Thanks!

Stephane