10 reasons for leaving Java to find a better language

Don't misunderstand. In fact, in my career, I have already compiled countless Java code, and I still think that Java is a great (Program) language. Compared with C ++ and smalltack, Java has made great improvements. But now, even Java has begun to feel its 15-year product weight.

In fact, in my experience, I always have to face some errors, defects, and deficiencies in Java design and specifications. These things make my Java programmer have little fun.

Now there are millions of Java programmers around the world, and hundreds of millions of lines of code are written in Java. If I say that Java will die in the near future, it is still a little far away. In any case, with the advent of JVM-compatible languages (Scala), these problems become increasingly intolerable. I started to think, it is time to slowly leave Java (but not JVM ).

Specifically, I think the top 10 problems of the Java language are:

1. Closure is missing ):

I don't need to explain this. Functional programming has been around for decades, but in recent years they have gained more and more attention. The main reason is that it can naturally write parallel programs.

I partially agree that Joshua Bloch emphasizes that the introduction of closures in Java requires another thought (the approach proposed by bgga is really bad), at least the lack of closures, this makes it impossible to do any real functional programming in Java.

2. The first-class function is missing:

This problem is related to the previous one, but I think it is worse.

In Java, the only way to achieve similar results is to use the famous, ugly, miserable, single-method anonymous internal class, but this looks indeed a poor method. Even in C #, the proxy mechanism provides a better implementation.

3. Native type (primitive types ):

If everything is an object in Java, how perfect it is, but they are not designed like this. Therefore, this leads to some problems. For example, you cannot put an int in a collection. This is solved in Java 5 through the automatic packing feature (as mentioned below ).

It also causes the trouble of passing values and references. Native data is transmitted to the method through values (copying a copy and then passing it to the function ), the real object is transmitted by copying the object address, so it should also be passed the value, but because the function can access the object through this object address internally, therefore, the effect is similar to the transfer reference ).

4. autoboxing and autounboxing ):

This feature was introduced in Java 5 to solve problems caused by the existence of native types. It allows silent conversion of native types to corresponding objects, but this often leads to other problems.

For example, the integer value can be null, but the int value cannot. Therefore, the JVM can only throw a null pointer exception (nullpointerexception) that is difficult to debug ).

In addition, it may lead to other strange behaviors. As in the following example, it is hard to understand why the variable test is false:

Intger a = new Integer(1024);Intger b = new Integer(1024);boolean test = a < b || a == b || a > b;

5. Lack of fan-type classification:

Fan type is a cool feature introduced by Java 5. However, to maintain compatibility with earlier versions of Java, some important features are missing, especially the type of fan type cannot be reflected at runtime.

For example, you have a method that accepts the list parameter. If a list is passed in, you cannot know the exact type of the model in the running. Similarly, you cannot create a fan array. This means that although the following code looks natural, it cannot be compiled:?>

List<String>[] listsOfStrings = new List<String>[3];

6. Unavoidable fan warning:

Have you ever found yourself stuck in a warning about the model that cannot be removed? If you use a large number of models like me, I bet you have met.

In fact, it is the scale symptom of this problem, which makes them think that a specific annotation (@ suppresswarnings ("unchecked") needs to be introduced to deal with this situation, I think, the model should be designed better.

7. You cannot pass the void to the method call:

I have to admit that this requirement for passing void to the method is a bit weird at first glance.

I like DSL. When I implement a specific feature of my DSL Library (lambdaj), I have to declare a signature like void dosomething (object parameter ), here the parameter passed in for this method is the result of another method call. Its unique purpose is to register the call (object) itself so that it can be executed later.

To my surprise, even if the println method returns void, it seems that there is no good reason for me to write the code as follows ,:

doSomething(System.out.println("test"));

8. There is no native proxy mechanism:

Proxy is a very effective and widely used mode, but the proxy mechanism provided by Java is only for interfaces rather than specific classes.

This is why libraries such as cblib provide such a mechanism are adopted by so many mainstream frameworks, such as spring and hibernate.

Besides, cglib is implemented by creating a subclass of the proxy class at runtime. Therefore, these methods have a well-known restriction-they cannot proxy final classes, such as string.

9. Poor switch... Case statement:

Java rules, switch... Only int and enum can be selected for case (start from Java 5 ). This seems too weak if compared to a more modern language such as Scala.

10. Checked exception ):

Similar to the native type, the checked exceptions have become a sin source of Java.

It forces programmers to do one of the following two terrible and annoying tasks: flooding your code with lots of bad, hard-to-read, error-prone try... Catch statement, and the biggest significance of doing so is to wrap the caught exception into a runtime exception and then throw it again; or let a large number of throwing declaration clauses pollute your API, lack of flexibility and scalability for interfaces.

The real problem is that the only solution to these major problems I mentioned here is to make a painful decision and define a new set of language specifications, release the backward compatibility of the current version.

I guess they will never do that, although I believe it is not very difficult to write a program that can automatically convert the old Java source code to make them compatible with the new version of the assumption. Finally, this is why I decided to start looking for a better JVM compatible language.

NoteSee the original TSS http://www.theserverside.com/news/thread.tss? Thread_id = 55185, I feel that the author still says something.

Http://justjavac.com/java/2012/04/18/beyond-java-find-10-better-language/