by Bozho | Jun 9, 2019 | Aggregated, Opinions
The other day I was wondering – which is the most important Java API. Which of the SE and EE APIs is the one that makes most of the Java ecosystem possible and that could not have just been recreated as a 3rd party library. And as you’ve probably guessed by the title – I think it’s the Reflection API. Yes, it’s inevitably part of every project, directly or indirectly. But that’s true for many more APIs, notably the Collection API. But what’s important about the Reflection API is that it enabled most of the popular tools and frameworks today – Spring, Hibernate, a ton of web frameworks. Most of the other APIs can be implemented outside of the JDK. The Collections API could very well be commons-collect or guava. It’s better that it’s part of the JDK, but we could’ve managed without it (it appeared in Java 1.2). But the reflection API couldn’t. It had to almost be an integral part of the language. Without reflection, you could not have any of the fancy tools that we use today. Not ORM, not dependency injection frameworks, and not most of the web frameworks. Well, technically, you could at some point have theme – using SPI, or using java-config only. One may argue that if it wasn’t for reflection, we’d have skipped the whole XML configuration era, and wend directly to code-based configuration. But it’s not just configuration that relies on reflection in all these frameworks. Even if Spring could have its beans instantiated during configuration and initialized by casting them to InitalizingBean, how would you handle the autowired injection...
by Bozho | May 19, 2019 | Aggregated, Developer tips, jks, keytool
Sometimes you don’t have a PKI in place but you still need a key and a corresponding certificate to sign stuff (outside of the TLS context). And after the certificate in initially generated jks file expires, you have few options – either generate an entirely new keypair, or somehow “extend” the existing certificate. This is useful mostly for testing and internal systems, but still worth mentioning. Extending certificates is generally not possible – once they expire, they’re done. However, you can have a new certificate with the same private key and a longer period. This sounds like something that should be easy to do, but it turns it it isn’t that easy with keytool. Even with my favourite tool, keystore explorer, it’s not immediately possible. In order to reuse the private key to have a new, longer certificate, you need to do the following: Export the private key (with keytool & openssl or through the keystore-explorer UI, which is much simpler) Make a certificate signing request (with keytool or through the keystore-explorer UI) Sign the request with the private key (i.e. self-signed) Import the certificate in the store to replace the old (expired) one The last two steps seem to be not straightforward with keytool or keystore exporer. If you try to sign the request with your existing keystore keypair, the current certificate is used as the root of the chain (and you don’t want that). And you can’t remove the certificate and generate a new one. So you need to use OpenSSL: x509 -req -days 3650 -in req.csr -signkey private.key -sha256 -extfile extfile.cnf -out result.crt The extfile.cnf is...
by Bozho | May 4, 2019 | Aggregated, caching, Developer tips, spring, spring-boot
Caching is key for performance of nearly every application. Distributed caching is sometimes needed, but not always. In many cases a local cache would work just fine and there’s no need for the overhead and complexity of the distributed cache. So, in many applications, including plain Spring and Spring Boot, you can use @Cacheable on any method and its result will be cached so that the next time the method is invoked, the cached result is returned. Spring has some default cache manager implementations, but external libraries are always better and more flexible than simple implementations. Caffeine, for example is a high-performance Java cache library. And Spring Boot comes with a CaffeineCacheManager. So, ideally, that’s all you need – you just create a cache manager bean and you have caching for your @Cacheable annotated-methods. However, the provided cache manager allows you to configure just one cache specification. Cache specifications include the expiry time, initial capacity, max size, etc. So all of your caches under this cache manager will be created with a single cache spec. The cache manager supports a list of predefined caches as well as dynamically created caches, but on both cases a single cache spec is used. And that’s rarely useful for production. Built-in cache managers are something you have to be careful with, as a general rule. There are a few blogposts that tell you how to define custom caches with custom specs. However, these options do not support the dynamic, default cache spec usecase that the built-in manager supports. Ideally, you should be able to use any name in @Cacheable and automatically a cache...
by Bozho | Apr 26, 2019 | Aggregated, blockchain, Opinions, security
Blockchain is a relatively niche technology at the moment, and even thought there’s a lot of hype, its applicability is limited. I’ve been skeptical about its ability to solve all the world’s problems, as many claim, and would rather focus it on solving particular business issues related to trust. But I’ve been thinking about the positive side-effects and it might actually be one of the best things that have happened to software recently. I don’t like big claims and this sound like one, but bear with me. Maybe it won’t find its place in much of the business software out there. Maybe in many cases you don’t need a distributed solution because the business case does not lend itself to one. And certainly you won’t be trading virtual coins in unregulated exchanges. But because of the hype, now everyone knows the basic concepts and building blocks of blockchain. And they are cryptographic – they are hashes, digital signatures, timestamps, merkle trees, hash chains. Every technical and non-technical person in IT has by now at least read a little bit about blockchain to understand what it is. So as a side effect, most developers and managers are now trust-conscious, and by extension – security conscious. I know it may sound far-fetched, but before blockchain how many developers and managers knew what a digital signature is? Hashes were somewhat more prevalent mostly because of their (incorrect) use to store passwords, but the PKI was mostly arcane knowledge. And yes, we all know how TLS certificates work (although, do we?) and that a private key has to be created and used with...
by Bozho | Apr 9, 2019 | Aggregated, as400, Developer tips, ibm i
In the category of “niche blogposts”, this is probably the “nichest”. But it might be useful, so I’ll share it. Recently I had to interface an IBM i system (think “mainframe”, though not exactly) from a command-line-only Linux environment. The interesting part is that you can access the IBM i files through SQL syntax, as they are tabular in nature. However, I failed to find a proper tool for that. There are UI tools by IBM but they don’t work in a headless environment. So I decided to write my own simple tool – a command line SQL client for IBM i 7.x. It relies on an IBM-provided library (which, by the way, fails in some cases in headless environments as well, as it tries to prompt for certain data using awt/swing). The tool can be used after building it with maven and by simply executing SQL queries after connecting: java -jar as400-sql-client.jar <connectionString> <username> <password> It can be can be fond here. Apart from being useful in navigating the IBM system, it relies in the jline project which allows you to create rich command line tools that support autocomplete, history, coloring, etc. I hope that nobody will need this tool, but in the rare case that someone does need it, I hope to save them hours of struggle. The post Command-line SQL Client for IBM i 7.x (AS/400) appeared first on Bozho's tech...
Recent Comments