mikmoila

Code contains deviations from assumed behaviour, and some behaviours might manifest themselves as failures. Some failures might be exploitable by attackers.

Yes, imagine a breakthrough moneymaker product containing generative AI parts; It'll be under legal attacks from day zero...

OpenJDK project (interim) AI-policy faq (https://openjdk.org/legal/ai):

"What are the intellectual-property risks of using generative AI tools? The Oracle Contributor Agreement (OCA) requires that a contributor own the intellectual property rights in each contribution and be able to grant those rights to Oracle, without restriction. Most generative AI tools, however, are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses, so contributing such content would violate the OCA. Whether a user of a generative AI tool has IP rights in content generated by the tool is the subject of active litigation."

How about intellectual-property risks?

I don't I use Java for small scripts/tools.

Are they really? I've been under impression that agentic LLMs are just instances of the LLMs, no "specialized training" involved

This is great idea.

Very interesting tool; I've done something quite similar by implementing a CLI-mode interpreter to VS Code Rest-client (https://marketplace.visualstudio.com/items?itemName=humao.re...) files, with a support of executing a test-code (Javascript) against the result of http operations. The idea was to have a tool which could run .http files in batch mode, and also to execute the selected set of http operations concurrently.

There is nothing special in getters and setters, the runtime sees them as methods and may optimize them as it'd do for any other methods.

Good point, isn't this the partial compilation?

Wasn't it so that as Graal jitter is written in Java, Truffle can easily call it by using ordinary Java api?

By the way there's an excellent series of articles about implementing an interpreter with Truffle by Adam Ruka: https://www.endoflineblog.com/graal-truffle-tutorial-part-12...

Of course, this is not fully comparable to Akka, but you might find this interesting: https://github.com/ebarlas/game-of-life-csp

Also there are some traceability issues involved in using asynchronous APIs: "In the asynchronous style, each stage of a request might execute on a different thread, and every thread runs stages belonging to different requests in an interleaved fashion. This has deep implications for understanding program behavior: Stack traces provide no usable context, debuggers cannot step through request-handling logic, and profilers cannot associate an operation's cost with its caller. "

https://openjdk.org/jeps/444

Jetty can be used with virtual threads: https://webtide.com/jetty-12-virtual-threads-support/

SC will be a preview level API in Java 21: https://openjdk.org/jeps/453

In addition, this implementation detail might help in gaining some insight: "The synchronous networking Java APIs, when run in a virtual thread, switch the underlying native socket into non-blocking mode. When an I/O operation invoked from Java code does not complete immediately (the native socket returns EAGAIN - “not ready” / “would block”), the underlying native socket is registered with a JVM-wide event notification mechanism (a Poller), and the virtual thread is parked. When the underlying I/O operation is ready (an event arrives at the Poller), the virtual thread is unparked and the underlying socket operation is retried."

https://inside.java/2021/05/10/networking-io-with-virtual-th...

Nima uses virtual threads where blocking call blocks only the current virtual thread but not the underlying carrier-thread, which can run another virtual thread while waiting i/o to complete.

One at a time, not concurrently.

"callRemote" simulates a blocking outbound http-call.

Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.

Fascinating info, thanks for sharing this with all the details! Didn't watch your youtube video but do you use any formal systems like TLA+ internally for validating your designs?

Rest in peace Klaus! Thanks for giving us a hope!

>You scan the live set (which most often is not dependent on the heap size).

This was an eye-opener for me; That GCs performance do not depend on the size of garbage but on the size of the live objects, finalizers excluded.

https://dev.java/

There aren't that many libraries available with full XPath 3.x conformance. In order to give some constructive feedback, perhaps an optional .conf file with ns-prefix->ns-name mappings could be read and passed to the XPath engine as ns-context? Even w/o the XPath functions support and only XPath selector expression this would make the tool to cover most of the usecases eg. simply finding elements.

Ah ok; Namespace support before XPath 3.0 with Q{nsname}localname would make cli tool like this a bit too verbose. Of course you could store ns-prefix to ns mappings to conf file or environment variables...

Looks good! Does the xpath expression support XML namespaces?

Co-routines: Java has project Loom coming very soon, which (IMHO) shows the way how it should have been done.

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.

According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."