Welcome!

Microservices Expo Authors: Stackify Blog, Aruna Ravichandran, Dalibor Siroky, Kevin Jackson, PagerDuty Blog

Related Topics: Java IoT, SYS-CON MEDIA

Java IoT: Article

i-Technology Viewpoint: Java's Not Evolving Fast Enough

Do Strongly Typed APIs Help Ensure Java's Survival or Extinction, Asks Java Developer's Journal's Joe Winchester

A programming API represents a documented contract between a function that provides some kind of computing service and those who wish to use it. In Java, once an API is used there is a physical contract between the two that the compiler and JVM enforce. If at some point in the future the author of the API wishes to make changes, they are limited in scope; if the author renames methods or removes arguments, programs that are bound to the previous signature will no longer run. The change can be published with the new version of the class library or framework so that users can upgrade their code; however, in many cases this isn't a viable option. It may be that the system that used the old API is no longer being worked on by a development team and is considered stable, or that the release cycle of the now broken system is dependent on other circumstances that prevent it from being upgraded.

No API can be got right the first time, irrespective of how many specifications, architecture meetings, and examples take place prior to its release. The whole idea of launching a set of class libraries and Javadocs onto the world as being the eternal way of doing something goes against the whole philosophy of agile programming. One of the principles of extreme programming is that a good program is built flexibly and in a fluid state; at each stage the feedback loop of usage and reconstruction means that the right solution is arrived at by accident rather than by design. This is akin to evolution, whereby variations in a species arise by random mutation and are mixed in offspring to create new individuals. The fittest varieties survive whatever the environment provides and the cycle continues, allowing the species to adapt and evolve.

The Java language has maintained its API over many releases so a program that is compiled on 1.2 will run unchanged on a Java 5 runtime environment The benefit of this is that older Java programs remain functional on modern JREs; however, it comes at a price. The language now contains a plethora of deprecated classes and methods, new features are sometimes sacrificed to ensure backward compatibility, and the evolution of Java is hindered and held back. The class java.util.Date, for example, has more public deprecated methods than non-deprecated ones. Not a lot has changed in the domain model of Dates since the Gregorian calendar was introduced in 1582, and this ratio of legacy to current API is a sign that code change is a natural flux that occurs during its usage.

In nature the extinction of a species is not a gradual thing but comes in waves. Punctuated Equilibrium describes an effect whereby the environment remains fairly static for a while and then a huge amount of change occurs in a small amount of time. These boundaries are mass extinctions that not only cause many species to die out, but are also the event that allows others to flourish and fill the void left by the departing ones. To a certain extent Java benefited from this back in 1995, when it was born out of a combination of the best ideas of C++ and Smalltalk; the catastrophic meteorite striking at the time being the Internet and demand for heterogeneous networked computing.

What worries me 10 years later is that I don't believe Java is evolving fast enough, and that strong typing to antiquated APIs are holding it back. XML won over a slew of competing technologies for program-to-program communication transport because it is text based, allowing it to be read by heterogeneous end points (as opposed to alternatives like CORBA IDL or other binary RPCs). XML is also flexible in its typing, because tags can be declared as optional and new tags can be introduced in a message without breaking callers using the older format. While Java has done well as an enterprise language in the application server space, this is largely due to the fact that the big names of IT backed it rather than any inherent feature of the language. Languages such as Ruby and Perl have grown tremendously in the past few years and now command a sizeable portion of application development.

If Java is to remain at the forefront of technology for the next 10 years, it must find a better way to evolve. It needs to find a way of decoupling API calls between internal code and external blocks, perhaps even introducing soft typing calls across program boundaries or having flexible message transport across modules. While XML parsing functionality is now included in a Java runtime by default, it feels very shoehorned into place when compared with how .NET has done the same integration. Older languages like COBOL or RPG, as well as Visual Basic, include the concept of structures into a program definition that can be externalized, and having Java include a slew of JARs and runtime bolt ons to do simple XML parsing seems a missed opportunity to embrace the technology.

