Clojurians Log v2

@alexmiller has joined the channel

could you drop the first 10 lines or so of the stack trace? (pst)

what jvm were the protobuff objects compiled with?

I shall, and JVM 1.8

so java modules were added in Java 1.9, not sure if that's involved here (doesn't really look like it from the message)

@ghadi has joined the channel

IllegalAccessError tried to access field com.google.protobuf.AbstractMessage.memoizedSize from class com.foo.Foo$Bar
        com.foo.Foo$Bar.getSerializedSize (DQAProto.java:7881)
        com.google.protobuf.AbstractMessageLite.toByteArray (AbstractMessageLite.java:62)
        message_window_enricher.interop.Interop.messageWindowToBytes (Interop.kt:12)
        user/eval32140 (NO_SOURCE_FILE:1)
        user/eval32140 (NO_SOURCE_FILE:1)
        clojure.lang.Compiler.eval (Compiler.java:7177)
        clojure.lang.Compiler.eval (Compiler.java:7132)
        clojure.core/eval (core.clj:3214)
        clojure.core/eval (core.clj:3210)
        clojure.main/repl/read-eval-print--9086/fn--9089 (main.clj:437)
        clojure.main/repl/read-eval-print--9086 (main.clj:437)
        clojure.main/repl/fn--9095 (main.clj:458)

I'm kind of wondering if you'd have same result if you had compiled the protobuf object w/Java 12

Thing is, I have a project, in pure java 1.8, does the same thing, works fine. Even when I switch the project to java 12, works fine

@thenonameguy has joined the channel

only in Clojure am I seeing this issue.

kotlin both when compiling to java 1.6 and 1.8 bytecode, works fine.

well those symptoms sound like a reflection issue - if you (set! *warn-on-reflection* true), do you see any reflection warnings?

No, and I have that on

reading the error, it sounds like messages can cache the computed size in the private memoizedSize field in the parent abstract class and the child class is unable to access the abstract parent field?

it's possible this is module related

when I switch to java 8, same issue with clojure

@sogaiu has joined the channel

java 8, kotlin/java == no issue

the confusing thing here is that the access error seems to be in calls from one external thing to another external thing, not in the Clojure call itself

Do you mind if I ping you privately, i.e., company data in error 🙂

@souenzzo has joined the channel

sure, although not sure how much time I have to look at it

I appreciate it - I hope it's something trivial and not a compiler bug

So, a huge thank you to Alex who helped me to get a solution to my problem by pointing the finger!

I had a rogue import of a protobuf library all the way from rebel readline which included the cljs libraries which included the closure compiler which included a version of protobuf that I am not using!

this solved the problem

:rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "RELEASE" :exclusions [org.clojure/google-closure-library
                                                                                       rewrite-cljs/rewrite-cljs]}}

May your fame increase a million fold Alex!

btw, it's a bad idea to use RELEASE versions, much better to set a fixed version

yes, thank you. Learning as I go 🙂

Your recommendation of using jhades helped tremendously

cool. I think there's some clojure lein plugin that does something similar too, but can't remember what it's called

I'll keep it in mind if I come across similar issues

(I'm getting a few use cases together for the adoption of clojure at work)

JHades seems useful

so translating one kotlin project to clojure will help 🙂

@andy.fingerhut has joined the channel

@seancorfield has joined the channel

@zulip-mirror-bot has joined the channel

(I just added the Zulip mirror bot so future discussions here will be archived and searchable within Zulip -- I didn't even know this channel existed!)

@lee has joined the channel