Neal Gafter schrieb:
> On Mon, Jan 19, 2009 at 6:38 PM, Jochen Theodorou <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Neal Gafter schrieb:
>
> > I think javac is acting correctly. It requires that every abstract
> > method have an implementation visible to the programmer.
>
> is there any specification on this? I mean I understand that there has
> to be an implementation, but that is has to be visible to the
> programmer? It doesn't really fit my thinking.
>
> Yes, the language specification. The "synthetic" methods don't play into
> the language specification, so they don't qualify as implementations.
Well, I was interested in the specific place. the only part about
synthetic I found is the part about adding code without source
representation
> Also in the case
>
> interface A<T> {
> T foo();
> }
>
> abstract class B implements A<String>{
> public String foo(){
> return null;
> }
> }
>
> class C extends B {}
>
> how does javac know there is a visible implementation?
>
> Because it can see it there in class B.
I playex a bit around with this... it seems javac is indeed checking for
the visible method even if the bridge method would call a different
method... btw, can someone explain what exaclty the bridge flag is for?
If I remove the bridge flag for the synthetic method in the case above,
then it will still compile.
> So I am just "lucky" that javac does not check this?
>
> Yes.
hmm... that means I have to rethink the usage of synthetic in the groovy
compiler
> If I have a tool that adds an interface and the implementation for the
> methods in the interface for the class, then I cannot make that
> synthetic even though there is no source representation for it and that
> means it should be synthetic? Or is there a way to keep the methods
> synthetic and avoid javac complaining about the methods not being
> implemented?
>
> Synthetic methods "don't exist" from a language perspective - they are
> implementation artifacts only. If you want the interface to be
> implemented, there must be something that guides what will be in the
> body of the implementation. What implementation is it adding?
The groovy compiler is doing that. And if it is groovyc alone, that is
involved all is fine, because this restriction of a visible method from
a language perspectiveis not important for the VM. But if you compile
against a class compiled bye groovyc, then we have the trouble for any
abstract class. Because groovy needs to add the interface GroovyObject
to the class and the implementation of the methods. Currently these
methods are flagged synthetic, because they have no source
representation. Now it seems I have to remove that flag for these methods.
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