Becoming strong enough to do battle with Microsoft, the T-Rex of computing, may have fared well for Java in the past, but at the expense of what it has now become and how quickly it can keep up with change and the legacy it has created. I fear that unless a fundamental change to the language is made that allows more flexibility in binding between functional units, between and across JVM boundaries, Java will be a victim of the same fate as the behemoths it fights in the IT tar pit. Survival against change - whether in nature, technology, or business - is determined by ones ability to adapt. Java needs to move forward by being more agile. As the language grows with more and more APIs and divisions, it runs the risk of losing sight of the finish line, while smaller and nimbler technologies become more ubiquitous. When the next IT meteor strikes, Java must be the fastest to adapt if it is to survive and grow over the next 10 years.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (12) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Byron Estes 01/12/06 01:10:10 PM EST

I wonder if this discussion might be more productive if someone offered a particular concrete situation they encountered that reflects the limitations that they feel are holding Java back. If the author reads this, I would call on him to supply a specific instance that would allow us to get away from opinions, and rhetoric. Discussing an example in this way (...more likely a series of examples) will probably help us get closer to understanding each others points. Given that understanding we could then expand back out to more broader discussion of he subject. Thoughts?

mel martinez 01/12/06 12:56:12 AM EST

I personally kind of hate comparisons between XML and Java. They are two totally different kinds of tools that are used in totally different ways. To suggest that XML (a spectrum of markup languages) is somehow 'more flexible' than Java (an OO programming language) is meaningless. They are both flexible and both rigid in totally different ways. An xml schema can be just as rigid and inflexible in the face of future changes as a strongly typed java interface signature. The correlary to the deprecated method in a java api is a long list of 'optional' attributes in a tag definition. I would suggest that the vast majority of problems that 'limit flexibility' in Java (or any programming language) have more to do with design patterns - too many anti-patterns and not enough use of good patterns. That is not to say that there could not be differences in the language that would help encourage good patterns and discourage falling into bad patterns. But even without fundamental changes to the language, much of that could be achieved through better development tools that better guard the developer from falling into anti-pattern traps and encourage the use of good patterns that facilitate future flexibility.

Joe Winchester 01/11/06 07:05:13 PM EST

The point about strong typing vs. weak typing is not trying to bring back memory spaces as a way of passing program arguments. Typing is good for the compiler, however it is too inflexible. XML has a benfit in its design which is that the data and the meaning of the data are combined, so it can be partially complete, pieces ignored by the receipient if it doesn't understand it. I'm not advocating XML as a transport between Java program modules, I just think we need something less brittle than what we have now that can't accomodate change. This is similar to how the Java XMLEncoder is superior to binary serialization, because it can deal with updates without everything breaking

mel martinez 01/10/06 06:46:49 PM EST

Somehow, I doubt it is the fact that java is a strongly typed language will be the determining factor in its long-term success. There are much bigger issues, primarily whether java is percieved by customers to be an appropriate tool for the solution of their real world problems. The number of deprecated calls in some of the APIs does not in my experience jump to the forefront of things to consider when comparing development tools and languages. Yes, it is symptomatic of some things that are going on, but it isn't imho a deal breaker with most folks. The fact is, the quality of development tools available and the ubiquity of experience of developers with a language and the associated tools will tend to be the predominant factors. I'm not saying here that java is destined to succeed (whatever that means) or not with or without faster adoption of changes. I just don't think that strongly typed signatures are the major negative issue the article makes them out to be. There are, after all, real benefits to a strongly typed language.

Gary Renner 01/10/06 04:42:10 PM EST

I could not disagree more with this article. Maybe you have to be as old as I am to remember the days before strong type checking. The lack of strong type checking in assembler, c and basic lead to very slow development process due to bugs that would have easily been detected in java, Modula 2, or Pascal. To me, you are advocating a change back to the bad old days. Elimination of strong type checking will not solve the problem of brittleness of code. Even eliminating type checking completely will not solve the real issues that impede software state of the art. To reach the next state in software development, we have to be able to stand on previous developers shoulders - that means reusability and modularity. What is the biggest impediment to reusability? From my perspective, it is the proliferation of computer languages. How many times do we have to spend software $ rewriting quicksort when we could be using those dollars to write more intelligent database management systems?

