jdk

build. Additionally you don't have to build Java libraries to use them anyway, because binary distribution works so everyone just distributes binary JAR files. 4. The source code is spread around several modules because JCA is pluggable. But for example a lot of the crypto code is found here: https://github.com/openjdk/jdk/tree/master/src/java.base/sha... 5. Oracle maintains it but other companies contribute, like Amazon, Microsoft, Red Hat etc (well, to Java as a whole). It's released under the GPL with Classpath exception license. They aren't going to come after you for using it - there are 12 million Java developers in the world. The only company that has ever got sued is Google and that's because they violated the (at the time non open source) license of Java to make a mobile version that wasn't from Sun. They knew they were doing it and chose to chance it anyway (which worked out quite well for them actually). Since then Java became fully open source and this no longer applies, and it'd have never applied to normal users of it anyway. I'm not trying to convince you here of anything, only to point out that everyone saying "there was no alternative" is just wrong. The failure mode here is not sufficiently advanced fuzzers. The failure is that there has been an alternative to NSS for years but C++ shops like Mozilla keep maintaining crappy decades old C libraries with memcpy calls all over the place, because they know and like C. That's it. That's all it boils down to.

building, and may or may not contribute these upstream. Eclipse Adoptium (formerly known as AdoptOpenJDK) [1] does not apply significant proprietary patches (just branding stuff), so it's a good place to get a plain vanilla OpenJDK build. Amazon's Corretto [4] in principle could contain whatever patches Amazon thinks are cool, but in practice usually just has a few backported bugfixes [5]. Azul's Core (formerly known as Zulu) has a bunch of patches (i couldn't find a list), and an option of commercial support) [6]. Oracle have a couple of builds, but you can ignore them. There are also builds from SAP, Bellsoft, and maybe others, but i have never really looked into them. Most people i know just use the AdoptOpenJDK / Adoptium builds, or whatever their distro gives them. EDIT: I got the Adoptium thing slightly wrong. AdoptOpenJDK made builds; those builds are now called Eclipse Temurin. Eclipse Adoptium is some sort of 'marketplace' where different builds are validated and made available. To me, this sounds like one of those Apache grand ideas that won't go anywhere, but we'll see. [1] https://github.com/openjdk/jdk/blob/master/LICENSE [2] https://opensource.stackexchange.com/questions/1410/what-is-... [3] https://adoptium.net/releases.html [4] https://aws.amazon.com/corretto/ [5] https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p... [6] https://www.azul.com/products/core/

an't be true... [1] https://github.com/openjdk/jdk/blob/master/src/java.base/sha...

lid when parsed with the 2,2,4 widths, and also valid when parsed with 1,1,2, but parses as different code in each case. This means that it is possible to craft a classfile that executes one piece of code when run on the actual JVM and displays a completely different set of fake code when viewed with reverse engineering tools" TL;DR JVM contained an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. The stack, locals, and code length typically has 2,2,4 bytes rspectively; in pre-45.3 classfiles, the JVM expects them to be 1,1,2 bytes instead. [1] https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-a... [2] https://github.com/openjdk/jdk/commit/eedc99c9ab2647f0233e48...