JVM bytecode javap Kotlin


There is a bunch of languages running on the JVM, from of course Java, to Clojure and JRuby. All of them have different syntaxes, but it’s awesome they all compile to the same bytecode. The JVM unites them all. Of course, it’s biased toward Java, but even in Java, there is some magic happening in the bytecode. The most well-known trick comes from the following code: public class Foo { static class Bar { private Bar() {} } public static void main(String... arg

JVM security JAR Spring Boot policy

Signing and verifying a standalone JAR

Last week, I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR. The nominal way This way doesn’t work. Readers more interested in the solution than the process should skip it. Create a keystore The initial step is to create a keystore if none is already available. There are plenty of online tutorials showing how to do that. keytool -genke

JVM security Spring Boot policy

Proposal for a Java policy files crafting process

I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed. In the former, all API are available with no restriction; in the later, some API calls deemed sensitive are forb

JVM language

Do we need other languages on the JVM?

It seems a trend has caught on and accelerated recently: every organization worth his salt in the Java ecosystem feels the need to create its own language that runs on the Java Virtual Machine. Side by side with legacy languages like Jython and JRuby, and along more promoted ones like Scala, Red Hat announced Ceylon and now it's JetBrain's turn with Kotlin. However, the real question is not whether we need them (the answer is a simple 'no' since we created software without them), but why there is