You mention XML as a positive thing because it is text based. That would only be true if their were fewer character sets than there are representations for fundamental types like float and integer. Last time I looked, this was not the case. The number of character sets is roughly the number of standards (ascii, ebcdic, unicode, etc.) times the number of languages (english, japanese, etc.) - there is plenty of room for lack of compatibility and brittleness in the XML world. Also, XML only addresses a very limited universe: fundamental data types. It does not deal with: semantics, complex objects (e.g. multimedia), mobile code, security, inheritance etc and most of all, performance. I see XML as negative evolution because these problems are already solved in JVM byte code. To call XML portable would be to mis-characterize it - the standards and tooling are so complex, they really exist on only 2 platforms: Java and .net. Even those platforms are not exactly compatible.

Jim Babka 01/10/06 01:45:28 PM EST

At some point in the evolution of any API, you hear someone calling for a do-over. They say, "it's too hard to evolve," or "nobody uses those methods anymore." While there might be the best of reasons for changing, incompatible changes to any API cause much more confusion and strife than living within the boundaries of compatibility.

If such a thing occurred to Java, it would kill the language. All the new cool features would go into "Java 3", while the entire corporate world stayed on Java 2, and thus the tools would also remain on Java 2 (it's a chicken-and-egg problem that we've seen numerous times before). Eventually, anyone who got fed up with the lack of new features in Java 2 would decide to move to a new language, and the lack of tools for Java 3 would be a big strike against it.

No, painful as it sometimes is, compatibility must be preserved. Once you decide you can break compatibility, you fracture the entire user landscape, and Java can't afford that.

Byron Estes 01/10/06 01:04:39 PM EST

Certainly, maintaining interfaces that supply services to support many applications is not easy and they do evolve over time. This form of distributed computing has advantages that do not come without a cost, but I would contend that the problems the author of this article is citing are as much or more a problem with how we design the interfaces as they are with the implementation. I agree, that you'll never get the interface right the first time and yes it will most certainly change over time. What I am talking about is tight cohesion and loose coupling. Nothing magical, but not always practiced. My experience has been that as long as you keep the services loosely coupled and start with some flexible command pattern super classes, that you can deal with lots of these issues. Is it perfect, no. I still, however, remember the headaches and hard to find runtime bugs that can be introduced through a lack of strong data typing and the use of pointers to blocks of memory. I have programmed in everything from mainframe assembler to Java (...and .NET). I still would rather use it than other language/platform I've ever encountered.

Yakov Fain 01/09/06 09:11:50 AM EST

>The class java.util.Date, for example, has more public deprecated methods than non-deprecated ones.

IMHO, Sun should come up with a light-footprint version of JVM that does not support deprecated version of methods. This JVM should not replace the existing one, but present an option to the recently developed Java applications

DoubtingThomas 01/09/06 07:03:39 AM EST

If Apple couldn't withstand the digital gottedamerung that is Microsoft, then what makes anyone think that Java can?

rolsen 01/09/06 06:55:12 AM EST

Rhe buzz at the last software conference I attended, a conference previously full of Java developers and talk, was all about Ruby. The web is filling up with talk about the R word. Yesterday an old friend of mine IM'ed me to say that he had a new job and his boss wants him to do this Rails thing and did I think it was for real.

Not Gone Yet 01/09/06 06:40:43 AM EST

>> Survival against change - whether in nature,
>> technology, or business - is determined by one's
>> ability to adapt. Java needs to move forward by
>> being more agile

Java's popularity might be declining, but the concept of its JVM sure isn't. And I'll be using Java for a considerable amount of time in the future anyway.

queZZtion 01/09/06 06:32:07 AM EST

||| If Java is to remain at the forefront of technology for the next 10 years, it ... needs to find a way of decoupling API calls between internal code and external blocks, perhaps even introducing soft typing calls across program boundaries or having flexible message transport across modules. |||

It will be interesting to see what Sun itself has to say in response to this. I am assuming JDJ has invited a response?

@MicroservicesExpo Stories
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
The Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.