For me, mid-2000 was the big bang of a new generation of languages that run on the JVM. Among the first languages interested in enjoying the benefits of the brilliant engineering behind the JVM were Scala, Groovy and Clojure. Both of them are still going strong and flourishing. But after them new languages have been created such as Golo, Ceylon, Kotlin and others.
Not that you asked me, but I believe that software engineering is mostly about solving problems. All those blog posts saying “every child should learn to code” and “pff, math? I’m a programmer and I’m doing so much more than math, have you seen my HTML5 debugger thingy” agree that software engineering is more than writing pieces of prose in specific languages that computers know to understand. Problems our software solves defines us as programmers.
You’ve probably heard of Jython before–a 13-year-old, mature, JVM-based, object-oriented scripting language, Jython is the ‘Java’nised version of Python, if you will. In the past, it went by the name JPython, a far cooler name, if you ask me!
Considering the time and effort that has been put into it in the recent years (the language development had a hiatus period during 2005- 2008/ 09); it has still not received the amount of attention from the programming community that it should have. This is one language that is laden with features and is the best of both worlds: Java and Python.
In our recent publication 10 Kick-Ass Technologies Modern Developers Love, we selected a group of tools that developers have proven to really enjoy (based on a heady mix of market data, community activity, anecdotal evidence, our own experiences and a general gut feeling). With Scala as the 1st choice of alternative JVM language to learn, we wanted to get a few more details from the coder perspective about Scala. So, we reached out to Typesafe and sat down with Adriaan Moors, Scala Tech Lead, and asked a few probing questions…
Back in May 2014, we launched what proved to be our most popular investigation into Java developers tools and technologies–The Java Tools and Technologies Landscape for 2014. Propelled by a rush of charitable feelings, precisely 2164 JVM developers responded to the survey–each response donated 0.50 USD to Child’s Play, a charity that gives sick children Playstations for passing their time in a hospital.
One of the most popular subjects that we regularly cover has to do with Java Web Frameworks–after all, it’s one of the most active and fragmented technology segments out there. One in 10 devs we talked to doesn’t use any frameworks at all, and one in five developers uses 40 or so frameworks that aren’t even in the top 8 most used out there. What the heck is going on here!
Here is what look at today:
* How many developers use multiple frameworks?
* Breakdowns for the top 4 frameworks compared to the average results (e.g. what % of Spring MVC users also use Vaadin?)
Did you know that in 1981, Estonians decided that their daily lives were a bit too bereft of humor and thus decreed that the 1st day of all months in the year was to be a day of jokes, sarcasm and fun. This is a total fabrication brought on by too many coffees this morning, but if it was true then I’d be wishing you an August Fool’s Day right now!
Introduction to the geek love fest
Have you ever heard the question: “How do you know if you’re in love?”
Well, forget that. We’d rather know “How do you know when a technology is going to change your life?”
In the first post on runtime code generation in Java, we looked at Java’s strong and static type system. Then we learned about different libraries for code generation and we had a closer look at Byte Buddy, a library of my own efforts.
Today we want to compare the different libraries in a benchmark. In the end, a shiny API will not be the only criteria for a best choice in code generation library. A library’s runtime performance might be an even more important factor, especially if the generated code takes up a crucial position within the running application.
We generate a microbenchmark and see if the performance of the different frameworks will allow us to draw any conclusion about which approach is better.
Performance is a complicated matter, especially if you take into account that your Java program gets through multiple rewrites during the compilation process. First, your source code is translated quite straightforwardly to bytecode, which is then compiled further, sometimes multiple times, to machine code.
By leveraging your knowledge of JVM internals and how the JIT compiler works, you can optimise (to a certain extent) your code to perform better. In this post we’ll talk about a tool called JITWatch that can give you some insight about how your application is handled by the JIT.