In this article, we’ll look at a simple example that uses a dictionary for our cache. Then, we’ll move on to using the Python standard library’s functools module to create a cache. Read on for more info.

Swift and C# are both high-level programming languages, with shared features, such as being compiled programming languages. Here's a look at Swift from the perspective of a C# developer.

There are several parser-generators out there and most of them are good enough for most goals you may have. Among them I tend to use ANTLR more than others: it is mature, it is supported, and it is fast. Read on for the full explanation.

Learn more about namespaces in Mule with this look at XMLs with dynamice namespaces.

When creating an object should we inject everything at construction time or specify optional attributes via setters.

If you've encountered this issue before, author Joost van Schalk discusses how to correct the problem so you can move on with your debugging!

Automated web tests should follow good object-oriented design principles, too.

In this post, let's take a look at how we can generate SQL Server scripts of our database with existing data.

Here's part 6 of our microservices architecture, with a focus on deployment strategy!

Awesome new reactive platform for JVM development.

Spring 4 is widely used, but as with any technology, there are loads of questions. Here are the most asked and answered questions on Stackoverflow, like differences in component and controller annotations, and what the Spring framework is actually used for.

Groovy language introduced many interesting features from Java programmer's point of view. One of them is the lack of differentiation between checked and unchecked exceptions - a nice quality for programmers who struggled with checked exceptions requirements. It turns out, however, that using this neat Groovy feature with existing frameworks can sometimes be tricky which I've experienced lately. I worked with relatively straightforward microservice written in Groovy. It was built on top of Spring Boot 1.3. Among others, it used @RestController to define REST endpoints and @ControllerAdvice to handle exceptions thrown by the controller or its internals. Very simplified example code looks like this (complete source code can be downloaded from https://github.com/yu55/groovy-undeclared-throwable-demo ): import org.springframework.web.bind.annotation.RequestMapping import org.springframework.web.bind.annotation.RestController @RestController class ExampleRestController { @RequestMapping(value = '/get') String get() { /* Lets imagine this exception is thrown somewhere from deepest layers of our service code and we don't have to be immediately aware of this. */ throw new ExampleRestControllerException() } } Controller advice: import org.springframework.web.bind.annotation.ControllerAdvice import org.springframework.web.bind.annotation.ExceptionHandler import org.springframework.web.bind.annotation.ResponseBody @ControllerAdvice class ExampleRestControllerAdvice { @ExceptionHandler(value = ExampleRestControllerException.class) @ResponseBody String onExampleRestControllerException() { return 'ExampleRestControllerException handled in ControllerAdvice' } @ExceptionHandler(value = Exception.class) @ResponseBody String onException() { return 'Exception handled in ControllerAdvice' } } Simple checked exception: class ExampleRestControllerException extends Exception { } When ExampleRestControllerException was thrown, it was handled by onExampleRestControllerException() method in ExampleRestControllerAdvice class. And this worked perfectly fine. But I had to add a simple aspect after the returning of get() method in ExampleRestController to do some additional stuff. @Aspect @Component class RestControllerAspect { @AfterReturning('execution(* org.yu55.ued.controller.ExampleRestController.get())') public void logServiceAccess(JoinPoint joinPoint) { // empty implementation for clarity reasons } With this simple aspect introduced, the microservice began to behave strangely. ExampleRestControllerAdvice started calling the onException() method instead of onExampleRestControllerException() when ExampleRestControllerException was thrown. I didn't expect that. What happened? When the aspect for ExampleRestController.get() method is defined, the Spring generates a proxy for ExampleRestController. Since ExampleRestController doesn't implement any interface, Spring uses CGLIB library instead of java.lang.reflect.Proxy for a dynamic proxy generation [1]. Generated proxy class name is similar to ExampleRestController$$EnhancerBySpringCGLIB$$8d751c8@4481 and it's an ExampleRestController subclass which intercepts all methods calls. There is also another dynamically generated class created: ExampleRestController$$FastClassBySpringCGLIB$$b01891ea which is a ExampleRestController class wrapper. This wrapper class promises faster methods invocations than the Java reflection API [2]. Spring is invoking get() method (via sun.reflect reflection classes) on enhancer class which then invokes get() method (via CGLIB MethodProxy) on fast class instance. When controllers get() method throws ExampleRestControllerException it's rethrown by fast class to an enhancer class and then the enhancer class get() method throwsjava.lang.reflect.UndeclaredThrowableException (which contains ExampleRestControllerException inside). This results in ExampleRestControllerAdvice matchingUndeclaredThrowableException with Exception class and firing handler method different than expected. But why UndeclaredThrowableException is thrown? Because the get() method written in Groovy in fact didn't declare any checked exceptions that it could potentially throw. The proxy doesn't know anything about that controller is written in Groovy and no throws declared means that checked exception may still occur. This behaviour also corresponds to Proxy documentation [3]. The issue can be fixed easily by adding checked exceptions to get() method definition or defining ExampleRestControllerException as runtime exception. Former solution technically works but isn't 'groovy' though and the latter is an approach that Spring prefers and is currently considered to be best practice for exception handling [4]. At the end, I would not blame Groovy for this situation. Instead, I would rather point that despite the fact that Groovy simply don't care about checked exceptions, it doesn't mean that other libraries also don't care. This is not what most programmers think of first when using Groovy. A similar situation may happen with any other JVM language that 'ignores' checked exceptions. The best thing we can do to protect ourselves from situations like this is to prepare tests carefully. Imagine no controller tests for ExampleRestControllerException case - whole application builds and runs perfectly on production until this special case occurs and controller simply returns a wrong answer to the client. A bug like this may not be so obvious and fast to track or fix.

ASM is a Java bytecode manipulation library. Mocking frameworks and runtime code generators use it to dynamically generate Java classes. Here is an introduction to how it works.

I’m not an ETL expert. In fact, I haven’t done any professional ETL work for several years. My skills are, at best, rusty. With this in mind, I knew I’d have a hard time extracting data from a local database in order to move it up to Azure SQL Data Warehouse. Read on to hear about my journey.

In a previous post, we showed how to execute a Groovy script in our source directories. But, what if we want to use the Groovy command line to execute a Groovy script? Read on and see how it's done.

Barclays Data Scientist Gianmario Spacagna and Harry Powell, Head of Advanced Analytics, describe how they iteratively process raw data directly from the central data warehouse into Spark and how Tachyon is their key enabling technology.

Security issues and problems with serialization of random objects.

How to use mocked and non-mocked data to write unit tests using the free and open source JUnit framework.

I was working with Web API for one of my new projects, when suddenly I got this error message: "the server responded with a status of 405 (method not allowed)" when I tried to delete a record through API. I began to scratch my head, and finally, I came up with a solution.

Here's a great guide to authentication interceptors in Java without using Spring!