The inevitable and unfortunate result of "handing out 'free' stuff" however will always be widespread fraud.

It works fine for simple models, but breaks down for production-sized tree ensembles. The JVM has a hard 64KB method size limit, and javac controls how your deeply nested if/else trees get laid out. m2cgen's own FAQ says to reduce estimators when you hit recursion limits during generation. With direct bytecode emission I control the method structure precisely, I can split across methods exactly where needed and manage the constant pool directly. I also wrote much more efficient bytecode than m2cgen creates as equivalent source.

The source code is also a pretty useless step, sets off all kinds of static analysis alarms in your stack, and also I worry about source code injection (not that can't happen with petrify, it's just a lot harder).

Finally, I'm grateful for the sweat the authors of m2cgen have put in, but the project has gone without updates for 4 years. That doesn't mean it's useless (some mature software never sees updates), but it's not a positive sign either.

Petrify will also be order of magnitude kinder to your Garbage Collector, which will increase performance in high-throughput situations. You're also not loading 10 gazillion classes, as your models are directly represented as a first-class Java Class.

The real goal here was the getting rid of dependencies! While thankful for the incredible (and free) work of the authors of the onnxruntime for Java, the primary onnxruntime jar a boat anchor; weighing is 90mb+ just by itself, not counting any of its dependencies.

Once you compile your models with Petrify, you have exactly one 6.9kb jar as a dependency essentially just carries the Fossil interface as an entry point to call your model. I licensed that jar ASL2.0 for maximum compatibility in a corporate environment.

Petrify is a machine learning model compiler for the the JVM. It reads your model from an ONNX or other model format, walks the Trees or Linear models, and encodes the model in equivalent JVM bytecode as a stateless class you can invoke.

This differs from every other ONNX Runtime that I know of, which are essentially interpreters. The ONNX Runtimes are also huge (90+mb!?!), JNI, and drag gargantuan dependencies!

This just compiles your models to native bytecode. Much simpler and you end up with 0 dependencies! (you need one interface technically, but I digress).

still in the works, but its here for those interested: Petrify: https://github.com/exabrial/petrify

If by doing this, can employers legally discriminate against you?

The cable/fiber providers played all areas of government like a fiddle.

perhaps it is cold there and they are out of firewood.

The lack of support is frustrating. The bug where any element in xml files gets mangled to still exists, and we've tried multiple channels to get ahold of their support for such a simple, but impactful issue.