GCJ was great - I wrote a handset UI entirely in java for a startup in the early 2000's, basically android before android existed, using GCJ. I remember their native interface was somewhat more convenient to use than JNI.
I wish we had GCJ resurrected, now that the java libraries are GPL'd.
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make up for the fact that these features require many decisions to be made at run time. Implementors of static compilers for Java code have therefore resorted to incompatible constraints, such as closed-world assumptions, and to putting significant burdens on developers, such as having to identify in advance the classes eligible for reflection.”
Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.
It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT.
Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch.
Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.
EF Core and F# still don't fully work, neither do the GUI frameworks, with exception of the buggy WinUI, mostly because it is all COM/WinRT underneath.
EF Core heavily relies on reflection so that's not really a surprise. F# not working surprised me but apparently the main thing is its `printf` depends on reflection.
By "the GUI frameworks" I assume you mean Microsoft's GUI frameworks. They're all basically abandoned or just bad. Use Avalonia! It's better, cross-platform, and supports AOT!
Well, they had enough time to refactor EF Core to use code generators.
F# is improving on .NET 11, but still not fully there, as contrary to the rest of .NET, it is mostly community driven.
Most Microsoft shops only consider Microsoft GUI frameworks, regardless of the great work done by Avalonia, and Uno as well.
As for being bad, they surely are much better than most competitors from other ecosystems, unless we're adding Delphi, C++ Builder, Qt into the picture.
I had projects with Java on the server and Microsoft GUIs on the desktop, for example. Swing and JavaFX are also quite good, however require additional programming for what Forms and WPF do out of the box, unless one is willing to pay for something like JGoodies.
we are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited.
i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
> i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2].
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM.
There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes.
As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for.
If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.
That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.
I wasn't surveyed but I would be part of that group. I believe the government has been corrupt for as long as I've been alive, if not longer. I also believe that it is not actually worse now than in the past. And contrary to what many uncharitable people in this thread claim, I am equally unhappy no matter which party backs the crooks in power. I just want a government that serves me, and I haven't had that in my 41 years on this earth.
I like 2D, that one's nice. So in total it reads (ellipses for brevity):
"In any investigation or inquiry conducted for the purpose of ascertaining the correctness of any entry, for determining the liability of any person for duty, fees and taxes due or duties, fees and taxes which may be due the United States, for determining liability for fines and penalties, or for insuring compliance with the laws of the United States administered by the United States Customs Service, the Secretary (but no delegate of the Secretary below the rank of district director or special agent in charge) may ... summon, upon reasonable notice ... any other person he may deem proper".
And of course, one could argue that it's important to just double check and determine (note it doesn't say suspect, just determine) if someone has entered the country legally, ever, and paid all import taxes, ever. In order to do that, you'd need to see a lot of records. And of course the result can be "nope, they're all good". You don't need to have a good-faith suspicion of these things, just that you have a need to determine these things.
How many laws like this are on the books? In the same way that LLMs are fantastic at finding bugs, what other bugs are in the U.S. Code or similar that LLMs could find? We've been living in a world for a long time where things like this wouldn't be exploited, or maybe even noticed, but now it feels like these vulns are being hoarded and used like software exploits.
No that’s the whole point of this article. In this case, the private companies being summonsed are acting as both judges and data holders being summonsed. This doesn’t go to a judge to approve. So in this case, the point they’re making is most private companies just roll over at the sight of a summons, so the law absolutely executes deterministically (ok, not truly deterministic, but you’re relying on the judgement of private companies and their legal teams who don’t want that heat from the government, so, close enough).
“About a month after the judge’s ruling in late February, the government said it was withdrawing the request.
But officials hadn’t given up on getting the data.
Less than a month later, the DHS served Google with a different request for the YouTube information. This time, DHS utilized a different method that didn’t require approval from a judge, only a sign-off from a DHS official. It served Google an administrative summons citing an arcane provision of federal law – 19 USC 1509 – dealing with customs imports. The provision gives the DHS broad power to inspect records in order to determine whether duties and taxes are being correctly levied on imported items. It also instructed the recipients of the summons to keep it secret.”
There are startlingly few, if any situations where anything other than an actual court order, not any of this BS "administrative subpoena" can compel someone to silence - that whole "prior restraint" thing.
So that also requires all judges who a case could be brought to about this, declaring that they don’t have jurisdiction. It’s still a choice made by the judges.
reply