Just recently my interest for Kotlin, JetBrains’ (the makers of the IntelliJ IDEA development environment) alternative to Java on the JVM, was piqued. These are the first things I’ve noticed.Read More »
Grails always has something new to offer, not only features but also random bugs (unfortunately). Out of the blue I couldn’t even let Grails show its own version (grails –version) let alone perform any other action. This is all I got for each and every command I tried to execute.
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at ../../../src/share/instrument/JPLISAgent.c line: 844 Exception: java.lang.StackOverflowError thrown from the UncaughtExceptionHandler in thread "main"
The following runtimes were used:
- Windows 7 64bit
- Java 7 Update 71 64bit
- Grails 2.4.4
Of course I removed all temporary files and folders, the “target” folder of the project and the “.grails”, “.groovy”, “.m2” and “.ivy” folders in the user directory. Nothing helped. Some say it has to do with forking processes, but playing with those settings didn’t change a thing. After all, the error happens way earlier.
Then I came across a post that mentioned to create the “.inputrc” file (on a Linux system) because through debugging it was found that Grails tries to access this files. Well, I’m not using Linux, but since I was already in the “helplessly desperate” phase I wanted to give it a shot. Surprisingly, this file already existed.
Solution: I deleted “.inputrc” from the user folder et voilà, Grails worked again.
Recently I have updated our Grails 2.3 based web application to Grails 2.4. Although the 2.3 release was working fine, one doesn’t want to fall too far behind. I know out of experience that this can happen very fast. If you wait too long, then at some point the migration to a newer version is almost like starting from scratch, instead of just updating a few lines of code to accommodate for deprecated APIs. The biggest problem I encountered going to version 2.4 was a behavioral change regarding the validation.
Read More »
I have written about the performance of iterating directories before, in the context of Java and its switch from version 6 to 7 that brought with it the new Java NIO API. For whatever reason I felt the urge to do something similar again, but this time I wanted to compare two different approaches to recursively scanning a directory’s contents:
- Use recursive function calls (a function that calls itself over and over again for each directory)
- Use an iterative approach (a function keeps a list of directories and iterates this list)
To make things more interesting, I implemented this in C++ using the Windows API and the Qt framework, in C# in combination with its buddy the .NET framework and, for good measure, I also threw in the old Java code from over a year ago.
Update (26.12.2014): I added additional data at the bottom of the article.
Read More »
The Grails web development framework is a very powerful tool for quickly creating web applications ranging from simple to enterprise ready. For that, it probably provides everything a developer ever needs. And if it’s not delivered by Grails itself there are many useful plugins and tons of existing Java libraries (including the JDK, of course, the underlying SpringSource Framework and the GDK).
However, there is one thing I have stumbled across several times now and a quick search on the internet shows that I’m not alone with this problem: how can I use the internationalization features from a regular Java or Groovy class?Read More »
A while ago at work we were confronted with the task of creating a directory listing in a Grails application. We’ve tried a couple of approaches, one the Groovy way and one the Java way. Both delivered only a poor performance. A short search brought forth a Stackoverflow thread addressing the issue of slow Java i/o performance with only one real solution: switch from Java 6 to 7. That’s no option at work but out of personal interest I gave it a try at home.Read More »