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?

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.

What else missing in java NIO

Java NIO2 in java 7 add important features to the NIO framework:
Finally we have good framework that handle files: http://docs.oracle.com/javase/tutorial/essential/io/fileio.html
and improvment of asynchronus chammels: http://www.ibm.com/developerworks/java/library/j-nio2-1/index.html

The reason that now the File framework is usefull is that in java NIO you are not have to support all the types of operating systems but only modern standard kind of desktop server OS. (today with the mobile revolution we can have all kind of OS not always with the same I/O features as windows and linux).
so we finally can copy files and handling directories and all kind of nice features.

Since we are no longer obligated to exotic OS i think it's about time to add interprocess communication in java NIO. so two processes in the same computer will be able to communicate without sockets.

why it is so important? today when we are going to the cloud and computer networks is very easy why spend time and add inter process communication? well i think it's important from the following reasons:
1. don't catch port for inter-process communication - let's say i have a multi process application on the same server - since java has GC sometimes for preformance issue you wish to seperate the application to several processes but still it can run on the same server. in this case if i can avoid catching port is for the best, becouse many time you need to handle issue like port is already taken by another application.

Second, we can add support of share memory that can be very useful in java applications. i know today you can use terracotta for that issue but it's much more complicated (you need teracotta server) here you get your service from the OS and it really simplify your application.

Third, security point of view, socket is a security risk if you can avoid it you reduce the security risk in your application. In addition, it can simplify integration with other languages like .NET since if we will get share memory with other languages communication can be easier.

public static void main(String[] args) throws IOException {
  Descriptor d = Descriptor.create("message");
  ProcessChannel proc = ProcessChannel.open(d);
  ByteBuffer buf = ByteBuffer.allocate(48);
  buf.clear();
  proc.receive(buf);
  ShareMemory s = ShareMemory.create(Descriptor.create("memory"),1000);
  OutputStream o = s.createOutputStream();
  ObjectOutputStream obj = new ObjectOutputStream(o);
  obj.writeObject(new Temp());
 }

So i really hope so java NIO will include such feature, what do you think?

Back to SELA and intersting issue

Hi all,
It's a long time since i posted something in my blog.
 but now after coming back to SELA i decided to renew my blog and make it much better.
I really wish to make my blog a place where programmers can find deep answers and understand better the all issue of programming.

When I browsing the internet looking for good topic to my blog I found the following question in stack overflow: http://stackoverflow.com/questions/2489701/value-object-getter?rq=1

First it looks like non important issue, however, I think this question is much more important than it looks like , I saw a lot of developers using such utilities methods or choosing the second approach and adding more methods. this issue is important since it touches the core of object oriented programming. both of the options are not good object oriented design.
the first approach creates utility methods that are not really belong to any type and it's really a procedural programming.
The second approach let's the amount of money deal also with the interpretation of the amount to specific type of coins.
The issue become more serious if you wish to support different types of coins (euro, yen, yuan...)
than you can see that both of the approaches are not so good.
Here is my object oriented solution for this issue, the UML should look like this:

1. Create abstract parent class called money with amount and factor, each type of coin will be a subclass of class money and only money will have methods of equals, hashCode and compareTo.
each subclass can implement the toString method for coin presentation. than you can write factory for it to create the right coin that also read the appropriate factor of the coin.
Now let's look how the code should look like:

public abstract class Money implement Comparable{
private int amount;
private int factor;

public Money(int a, int f){
   amount = a;
   factor = f;
}

public boolean equals(Money m){
 return (amount * factor == m.amount * m.factor);
}

public int hashCode(){
  return amount * factor;
}

public int CompareTo(Money m){
    return amount * factor - m.amount * m.factor
}

public int getMoney(){
   return amount;
}

public int getCurrency(){
  return factor;
}

}

public class Cent extends Money{

public Cent(int amount){
  super(amount, 1);
}


public String toString(){
  return Integer.toString(amount) + "C";
}

}

public class Dollar extends Money{

    public Dollar (int amount){
        // here you can also calculate the currency 
        super(amount,100);
    }

    public String toString(){
      return Integer.toString(amount) + "$"; 
    }
}

open house architecture development in jee

Hi All,
I would like to thank all of you that came to our open house yesterday, mainly to oded who give the lecture about devlopment considerations and deployment in jee. you can find the oded's presentation here , i hope to see you again in our next open house. if you have any comments or topics to raise you are more than wellcome to send me mail or send a reply to my mail.

concurrency in jdk 7

Hi All,
sorry for the late response, now you can see the presentation of the open house: concurrency in JDK 7 here, i hope you enjoy it, and i will love to see you again in our next open houses.

The internal implementation of the allocate reference

I am now exploring the idea that allocates reference will be implemented as a new type of reference like soft, weak and phantom reference. it looks like allocate reference are completely the opposite of phantom reference since the get method can't return null. the idea is that every declaration of String $moshe will be translated to the following: AllocateReference moshe when the 'get' method return the value of moshe. this one is very useful since you can extend the allocate reference and customize allocate reference for your own needs. The only question is the preformence issue. Is anyone knows what is the performance penalty for using references?