This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (9)
- # alda (2)
- # babashka (89)
- # beginners (86)
- # bristol-clojurians (1)
- # calva (54)
- # chestnut (2)
- # cider (18)
- # clj-kondo (19)
- # clojure (160)
- # clojure-brasil (2)
- # clojure-europe (6)
- # clojure-italy (8)
- # clojure-nl (46)
- # clojure-spec (52)
- # clojure-uk (45)
- # clojured (4)
- # clojuredesign-podcast (11)
- # clojurescript (15)
- # core-async (50)
- # datomic (41)
- # devops (3)
- # emacs (10)
- # fulcro (95)
- # graalvm (11)
- # graphql (3)
- # kaocha (1)
- # luminus (1)
- # malli (4)
- # off-topic (13)
- # overtone (3)
- # pathom (8)
- # re-frame (13)
- # reitit (10)
- # shadow-cljs (83)
- # spacemacs (2)
- # specter (9)
- # tools-deps (3)
- # vim (2)
user=> (import '[java.time LocalDate]) nil user=> (def d1 (LocalDate/parse "2019-11-11")) #'user/d1 user=> (def d2 (LocalDate/parse "2019-11-12")) #'user/d2 user=> (.isBefore d2 d1) false
java-timebranch). What classes are important to add beyond the ones listed here in the class/enum/exception summary? https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html
Hmm, adding these classes to the reflection.config adds about 7 MB (binary goes up from 30 MB to 37MB), is it worth it?
$ ./bb '(Math/pow 2 3)' 8.0
Babashka, a native Clojure scripting tool, v0.0.43:
@nate I guess this covers java.time well enough. People can now build their own babashka time libraries on top of the raw Java classes
ghadi was saying something in one of his talks about how some of the clojure wrappers for java.time had some "issues" (sorry, paraphrasing), so may be this approach is a good one to start with.
btw, bb recently seems to require java 8 to compile. i was getting away with java 11 up to not-too-long ago 🙂
I think it's because of the unix-named classes which got renamed to jdk.internal.something.something
- Change the unix-named classes in babashka.impl.classes.clj to their JDK 11 equivalents
for reference, the error is:
so that supports what you are saying i guess.
Compiling babashka.impl.classes Syntax error compiling at (babashka/impl/classes.clj:112:16). Syntax error (ClassNotFoundException) compiling at (babashka/impl/classes.clj:112:16). java.lang.UNIXProcess$ProcessPipeOutputStream Full report at: /tmp/clojure-929038568194110145.edn Compilation failed: Subprocess failed
all tests (tried both script/test and lein test -- former includes latter i presume) pass
is it the case that the unix-related classes were actually renamed -- not just subsumed into something else?
can you test if this works with your version of bb? https://github.com/borkdude/babashka/blob/master/examples/process_builder.clj
$ ./bb examples/process_builder.clj No matching method getOutputStream found taking 0 args for class java.lang.UNIXProcess [at line 11, column 20]
if i add
java.lang.UnixProcess back in to classes.clj and run the lein command, i get:
$ lein do clean, with-profiles +reflection run Syntax error (ClassNotFoundException) compiling at (babashka/impl/classes.clj:110:16). java.lang.UnixProcess Full report at: /tmp/clojure-15381430602635576939.edn Error encountered performing task 'run' with profile(s): 'base,system,user,provided,dev,reflection' Suppressed exit
i type-hinted proc in the example script with java.lang.Process and that seems to work
are you sure you used jdk11 in both lein (script/compile the jar step) + graal (script/compile the native-image step)?
--report-unsupoorted-elements-at-runtime to get the compilation to complete.
now the error i get at runtime for the process builder script is:
$ ./bb examples/process_builder.clj Invoke with MethodHandle argument could not be reduced to at most a single call: java.lang.invoke.Invokers$Holder.invoke_MT(Object, Object, Object, Object)
--verbose is already in the compile script
on a side note, there are some options with = that don't have double quotes around them -- should i submit a pr for that?
(i don't know if you remember, but we are warned by native-image [whether we have quote them or not] that they might be problematic)
yeah, that's an issue that has to be fixed first if we're moving to jdk 11, it's already documented in the issue
graal doesn't play well with the dynamic usage of resolving a JDK 11 method in that class
I was thinking of releasing a small lib which copies the code from Reflector.java and removes the JDK8 reference and make the code for JDK 11 more static
we can also just incorporate it directly in babashka I guess and compile it with lein (I think it's a good choice for graal projects, it can do all the stuff you need)
perhaps something relevant can be put in babashka initially and if it proves useful factored out later?