oh, right. thats a good point.

ill re-post that correction on the bug report.. thanks for the review!

On Wednesday, March 13, 2013 1:42:51 PM UTC+2, Marko Topolnik wrote:
>
> 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.


Reply via email to