I came, I coded, I debugged.

Even the trivial things are not A common activity the vast majority of software engineers share is working with code. There are many programming languages out there, some are statically typed, while others dynamically. Some are object oriented, and some are functional. Others are still trying to make up their mind (just kidding, we love you Scala!!). Regardless of the programming language at hand, in the end, working with code means manipulating code. These manipulations can be read-only, e.g., code navigation, or mutating, where existing code is being changed, and/or new code is being written, or both. Not only is manipulating code a very common activity for software engineers, some would argue that this activity is what takes up most of one's time as a software engineer, or at the very least, one of the top activities software engineers spend time on. Other activities includes consuming coffee, debugging, context gathering, etc.  Manipulating code is not trivial. For example, in...

Reflection has always been a bit of a trickery, and while there may be some true to it, it does not mean one cannot master mind some cool stuff using it, and by cool I mean useful,  re-usable, elegant and the likes. In this post we put on the wizard hat and pull out some rabbits. Problem Statement In this post we'll discuss 3 use-cases in which we want to retrieve runtime information for some generic parameters. In all three of the following use-cases, our goal is to retrieve the runtime information for the generic type parameter T. The first use case is when you have a class deriving from a generic class, without having generic parameters of its own: class GenericInt extends Generic<T> {} // one wants to know the type of T of its parent new GenericInt () The second use case is when you create a new instance of a generic class by providing a generic parameter: // one wants to know the type of T inside the class new GenericClass<Integer> () The third...