Clojurians Log v2

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.

e.g. (.myMethod instance1 ^long x y z w)

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.

@andy.fingerhut 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-

Like this

(.setNonStrokingColor my-instance ^PDColor colour)

But that method is overloaded with a Color type arg as well.

Have you added (set! **warn-on-reflection** true) near the beginning of the source file where you make that call? e.g. after the ns form.

No!

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?

And just to confirm, type hinting isn’t guaranteed to work?

I get a class cast exception.

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)))

I have. I’ll double check that.

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.

I might have to use a different signature.

Do you know which one is 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')

Or none of them are, because the first time you try you get an exception?

I don’t think any are being called.

Do you have a stack trace with that exception?

No

Can I generate one? Nothing coming out in the REPL

let me try catch it

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

*e is the value of the last exception in a REPL session

You can show it by evaluating that form

https://gist.github.com/stuartrexking/dcf218427c2339157024695a03d81fac

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 39 should be a line number in the file appearance_content_stream.clj

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.

I’m using deps.edn

I don’t get a warning when I have the type on the instance (not the param)

Would you like me to share the repo with you?

If it is public, or you otherwise don't mind.

https://github.com/stuartrexking/pdfboxing

If you want to trigger it run the code in the comment block at the end of the core ns.

I’m mid refactor so the output is likely to be broken or not output at all.

I’m trying to isolate all the icky java interop.

If you have any tips on how to improve the code please let me know.

Thanks for your help.

It may not matter, but what OS, JDK version (e.g. 8, 11, etc.), and Clojure version are you using?

Java

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)

Clojure Version: 1.10.1.727

MacOS 11.01

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.

Or at least the documentation says 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.

I don't know why it does that

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)

I might be confusing myself. Let me through it again…

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

Something not right with this lib.

Or that version of it’s javadoc.

I think that Javadoc isn’t correct.

Agreed.

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.

Ok thanks.

I appreciate your help

Sure, no problem. Not there yet, obviously, but some clues.

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.

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.

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 instrument .

> RCFs What does this stand for

do you have recommendations on where to get guidance on generative tests? We’re looking into them for our team.

I really wish I did, for our team too.

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.

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.

@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.

Ah, got it, thanks!

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.

@ordnungswidrig https://www.clojure-toolbox.com/ also has a section on this