devopsy.kinsta.cloud

Tag: java

  • Convert COBOL Easily? Yes, Please!

    Convert COBOL Easily? Yes, Please!

    I was reading Mike Vizard’s article about IBM previewing an AI tool to convert COBOL to Java and mentally cheered this move. No, seriously—massively cheered this move.

    There are a lot of uses of large language models (LLM) right now, and many of them are not all that exciting, in my opinion. This one, though? This is huge. In the course of my career, I have been involved in three projects to convert COBOL and one to convert FORTRAN, with some projects that required interfacing with RPG III systems. In all of these cases, the costs were prohibitive. Two of the three COBOL projects never made it past estimates because the cost of resources who know both COBOL and Java were prohibitive, as is the complexity of most mainframe applications as they were modified over the years. The Fortran project never got past resourcing, and the RPG III interfaces were just that. We had to pull the data as it was presented by RPG III systems and only act on our copy, with a separate process used to update the core systems. Why? Because modifying the RPG was impractical, but we could be agile. It was … painful, to put it mildly.

    What all of these projects shared was the lack of a skilled workforce. And what IBM is offering is an LLM that acts as that workforce. If you get the application into Java, there is a large pool of developers that can then troubleshoot it. While the environment issues will still exist and people skilled in tools like JCL are increasingly hard to find, that part can be rebuilt in the new environment. (One question I have about IBM’s project is, “Can it convert to Java for a Linux LPAR/VM?” I suspect that this iteration converts within z/OS, but it would be cool to see increased options in the future.)

    Honestly, this trend will only increase. While IBM’s use of LLM is aimed at moving COBOL to Java, there are an incredible number of lines of Java out there to train on, so soon enough, there will be other conversions in and out of Java. And that’s all good news. We recreate the wheel a lot. The longer-term implication of AI-assisted conversion is that we won’t have to. Think about it: We could feed in a mathematical routine in Fortran and get the language of our choice out the other side.

    Way back in the day, a collection of compilers named TopSpeed let you develop in any of several languages, even mixing and matching to create applications that used each language (and developer) for their strengths. This is the TopSpeed dream writ large. (Disclaimer: I was a huge TopSpeed fan. Bought their intro kit and wrote systems mixing C/Pascal/ASM without having to mess with things like parameter sequences. Yeah, I was cool.)

    We have had too few developers for a very long time. Now, we are about to have a world where developers can focus on truly unique functionality, and the rest is generated based on the mass of implementations we already have. Think in terms of sorting algorithms—99% of the sorting problems out there were mastered decades ago, and yet we frequently see people re-implementing, even today. Now we can tell a system, “Generate a tree sort,” and just make calls. Every time we implement a new language, this type of thing has to be re-implemented, and often it is re-implemented because we don’t know about the available solutions. In the future, we will have solutions at our fingertips.

    And as with the other benefits of automation, we’ll do less busy work and add more business value. While there will be some pain, I think in the long term that is a huge benefit. And you’ll still be there, making things go zoom.

  • IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM Previews Generative AI Tool for Converting COBOL to Java

    IBM this week announced it will preview a generative artificial intelligence (AI) tool for converting COBOL code running on mainframes into Java. The preview will be available next month during IBM’s TechXchange learning event, IBM said.

    Kyle Charlet, CTO for Z software at IBM, said watsonx Code Assistant for Z makes use of large language models (LLMs) that IBM has trained to both convert and optimize Java code for z/OS running on IBM mainframes.

    Rather than converting COBOL into Java code line for line, the watsonx Code Assistant for Z improves the syntax of Java code generated using object-oriented techniques, he noted.

    IBM’s watsonx.ai code model, which will have knowledge of 115 coding languages, is based on 20 billion parameters that will eventually be applied to other programming languages such as PL/1, added Charlet.

    That model is the same core LLM that IBM used to create Red Hat Ansible Lightspeed, a tool to generate code for an IT automation framework that is scheduled for release later this year. In the future, IBM will also most likely employ generative AI to convert REXX code into Ansible code, said Charlet.

    IBM expects the final offering will combine generative AI tools with its existing Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool to streamline the modernization of legacy mainframe applications.

    The goal, however, is not to move COBOL applications off the mainframe. Java applications created using watsonx Code Assistant for Z will still call the same data sources, such as an IMS database or CICS transaction processing system, as the original COBOL application.

    That approach will make mainframes more accessible to a wider pool of developers that know Java, which should increase the overall pace of innovation for application development, noted Charlet.

    There are billions of lines of COBOL code currently running on mainframes that, in one way or another, need to be modernized as the pool of developers that know COBOL continues to shrink. Generative AI will make it easier to quickly assess, update, validate and test code, which should accelerate code conversion efforts that otherwise would take years to complete, said Charlet.

    It’s not clear how quickly organizations might move to modernize COBOL applications, but as the time and effort to do so decreases, so should the cost of modernizing legacy code. Most organizations still running z/OS on mainframes are committed to the platform, but if they can transition to Java, the overall cost of building and maintaining mainframe applications should decline.

    In the meantime, it’s not likely that AI will replace developers. IBM recommends that developers further optimize the Java code generated by watsonx Code Assistant for Z.

    Most developers are already using some form of AI to accelerate application development. The next wave of AI will see more widespread use of LLMs that are optimized for specific tasks and that generate more reliable results. After all, the quality of any output from an AI model is always directly related to the quality of the data used to train it. The narrower the set of vetted data, the more trustworthy the AI becomes—the opportunity for erroneous data to create AI hallucinations is a whole lot less than any general-purpose AI model could achieve with customization.

  • VMware Previews Spring AI to Accelerate Java Development

    VMware Previews Spring AI to Accelerate Java Development

    At a SpringOne at VMware Explore event this week, VMware demonstrated a tool that uses abstractions to make it simpler to build Java applications that invoke multiple artificial intelligence (AI) components with minimal changes to code.

    The goal for the open source Spring AI project is to, for example, make it simpler to swap out AI models using an AiClient interface for invoking OpenAI and Azure OpenAI services. It also adds capabilities that promise to make it simpler for developers to query documentation using generative AI enabled by large language models (LLMs). An additional goal is to extend those capabilities to other Spring projects, including Spring Integration, Spring Batch and Spring Data.

    In addition, the Spring command line interface (CLI) has been extended to support Spring AI and the Spring Boot framework has been extended to help set up dependencies and classes more easily.

    The AI capabilities are part of several additions made to the widely used framework for building Java applications that address everything from automatically turning off instances of Spring running in a container, also known as scaling to zero, to using virtual threads to call external services in a way that reduces memory consumption.

    Those additional capabilities promise to make it more efficient to run Java applications in, for example, a cloud computing environment.

    Betty Junod, vice president of product marketing for modern applications and the Management Business Group at VMware, said generative AI capabilities should serve to make Spring more accessible by not having to click around as much to gain answers to questions.

    In general, VMware is betting that a larger percentage of the Java applications built using Spring will be deployed on the Tanzu platform the company has built on top of Kubernetes. That platform streamlines the application development process in a way that reduces the cognitive load on developers by eliminating the need to know how to work with YAML files or use Docker Compose to create containers.

    Despite the proliferation of alternatives to Java, it remains the primary programming language used by developers to build applications. The challenges involved with learning additional programming languages are high, so most developers would prefer to continue to use Java to build both monolithic and emerging cloud-native applications.

    In the meantime, AI is already widely employed to help developers write code faster. AI isn’t going to replace the need for developers, but it will increase the pace at which applications are being developed. As such, DevOps teams will soon see a significant increase in the amount of code moving through DevOps pipelines. The hope is that AI will be applied in a way that enables those DevOps teams to manage increasingly larger codebases.

    In fact, the way applications are built and deployed will drastically change now that the AI genie is out of the proverbial bottle. But it remains to be seen how quickly those advances will change the way DevOps is managed at a level of unprecedented scale.

  • IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

    IBM LLM AI: COBOL to Java ASAP ¦ ARM IPO is GO!

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Translating legacy COBOL code to a slightly more modern language, and Arm will go public (again) next month. (more…)

  • New Relic Report Surfaces Spike in Amazon JDK Usage

    New Relic Report Surfaces Spike in Amazon JDK Usage

    An analysis of the Java applications observed by New Relic showed nearly one-third of organizations (31%) are using the Amazon Java development kit (JDK) compared to 28% using the Oracle JDK as more Java applications are built and deployed in the cloud.

    The report also found the number of Java applications running in containers is remaining steady year-over-year at 70%.

    Overall, the report published last week found more than 56% of applications are now using Java 11 in production, followed by Java 8 at nearly 33%. However, more than 9% of applications are now based on Java 17, representing a 430% growth rate.

    Jemiah Sius, director of developer relations for New Relic, said it’s clear that Java 17 is starting to gain traction in production environments. This is happening at a faster rate than previous releases of the venerable programming language as more cloud-native applications based on containers are being built and deployed, noted Sius.

    Regardless of the version of Java, it doesn’t appear developers are moving away from Java as they build cloud-native applications, noted Sius. Rather than requiring developers to learn a new programming language, it’s simply been more cost-effective to enable them to continue building applications using a programming language they already know.

    Java, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under open source licenses. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications being modernized. As a result, most organizations will continue to deploy Java applications everywhere from the network edge to the cloud.

    New Relic, of course, is betting that as more cloud-native applications are deployed, the need for an observability platform that addresses the needs of developers and IT operations teams alike will become more apparent.

    In general, most organizations are still in the early stages of achieving full-stack observability. A recent New Relic survey found only 27% of respondents have achieved full-stack observability and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.

    On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    The expectation is that that augmenting DevOps teams with observability tools and platforms that are increasingly being infused with artificial intelligence (AI) will reduce outages, even as cloud-native applications make IT environments even more complex than they already are. The issue is, however, those application environments are becoming more complex at a rate that is far exceeding the pace at which observability platforms are currently being adopted.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Monster.com

    Ace American Insurance Company (Chubb)
    Philadelphia, Pennsylvania
    DevOps Engineer
    $157,477 to $172,000

    LinkedIn

    DRISHTICON
    Mountain View, California
    Senior DevOps Engineer
    $120,000 to $150,000

    Dice.com

    Srivango Technologies
    Cary, North Carolina
    Java Developer with Azure and DevOps Expertise
    $120,000 to $140,000

    Indeed

    The Coca-Cola Company
    Atlanta, Georgia
    Cloud DevOps Engineer
    $102,00o to $109,000

    SimplyHired

    Moody’s
    Remote
    DevOps Engineer
    $90,000 to $159,300

  • Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    This is perhaps the toughest issue for all of us to acknowledge: The longer you are in the space, the more skills you have filled out on LinkedIn (or wherever you are tracking your career for HR reps to look at) but the skills you possess today are, by definition, a subset of the skills you will possess even a couple of months from now if you change roles. Note that I said “change roles,” not “change employers.” The fact is that we use an insane number of tools in the development, DevOps and operations environments, and we’re addicted to adding new ones (that might be a hint about part three of this series). Changing roles within a company can involve minor changes, or it can take you to a whole new environment where no one cares that you are a Java genius; they want to know how fast you can pick up Python and be truly productive. Or they nod at your talk of configuring servers and ask if you can do that with Ansible on containers. It’s just not as important anymore for most employees to have a specific skillset. That’s a major contributor to the problems I talked about in part one.

    Of course, there are roles in IT that involve far less change. Email administration, for example, isn’t all that different from the way it has been since, well, forever. We have changed how/where the server is configured and many orgs have added SSO or multifactor authentication, creating new issues, but it’s all evolutionary. When NoSQL systems came out, it looked like a major change in DBA work, but it really wasn’t. Within a year, reality put SQL over top of NoSQL stores and DBAs kept chugging along.

    But DevOps has impacted both development and operations in profound ways. We pretty much standardized on Java, with all of its warts, because it was object oriented, general purpose and could be compiled if needed. Though embedded largely stayed with C, there was no serious competition in the enterprise for Java and Java-like (.NET) languages. Knowing them meant you could do everything but real-time/embedded development jobs—and even some embedded work shifted to Java as prices for miniaturized compute power dropped.

    But that changed. The inflection point was JavaScript, and from there, we went a little bit crazy. When JavaScript took off, full-stack developers needed to know one front-end and a couple of backend languages. Other languages still existed—the staying power of both Perl and PHP is somewhat surprising to me; they’re both good languages but have limitations. But still, no serious competition. But Node.js took JavaScript to the server, Ruby was popular for backends, Python came along for quick scripting … And now we have apps written in those and a dozen more languages floating around.

    I chose languages to fit the whole story into a blog because they see less change than the operations side, where we’ve gone from annual big releases to rolling deployments updated frequently and all the support tools changed in the process. Infrastructure has changed, data stores have changed, mobility has changed, UI targets have changed—basically, it’s a chaotic mess.

    And you’re in the heart of it, keeping the data flowing and the org running. It’s astounding, and you deserve more kudos than you’re likely getting. So approach hiring differently. Some orgs are already there, but skill-based hiring is still too prevalent. Hire broad technical knowledge and a desire to know more. As someone I know honestly said in a job interview once, “No, I never used it, but it is just another programming language. I’ll be productive in a week.” She got the job and delivered as promised. For all but those few corner-case roles, hire for potential and achievements and skills will follow.

  • Oracle Makes Java 20 Platform Generally Available

    Oracle Makes Java 20 Platform Generally Available

    At an Oracle DevLive Level Up event, Oracle today announced the availability of a Java 20 update that makes a range of innovations more accessible to application development teams.

    Georges Saab, senior vice president of development for the Java Platform and chair of the OpenJDK Governing Board for Oracle, said the latest version of the venerable programming language builds on previous extensions made to the Java development kit (JDK) that exemplify how the pace of Java innovation is now increasing.

    Specifically, seven JDK Enhancement Proposals (JEPs) are now supported in Java 20, including OpenJDK project Amber for record patterns and pattern matching for switch expressions and statements; enhancements from OpenJDK Project Panama to interconnect Java Virtual Machines (JVMs), features related to Project Loom that streamline the process of writing, maintaining and observing high-throughput, concurrent applications and a Function & Memory application programming interface (API) and Vector API.

    Oracle also revealed Java 20 is supported by Java Management Service, an Oracle Cloud Infrastructure (OCI) native service that provides a single pane of glass to help organizations manage Java runtimes and applications on-premises or on any cloud.

    Finally, Oracle is making available an Oracle Java Universal SE Subscription that provides access to a pay-as-you-go offering that includes entitlement to GraalVM Enterprise, the Java SE Subscription Enterprise Performance Pack, access to the advanced features of the Java Management Service and the flexibility to upgrade at any pace an organization prefers.

    Oracle Java Standard Edition (SE), GraalVM Enterprise and the Java SE Subscription Enterprise Performance Pack are also now available free of charge on OCI.

    Despite the number of programming language alternatives that exist, many enterprise IT organizations remain committed to Java. Rather than opting to retrain developers, it’s simply been more cost-effective to enable developers to continue to build applications using a programming language they already know.

    Java itself, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under an open source OpenJDK license. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications that are being modernized. As part of those efforts, the rate at which Java applications are being deployed in the cloud has substantially increased.

    As part of those efforts, many organizations are currently in the process of shifting to Java 17. It’s not clear how many organizations will skip Java 17 and jump to Java 20 from previous versions of Java, but DevOps teams should expect to be supporting a wide range of versions of Java for years to come.

    In fact, most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a programming language that has persevered through two decades and appears to have enough staying power to stick around well into the next.

  • Eclipse Foundation Touts Java SE Temurin Certification Momentum

    Eclipse Foundation Touts Java SE Temurin Certification Momentum

    The Eclipse Foundation revealed today the number of downloads for Java Standard Edition (SE)—dubbed Eclipse Temurin—certified using both a technology compatibility kit (TCK) and compatibility tests for evaluating associated runtimes reached 12.3 million in February.

    Tim Ellison, a project lead for creating compatibility tests for the Eclipse Foundation, said that level of activity suggests the governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based OpenJDK source code from multiple providers is gaining traction. Members of the Adoptium working group include Alibaba Cloud, Bloomberg, Google Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, Red Hat and Rivos. Eclipse Temurin has also become the default Java option for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    OpenJDK is a free and open source implementation of Java SE provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that allows it to run compatibility tests to ensure conformance to the Java specification.

    One of the reasons Eclipse Temurin is gaining traction is organizations are looking to reduce Java licensing costs during uncertain economic times by relying on an open source platform. At the same time, a consistent set of certified runtimes also reduces the level of DevOps friction that might otherwise be encountered when building and deploying Java applications, noted Ellison. There will, of course, always be multiple Java runtimes, but the level of incompatibility that would exist without testing them could be substantially higher, he noted.

    Despite the plethora of programming languages developers use, after more than 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Developers may be building and deploying applications faster, but most of them will continue to rely on the programming language they already know rather than master another. In addition, many of the Java applications that have been deployed over the last two decades are now being modernized within the context of a cloud migration.

    Arguably, Java is experiencing a renaissance following efforts to make it simpler for multiple organizations to contribute code to open source projects and increase the pace of innovation. The rate at which organizations can absorb that innovation will naturally vary, but it’s clear that more organizations are now running later editions of Java that improve both performance and cybersecurity overall.

    In the meantime, DevOps teams should expect to see more Java projects moving through pipelines in the months and years ahead. While not every legacy Java application may need to be updated before being retired, it’s apparent that the bulk of Java applications are still relevant. As such, it’s probable the efforts to modernize those applications will keep DevOps teams occupied well through the end of the decade.

  • More Java Apps Are Migrating to the Cloud

    More Java Apps Are Migrating to the Cloud

    A survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, found that, as part of modernization efforts, the pace at which Java applications are moving to the cloud is now accelerating.

    The survey found more than one-third (36%) of Java applications are already deployed in the public cloud. More than half of respondents (56%) are also already deploying some of their Java applications into Kubernetes or serverless environments. Nearly two-thirds (63%) said they planned to move more Java applications to the cloud over the next 24 months, the survey also found.

    Kim Weins, vice president of product and marketing at Vaadin, said the survey makes it clear that enterprise IT organizations are still highly committed to Java. Still, there is a clear shift underway in terms of where those applications are being deployed. More than a third of respondents (35%) said they have Java applications deployed on Amazon Web Services (AWS), while 22% have deployed them on the Microsoft Azure Cloud. Another 11% are running them on the Google cloud platform.

    This shift, however, will take time. Almost half (47%) of Java applications still need modernization. As a result, 63% of respondents planned to increase their investments in modernizing existing Java applications.

    Maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%), the survey found.

    The top three challenges in developing Java applications are building an intuitive and simple user interface (81%), upgrading the tech stack (81%) and ensuring app security (78%).

    There is also a shift underway in terms of the frameworks used to build and modernize applications using a more cloud-native approach. A full 70% of respondents use Spring today, but 50% also noted they are planning to increase their use of Spring Boot. Other Java frameworks used include Vaadin Flow, Quarkus, Hilla and React. While derivatives of Spring are the dominant framework, it appeared more organizations are at least evaluating other options, noted Weins.

    Most organizations are also integrating Java applications with modern tools for logging (72%), observability (61%) and single sign-on (53%), the survey found.

    The shift to Java 17 is also well underway, with nearly three-quarters of respondents (73%) using or planning to use it over the next year. More than a quarter (26%) are already on Java 17 or a later release. Another 21% are currently upgrading, while 26% plan to update in the next 12 months.

    Overall, the survey found Java is being widely used for both internal (64%) and customer-facing (62%) applications. Java is most often used to build full-stack Java apps (70%) and backends (69%), the survey found

    Finally, the survey found more than a third of respondents (38%) expected that finding and retaining developers would be a significant challenge in 2023.

    There are, of course, no shortage of options when it comes to deploying Java applications. Most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a venerable programming language that itself has been modernized.