Back from Easter? Here are some goodies from us :
In 2011, it was the ‘Hot New Product‘.
In 2012, it was ‘Best Developer Tool‘.
This year, 2013, keeping up with the annual tradition of winning at EclipseCon, we have won ‘Best Application‘!
The application in this case is Chronon 4 ‘Ops’.
They say 3rd time is the charm. Huge thanks to everyone in the Eclipse community for helping us win 3rd year in a row! We hope to continue delighting you with amazing software in the years to come
The reason why the JVM is so popular and has so many languages, IDEs, profilers, debuggers, APMs and other wonderful tools is because the JVM bytecode is extremely simple. You can teach someone the pretty much the entire bytecode in an hour and the next they would be using the ASM framework and manipulating bytecode.
Enter Stack Map Frames..
Java 7 brings with it a new bytecode ‘feature’ called Stack Map Frames which is the most complicated and unnecessary addition to Java yet and which erodes any simplicity the JVM bytecode has enjoyed thus far.
To be fair, Stack Maps were initially introduced in Java 6, but they were an optional part of the class file and every tool maker ignored them. However Java 7 makes them a compulsory part of bytecode, opening the can of worms described below.
What are Stack Map Frames?
The aforementioned simplicity of the Java Bytecode came from the fact that it hid away all the black art and gory details of compiler design inside the JVM’s JIT compiler, leaving programmers to deal only with a dead simple high level representation. You didn’t have to understand compiler theory terms like data flow or control flow analysis if you just wanted to inject some bytecode. However, Stack Map Frames make you do exactly that!
Stack Map frames essentially require you to keep track of the exact ‘type’ of the local variable table and operand stack at every bytecode instruction. While in theory, this may sound simple, in practice it will make your pull your hair out.
Consider the case of code like this and how the popular ASM framework generates Stack Map Frames:
1. The ‘type’ of
a at line 6 will need to be whatever the superclass of MyThis and MyThat is.
2. You don’t really know the type hierarchy of the classes during runtime bytecode transformation
3. Trying to use reflection to lookup the hierarchy can cause the said class to be loaded. This has a few flaws:
How complex you ask?
1. The code to do the Data Flow Analysis for this is so complex that the ASM Framework has over a 1000 lines dedicated to just this and it took 2 versions to get it right. But even then the fundamental approach is flawed due to the problem of trying to find the ‘common superclass’.
2. As an example, here is what a google search for Stack Map Frames shows for me:
3. Since the ‘common superclass’ approach used by the ASM Framework doesn’t really work, correct custom implementations are so complex and hard to get right that that for Chronon we skipped it altogether and run the jvm with a special switch (described below) that falls back to the old verifier.
According to the JVM spec, this new ‘feature’ of the JVM allows the bytecode verifier to go a tiny bit faster since it doesn’t have to do all those type calculations itself, since they are already done during compile time.
The above rationale is so bad and full of bullshit that it deserves to be classified as a design flaw of the JVM. Here is why:
Bottom line: The new verifier resuls in slower, more complex and buggier code.
The addition of Stack Map Frames only results in a net negative to the Java community and should be abolished.
I propose the following:
-XX:-UseSplitVerifierthe flag when running JVM 7. It will disable the new verifier which requires the need for Stack Frames.
Apparently Oracle is deprecating the
-XX:-UseSplitVerifier flag in Java 8, which will make the this workaround impossible and have us forever stuck with stack map frames
@stalar that makes things even worse….
— Chronon Systems (@chrononsys) March 25, 2013
Comment on bug 8009595 to prevent Oracle from doing so.
I absolutely love it when a product completely obviates a need for certain process/step to the the point that you never even have to think about it.
This is why I love Eclipse over all other IDEs. In Eclipse, your project is always compiled. In fact there isn’t even a compile button in the UI. Just click ‘Save’ and that’s it! If you have any errors in any of your thousands of source files after your most recent edit, just the act of hitting save will make it appear.
While other IDEs seem to be moving in this direction, none has an implementation currently that works as well as Eclipse.
For this reason alone, I find Eclipse to be heads above the rest. I never have to think about the ‘compilation’ step.
Its taken us a while, but Java 7 support is finally here!
Note that we don’t support other dynamic jvm languages like Groovy, etc, so the invokedynamic instruction in the jvm (which is used by these lanagues, not Java) is not supported by Chronon.
We usually update Chronon so often (almost every few days) that when we even sometimes we do a traditional company style update, which takes a few weeks, our users get a little upset
But not to worry, because version 3.2 is finally here!
We got delayed a bit with this one because some of the bugfixes and performance enhancements we wanted to make needed us to change the recording file format in a way that broke compatibility with previous versions of the debugger. Thus we combined a bunch of fixes/updates into one big update. Here is what it contains:
Unpacker Performance and File size improvements
Both the file size and time taken to unpack have been reduced by almost 20%. Enjoy a faster Chronon experience!
Tons of them. If you were running into bugs in the debugger, you couldn’t be anymore. If you use the Chronon Recording Server, make sure to update the Chronon Controller since this one contains a critical bugfix.
Enjoy the new Chronon and rest assured our future updates will not take this long.
The Chronon Recording Server installation was quite tedious for some users since it involved configuring and installtaing multiple components and needed a standalone container for deploying recordingserver.bat.
We have made things much simpler now with version 188.8.131.52.
Just double click on start.bat( or start.sh) to start running the Recording Server and Chronon Controller processes.
Full details here:
Intellij IDEA recently launched with a cool new Dark theme, so I set about to find something equivalent for my beloved Eclipse.
Apparently it didn’t take me too long. All you need to do is :
1. Make sure you have the latest version of Eclipse, ie, Juno
Sorry but previous versions dont exactly support theming.
2. Download the ‘Dark Juno’ theme
This will change the color of all eclipse view and toolbars to a dark theme. However we still have to change the color theme of the editor.
3. Get the Eclipse Color Themes plugin
Install a dark theme for the editor from there. I personally recommend ‘Oblivion’. It is also the most popular theme on the site.
And tada! You now have ‘Dark Eclipse’! Granted the theming is a bit rough around the edges but you didn’t have to fiddle with your OS color schemes and takes only minutes to setup. You end up with a nice, eye soothing color palette for an application you will be looking at all day
More bang for your buck!
This means for just $500 for Chronon Recording Server Lite, you can get the full Chronon experience!
Enjoy squashing bugs!