As mentioned in our recent webinar, the release cadence of Java has increased with Java 10. A new major version of Java is now released twice a year, in March and September. This means that we will already have Java 11 in five months’ time. This increased pace means that features can be delivered faster, when they are ready, so users no longer have to wait potentially multiple years. Just in the six months between Java 9 and Java 10, we saw numerous features added to Java. Expect to see a good number going into Java 11 as well.
Since the release of JRebel 7.1.0 six months ago, JRebel has become part the robust suite of Java solutions at Rogue Wave Software. To celebrate this, we’ve made the new JRebel release two thousand and eleven times more awesome! Starting with this release, the version number will be based on the year. Making 2018.1.0, the first major release of JRebel in 2018. We’ll follow this up with 2018.2.0, the second major release this year, and so on. The regular minor updates will increment the third digit in the version number, which means the next minor release will be called 2018.1.1. We continuously improve our integrations and deliver support for new framework versions with each JRebel release, be that a major or minor update. So, what are you waiting for?
Java 9 is finally here
After many delays, we finally get our hands on Java 9, along with its new features and improvements!
One of the greatest and most talked about new features in Java 9 is the Java Platform Module System (previously known as Project Jigsaw). Not only has the Java runtime been split into individual modules, Java now also supports the creation of your own modules and declaring their interdependencies. This can now be done without the use of a third party module runtime (like an OSGi container). The module system also introduces stricter access checks for compile time, runtime, and reflection. Public is no longer public! You can now have classes that are public to other classes in your module — and only your module — as well as limit how classes in other modules can manipulate your private state using reflection.
Believe it or not, Java developers don’t consider build tools to be the most interesting topic out there. They are generally not considered the most exciting segment of any developer’s overall utility belt.
After all, the majority of the dev world still chooses between just two build tools, Maven and Ant, the latter of the two having been created nearly a generation ago. At best, programmers would prefer their build tool remain invisible and stable; at worst, we hear complaints of downloading enormous libraries, scripts failing for no reason due to some invisible rule running in the background, and general annoyances.
However, build tools should still be able to rock, and it’s in the spirit of “Build Tools [Can] Rock!” that RebelLabs has set out to finalize our journey into the realm of Java’s three most popular build tools–Maven, Gradle and Ant (along with Ivy for managing dependencies). After all, if anyone was going to try to put it a little “sexy” back into Ant, it would be us ;-)
Java Build Tools: Part 1 – An Introductory Crash Course to Getting Started with Maven, Gradle and Ant + Ivy
Build tools are an integral part of what makes our lives easier between checking code in and testing your product. Love them or hate them, they’re here to stay so let’s first take a look at what they are, how they emerged and why they are both hated and revered today.
This is not another Maven rant nor intended as a flame war–we could even think of this as an “anti-rant”, if you like. I didn’t even bother to see how many other dozens of blog posts on this subject have been written. But let’s face it, one of the most commonly ranted-against tools in the Java development industry is Maven. According to recent results in our 2012 Developer Productivity Report (check out our really popular 2013 version too), Maven is the #1 build tool used by developers.
So what is a build tool supposed to do? Basically, it should automate a bunch of processes that developers need to do regularly, removing some of the manual sting from compiling your source code, packaging and running tests on it, etc.
Let’s start by reviewing the top 5 things that a Build Tool should do really, really well…