Oh! Yes, I think that's it. I didn't realize the uberjar would include
source, which clojure would attempt to re-compile. I'm not sure why that
would be useful in an uberjar.
I tried the lein :omit-source flag, which does indeed omit the source for
my project, but still includes the source for
Hello,
I think it does for deciding whether to use the class file found on disk,
or to recompile the namespace in memory from the .clj file.
Does the above make sense ?
Laurent
Le mercredi 10 décembre 2014, Brian Craft a écrit :
> This exception is related to the pack200 -m option, which alter
This exception is related to the pack200 -m option, which alters class file
timestamps.
Do clojure class loaders depend on class file timestamps?
On Monday, December 8, 2014 9:15:57 AM UTC-8, Brian Craft wrote:
>
> Assuming this is something to do with class loaders going wrong, how would
> I a
Assuming this is something to do with class loaders going wrong, how would
I approach finding the code paths involved? Could I identify where the
class is being loaded; set breakpoints at those places to get the stack
traces? Something else?
In my case it seems to be triggered by a type hint on
Not sure if I followed the non-interactive case. Is it just
1) deftype or defrecord in one file
2) import the class in a different file
3) AOT compile (e.g. uberjar)?
On Saturday, December 6, 2014 11:07:36 PM UTC-8, Ambrose Bonnaire-Sergeant
wrote:
>
> Perhaps this issue is biting you
> http://
Perhaps this issue is biting you http://dev.clojure.org/jira/browse/CLJ-979
Thanks,
Ambrose
On Sat, Dec 6, 2014 at 5:22 PM, Brian Craft wrote:
> Yes, I know. ;) In this case it's happening with an uberjar, not with the
> repl. I do "java -jar myapp.jar", and later, while it is processing data,
Yes, I know. ;) In this case it's happening with an uberjar, not with the
repl. I do "java -jar myapp.jar", and later, while it is processing data,
get this exception. No repl involved.
On Saturday, December 6, 2014 2:02:01 PM UTC-8, juan.facorro wrote:
>
> Hi Brian,
>
> This problem usually hap
Hi Brian,
This problem usually happens when working on the REPL and you redefine a
record or type (derecord and deftype), but there are still some existing
instances lying around, that belong to the previous definition of that same
type.
See this thread for more
information:
https://groups.g
I'm experimenting with jwrapper, and am getting runtime exceptions like
this, due to some jar manipulation that it's doing. I know one of the steps
is pack200, however running pack200 manually doesn't create these issues.
Anyone have suggestions for debugging this? I've seen this type of error
