Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to and GraalVM slack:
lvh 2020-06-16T15:14:05.441900Z

unfortunately HttpURLConnection does not allow PATCH method, which the GitHub API requires 😞

lvh 2020-06-19T20:45:09.447800Z

Oh, crud I missed this message, thank you though

lvh 2020-06-19T20:45:18.448300Z

which I regret to inform you actually works

borkdude 2020-06-16T15:14:41.442300Z

this is one of the reasons I built babashka.curl... Curl is amazingly useful in some niche cases. E.g. also when talking http over a unix socket

lvh 2020-06-19T20:45:35.448500Z

(I regret to inform you there is no justice in the universe and the above worked just fine)

borkdude 2020-06-19T20:49:52.448700Z

so you patched Java's class and this works in the final GraalVM binary?

lvh 2020-06-19T21:05:12.448900Z


lvh 2020-06-19T21:05:42.449100Z

you have to do it at the right time though, if you change the order of operations even the patching itself fails in pure java

lvh 2020-06-19T21:05:51.449300Z

so I'm not going to pretend this is a good, well-supported idea

lvh 2020-06-19T21:07:02.449500Z

i definitely don't understand why the people who wrote that class decided to make HTTP methods static final though

lvh 2020-06-19T21:07:14.449700Z

(there's even a WONTFIX ticket about it)

borkdude 2020-06-19T21:20:14.449900Z

what about vendoring the HttpURLConnection class and fix this one thing? is it a big class?

lvh 2020-06-19T21:41:45.450100Z

I imagine that would work fine yep

naomarik 2020-06-16T15:48:22.443200Z

@lvh clj-http says it supports patch, but might want to pay attention to the size increase of your binary

lvh 2020-06-16T16:04:43.443300Z

did you attempt to fix this with a gross reflection hack?

borkdude 2020-06-16T16:06:07.443500Z

fix what?

lvh 2020-06-16T16:17:36.443700Z

well, the issue is arguably that httpurlconnection has a hardcoded array of methods, if you use reflection to make that array a little less hardcoded...

borkdude 2020-06-16T17:09:19.443900Z

I haven't attempted this

lvh 2020-06-16T17:22:34.444100Z

I'll let you know how this works out:

(def ^:private modifiers-field
  (doto (.getDeclaredField Field "modifiers")
    (.setAccessible true)))

(defn allow-patch!
  (.setAccessible modifiers-field true)
  (let [methods-field (doto (.getDeclaredField "methods")
                        (.setAccessible true))
        not-final (bit-and-not (.getModifiers methods-field) Modifier/FINAL)]
    (.setInt modifiers-field methods-field not-final)
    (assert (not (-> methods-field .getModifiers Modifier/isFinal)))

    ;; Note, the order of operations here matters a lot! If you .get access
    ;; methods-field while it's still static final, the access result will be
    ;; cached, and this will fail even though ostensibly you disabled final.
    (let [new-methods (-> (.get methods-field nil) seq (conj "PATCH"))]
      (.set methods-field nil (into-array String new-methods)))))

lvh 2020-06-16T17:22:43.444300Z

if there is any justice in the universe, "not well", presumably

borkdude 2020-06-16T20:48:24.446200Z

did a quick, small and probably naive POC with incorporating spec1 into babashka. it does work:

$ ./bb "(require '[clojure.spec.alpha :as s]) (s/def ::a int?) (s/explain-data ::a :foo)"
{:clojure.spec.alpha/problems [{:path [], :pred clojure.core/int?, :val :foo, :via [:user/a], :in []}], :clojure.spec.alpha/spec :user/a, :clojure.spec.alpha/value :foo}
but the binary grows with 35 megabytes (from 60 to 95) and the RAM usage grows also considerably. Might be worth digging into this some more, maybe the spec source can be vendored and curated a little bit, etc.


If I remember correctly the github api supports the ?method=PATCH or {"method": "PATCH" ..other json stuff} when using POST