tools.analyzer

Another difference in reflection warnings from eval'ing emit-form vs. plain Clojure

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I think the list of differences between reflection warnings issues by 'lein check' and Eastwood for projects in Eastwood's crucible is getting fairly short now, but there are still a few.

I have switched to doing my comparison with Clojure 1.6.0-master-SNAPSHOT after realizing that a few of the differences go away when using that, I think due to the change introduced by CLJ-1202.

Get latest 'reply' project (it is one pulled by Eastwood crucible), and edit its project.clj file to add these things:

:global-vars {*warn-on-reflection* true}

   :profiles {:dev {:dependencies ~dev-deps}
              :1.6 {:dependencies [[org.clojure/clojure "1.6.0-master-SNAPSHOT"]]

Then run the command below, assuming you have done 'mvn install' on latest Clojure 1.6.0-master-SNAPSHOT:

lein with-profile 1.6 eastwood '{:namespaces [reply.reader.jline.JlineInputReader] :debug #{:eval}}'

[ ... ]

Reflection warning, reply/reader/jline/JlineInputReader.clj:15:10 - reference to field state can't be resolved.
Reflection warning, reply/reader/jline/JlineInputReader.clj:18:18 - reference to field readLine can't be resolved.
Reflection warning, reply/reader/jline/JlineInputReader.clj:30:10 - reference to field state can't be resolved.

No reflection warnings appear for that namespace in the output of 'lein with-profile 1.6 check'

Activity

Hide
Nicola Mometto added a comment -

Honestly I have absolutely no idea how that code doesn't trigger a reflection warning in Clojure.
There must be something going on under the wood of gen-class that I'm not aware of, I'll need some time to take a look & understand.

Thanks for the report

Show
Nicola Mometto added a comment - Honestly I have absolutely no idea how that code doesn't trigger a reflection warning in Clojure. There must be something going on under the wood of gen-class that I'm not aware of, I'll need some time to take a look & understand. Thanks for the report
Hide
Nicola Mometto added a comment -

Upon further investigation, I think that for some reason Clojure is not printing the reflection warning even though reflection is actually needed.

Empirical evidence: try to change a method call to .foo and no reflection warning will be printed.

Show
Nicola Mometto added a comment - Upon further investigation, I think that for some reason Clojure is not printing the reflection warning even though reflection is actually needed. Empirical evidence: try to change a method call to .foo and no reflection warning will be printed.
Hide
Nicola Mometto added a comment -

Verified that if the (set! warn-on-reflection true) is put in the ns, I get the same reflection warnings from clojure.

I have no idea why it won't print when warn-on-reflection is set! outside the ns though.

Show
Nicola Mometto added a comment - Verified that if the (set! warn-on-reflection true) is put in the ns, I get the same reflection warnings from clojure. I have no idea why it won't print when warn-on-reflection is set! outside the ns though.
Hide
Andy Fingerhut added a comment -

Weird, I was trying to reproduce this again to see why 'lein check' was not producing those warnings, but now it is. I can't think what might have changed since yesterday.

Show
Andy Fingerhut added a comment - Weird, I was trying to reproduce this again to see why 'lein check' was not producing those warnings, but now it is. I can't think what might have changed since yesterday.
Hide
Andy Fingerhut added a comment -

Not sure, but the :gen-class may have something to do with it. If the class has already been generated, perhaps Leiningen is not recompiling that file. 'lein clean' first should make things more consistent.

Show
Andy Fingerhut added a comment - Not sure, but the :gen-class may have something to do with it. If the class has already been generated, perhaps Leiningen is not recompiling that file. 'lein clean' first should make things more consistent.
Hide
Andy Fingerhut added a comment -

Confirmed. If you do 'lein clean' then 'lein check' twice with no changes to the source files, the warnings are produced the first time, but not the second. If you edit the source file, it is newer than the target class file and so gets recompiled.

Show
Andy Fingerhut added a comment - Confirmed. If you do 'lein clean' then 'lein check' twice with no changes to the source files, the warnings are produced the first time, but not the second. If you edit the source file, it is newer than the target class file and so gets recompiled.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: