Anybody likes reading com.superframework.core.base.Object object = new com.superframework.core.base.Object() in the code?

I wonder how many times I have asked myself why Java is so complicated to read and write? Why I have to keep writing so many characters and lines of code to express a simple repetitive task? It's appeared to me like Java language designers keep torturing developers by forcing us to use constructs invented 15+ years ago without an alternative.

But this one is simply an outrage. Considering that e.g. Python is even older language than Java and you never have to write complicated namespaces in the code more than once in the import. On the contrary, Java does not provide a simple and readable solution when two classes of the same name have to be used in one source file.

Consider following code comparison.

In Java:

import com.myapp.base.Object;
...
com.superframework.core.base.Object frameworkObject = new com.superframework.core.base.Object();
Object javaObject = new Object();

In Python:

import com.superframework.core.base.Object as FrameworkObject
import com.myapp.base.Object as MyObject
...
def frameworkObject = new FrameworkObject()
def object = new MyObject();

No commentary needed, everybody can surely see the difference. Although, you can see the horrible Java code above mostly in generated code, sometimes it is not easy to avoid name clashes, which lead to Java code one would puke from. In this particular example, imported Object can be even easily confused with standard java.lang.Object. In Python, you may name it as you wish to avoid name clashes.

After many helpful improvements in this direction in Java 7 and Java 8, I strongly recommend also to revise a recommendation raised almost 15 years ago for Java version 1.3:
- http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4478140

I understand that 15 years ago adding syntactic sugar to the language was not a top priority. But nowadays, if Java aims to stay the language of choice for millions of developers, it is necessary to consider small improvements like this, which have drastic impact on quality of the code and developers' work.

Decrease your Java IDE lagging by fine tuning JVM Garbage Collector

Ever wondered why Eclipse/Netbeans keeps pausing for a while every now an then? Especially right at the time you when you want to show something in the code to your dear colleages? It feelt embarrassing and awkward, didn't it?

I found out that most of the time the IDE pauses because of Garbage Collector execution. The subtle little element in design of JVM, which usually does great job in relieving us developers from worrying about memory consumption, and most people are just happy that it does its job well and ignore it most of the time. However, the consequences of running Garbage Collector may surprise us if we simply ignore it.
In short, when GC is running, it pauses execution of the application until it is done freeing the memory. This is for sure unacceptable for real-time systems, where Java is certainly not the number one option. But even in non-critical huge desktop applications, which modern Java IDEs certainly are, the GC may stop the whole application for several seconds. And this may happen several times during the day. You can imagine that with productivity tools like IDEs, this is simply dragging down their "productivity" effect.

A solution is to do some tweaking:
- increase memory for JVM on which the IDE is running (beware that this only reduces frequency of GC being called, but prolongs the execution time of a single GC run - it takes longer to collect garbage from bigger pile...)
- switch default GC engine for a more concurrent engine, which tries to collect garbage continually even between stop-everything-until-done executions of complete GC

The first option is well known to majority of Java programmers - just define reasonable values for MaxPermSize and the family.

The second option, however, is not so well known. The point is that Oracle Java Hotspot JVM provides several alternative GC engines, which we can choose from. And they, unlike the default one, provide continuous garbage collection even between the big GC executions that slow everything down.

G1 Garbage Collector

Since Java 7 update 4, Oracle provides G1 Garbage Collector in JVM.

You may enable it simply with this command line param:

-XX:+UseG1GC

For more info on how to configure G1, see  Java Hotspot VM G1 options.

CMS Garbage Collector

In some benchmarks, older CMS collector outperforms the newer G1 collector.

You may enable it instead of G1 with these options:

-XX:+UseConcMarkSweepGC

Special Eclipse tweaking

GC tweaking really helped to improve performance of my Netbeans installation. However, to be honest, with Eclipse IDE, GC tweaking is only one of many steps to optimize the performance, and it is unfortunately only a minor one. What helps a lot more are tweaks in configuration, like turning some validations in the code, reducing size of console output. In my case, console output was freezing Eclipse so much, that I needed to redirect standard output of my application server to a file and bypass the console completely :(