Upgrade from a language to a platform: Java is old, is it okay?

Java originated from a set-top box project in 1991, and Sun released version 1995 in 1.0. It may take 20 years to calculate it. Jdk1.3 --> jdk1.4 --> the two version upgrades of jdk5 have greatly improved the Java language. However, since then, jdk6 and jdk7 have not yet been officially released, which has not given many surprises, at least that's how I feel. In fact, in the past few years, the JVM compatibility language has been shown in the beginning: the status of Java on the JVM platform is facing increasingly serious challenges.

JDK 6 to JDK 7 has a span of more than four years, and the new features are not so exciting (as opposed to the expectations of the community and the rapid development of dynamic languages), closures (closure) it was originally a feature of 10 thousand expectations and was abandoned after fierce debate.

More and more people are beginning to worry about the future of Java. I think it may be a matter of time for Java to lose the status of number one on JVM, but we should not forget, this somewhat old-fashioned Java was once brilliant, as well as its compatibility burden.

For each progressive version of Java, the language compatibility, platform compatibility, and porting compatibility of previous versions must be considered.
Language compability ensures that the meaning of the existing lexical and syntax remains unchanged in the new version; platform compability ensures the APIS provided by the new version (such as Java. util/Java. io) is consistent with the existing version, the original program is not modified, and can be run on the new platform, and the behavior is consistent; migration compatibility (Migration compability ), it requires that the original program can be gradually migrated to the new platform, rather than the relevant modules must be changed. Taking generics as an example, if two modules do not support generics, use collections for Data Interaction. After one module is upgraded to support generics, it will not affect another module.

In fact, it is not just java. Any software system will gradually become bloated with more and more plug-in functions, because no architect has the ability to predict the future in a long term. The classic concept of C is that its language features are simple and time-stable. To add generics, closures, and garbage collection to C, C is no longer C, but C #.

However, for developers, I think there is no need to be pessimistic or doubt the future of Java, or to be precise, do not doubt the future of JVM, java is switching from a language to a platform ). The Java 7 virtual machine has added support for multiple dynamic programming languages, and fully demonstrates Sun (or Oracle)'s intention: Java is not the only language, and Java is not the opposite of other JVM compatible languages, the more languages the platform has, the better.

However, developers should also make appropriate adjustments, that is, they should focus on JVM specifications and other language features. Since there are more choices, we should also give full play to the strengths of various languages and use appropriate technologies to do the right thing.

 

Maybe in a few years, we will pay more attention to the JVM version instead of the Java version. The Java language may become a reference implementation, just like glassfish in J2EE; or, we can seamlessly integrate various Java/groovy/Scala languages into a single source file (just like JSP and HTML.

 

The future is always beautiful. What do you think?

 

Thank you for making a brick!

 

 

 

 

 

The following information is from Wiki and is applicable to various JVM languages.:

JVM implementations of existing languages ages

Language	Java implementations
ADA	Jgnat
Awk	Jawk[2]
C	C to Java Virtual Machine Compilers[3]
Common LISP	Armed bear Common LISP[4] Clforjava Jatha (Common LISP)
Forth	Myforth[5]
Haskell	Jaskell[6]
Javascript	Rhino
Logo	Jlogo[7] Xlogo[8]
Lua	Kahlua[9]
Objective caml (ocaml)	Ocaml-Java[10]
Pascal	Component Pascal
PHP	IBM WebSphere smash PHP (P8)[11] Caucho Quercus[12]
Python	Jython
Rexx	IBM netrexx
Ruby	Jruby
Scheme	Bigloo Kawa SISC Jscheme
TCL	Java TCL

New JVM ages

• Aspectj, an aspect-oriented extension for the Java programming language.
• Beanshell, a scripting language whose syntax is close to Java.
• Duby^{[13], a customizable programming language featuring type inference and a heavily ruby-converted red syntax.}
• The E programming language has an implementation on the JVM.
• Fan^{[14], a language built from the ground-up to be portable guest ss the JVM and the. net clr.}
• Fortress, a language designed by Sun as a successor to Fortran.
• Frink, a language that tracks units of measure through calculations.
• Hecl
• Ioke, a prototype-based language somewhat reminiscent of Io, with similarities to Ruby, LISP and smalltalk.
• Join Java, A extends Java with the join semantics of the join calculus.
• Jelly (programming language)
• Joy
• Judoscript.
• N. A.M. E. Basic.
• Netlogo, a multi-agent programming language.
• Nice.
• Noop, a language built with testability as a major focus.
• Objectscript
• Pizza, a superset of Java with function pointers and algebraic data types.
• Pnuts.
• Cal, A Haskell-converted red functional programming language.
• Sleep, a procedural scripting language written red by Perl and objective-C.
• The V Programming Language^{[15] has an implementation on the JVM.}