Hey Sean,
Your attempt worked because in Netty 4.0.0.Alpha8
AbstractBootstraphttps://github.com/netty/netty/commit/23438de66f82c72720b092c539bb430995722d2d#transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
was
still public.. Try it out with 4.0.0.Beta2..
Thanks!
On
When you annotate, is it a runtime or a compile-time error? I would be very
surprised if it happened at runtime (when the function is actuall called).
On Wednesday, March 13, 2013 1:26:00 AM UTC+1, Shlomi Vaknin wrote:
hey, I have a similar problem, even when i type annotate with clojure 1.5
yes you are right, it is a compile-time error..
On Wednesday, March 13, 2013 11:19:25 AM UTC+2, Marko Topolnik wrote:
When you annotate, is it a runtime or a compile-time error? I would be
very surprised if it happened at runtime (when the function is actuall
called).
On Wednesday, March
here is the full exception when compiling:
Exception in thread main java.lang.IllegalArgumentException: Can't call
public method of non-public class: public
io.netty.bootstrap.AbstractBootstrap
io.netty.bootstrap.AbstractBootstrap.channel(java.lang.Class),
compiling:(netty.clj:31:1)
at
It is almost certain that the method you want to call is inherited from a
public ancestor. Annotate the call with that ancestor and it will work.
On Wednesday, March 13, 2013 10:23:31 AM UTC+1, shlomi...@gmail.com wrote:
here is the full exception when compiling:
Exception in thread main
hey
we dont need to be almost certain, we can just look at the code :
https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/bootstrap/AbstractBootstrap.java
and
see that it is not a public ancestor. more then that, i annotated the code
and it didnt work. here is a repl
It does have a public descendant, though. It is not acceptable for you to
annotate with ServerBootstrap? It really is bad practice to annotate with
non-public classes.
On Wednesday, March 13, 2013 10:43:35 AM UTC+1, shlomi...@gmail.com wrote:
hey
we dont need to be almost certain, we can
I fully agree with you, only it doesnt work.. ServerBootstrap does not
override that specific method, which is what causing this pain, so i dont
know what other options i have.
here is my attempt:
user (.channel ^ServerBootstrap b ^Class
io.netty.channel.socket.nio.NioServerSocketChannel)
I see, that's very unfortunate then. It fails even when it is not actually
making the reflective call. Your last recourse is writing your own code
against the Java Reflection API, using *setAccesible(true)* if necessary.
On Wednesday, March 13, 2013 11:03:50 AM UTC+1, shlomi...@gmail.com wrote:
hmmm, that what i was afraid of :)
ill take my chances harassing the netty people now before i go down that
path..
On Wednesday, March 13, 2013 12:09:44 PM UTC+2, Marko Topolnik wrote:
I see, that's very unfortunate then. It fails even when it is not actually
making the reflective call. Your
The netty people are not to blame; harass Rich instead :)
On Wednesday, March 13, 2013 11:11:46 AM UTC+1, shlomi...@gmail.com wrote:
hmmm, that what i was afraid of :)
ill take my chances harassing the netty people now before i go down that
path..
On Wednesday, March 13, 2013 12:09:44 PM
That is very true.
is here the right place? is there a a different group/forum for the
language developers? should i file a bug on github?
On Wednesday, March 13, 2013 12:17:45 PM UTC+2, Marko Topolnik wrote:
The netty people are not to blame; harass Rich instead :)
On Wednesday, March 13,
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
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
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
You didn't recompile everything, that's the reason. I got the same error
the first time, that's how I realized that the child had overridden the
method. This is an interesting finding in itself: javac provides the
override precisely to avoid pitfalls such as this one. If the parent was
public,
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
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
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
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,
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:
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
hey, I have a similar problem, even when i type annotate with clojure 1.5 i
still get that error.. any suggestions?
--
--
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
I meant to post this as a reply
to https://groups.google.com/d/msg/clojure/jYfEKVH5GsQ/3Hq5hU0u6UQJ
In my case i am trying to get clojure working with netty 4, here is the
code:
(def #^AbstractBootstrap b (ServerBootstrap.))
(.channel
On Tue, Mar 12, 2013 at 5:46 PM, shlomivak...@gmail.com wrote:
In my case i am trying to get clojure working with netty 4, here is the
code:
(def #^AbstractBootstrap b (ServerBootstrap.))
(.channel ^AbstractBootstrap b ^Class
io.netty.channel.socket.nio.NioServerSocketChannel)
which
I found the following work-around since I have access to the java code I am
calling:
I had the package-visible ABC Bytes implement a (public) interface
declaring the toHexString method. This placated the compiler.
On Monday, March 4, 2013, Vladimir Tsichevski wrote:
I think not. But upgrading
I think not. But upgrading to clojure 1.5 will do.
On Friday, March 1, 2013 1:20:57 PM UTC+4, Marko Topolnik wrote:
I'd say it's a bug. You are invoking a public class's method, which
happens to be inherited from a package-private class. Clojure's reflective
code accesses the superclass
Simplified, from a more complex example:
abstract class Bytes {
public toHexString() { return ...; }
Bytes { }
}
public class Hash extends Bytes {
public Hash() { super(); }
}
This works in Java:
new Hash().toHexString();
This fails in Clojure:
(.toHexString (Hash.))
I'd say it's a bug. You are invoking a public class's method, which happens
to be inherited from a package-private class. Clojure's reflective code
accesses the superclass method directly so there's no distinction between
direct invocation and invocation through inheritance.
If you are
29 matches
Mail list logo
