The last vJUG session in June was all about Spring Data project and how it can make your life easier by unifying and simplifying the way your code interacts with the database. The session was special because we had Oliver Gierke from Pivotal for the speaker. Oliver is the lead of the Spring Data project and no doubt is in the best position to describe how the project is shaping up and why it’s happening. Oliver delivered a great and educational session and if you didn’t get a chance to ask questions on the IRC, which is by the way, #VIRTUALJUG at Freenode, you can always catch up with him on Twitter: @olivergierke.
This time Virtual JUG had the opportunity to invite and talk to one of the best Gradle experts in the world — Andres Almiray. Andres is a Java Champion with more than 16 years of experience in software design and development, he’s a brilliant Java and Groovy developer, a true believer in the inevitable success of Gradle, open source in general. He’s the spec lead of JSR 377 that tries to standardize common parts of standalone Java applications, both desktop and IoT ones.
He talked about things that he finds the most attractive in Gradle and the best ways to organize a project, what to think of Gradle wrapper and how it helps you establish reproducible builds. This was a great live session with no slides. Check out what we learned from in inside.
In my previous post about Graph databases, we went through the introductions to NoSQL and Neo4j, tried to understand what a graph storage is, and how it makes our lives a little easier. We also had a sneak peek into the workings of the SQL through the example of the friends-of-friends scenario and looked how Cypher, the query language for Neo4J database, makes things simpler by easing the syntax, making your queries more readable and expressive at the same time.
Our speaker for this session, Rafael Winterhalter, lives in Oslo and is the main author and contributor to ByteBuddy, a runtime code generation library. He is also part of the excellent community that helps put together JavaZone a great conference (2nd largest in Europe actually) that happens each year in Oslo.
Rafael took time to talk to us about bytecode, It was an excellent educational session, Rafael is a world class speaker and I encourage anyone who deals with Java code to watch it and become more familiar with such an important part of Java ecosystem: Java bytecode.
To improve the performance of your application you need to perfectly understand the system, its needs and abilities, and feel comfortable using a range of performance related tools: APMs, profilers, testing libraries that will help you solve the issues you have.
Which Java performance tools are you going to use in your next project and why would you choose one over the other? There are many aspect which may sway your decision and of course it will depend on the details of application you’re building. This report covers typical Java performance considerations, monitoring and application performance management tools, Java profilers, and common performance testing libraries.
Inside, we talk about Dynatrace, AppDynamics, NewRelic, Plumbr, Illuminate, Java Mission Control, YourKit, JProfiler, XRebel, Honest profiler, JMeter, Gatling and show some of the tools in action on a reference application.
IDEs are a very personal thing. One might favor IntelliJ over Eclipse or vice versa with the same kind of gusto as someone who supports a soccer or baseball team. Rabea Gransberger gives her very first session on the vJUG to explain to us how we can use our IDEs more effectively.
Imagine a situation where you suddenly need to obtain the bytecode of all the loaded classes in a the Java process. For example let’s say you want to debug some sort of instrumentation that happens at runtime and you can’t locate the .class file and inspect that.
Alternatively, let’s say you’re doing something along the lines of JITWatch and want to link together the bytecode you produce with the machine code the JIT generates. In any case, you have a problem which involves classes and as we know all too well, problems with classes and classloaders are gonna get interesting and you’re gonna need coffee.
In this post we’ll look at two approaches to obtaining the bytecode of classes loaded into the JVM and learn a thing or two about javaagents and the HotSpot Debugger, a hidden gem of the JDK.
So let’s outline the problem that we’re tackling in this post.
Problem Description: Obtain the bytecode of all classes loaded into the JVM.
Let’s get started…
In this post we analyze the main problems you face when debugging code that runs in production. Let’s get started with a fair warning that our made up legal department forced us to put here.
WARNING: The following post contains explicit descriptions of bugs in production systems that some developers may find disturbing.
In this teaser blog post, we’ll take you through some of the answers we have received so far in our Java Performance survey, which incidentally is still running so please take the survey before we do our full analysis of the data. Use the button below to take you directly to the survey (Oh and by the way, we’re still donating 50c for every completed survey to Dogs for the Disabled, so you can feel great while filling it in).
TAKE THE SURVEY!
Hi, I’m Jeremy Prime, an independent software consultant based in the UK. My primary professional interests revolve around software development on the JVM, and hence most of my development projects are Java-based. I first used JRebel (in its trial version) on a Spring/JavaEE project I worked on in 2013, and was pretty much instantly addicted to the reliable hot class reloading, sufficiently so that it took just days before I shouted “TAKE MY MONEY” to ZeroTurnaround to buy a full licence. I’ve had a strong interest in the non-blocking application platform Vert.x (http://vertx.io) since I first heard of it back in 2012, and late in 2014 I was asked to join a project using Vert.x (at that time version 2) as one of its core technologies. So in my idealized world for this project, I’d want to keep my Vert.x application running while making code changes and recompiling.