30 December 2008

What do I need in JDK ?

I'll put some staff that I found that are much problem from time to time for me.

  • Lack of methods in File class...
  • String Comparator...
  • Thread Statics...
  • Add .shrink() for StringBuffer & StringBuilder...
  • 1st lvl type validation in standard Generics...
  • Generics variables...
  • Support for method to be able to return more than one variable...
  • Extended printStackTrace...
  • Read-Only Arrays...
  • 'forget' keyword...

28 December 2008

Null handling: Small language changes on JDK 7

The idea is about allowing people to handle null object situation as easy as possible (here by new operator). And I agree with that since even before.

What did we loose with hiding object's address?

Let's list advantages:

  • More control over application security! Mostly, it's impossible to get forbidden information.
  • Information has to be delivered overtly.
  • Garbage collector can work easier, more reliable and it's not so rare to be faster than manual deallocating memory. What's more, programmers have more time for code quality and efficiency.


  • Programmer is obliged to predict which data will be needed in future.
  • Natural (physical) objects order has been lost.

27 December 2008

For-each loop: Small language changes on JDK 7

Lets talk about:

  • For-each loop over a Map
  • Control over for-each loops (index/remove)

At first, I asked myself if it's possible to obtain those targets just by a simple code.?
It's not so clear for all, but answer is YES.
However, there are still some small languages changes that would improve programming quality.

26 December 2008

String switch: Small language changes on JDK 7

According to Stephen Colebourne's Weblog: JDK 7 language changes - JavaEdge votes!
Allowing put String into switch statement is OK for me. But I cannot agree with placing that into JDK.
You can ask why. For me it's quite simple. Java is Object oriented language, while this change we make it more String or 'Script' oriented.

19 December 2008

Is Javadoc killing program evolution?


When I found what Javadoc was, I was totally impressed. The way that it made code more readable was increadible for me. So it didn't take too much time until I used to comment each class, method and parameter. I did that in one project and was satisfied with results. However, in the second one I found a problem that improving Javadoc after rebuilding some parts of code took even 3x more time and efford than it should have. That's why nowadays, I'm used to providing comments as little as possible. This doesn't mean that I avoid using Javadoc. I just try to make it as brief as possible, omitting as much as I can without harming a project.