JVM

Episode 86. Move Over Slow Startup times, GraalVM…IS…HERE. (and cross-language support, and less memory footprint…)

Oh my! This episode is going to be one of our favorites. There are times where the Java ecosystem delivers something incredibly interesting (InvokeDynamic, Lambdas, Streams, Kotlin), and this episode is one of those! You may have heard it mentioned around the interwebs or conferences (this new GraalVM thing)… well, it’s here to stay and is propelling JVM languages to a whole new level of interoperatibility and performance!

So GraalVM at the very high-level view is a “Java Virtual Machine” (in reality there’s much more to it, but we can at least start there). It provides tons of interesting features, like the ability to not only compile Java/JVM languages, but also Javascript, LLVM Languages (like C++), Python, R (and is expanding to others), and more importantly, interoperatibility between all these languages.

But the bee’s knees (or the most interesting fact) is that GraalVM also have the “Native Image”, which allows you to completely bake in a Linux (more platforms coming) binary straight up from your source code. The Native Image doesn’t require Java to be installed, and you can start your application as you would any other Linux executable. The most impressive part? Startup times are incredibly fast!

So we have usually addressed tons of misinformed myths of the Java language like “It’s slow:” (No, not really), or “You can code more performant code in C++” (possibly, but you have to be an expert to squeeze more performance than the JVM’s JIT compiler). But one area that the claim has held true is that “Java has slow startup times”. And (it used to be) true! Because of the dynamic classloading that Java supports, it’s very hard for the JVM to startup fast. For long running applications this is usually not a problem, even so, for the new Cloud folks (and Lambdas, and AutoScaling Groups), fast startup time is a “thing”. And so, with GraalVM (with some caveats) we are conquering one of the last arguments against the JVM languages.

In all, THIS is the episode to listen this year. It’s exciting, new technology that we could really spin up and use. Let’s have fun programming again with GraalVM.

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 85. Monitor the World with JMX!

There are technologies that sometimes are forgotten in a lonely corner, but that actually are quite sturdy. One of these is the All-Powerful Java Management Extensions (also known as JMX). With JMX you can actually expose a lot of metrics of your application and TONS of libraries use it “out of the box”. Libraries like Tomcat, JVM, ActiveMQ, Spring (and ton others) exposes their metrics through JMX. And you can too!

In this episode we go over how to both consume JMX metrics (through JConsole, or statsD, or other Performance Monitoring Tools), and how to produce them as well (By creating your own MBeans), not only that, but we also go with how to be able to “invoke” these on a live application. Have you ever wanted to say “Oh my, I wish I could call this method while the program is running in production ‘At will'”. Well, with MBeans, you can make that happen! Not only that, but if you really want to you can also expose your MBeans through a Rest Endpoint with Jolokia.

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo

We also thank OverOps for sponsoring this podcast episode

OverOps Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 50. How many Classes would a ClassLoader Load if the ClassLoader was Loading the parent Classes?

You worked with them “all the time”, whenever you know it or not! Classloaders are the little workers that make sure all the code is there and ready to be executed. Bob revisits this topics and goes into more detail on how the ClassLoading hierarchy works, when to watch out, and how different frameworks (OSGI, and Java EE containers) may be configured to load classes. If you have run into “ClassNotFound” exceptions, this can help you explain why!

Don’t forget to SUBSCRIBE to our NewsCast
Java Off Heap

 

We thank Codeship for being a Sponsor of the show! Need Continuous Delivery made simple? Check Codeship.com! And use code JAVAPUB20 for a 20% discount!

Follow
Me
on
Twitter! (@fguime) (thanks!)

Ok, so now is allergy season, and I heard beer with honey is good for you. Or better yet, beer made of honey (Mead!)