Thursday, September 09, 2010

Java 7 new feautres (part 2)

Hi there,

I'm continuing my review on the expected features from where I started them:

JSR 308: Annotations on Java types
An extension to the Java annotation syntax to permit annotations on any occurrence of a type
In my opinion, this will make Java code stranger... May be I have got used to the current Java code style, but too much @ will make it look like PHP or other languages using strange symbols.
About the feature - it could add new flexibility in checks - kinda like "throws", final ... Imagine how JUnit will change after this feature is introduced!

JSR TBD: Small language enhancements (Project Coin)
A set of small language changes intended to simplify common, day-to-day programming tasks
String in switch --- My comment is "FINALLY, GUYS!"
Automatic resource management --- Well, we all got tired of all the try-catch around code pieces using  Streams. Just makes the code larger, but not doing anything special.
Generics initialization improvement - personally, I don't mind leaving it out, but sloppy developers will make less errors.
Collection literals and array-like access - this is similar to the one above. Just for easier initialization and access.

JSR 203: More new I/O APIs for the Java platform (NIO.2)
New APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams
The best new feature about this is the new .resolve() method, which will find the files as they are meant to be found and not force the developer to think which class loader is used at the moment etc etc... Until man encounters this problem, he doesn't know how frustrating it can be.

Update the XML stack
Upgrade the JAXP, JAXB, and JAX-WS APIs to the most recent stable versions
Actually, I don't know the exact reason behind the decision to drop the upgrade of the above-mentioned technologies, but as I use them at work on daily basis, I find this surprising. It would be great if their specifications are revised and developers at Oracle (former Sun) upgrade them to the next level, because Java API for XML will always be "modern" and the need for updates/improvements won't decrease.
Of course, I could be terribly wrong. ;)

Swing JDatePicker component
Add the SwingLabs JXDatePicker component to the platform
I have not used Swing as much as to notice that DatePicker is missing ... When I read it was to be "ADDED" I thought, "shame on you for forgetting it"! I suppose that more than half of Swing applications need date of some sort...


I'll skip intentionally the other improvements regarding class loaders, collections concurrency and Swing , because I don't find them as attractive as the ones I commented above. Here's a link to the full list.

I hope you found my comments reasonable. I am optimistic about the new Java version. I just hope the developers don't have too many problems and they don't delay the launch...

Good luck!

Leni Kirilov

Thursday, September 02, 2010

My own naming convention and what problems could arise from it

Hi, developers!

We write applications and our applications use data. We create data, edit data, store data...
Sometimes we store data on the File System. And I think that's a common practice.

Have you ever wondered how to name your files in order, not to have naming collisions or creating some temporary files with some extensions, only you as a developer, should know about ?
Have you ever encountered exceptions in your code while accessing the file system? A glitch in your code maybe?

I am going to address this issue because it's sometimes regarded as a trivial task and everybody is said to do it the right way.

1. Create states in your program 

If at runtime your program has some strict set of states that it is in, then you can be calm and happy about your design. If you can keep the state of your variables consistent, you can manipulate them as you wish and not fear some collisions. What I mean is when you invoke a method, it knows exactly what to expect - whether a String that is passed as a parameter could be null, or if it is in a special internal format, etc...

Entering methods and exiting from methods must keep the representation invariant intact and everybody should know their role in the process.

2. Keep the number of states of your program low
If you apply rule no.1, you can still mess up, if you have like ... 100 different states. Your head will be full of conditions and rules to transit from one state to the other...

 A developer should not think about more than 7 things while developing. That way he can stay focused and make always the best decisions about his design.

3. Document your states

Be honest about your program's states. Tell your colleagues. Don't be shy or overprotective , if there's this colleague who always critisize your code. If they know about the states you introduced, then they could tell you about a problem earlier and adopt those states in their modules early on.
Not to mention that at one happy moment, somebody else different from you will be supporting this code.

4. Avoid tricky (smart) code

I've seen smart code and it lead to invisible problems, reported and fixed years after the code was written and got into the final product.

- Imagine the following situation - you are passed String with the name of a file, and you must create your own temp file, where you should store your temporary data during the processing of the original file. So you create a file with

String tempName = originalFile + "temp";

