cel-spec VS graalvm-demos

My employer uses a combination of Protocol Buffers (for the config schema definition) and Bazel/Starlark (for concrete instantiations). Configs are validated at build time and runtime using CEL (https://github.com/google/cel-spec).

The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate. https://github.com/google/cel-spec

Looks like Google invented a specification for a simple "expression language." -> https://github.com/google/cel-spec/blob/master/doc/langdef.md. Writing the expressions feels like writing Java, C++, Go, or TypeScript code. Google then released C++ and Go versions of this langauge as a library.

https://github.com/google/cel-spec unfortunately, it's in Go or C++. Of course I can write a binding to them. But is there any other similar that you would know of for Java? My other course of action would be to offload computation to another service using this library in Go, or Jsonnet or Open Policy Agent/Rego based evaluation, which I'd prefer not to. Executing JS in Java via Nashorn also an option but it'd be heavy weight.

Having a standard way to share expressions does seem quite useful, especially when it's multilingual.

[0]: https://github.com/google/cel-spec

There's more information about CEL and its specifications here

Especially when dealing with more complex match rules, I personally much prefer Caddy's matchers over building some weird-ass if constructs in Nginx. It also supports CEL for request matching, giving you access to extremely powerful logic, if you need it.

https://www.graalvm.org/ can generate exe, there are many examples at https://github.com/graalvm/graalvm-demos

Spring Framework 6 and Spring Boot 3.0.0 have recently gone GA. My favorite feature of these new releases is hands down the AOT processing. The AOT processing, provided by GraalVM, creates statically linked binary images. These images are optimized, ahead of time, for the operating system and architecture. For many modern workloads they can provide smaller image sizes, smaller memory footprint, and a much faster startup time.

It's not "just" an interpreter; but ironically the beauty of our approach is that you write a simple interpreter in Java and with Graal/Truffle and you get a JIT compiler for free (via partial evaluation, e.g. first Futamura projection), that's the value, the fact that partial evaluation can be used in a practical way for Java code to the point of being able to implement a meta-circular JVM. With GraalVM native image tool there's no need for HotSpot to run Espresso. The goal is not to replace HotSpot, but to cover more use cases and make Java and the JVM even more accessible. See our native jshell + Espresso demo: https://github.com/graalvm/graalvm-demos/tree/master/espresso-jshell Note that the demo includes a true port of jshell to Java 8 without changing a single line of code in jshell.

The repo is available here: https://github.com/graalvm/graalvm-demos/tree/master/espresso-jshell