Current IT Scenario
The current IT market is characterized by a fast change. Many different issues are bringing great complexity. Among them we can mention the need for multi-tenancy and cloud platforms. These new paradigms require more sophisticated instruments to implement solutions at an effective production pace. Some issues in the software lifecycle must be dealt with new processes and methodologies, other are more focused on tools. When it comes to discuss about tools, we have a lot of choices among frameworks and middleware. But what about the Java core? Is the language itself fully fitted for the current IT market and for the near future?
New Java core capabilities
If we look at the latest Java releases, until Java 8, we see that some new features have been implemented. Among the main features the Generic Programming and the Functional Programming deserve a special attention. They fill a gap in the development world and let Java keep the pace with other technologies. In the following two paragraphs we summarized the two.
Generic programming can be defined in a simple way as a style of computer programming in which algorithms are written in terms of types that can be specified parametrically. Generic programming provides a different concept of reuse than general object oriented paradigm: when a set of classes have the same behavior and data structure and differ only in types there is the opportunity to exploit the features of generic programming. Generic programming provides a way to define reuse that is complementary to the usual Object Oriented programming, it is based more on templating than on inheritance and other OO concepts.
Giving a precise and definitive definition of Functional programming is not so easy as most of the literature on the subject lack any formal approach and scatters across a variety of different descriptions. As a Object-Oriented programming (OOP) language, Java was originally designed to primarily support the standard imperative (procedural) programming. With imperative programming the code is written in such a way that describes in exact detail the steps to accomplish a task. We can also call this algorithmic programming. In this style of programming some information must be stored in a shared manner. Functional programming avoids to put status information in ‘external’ variables and instead consists in composing a problem as a set of self-contained functions to be executed. Each function has an input return an output and the output of one function could the input of another one. There is no storing of whatsoever status information in the run. We can say that functional approach is focused not on how to perform tasks (algorithms) but on what information and what transformations are required to obtained that information. Even if Java is not a pure functional language it has introduced it by the use of Streams and Lambda functions. That lacks of the performance power of a pure language but gives the opportunity to approach specific problem with a more robust and less error prone approach.
Is that enough?
The support for Generic and functional programming are certainly of great importance and cover programming issues that otherwise should be addressed outside the scope of Java stack technologies, but there are also other issues that are lacking a sufficient support. JEE offers in some way a standard and following standards is a good thing, but its releases follow a very large timeframe, you have to wait years to have something new which is not in touch with the rapid growth of new requirements from the IT world. The new IT tendencies are toward SaaS and cloud paradigms, which require highly configurable systems. Many software features need to be configured dynamically in a programmatic way. Designing the solutions as plugin oriented ones is a must, and is also a must that the components could be to dynamically installed and uninstalled. Dealing with these issues requires the use of some underlying framework that must be robust, flexible, maintainable and as standard as possible. The OSGi technology was meant to be a standard to cope with these requirements, but is it really a viable solution?
OSGi is a standard developed by the Java IT industry aimed at implementing dynamic modular systems. It can deal with components that can be installed, started, stopped and uninstalled on the fly, without affecting the whole application server lifecycle, and it also maintains a registry that can adapt accordingly to the components installation state. The main drawback is that its implementations are somewhat heavy-weight and complex, they not fit well with other frameworks (Spring, Struts…) and they require a specific running environment on application server side. It is definitely not a lightweight solutions. It addresses the problem to deal with highly dynamic, components based systems, but it imposes too many constraints on the overall software ecosystem. The only possibility that it could have to gain success in the future would be if all the application server vendors would be turned into considering it a definitive standard. But normally the software frameworks have really success if they fit well with world and not if the world fit well with them. All the crucial features that the IT market requires should be addressed by the Java core platform in the first place and leave to the external frameworks only the burden of the high level stuff.
Java Core And Dynamic Class Loading
The main problem in developing lightweight solutions lies in the lack of support from the Java core itself. Java classes can be loaded dynamically by the use of the Class Loader architecture, but when it comes to load and unload classes on the fly, it is not so straightforward and a special attention is required. Furthermore the things become more complex if we must deal not just with the lifecycle of single classes but with bundles of classes as a whole (as jar libraries for instance). There is no reliable mechanism to deal with this. And also there is no support to handle and share different versions of the same library on the virtual machine, something like the Global Assembly Cache of the .NET platform, for instance. It is frankly difficult to understand why this has not deserved any attention in the latest releases of Java, since the overcome of this limitation would be a great impulse to address even that web applications market segment that is up to now almost fully owned by dynamic language platforms like PHP.
The lack of a support for the reliable handling of dynamic loading and unloading of class bundles in the Java core and their versioning represents a great obstacle to the growth of mature and flexible solution based on Java Stack in the new IT scenarios based on highly dynamically configurable systems. If the future releases of java core will fill this gap, heavy implementations like OSGi will lose importance and there will be much more room for light and extensible implementations.