Absolutely, although with this fix execution doesn't work properly (for
example, the tests fail because when you import a gen-class'ed class its
namespace isn't loaded). However it would be good to be able to toggle it
via a system property or something for compilation purposes. It's possible
that
Definitely exciting to hear that it works. Is this something you could
propose as a patch on the Clojure JIRA?
On Friday, December 27, 2013 9:52:04 PM UTC-5, Colin Fleming wrote:
>
> Wow, that works! You just saved me an extraordinary amount of pain - thank
> you!
>
> I had to make one further s
Wow, that works! You just saved me an extraordinary amount of pain - thank
you!
I had to make one further small change, to invoke the method on RT instead
of Class, but that was it.
On 28 December 2013 14:16, Aaron Cohen wrote:
> I have the sneaking suspicion that this may be as simple as chan
I have the sneaking suspicion that this may be as simple as changing
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L697
to:
final static Method forNameMethod = Method.getMethod("Class
*classForNameNonLoading*(String)");
and making "classForNameNonLoading" pu
Yeah I tried this with RoboVM, but there are so many classes that needed to
be stubbed that it turned into an endless rabbit hole, so I gave up. It may
be a good solution for those who just have one or two problematic classes,
though.
On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Flemi
In case anyone is interested in a workaround for this, I managed to "fix"
my compilation by stubbing out the problematic classes and putting the
stubs ahead of the real classes in the classpath when I compile. Where
those stubs return other objects that are required during static
initialisation, I
I've just spent some time today looking at the compiler code, and
unfortunately I think the answer is "no". When a symbol is imported,
Clojure currently instantiates the Class object using Class.forName() and
stores that in the namespace's mapping. At the point the Class is
instantiated, static ini
Is this something that is fixable?
--
--
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 unsubscri
Right, my Spacing problem is not related to the static initializer problem
(which I also suffer from) but it is another example of (what seems to me)
a fairly standard pattern that I can't use in Clojure if I AOT and which
doesn't have an obvious workaround.
On 24 October 2013 03:32, Alex Miller
Agreed - merely importing this class shouldn't be an issue (which is the
issue at hand).
If you need to configure Spacing, you should do that prior to using it in
your def, but that should work fine. If that needs to happen at runtime,
then you shouldn't do this in a def.
On Wednesday, Octob
That's how I read things. Importing a class causes the class to be loaded
(via Class.forName()) so that it can be stored in the namespace's mappings.
My impression from the commented out older code is that some prior
incarnation of the code used class names instead of Class objects in some
prio
So, is this a correct summary of the problem?
"Importing a class in clojure causes static initializers to run. This
differs from Java where static initializers don't run until the first
'initialization' (either the invocation of a constructor, or invocation of
a 'main' method) of a class. In some
I'm not sure if this is related to the original problem.
How is the setFactory method expected to be invoked, through some sort of
dependency injection framework?
On Wed, Oct 23, 2013 at 7:06 AM, Colin Fleming
wrote:
> I've also had a lot of problems with def'ed forms. For example, if I do
> t
I've also had a lot of problems with def'ed forms. For example, if I do
this:
(def no-spacing (Spacing/createSpacing 0 0 0 false 0))
Which looks like this:
public static Spacing createSpacing(int minSpaces,
int maxSpaces,
Here's the error I get when I import LibGDX's Timer class:
http://pastebin.com/q7wys8yi
On Tuesday, October 22, 2013 9:55:16 PM UTC-4, Alex Miller wrote:
>
> I'd love to see a stack trace when that happens (could even be triggered
> by dumping stack in your static initializer if nothing else).
>
I'd love to see a stack trace when that happens (could even be triggered by
dumping stack in your static initializer if nothing else).
On Saturday, October 12, 2013 3:17:50 AM UTC-5, Wujek Srujek wrote:
>
> So you are saying compilation is trying to instantiate class and run
> static initializer
I'm just pulling LibGDX from maven and trying to call its classes via
Clojure. I don't doubt that mock classes could work, but I think the effort
in writing and maintaining them would be more than it's worth.
On Saturday, October 12, 2013 4:25:15 PM UTC-4, Colin Fleming wrote:
>
> In my case I'm
In my case I'm AOTing, so compiling against one set of classes then running
against another isn't difficult. If you're compiling from source it's
tougher, but aren't you basically compiling at runtime at that point?
Couldn't you work around it changing your startup order (i.e. loading
LibGDX with s
Compiling against mock classes is the other solution I've tried as well.
I'm not sure how the real classes would take over once the program is run,
and also it's a quite laborious and brittle solution since updates to the
real classes would break the mock classes. Definitely interested in ideas
Yup, it's true. I suffer from this as well. When I'm compiling Cursive
normal compilation fails because a bunch of the IntelliJ classes assume the
IntelliJ platform is running and barf if it's not. I have an awful hack
which is to run the compilation within their test framework which sets up a
mock
So you are saying compilation is trying to instantiate class and run static
initializers? This seems very backward, are you sure?
On Sat, Oct 12, 2013 at 8:30 AM, Zach Oakes wrote:
> I should add, I am aware I can bring in a class dynamically with
> Class/forName, and that is what I ended up do
I should add, I am aware I can bring in a class dynamically with
Class/forName, and that is what I ended up doing for the Timer class.
However, this is not always practical, and sometimes is simply not an
option if aot-compilation is required.
On Saturday, October 12, 2013 2:28:38 AM UTC-4, Zac
I recently learned that merely importing a Java class in Clojure causes
static initializers to be run. Sometimes, this causes compilation errors,
because they are written with the assumption that they will only be run
during runtime.
I ran into this just now while trying to make a simple Clojur
23 matches
Mail list logo
