This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (4)
- # aleph (1)
- # announcements (7)
- # aws (10)
- # babashka (23)
- # beginners (23)
- # calva (20)
- # chlorine-clover (13)
- # cider (17)
- # clj-kondo (13)
- # cljfx (9)
- # cljsrn (9)
- # clojure (98)
- # clojure-australia (1)
- # clojure-dev (15)
- # clojure-europe (127)
- # clojure-nl (4)
- # clojure-sanfrancisco (3)
- # clojure-uk (98)
- # clojurescript (25)
- # community-development (8)
- # core-async (15)
- # cryogen (9)
- # cursive (7)
- # data-science (1)
- # datascript (5)
- # datomic (3)
- # devcards (2)
- # fulcro (5)
- # graalvm (1)
- # helix (8)
- # jackdaw (1)
- # jobs (5)
- # kaocha (17)
- # malli (5)
- # meander (5)
- # off-topic (37)
- # pathom (33)
- # pedestal (3)
- # re-frame (12)
- # reitit (1)
- # remote-jobs (3)
- # sci (1)
- # shadow-cljs (6)
- # testing (1)
- # vim (6)
- # vrac (5)
How do a call a specific java method (which is overloaded by type, rather than number of params)?
Often giving a type hint on at least one of the parameters that has a distinct type from the other java method signatures should do it. Might require multiple type hints if one isn't enough to make the signature unique.
that would be if the first parameter x is type
long in the Java method signature. Can also type hint any or all of the other parameters.
@U0CMVHBL2 That doesn’t seem to work for me. I’m calling this method on an instance https://javadoc.io/static/org.apache.pdfbox/pdfbox/2.0.21/org/apache/pdfbox/pdmodel/PDAppearanceContentStream.html#setNonStrokingColor-org.apache.pdfbox.pdmodel.graphics.color.PDColor-
Have you added
(set! **warn-on-reflection** true) near the beginning of the source file where you make that call? e.g. after the
That can help detect when the Clojure compiler has not successfully resolved the method down to only one choice at Clojure compile time.
Adding it will not help the compiler pick one of the methods, but it will quickly tell you if it hasn't.
Any reflection warnings you see when that is present in a file imply that the Clojure compiler will perform run-time Java reflection on each call it warns about, which can be quite slow relative to when those warnings are not there. I wouldn't worry about such warnings in code that is run once or a few times, but if it is in a hot code path you want to be fast, best to eliminate it.
When you say "it doesn't work for me", what do you see happening in your call that isn't working?
Are you certain that the type of the argument is actually PDColor, e.g. you have done a debug print or something similar just before that method call to show the class of the argument?
maybe something like
(if (not (instance? PDColor foo)) (println "(class foo)=" (class foo)))
It might be that 99.9% of the time it is the class you expect, but it only takes one that isn't ...
Here is what I know: 1. Class is definitely the right type 2. Type hinting makes no difference to which function is being called. I’ve even put a debug breakpoint in the function that should be called and it’s not being called.
This is the error
class org.apache.pdfbox.pdmodel.graphics.color.PDColor cannot be cast to class [F (org.apache.pdfbox.pdmodel.graphics.color.PDColor is in unnamed module of loader 'app'; [F is in module java.base of loader 'bootstrap')
A stack trace could tell you if the error is occurring in your code, at the call you are interested in now, or somewhere within the depths of the Java library
The most recent calls appear first in the stack trace. The first few are inside of Clojure's implementation of run-time reflection it appears
The first stack frame that is not inside of Clojure is this one: [ventures.fierce.pdfbox.appearance_content_stream$non_stroking_color_GT_ invokeStatic "appearance_content_stream.clj" 39]
The exception message is this: "Cannot cast org.apache.pdfbox.pdmodel.graphics.color.PDColor to [F"
complaining that it has a value of type PDColor, and it cannot cast it to type [F, where [ denotes a Java array of the next thing, and F is a 1-letter abbreviation for one of the Java primitive types, I think float IIRC
An array of primitive floats is the type of the only parameter of one of the other 1-parameter signatures of that method setNonStrokingColor, I see.
If you added that set! statement to warn on reflection, do you get a warning on this line 39?
Out of curiosity, do you have the dependency you added to your Leiningen project.clj file or deps.edn file for this apache library?
I might try to create a REPL locally on my machine and make a call to that method to see if I get the same behavior.
If you want to trigger it run the code in the comment block at the end of the core ns.
It may not matter, but what OS, JDK version (e.g. 8, 11, etc.), and Clojure version are you using?
openjdk 11.0.2 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
I am running macOS 10.14.6, AdoptOpenJDK 11 something, and Clojure 1.10.1, and am seeing a similar excpetion
This is still weird to me so far. Clojure is using its run-time reflection techniques for this call, which is slower, but usually succeeds in finding the correct method. In this case, it is only finding that the class has 1 non-static method with 1 parameter, but clearly there are more.
If I grab the source of that version of the jar I can see the methods in the abstract parent class.
And if I use the IntelliJ decompiler on the compiled code I can see them as well.
The method you want has the 'bridge' and 'synthetic' flags set in that class. The one with the float type parameter has neither of those 'bridge' nor 'synthetic' flags.
The Clojure reflector looks like it might use methods without the 'bridge' flag in preference to those that do.
It is also odd to me that the reflection warnings do not show up at all for the method call that is causing this exception.
That would suggest to me that the Clojure compiler should have found what it thinks is a matching method at compile time, and not try to look for one at run time.
But if the compile time looking for a method has this same behavior of preferring non-bridge methods over bridge methods, perhaps that is part of the cause, too.
• What abstract parent class? According to the Javadoc page you sent me a link to, the class PDAppearanceContentStream extends class Object directly (or I misunderstand that JavaDoc page, perhaps)
The Javadoc is incorrect. The class clearly has an abstract parent https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/PDAppearanceContentStream.java
I just sent a message to the #clojure-dev channel describing this situation generally.
I can try adding a link there to this discussion thead, in case someone sees it and is interested in looking further.
There may be a completely-in-Clojure way to handle this, but if so, I don't yet know what that is.
If you are willing to go the length of writing a little bit of Java code, you could write that method call in Java, and it will probably be able to find the right method.
Then call that Java method you write from Clojure via Java interop (as long as you don't write several methods with same name & # of parameters that leads to this same issue in your Java code, of course)
is it common to write in spec.test
checks into unit tests, or are they normally just run by hand from the REPL?
@risinglight I wouldn't say it was "common" to write such
check's into unit tests but I think people do it because they have no better guidance on how/when to run generative tests right now.
do you have recommendations on where to get guidance on generative tests? We’re looking into them for our team.
The practice we've adopted is to have a few generative tests in our "unit test" suite but with fairly low iterations so they don't take long (since unit tests are meant to be fast), and then to have additional generative tests in
comment forms that we run manually from time to time. Not a great solution, to be honest.
I have some "small"
check's in unit tests but mostly I put them in RCFs and run them manually from time to time when the code has changed significantly.
Rich Comment Forms. Using
comment to have blocks of dev/test code in your source files. Stu Halloway coined the name, because it's an approach that Rich Hickey uses quite a bit. I've been doing it for quite a while before I heard that from Stu, so it's kind of nice validation of the technique to know Rich (and others) do this too.
You could always use test metadata tagging to selectively run "unit" tests and "integration" tests separately (although I don't know how common that is either).
Thanks, I’ve definitely been struggling a bit with the lack of guidance part. Same with when/how exactly to utilize
@risinglight What I tend to do with
instrument is to add it to the top of my test files, to instrument functions in the source namespace corresponding to the test namespace. You can see that in action in the tests for
next.jdbc for example.
I'll also enable it manually sometimes during dev, especially when I'm exploring parts of our code base that I didn't write.
Hi! Who happens to have a link to a list of clojure(script) static website / blog generators? I have a octopress installation which is littly rusty now and I want to replace it with something I do understand.
@ordnungswidrig #cryogen seems to be a well supported Clojure static site generator. Some people have also used babashka + bootleg (e.g. https://github.com/lambdaisland/gaiwan_co#tech-stack) but that's a more do it yourself solution.