And later you decide to wipe all those temp files, but since you have added "temp" at the end, you can just use
if ( "temp".equals(String.lastIndexOf(aFileName) ) {...deleteFile(); }

And you thought you deleted your files. What happens if there are files that are called "xxxtemp" by the original user? Even if you add "temp" at the end , you will get to delete both the temp and the original.

- Another smelly situation - your use case is to keep the temp files and delete all non-temp-ending files.
Ok so lets use:

fileName.replaceAll("", "temp");

So we'll discard the temp and we'll automatically get the original filename...
Wrong! What happens if all this is happening in directory "c:\temp\myfiles" ? You will get invalid file paths and another exception is thrown.

You should be very careful with these kind of situations with files.
I suggest 2 ways to avoid problems:

A) store in a collection the original files and in a new collection the references to the temp (new) files.
That way you don't need to think of weird algorithms to find temp/original files by their derivative's names.

B) if you have to think of such an algorithm be sure that it finds exactly what you want.
Back to the example with the replaceAll():
int lastIndex = fileName.lastIndexOf("temp");
fileName.replace("", "temp", lastIndex);

And this is exactly the opposite of string += otherString.

I am sure other developers have found other techniques to avoid problems but those were mine.
Feel free to share your opinion.

Leni Kirilov

Wednesday, September 01, 2010

JDK 7 new features (part 1)

Hi there,

We all know Java. Many love it, some dislike it, other actually hate it... and if they knew its weaknesses and flaws as I know some of them, well, they'd pity all the Java developers for choosing such a fragile platform and language...

 So basically , before you thought I hate Java, the thruth is just the opposite - check this blog's name :) - but I admit that Java has some veeeery bad treats and design flaws.

But why am I talking about Java flaws in a posting called "Java 7 new features" -- well , because they(the guys behind Java) try to address some of these problems , I'm also going to point some of them to you..

This list is not ordered by me - everywhere I look these features are presented in this order. I'll keep it that way for consistency.

Feature: 64/32 bit pointers support 
-- why store 32bit pointers in 64bit space, when you don't need it. The JVM will be more agile and not create empty spaces in the pointers, so less space will be required, which will help the traffic more than a local system with gigabytes of RAM. Performance boost.

Feature: Garbage-first Garbage Collection
- kills the young fast-dying generation first. and preserves objects that have survived the wipe a few times.
Result: more GC options and strategies -- performance boost.

Feature: dynamic languages in JVM
-- All can agree that Dynamic languages have big future ahead of them and that's a good reason that Java should try to adopt them and try to run them natively on a JVM. Thus making the JVM something like a universal VM for different kinds of languages. Imagine the freedom to combine different languages and techniques easily with native support and not some simulators.... no performance problems ... no interoperability problems... I really hope this is going to be implemented very professionally.

Added support for lambda functions, which could revolutionize some known patterns in the Java world - creation of an anonymous class for an interface like MouseListener and so on - now you can create a lambda implementation, pass it as an argument and inside it can be executed. This will make our Java a more interesting place. The anonymous-class design that was being forced because of the lack of such a feature and it's not intuitive at all. Let's see where this will get us.

Feature: Java modularity - Project Jigsaw
This project, in my opinion, will be an improvement, which will improve our Java experience. But what exactly is the problem? What do you mean with "Java modularity" ? Java is already modular, some will say... Well, it isn't.

Just check your local JRE installation and see in the \lib\  directory the rt.jar (rt = runtime). Notice the size - using latest JDK 1.6 Update 21, the rt.jar is around 47 MB.

Yeah, 47 MB and that's a module... yeah right. Nice design, guys! Many classes must be written with lots of lines to fill those 47 MB and believe me - these 47MB in rt.jar are all classes. Who wants to say how many millions of code...

But why when I only use and java.lang should my JVM also load SWING and java.beans and javax.xml ... The sad reason is that all of them are all TIGHTLY coupled...

Somehow, somebody let it all loose control and everybody started pushing shit in this .jar file... well it works, so who cares? It's not modular... again, who cares? You can't easily extract a piece of it and place it elsewhere. You can't manage your JVM RAM requirements because of required modules being all stick together and you can't separate them.

Image that you can modify your JVM depending on your business case !
Well, project JIGSAW is trying to solve exactly this problem - separating all swing, applet etc modules into separate sub-projects and decomponentizing the  rt.jar into several (hundred?) jar files.

I imagine something like a ( JVM + OSGi ) ... yeah :)

I wish the developers good luck, because of the issues that could arise, and I think it's not a trivial job.
Remember they also have to maintain the backwards operability somehow...

I see that this post has become very long, so I'm going to continue it later.

Feel free to comment, because my view on a topic could be very wrong, but I'd love if you start a discussion. Especially when the topic is Java :)

Leni Kirilov