hashmash

I used BeanShell for a few projects years ago, but with JShell and the ability run a Java program directly from a source file, I have no reason to use BeanShell again. What does BeanShell3 offer over what's currently available?

Low pause collectors like ZGC and Shenandoah must be enabled explicitly. G1 is still the default.

It should also be noted that the low pause Azul C4 collector was available in 2010, but it was a commercial product.

Just say "tracing garbage collection" to avoid the usual referencing counting arguments.

Because none of the existing software would work. The idea of running a Rosetta-like feature on an 8-bit CPU isn't feasible. The Apple II eventually received an upgraded processor, the 65816, which was compatible with the 6502.

It wouldn't have happened because the 6809 wasn't binary compatible with the 6800.

Yes, I'm familiar with these. Many of the earliest problems were to due bugs in the verifier, and there were several different vendors with their own set of bugs. The bulk of these problems were identified and resolved over 25 years ago.

Most of the later problems are due to the fact that the API attack surface was too large, because of the backwards SecurityManager design. And because it existed, it seems there was little incentive to do something better.

Once the instrumentation API was introduced (Java 5), it made it easier to write agents which could limit access to APIs using an "allow" approach rather than the awful rules imposed by the SecurityManager. Java 9 introduced modules, further hardening the boundaries between trusted and untrusted code. It was at this point the SecurityManager should have been officially deprecated, instead of waiting four more years.

Going back to the earlier comment, the problem isn't due to the runtime being somehow inherently insecure, but instead due to the defective design of the SecurityManager. It hasn't been necessary for providing security for many years.

The Java runtime isn't any more inherently insecure than the JavaScript runtime, and JavaScript seems to work just fine for the web.

The key reason why applet security failed was because it gave you the entire JDK by default, and so every method in the JDK needed to have explicit security checking code in place to restrict access. The model was backwards -- full control by default with selective disabling meant that every new feature in the JDK is a new vulnerability.

The post is pretty much bullshit. Variable names have no impact on performance.

This adds an extra level of friction that doesn't happen when the set of primitive types is small and simple. When everyone agrees what an int is, it can be freely passed around without having to perform special conversions and deal with errors.

When trying to adapt a long to an int, the usual pattern is to overload the necessary methods to work with longs. Following the same pattern for uint/int conversions, the safe option is to work with longs, since it eliminates the possibility of having any conversion errors.

Now if we're taking about signed and unsigned 64-bit values, there's no 128-bit value to upgrade to. Personally, I've never had this issue considering that 63 bits of integer precision is massive. Unsigned longs don't seem that critical.

Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa?

Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when doing less-common, low-level operations.

The first official JIT became available in JDK 1.1, in 1997. The Symantec JIT was available as an add-on sometime in mid 1996, just a few months after JDK 1.0 was released. Even better performance was possible with GCJ, available in 1998.

The release of HotSpot was in 1999, and became default with JDK 1.3 in 2000. It took JIT compilation to the next level, making tools like GCJ mostly obsolete.

If JEP 401 is ever delivered (Value Classes and Objects), then this sort of problem should go away.

At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.

Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.

So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.

What's the elevator pitch? If I'm already happy with the OO language I'm using today, why should I use Nod? What does it do better?