Hm. You shouldn't have made ConcreteChild a nested class, that is a
distraction that may set people on a wrong trail. In Java you are allowed
to have as many package-private classes as you wish; the constraint is only
on one *public* class. If you had ConcreteChild.java with this in it:
abstract class AbstractParent {
public final int x() { return 6; }
}
public class ConcreteChild extends AbstractParent {}
it would have compiled.
On Wednesday, March 13, 2013 12:16:10 PM UTC+1, shlomi...@gmail.com wrote:
>
> here is the bug report: http://dev.clojure.org/jira/browse/CLJ-1183
>
> Thanks!
>
> On Wednesday, March 13, 2013 1:02:25 PM UTC+2, shlomi...@gmail.com wrote:
>>
>> right, i managed to reproduce it here, thanks!
>>
>> so i am opening a bug and linking back here
>>
>> On Wednesday, March 13, 2013 12:48:43 PM UTC+2, Marko Topolnik wrote:
>>>
>>> Yes, the error is there. I also created a *lein new app* project, which
>>> by default creates a gen-classed main namespace:
>>>
>>> (ns call-test.core (:gen-class))
>>> (set! *warn-on-reflection* true)
>>> (defn -main [& args] (.x (test.ConcreteChild.)))
>>>
>>> Now try *lein do clean, uberjar. *It will report a reflection warning
>>> while AOT-compiling.
>>>
>>> Then do *java -jar target/call-test-0.1.0-SNAPSHOT-standalone.jar *and
>>> see it fail.
>>>
>>> This cleanly separates compile time from runtime.
>>>
>>> On Wednesday, March 13, 2013 11:44:05 AM UTC+1, shlomi...@gmail.comwrote:
>>>>
>>>> very interesting.. are you getting the same error as i originally got?
>>>>
>>>> On Wednesday, March 13, 2013 12:38:26 PM UTC+2, Marko Topolnik wrote:
>>>>>
>>>>> Detailed finding: it *doesn't* fail at compile time; it always fails
>>>>> at runtime.
>>>>>
>>>>> Reason: at compile time there is a *reflection warning*, which means
>>>>> that the method wasn't found and a reflective call was emited by the
>>>>> compiler.
>>>>>
>>>>> On Wednesday, March 13, 2013 11:31:08 AM UTC+1, Marko Topolnik wrote:
>>>>>>
>>>>>> I did it: the method must be final. Apparently without that the child
>>>>>> is compiled with an overriding method that I didn't even define!
>>>>>>
>>>>>> On Wednesday, March 13, 2013 11:27:55 AM UTC+1, Marko Topolnik wrote:
>>>>>>>
>>>>>>> You should first make a minimal example that reproduces this. I've
>>>>>>> just failed to do so with the following:
>>>>>>>
>>>>>>> abstract class AbstractParent {
>>>>>>> public void x() { System.out.println("x"); }
>>>>>>> }
>>>>>>>
>>>>>>> public class ConcreteChild extends AbstractParent {
>>>>>>> }
>>>>>>>
>>>>>>> user> (set! *warn-on-reflection* true)
>>>>>>> true
>>>>>>> user> (.x (test.ConcreteChild.))
>>>>>>> nil
>>>>>>> user> (.x ^test.AbstractParent (test.ConcreteChild.))
>>>>>>> nil
>>>>>>> user> (def cc (test.ConcreteChild.))
>>>>>>> #'user/cc
>>>>>>> user> (.x cc)
>>>>>>> Reflection warning, NO_SOURCE_PATH:1:1 - reference to field x can't
>>>>>>> be resolved.
>>>>>>> nil
>>>>>>> user>
>>>>>>>
>>>>>>> What must I add to break it?
>>>>>>>
>>>>>>>>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
