Autoboxing's evil twin, auto-unboxing should knock the score down a few points.

  Integer a = null;
  int b = 42;
  if (a == b) {} // throws NullPointerException

Or my favourite...

  Short w = 42;
  Short x = 42;
  out.println(w == x); // true
  Short y = 1042;
  Short z = 1042;
  out.println(y == z); // false

Once, after we had an application go live, we started getting reports after a few hours that new users were unable to log in.

It turns out, somewhere in the auth path, a dev had used `==` to verify a user's ID, which worked for Longs under (I believe) 128, so any users with an ID bigger than that were unable to log in due to the comparison failing.

I’ll bite. Why does this not work as you’d expect?

I'm comparing object references (pointers) not the value boxed by the object (what the pointer points to).

For performance reasons boxed Short objects are interned when they represent values in the range -127 to +128 so for 42 the pointers will point to the same interned object after 42 is autoboxed to a Short. Whereas 1042 is outside this interning range and the autoboxing creates two distinct objects with different pointers.

It's very simple but (a) non-obvious if you don't know about it and (b) rather wordy when I spell it out like this :)

In general in Java you want obj.equals(other) when dealing with objects and == only with primitives, but autoboxing/unboxing can cause confusion about which one is dealing with.

In other other words, the surprise ought to be that w == x is true, not that y == z is false!

That's another gotcha-- interning of strings and boxed primitives.

Are there linters for this sort of thing? I don't write Java much any more.

> Are there linters for this sort of thing?

Yes and they're pretty good so it's rarely an issue in practice. Using == on object references will indeed usually get you yelled at by the linter.

I’ll say from experience that even if your IDE highlights that by default people won’t pay any attention to it and the bug will get in.

I’ll be happy when it’s fixed.

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

Do Java problems go away? I thought the selling point was that your huge un-rewritable enterprise software will crash tomorrow like it crashed yesterday.

Here's a talk from Netflix (hopefully sufficient enterprise for the discussion) that goes over how a JDK version upgrade to generational ZGC improved a bunch of their request timeouts: https://youtu.be/XpunFFS-n8I?si=XG6zYYZy50sfNE4j

This is nuts lol

I'm not much of a PL nerd, what should it do?

Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.

Fail to compile when you assign something which isn't an integer to an integer.

None of that code does that; the "issue" is with `==` between an int and an Integer. I'd accept a failure to compile _that_, but that does kind of kill the utility of the 99.9% of times where auto-boxing and unboxing is syntactically simpler.

Seems reasonable to me

It's useful and very common to use. For example, you could concatenate together command-line argument flags that may or may not be present.

A separate VLAN, if your router is capable

The PDF metadata says it's PyPDF2

i used PyPDF2 to implement some tools, but not all of them.

You would also need to learn about Maven profiles and activation. And for other build tools, you'll be delighted to know they have partial support.

This wouldn't work on Windows, because you can't delete a DLL while it's in use

You might be able to use FILE_FLAG_DELETE_ON_CLOSE, but this would likely require calling the Windows API functions directly.

Couldn't you: Extract DLL Load DLL Unload DLL Delete DLL ?

Though in the example given, I do see your point now. You'd have to make sure the DLL was unloaded before the delete-on-exit happened.

According to JNA it's not safe to unload the DLL:

https://github.com/java-native-access/jna/blob/40f0a1249b5ad...

  Do NOT force the class loader to unload the native library, since
  that introduces issues with cleaning up any extant JNA bits
  (e.g. Memory) which may still need use of the library before shutdown.

Following the blame back to 2011, they did unload DLLs before https://github.com/java-native-access/jna/commit/71de662675b...

  Remove any automatically unpacked native library.  Forcing the class
  loader to unload it first is only required on Windows, since the
  temporary native library is still "in use" and can't be deleted until
  the native library is removed from its class loader.  Any deferred
  execution we might install at this point would prevent the Native
  class and its class loader from being GC'd, so we instead force 
  the native library unload just a little bit prematurely.

Users reported occasional access violation errors during shutdown.

You can install a shutdown hook to do cleanup like this.

    Runtime.getRuntime().addShutdownHook(...)

That's how java.io.File#deleteOnExit works under the hood. The DLL is still loaded at that point and can't be deleted.

Ah, looking through the docs [1]; you have to use your own ClassLoader (so it can be garbage-collected), and statically-link with a JNI library which is unloaded when the ClassLoader is garbage-collected.

1: https://docs.oracle.com/en/java/javase/22/docs/specs/jni/inv...

Hmm, interesting. They do have DLLs in the JAR...

Native libraries are typically packaged inside a jar so that everything works over the existing build and dependency management systems.

For example, each these jars named "native-$os-$arch.jar" contain a .dll/.so/.dylib: https://repo1.maven.org/maven2/com/aayushatharva/brotli4j/

JNA will extract the appropriate native library (using os.name and os.arch system properties), save the library to a temp file, then load it.

    > JNA will extract the appropriate native library ..., save the library to a temp file, then load it.

JNA does this?

FYI: JNA = Java Native Access project: https://github.com/java-native-access/jna

It does! Code is here https://github.com/java-native-access/jna/blob/40f0a1249b5ad...

Examples of JARs, that transport such libraries: snappy, sqlite...

> I can't think of another statically typed language that screws this up so badly. It just keeps getting worse with stuff like Optional and @NotNull.

Java might be the only language where a simple assignment `x = y` can throw a NullPointerException (due to auto-unboxing)

Or more succinctly

  val num = words.count(_.nonEmpty)

This cheatsheet would have you publish dist/*.{js,d.ts}. Presumably you would use "files":["dist"] in package.json to exclude sources from being published.

The OP recommends to additionally package src/*.ts along with sourceMaps and declarationMaps.

What's actually the best practice here?

I poke around in node_modules with some regularity (often in combination with the debugger) and it’s always nice to find actual source files, not just source maps.