When you use JUnit 5 for writing unit tests for your Kotlin code, there are a few things to be aware of to make this work smoothly. One of those things affect parameterized tests with
@MethodSource. In this blog post, I’m going to show you an error you might encounter in such a setup and how to work around it. The current Kotlin version used is 1.3 and for JUnit it is 5.3.1.
The next major release for the promising JVM language Kotlin by JetBrains has now been published (read the release notes here). The most prominent features of this version are the finalization of coroutines and a beta release for Kotlin/Native. Version 1.3 is an important step forward for Kotlin. With coroutines, the release brings a stable mechanism to the language for writing concurrent applications in a concise and easy to maintain way. Kotlin/Native allows the compilation of Kotlin code into native code for a decent number of target platform. You can, for instance, compile Kotlin code into native executables or libraries for iOS, Windows, MacOS, the web (WebAssembly), and more. Together with Kotlin’s aim to facilitate multiplatform projects, it will be possible to share code between these platforms so that only a single Kotlin code base needs to be maintained.
JUnit 5 allows you to parameterize your tests so that the same test case is executed repeatedly with a varying set of test parameters. This is similar to the parameterized test feature of JUnit 4, except now these tests are much easier and much less cumbersome to write and maintain than in the old version of JUnit.
If you need to provide
null as a test argument value, however, there is a caveat which is described in this post.
Nehmen wir folgendes Szenario an: auf einem Linux Server läuft ein Docker-Container mit einer Java-Anwendung. Es kommt zu Problemen mit dem Container-Netzwerk und Dateizugriffen aus dem entfernten Container heraus, die man lokal nicht nachvollziehen kann. Die Idee ist per Remote Debugging aus der IDE heraus die Serveranwendung zu analysieren. Folgende Schritte sind notwendig:
- Debugging beim Start der Java Anwendung aktivieren und Remote Debug Port im Docker Container veröffentlichen
- Beim Start des Containers den Port zum Docker Host durchschleifen
- Remote Debug Port per SSH zum Client tunneln
- Remote Debugging in der IDE aktivieren
Alle halbe Jahre wieder kommt das nächste Java Release und so ist nun gerade Java 11 herausgekommen. Der Inhalt schien aber zunächst nur zweitrangig zu sein. Die letzten Wochen und Monate waren stark geprägt von den Debatten zu Oracles neuer Support- bzw. Lizenzpolitik und der Frage, ob Java bzw. das JDK überhaupt kostenlos bleiben.
WildFly 14 has been released and is now Java EE 8 certified. From now on, WildyFly only provides EE8 APIs by default in all its run modes. The Java EE 8 preview option and Java EE 7 mode have been dropped.
Since Java EE 8 is backwards compatible, Java EE 7 and older applications will still run in the new WildFly version.
Besides the promotion of Java EE 8 as new default mode, WildFly 14 comes with some new standards for Eclipse MicroProfile. The new APIs MP Config, MP OpenTracing and MP Health are now part of WildFly 14 and will help with the use of container environments.
Another new improvement is a high performance connection pool, provided by the Agroal project, although JCA is still activated by default.
The complete list of all new additions can be found in the release notes.
One of the many pleasant advantages the dependency management of a modern build tool such as Maven or Gradle gives you is that you simply declare the set of dependencies your application needs and the build tool then takes care of downloading them together with their transitive dependencies from a public repository. There’s no need to painstakingly assemble these by hand and later having to hassle with updating them to some newer version. The times when you had to manage a
lib directory in your project by hand are luckily long over (anyone remember Ant?).
But what if your project depends on some library that cannot be found in a public repository, either because it is proprietary or because it was never uploaded into any repository in the first place? How can you include such a dependency into the build process anyway? There are basically four options which will be discussed in this article.