Java snippet: get PID at runtime

package my.pid;

import java.lang.management.ManagementFactory;

public class MyPid {
  public static void main(String[] args) {
    String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
    int p = nameOfRunningVM.indexOf('@');
    String pid = nameOfRunningVM.substring(0, p);
    System.out.println("Java app PID: " + pid);
  }
}

Java Bytecode Fundamentals

Java bytecode is a bread and butter of JRebel, the productivity tool for Java developers. This is why I decided that it would be a good thing to write a blog post on this subject. This blog post is a summary of various sources that I've found while googling on the subject. Hopefully someone may find it relevant and useful. What is a little weird is that there's not much information on the subject, either books or articles. BTW, if you have anything to add or comment - don't hesitate to post to comments :)

UPDATE This blog post, along with many improvements is a part of my article for RebelLabs' report on Java Bytecode that can be found here: http://zeroturnaround.com/rebellabs/rebel-labs-report-mastering-java-bytecode-at-the-core-of-the-jvm/

The developers who use Java for application development, usually do not need to be aware of the bytecode that is being executed in the VM. However, those developers who implement the state-of-the-art frameworks, compilers, or even Java tooling - may need to understand and may even be using bytecode directly. While special libraries (like ASM, cglib, Javassist) do help regarding bytecode manipulation, it is still important to understand the fundamentals in order to make the effective use of those tools.

Let's start off with a simple example - a POJO, with one field, a getter and a setter.

public class Foo {
    private String bar;

    public String getBar(){ 
      return bar; 
    }

    public void setBar(String bar) {
      this.bar = bar;
    }
  }

First of all, one you compile the class using javac Foo.java, you'll have the Foo.class, which now contains the bytecode. Here's how it looks in the hex editor:

Each pair of hex numbers (a byte) is actually translatable to opcodes (mnemonics), but obviously it would be too brutal to start reading it in the binary format. Let's proceed to the mnemonical representation.

Executing javap -c Foo will print out the bytecode:

public class Foo extends java.lang.Object {
public Foo();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public java.lang.String getBar();
  Code:
   0:   aload_0
   1:   getfield        #2; //Field bar:Ljava/lang/String;
   4:   areturn

public void setBar(java.lang.String);
  Code:
   0:   aload_0
   1:   aload_1
   2:   putfield        #2; //Field bar:Ljava/lang/String;
   5:   return

}

The class is very simple and it is easy to see the relation between the sourced code and the generated bytecode. First of all we notice that in the bytecode version of the class the compiler inferred the default constructor (as promised by the JVM spec).

Apples vs Oranges. Java Container Startup Times

Just recently with @toomasr we've studied how fast are the Java application servers at the boot time. The boot time for an application server is an integral part of what we call the developers' productivity.

The most surprising this thing about the results was that the JBoss 7 average startup times where extremely fast compared to the previous JBoss versions.



At the beginning we couldn't believe this improvement is for real and assumed that JBoss 7 is an OSGi container. But just a bit later some JBossAS developers commented on the blog entry, that actually JBoss 7 has been completely redesigned for classloading performance.

Andy Miller said:

The startup times really don't have anything do with the OSGi stuff that is in there. It's based on a new services architecture underneath, which can start services and load classes in parallel (there are some JVM limits in class loading that make it serial, but we hope that will disappear), and take advantage of the fact that there are multiple cores on virtually every machine someone would use today.

To learn about the new features in JBoss 7, the highly recommended listening can be found at the JBoss Asylum podcasts page.

Thumbs up for the JBoss engineers, really! At least some AS vendors do care about the developers productivity! :)

LiveRebel Product Demo

JetBrains Youtrack

Recently, I've spent some time playing with Youtrack, the bug tracker by JetBrains. The last time I was looking at it was about 2 years ago, when it was announced under the name Charisma.

Long story short - I've a very pleasant experience while trying Youtrack now. But let's take a closer look!


I kick ass withAJAX-based issue management system
What are the features that I've noticed and liked:

The command-line with auto-complete. Sometimes I get really lazy and just unwilling to use the bugtracker as I have to use the mouse and click over several screens in the bugtracker's UI to get the job done. With Youtrack, I can make queries in the command-line that has autocompletion, which is awesome!
Project settings and administration. It took me just a couple of minutes to configure a project and the users. And also I figured out very quickly how to the user roles work. Considering I'm just an ordinary user for this type of software - this is a good sign!
Shortcuts are configured just like in IntelliJ IDEA, which I'm being a big fan of. I think this is an awesome feature for any IntelliJ user trying to use Youtrack.
The UI did not cause any animosity during use for me. Also, you can make screenshots just from the form where you report an issue - a very handy feature I have to say.

Eclipse, JBoss, EAR, JRebel

Some Pictures from Devoxx 2010

JRebel at Devoxx 2010, Conference Day #2

Day 3 at Devoxx for me is over. Lots of JRebel demos today again at Devoxx expo area.

We've got plenty of feedback for the product and features/improvements we would consider to implement  in the next releases. That includes Grails GORM support, support for adding new EJBs (3.0) on-the-fly, support for Servlets 3, better support for Wicket, better NetBeans plugin, plugin.xml support for Eclipse RCP, and many more! So that's something we should definitely to consider for the upcoming releases of JRebel.

Also, I met some people who haven't used JRebel yet, or haven't heard of it at all. After the demo they wanted to start using it! I hope we'll get to hear from those who started using JRebel - the feedback for is really appreciated!

I managed to escape from the booth to attend JavaPosse live session at the conference - I haven't had a chance to attend their sessions before. That was fun! :)


With that, the expo is over and JRebel team is going back to continue doing the awesome job!

JRebel at Devoxx 2010, Conference Day #1

Day 2 at Devoxx for me is over! Lots of demos, chatting, explaining things, etc

For a start we had a quick chat with Geertjan Wielenga about Javeleon. Even after a short conversation I think I have more understanding what it is about.

Also, I had luck to "unvirtualize" with Claus Ibsen and Charles Moulliard (from FuseSource), the guys behind Apache Camel - it is always a pleasure to meet people in person.



Also, somehow, my twitter reference have gotten to the Devoxx daily web page. Just because we have released a new JRebel version before Devoxx we were actually get quite a lot of buzz for the product which is positive as it gives the opportunity to get the feedback faster from the users. For Devoxx attendees we still have the giveaway "LiquidMetal" licenses - so go grab one!

I attended one session, the Reflection Madness by Heinz Kabutz. This was an awesome talk, but pretty much a compilation of the articles from JavaSpecialists.eu newsletter.

I can say I really like the spirit of Devoxx (compared to JavaOne this year) - it is even more technical: people come and ask good questions about JRebel. Some already use it but want to know more - that's also great! What I'm realizing now, is that the awareness is quite low for the issues that we're trying to solve. Probably, it would be a good idea to submit a talk at JAZOON'11, just to show what problems exist that are related to deployment under application servers of all sorts...

JRebel at Devoxx 2010

The first day for us was actually the University Day #2 at Devoxx. Not as many participants yes as it is expected on the real conference days. I did a few demos today demonstrating the PetClinic Spring MVC app. Frankly, I've got sick from doing the same demo again and again. Gotta prepare a new demo for tomorrow so it wouldn't be as boring :)




The fun stuff is that I managed to convince some hard-core devs that JRebel isn't about continuous integration, and it doesn't prevent devs from doing TDD and any other 'enterprise practices' one may apply during the development cycle.