Nicolas Frankel
Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with narrower interests like Software Quality, Build Processes and Rich Internet Applications. Currently working for Exoscale. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.
From annotations to declarative, the path to more explicit Spring configuration
In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder.
Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations.
It’s called functional, because it moves configuration from objects to behavior. This talk aims to demo a step-by-step process to achieve that.
In the end, the demo application will run without any annotations at all using only declarative configuration, thanks to a new initiative called Spring Fu.
Securing the JVM – Neither for fun nor for profit, but do you have a choice?
The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do.
Consider a Java application in a private banking system.
A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided.
Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run…
By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous.
In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.