Monday, February 18, 2013

Project coin and operator overloading

Today there a lot of programming languages running on the JVM. one of the arguments of the advocates of these languages is that java is old language that require you to write a lot of code while you can simplify and shorten your code if you will use language like scala. This is the reason why in java 7 there is a new project - coin project that wish to simplify the syntax of java. in java 7 the following features were added: 1. using string and enums for switch statement 2. enable adding more than one exception in the catch clause. 3. the diamond operator in generics (removing generics in the constructor) 4. ability to call exotic names of methods that exist in other JVM languages - i will refer to it soon. and one still in thinking process: 5. adding notation to access collection - this one i would like to discuss. Collections are widely used in java and array is pretty much old fusion, however, it is very nice that you can write array[i]. It can be very nice if you can do it to collections as well.
for (int i = 0; i < list.size();i++){
   list[i] = something(i);
}

first, i'm not sure it is such a bright idea since it discourage users to use iterator, but there is something appealing in this idea. so if you wish to create a solution for it, you can go in two ways: collections that provide us index should implement an interface, the list interface - so array should implement list too? and the operator [] will be overloaded only on the list interface. this solution is not generic solution and you can ask yourself why this interface should get operator overloading and other java objects not. or finally we will have operator overloading in java and the integration with languages like scala will be much simpler. it can be nice if you will be able to write the following code:

if (newDate > oldDate){
doSomething();
}

this is really can be nice... and it will also resolve number 4 that i said that i will refer to it later. now you don't need exotic names for functions that support operator overloading. however, operator overloading has problem in java since in java we have only two types of variables: primitive & references. and operators refers to variable and not for objects, let examine the following code:
if (person1 == person2){
   doSomething();
}

the == operator refer to the reference and not to the object. so now if you wish to overload the == operator you can't check if the references point on the same object! so it is a problem to implement operator overloading in java. so you can add syntax sugar in the coin project but it is not feet to a common standard. and one more thing what happened if the object itself is null, what happened in the operator invocation. so i guess, full operator oveloading is not simple in java. but i really be happy to see more thoughts about this idea.

Thursday, February 14, 2013

will we abandon mobile applications

Today most of the java applications has web UI interface and not rich client application. It is almost a curse to develop a rich client application that run on the client side. In one of the projects that i did in a very big enterprise company i herd one of the managers says: I do not wont to install anything on the user machine, only anti virus and OS. No doubt, web UI has a lot of advantages and today with HTML5 you can get rich client application look & feel in your web browser. so it looks very reasonable to abandon rich client technologies like swing and use web development instead. and with tools like GWT it looks very easy to work in web development and you don't have to work with java script if you don't like it. However, today we are facing a very big revolution, the mobile revolution we are replacing our computers and laptops with mobile phones and tablets. But in this world we would like to install applications on our device! even if we write it in java script we wrap it in installation, why? there are probably a lot of answers: 1. very easy to install 2. can use the app store / Google play for earn money and promotions 3. better user experience 4. better performance 5. more capabilities from the device hardware (GPS,jyro...) let me answer it one by one: 1. install on desktop is also quite easy 2. This is an advantage but i ask myself is it a silver bullet? 3. also in desktop 4. also in desktop 5. many applications that don't need extra from the hardware still used as applications. more than that i suspect that the factors that made us abandon rich client and focus on web still exist in mobile slow the computer viruses security and many more... so do you think one day we will stop using applications and return to the web again?

Wednesday, February 6, 2013

Thanks god for ARM in java 7

One of the most disturbing thing that was exist in java was closing resources such files. first, you need to remember to close the file and put it finally since there is a chance that you will suffer from exception, but in the finally you have to protect yourself from getting null since the exception can happened in the creation of the stream or the channel. so the code should look like this:
      FileInputStream FileReader= null;
      FileOutputStream FileWriter = null;
      try {

        FileReader= new FileInputStream("in.txt");
        FileWriter = new FileOutputStream("out.txt");
        int var;
        while (var = FileReader.read()) != -1)
          FileWriter .write(var);
      } finally {
        if (FileReader!= null)
          FileReader.close();
        if (FileWriter != null)
          FileWriter .close();
      }

In addition, the close method throw exception as well so you need to handle it as well. This is very tricky code and very easy to make mistakes. no wonder spring provides useful templates for this issue. But from java 7 with automatic resource management we don't have to take care of it anymore. from java 7 you can write the same code like this:
try (
FileInputStream FileReader= new FileInputStream("in.txt");
FileOutputStream FileWriter = new FileOutputStream("out.txt")
) {
      int var;
      while((var= FileReader.read()) != -1 )
            FileWriter .write();
  }
since OutputStream and InputStream implements the interface closeable with the method close, the close method will be called automatically if the object was created since the code is in try brackets. so now java take care the close of the file. I believe it will save a lot of time and many bugs mainly for novice programmers.