Ah, that's a great question, and the answer is in the JEP (https://openjdk.org/jeps/500#Mutating-final-fields-from-nati...).

When running with -Xcheck:jni, you'll get a warning when trying to mutate a final field with JNI.

Now, enabling this check by default without harming JNI performance proved to be too much of an effort. However, mutating final fields with JNI even today can already lead to undefined behaviour, including horrible miscompilation, where different Java methods can read different values of the field, for final fields that the JVM already trusts to be immutable, such as static finals, record components, or a few other cases (indeed, there are non-final fields that the JVM trusts to be assigned only once, and mutating those with JNI is also undefined behaviour). As the compiler starts trusting more final fields after this change, mutating almost all final fields will lead to undefined behaviour. Then again, using JNI can lead to undefined behaviour in many ways.

So to make sure your JNI code isn't mutating finals, test with -Xcheck:jni (as of JDK 26).

Between you and me, are a bunch of other hops. Blindly trusting dependencies is one part of why npm is burning down at the moment.

Why trust un-signatured files hosted on a single source of truth? It isn't the 90s anymore.

> I’m always a bit shocked how seriously people take concerns over the install script for a binary executable they’re already intending to trust.

The issue is provenance. Where is the script getting the binary from? Who built that binary? How do we know that binary wasn't tampered with? I'll lay odds the install script isn't doing any kind of GPG/PGP signature check. It's probably not even doing a checksum check.

I'm prepared to trust an executable built by certain organisations and persons, provided I can trace a chain of trust from what I get back to them.

I think there's a fundamental psychological reason for this - people want to feel like some ritual has been performed that makes at least some level of superficial sense, after which they don't have to worry.

You see this in all the obvious examples of physical security.

In the case of software it's the installation that's the ritual I guess. Complete trust must be conferred in the software itself by definition, so people just feel better knowing for near certain that the software installed is indeed 'the software itself'.

I'm so thankful for nixos for making it hard for me to give in to that temptation. you always think "oh just this once". but with nixos I either have to do it right or not bother.

agreed. i get if you're great at cli usage or have your own scripts, but if you're publishing for general use, it should be long form. that includes even utility scripts for a small team.

also, putting it out long-form you might catch some things you do out of habit, rather than what's necessary for the job.

For a small flight of fancy, imagine if each program had a --for-docs argument, which causes it to simply spit out the canonical long-form version equivalent to whatever else it has been called with.

Absolutely agree.

The shorthands are for when typing it at a console and the long form versions should be used in scripts.

BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong

Not a java developer but why the void? Shouldn't your main function and program return an integer?

Thanks, I made a note to update that someday.

You just have to read his blog, it is short and he answered everything.

> he used python and xelatex

> https://github.com/ttmc/hello-world-ways

Smalltalk, but in C

This, lisp is perfect for representing arbitrary data, nesting is just another sexpr, easy to produce, easy to parse and easy to debug / reason about

I can appreciate this answer, but I don't think it's really what I'm asking.

I think I'm more looking for some kind of standardized struct definition that translates easily to llvm IR and is flexible enough for a wide variety of languages to target.

Something like this: https://gist.github.com/thomaswp/8c8ef19bd5203ce8b6cd4d6df5e... (Which doesn't meet my criteria because AFAICT isn't used by anything, but is reasonably close to what I want) or this: https://docs.rs/sap-ast/latest/src/ast/lib.rs.html#1-83 (which seems specific to SAP, I would like something more general)

Thank you! this looks pretty helpful

Ok. Let me ask differently. Why would I download and use LLVM for working with java code? Which usecases favor this?