devopsy.kinsta.cloud

Tag: java

  • Oracle Proposes Replacing Mercurial SCM for Java With Git

    Oracle Proposes Replacing Mercurial SCM for Java With Git

    Oracle today at its Oracle Developer Live—Java event proposed making a bevy of updates to Java that includes replacing the Mercurial source code management (SCM) platform, which is the repository Oracle created to share updates to the Java community, with Git starting with the initial availability of Java 16 and then migrating the project itself to GitHub.

    In addition, Oracle has developed server-side tooling compatible with GitHub and GitLab and client-side tooling compatible with Git and Mercurial to aid in the migration. The effort is based on the Project Skara initiative, which already provides read-only Git mirrors of all active and consolidated lines of development for the Mercurial SCM repository.

    Oracle is also proposing to add a Vector application programming interface (API), along with enabling some C++ features in Java 16.

    Oracle today also announced enhancements to Java 15, including support for Edwards-Curve Digital Signature Algorithm, hidden classes and reimplementing the legacy Datagram Socket application programming interface (API). In addition, support for a more advanced garbage collection tool as well as text blocks has been finalized.

    Other capabilities that have been advanced but are not finalized in Java 15 includes support for sealed classes, enhanced pattern matching, records and an API for accessing foreign memory.

    Chad Arimura, vice president of Java developer relations, said collectively the latest innovations show the venerable programming language is still vibrant. Despite a plethora of options most enterprise IT organizations still rely mainly on Java to build applications even as they transition to building microservices-based applications based on containers deployed on Kubernetes clusters. As such, Java is not in danger of suffering the same fate as the COBOL programming environment, which from a pace of innovation has grown comparatively stale, noted Arimura.

    Many of those organizations are also well down the path toward adopting best DevOps practices that revolve around a Git repository. Adoption of Git as the SCM repository for the Java project will further those efforts by simplifying workflows for organizations that have standardized on Git repositories, he said.

    While Java continues to dominate development of applications in the enterprise, it’s also true organizations of all sizes are employing a wider range of programming tools. By embracing Git and GitHub, the Java community will be able to more fluidly coexist with a wide range of open source projects being created using a diverse range of programming tools. Enterprise developers are clearly still relying on Java to write most of their server-side applications, but more client-side code is being developed using frameworks based on, for example, JavaScript.

    In the meantime, however, IT organizations looking to modernize application portfolios should be able to count on the fact that nearly 30 years after its initial launch, Java remains relevant. The challenge now is determining where best to rely on Java alongside a plethora of other programming tools that developers of all ages now regularly employ.

  • Eclipse Foundation Touts Jakarta Progress

    Eclipse Foundation Touts Jakarta Progress

    The Eclipse Foundation today published the results of survey of 2,180 software developers that finds over half of respondents (55%) have adopted Java/Jakarta EE 8.

    In addition, the Eclipse Foundation is making available an update to the Jakarta Enterprise Edition (EE) specification that will move away from the javax namespace to embrace jakarta namespaces for all components.

    Jakarta EE 8 is essentially Java EE 8, which Oracle agreed would become open source software when it transferred ownership last year to the Eclipse Foundation. The transition from Java EE to Jakarta nomenclature remains a work in process.

    The Eclipse Foundation finds the use of Java technologies is in a state of flux across the board. For example, adoption of Java 11 now stands at 28%, while Java 14 adoption is at 11%, according to the survey. That compares to 64% that are still employing Java 8.

    Spring/Spring Boot at 44% adoption continues to be the leading framework for building cloud-native applications, compared to 35% using Jakarta EE and 16% for Red Hat Quarkus, a framework that runs natively on Kubernetes.

    Usage of Eclipse Che, an open source integrated development environment (IDE) for building applications on Kubernetes, now stands at 11%, the survey also finds.

    Mike Milinkovich, executive director of the Eclipse Foundation, said it’s clear organizations are now employing multiple frameworks to build Java applications, given a 13% drop in reliance on Spring/Spring Boot from last year’s survey results.

    However, the survey also finds that overall, the use of Java to build microservice applications has declined to 39% from 43% during the same period. That drop may reflect both the complexity of building microservices-based applications, given the fact that 25% of survey respondents said they are using Java to build monolithic applications, said Milinkovich.

    At the same time, some organizations may be opting to lift and shift existing monolithic Java applications into the cloud in response to the COVID-19 pandemic, he said, noting once redeployed, those organizations may then opt to modernize those applications using microservices.

    With access to many local data centers limited during the pandemic, many organizations may have decided the most prudent option was to lift and shift Java applications as they are than re-engineer them first, he added.

    There are currently 12 frameworks officially that are compatible with Jakarta EE 8, which Milinkovich said is indicative of the continued relevance of Java technologies for building applications both inside and out of the cloud. Now that Java is available as open source software, the level of innovation surrounding Java platforms will also accelerate, he said.

    There is still a large base of developers that rely on Java and by extension Jakarta to build enterprise applications. However, IT organizations now routinely employ a wide range of programming languages and platforms to build applications. Java is still the most dominant when it comes to building backend applications; however, many organizations are still evaluating their options when it comes to building cloud-native applications on platforms such as Kubernetes.

    Java in all its forms will, of course, be around for a long time to come. The only real question is how much organizations will continue to rely on it, in an IT world that continues to transform.

  • Oracle Adds APIs to Java SDK To Advance DevOps

    Oracle Adds APIs to Java SDK To Advance DevOps

    Oracle announced it is making available the Java 14 software development kit (SDK), which provides access to several additional capabilities designed to help advance DevOps adoptions within IT organizations that still rely heavily on Java to build enterprise applications.

    Those capabilities include a set of application programming interfaces (APIs) to enable continuous monitoring of JDK Flight Recorder data and a set of APIs that make it easier to access foreign memory.

    In addition, via an incubator module Oracle is now providing access to a Packaging Tool that will enable developers to package Java applications and runtimes for distribution in platform-specific formats. That capability is being exposed as an incubator module because the associated APIs have not been finalized, which means they are subject to change in future releases.

    The Java 14 SDK adds Java language support for switch expressions to be used as either an expression or statement and extends the availability of the low-latency Z Garbage Collector to macOS and Windows.

    Finally, Oracle has added support for a Pattern Matching capability that eliminates the need for boilerplate code and a preview of a tool that makes it simpler to declare data immutable.

    Aurelio Garcia-Ribeyro, director of product management for Java SE, said a lot of the capabilities being added to Java SDK were developed as part of the ongoing Panama and Amber research projects that in some cases have been in development and testing for years.

    Despite the rise of rival programming languages, Garcia-Ribeyro said enterprise IT organizations continue to rely on Java to build most of their applications, especially mission-critical backend systems.

    The challenge is modernizing the processes via which Java applications are built and deployed. Many organizations, for example, are embracing containers and microservices to build next-generation applications. As that transition occurs the need to embrace best DevOps practices becomes more apparent because applications themselves are becoming more complex. The upside, of course, is that microservices also make it possible to build more robust applications faster, which has become a critical requirement as organizations embrace digital business transformation.

    Of course, no two organizations are likely to be at the same point on the DevOps maturity curve. In fact, in many cases, DevOps adoption is being driven from the bottom up as developers embrace new capabilities being added to familiar tools such as the Java Development Kit from Oracle. In some cases, the SDK will be used to build new applications while other members of the development team employ it to modernize legacy applications. Before long, however, IT operations teams start to realize how monitoring APIs and packaging tools are transforming how IT operations are managed.

    Naturally, Oracle is hoping all these new capabilities will help keep organizations focused on Java as the primary means for building enterprise applications at a time when developers have more options than ever. The one thing that Oracle has most in its favor is that most organizations don’t want to retrain developers to learn how to master a new programming language unless it can’t be avoided.

    — Mike Vizard

  • Looking Back on 20 Years of Enterprise Java

    Looking Back on 20 Years of Enterprise Java

    It is hard to believe, but enterprise Java has existed as we know it for more than 20 years. In December of 1999, the Java 2 Platform, Enterprise Edition (formerly J2EE, now called Java EE or Jakarta EE) was introduced.

    J2EE built on the “write once, run anywhere” mentality of the Java programming language, but made it enterprise-ready by extending the neutrality and portability with specifications that are better suited to build large-scale applications. It also built on years of work on distributed systems, such as the Common Object Request Broker Architecture (CORBA) and the Distributed Computing Environment (DCE).

    Since its birth in 1999, J2EE has played a powerful role in shaping enterprise applications as we know them today. This article will take a look back at the influential programming platform and what is next.

    First, for context, it’s important to note that the enterprise Java platform is not the same thing as the Java programming language, though they are related. Java, the object-oriented programming language, was started as a project called Oak in 1991 by James Gosling and some of his colleagues at Sun Microsystems. The language is coming up on its 25th anniversary, and is important to note for the history of J2EE. The original goals of Java were to create a language that had a familiar notation (drawing parallels to C/C++) but that had greater uniformity and simplicity. Java was also intended to be assembled as a byte code and then run using a Java Virtual Machine (JVM).

    Java wasn’t publicly released until about four years later, in 1995, from Sun. This came at a pivotal time for the world as we know it: the World Wide Web was rising in popularity, and Netscape announced that it would include support for Java in its web browser. Four years later in 1999, when J2EE was released, the industry was going through yet another critical shift when it came to how the world was using the internet: it was becoming something enterprises were not only thinking about, but realized they needed a strategy for.

    The shift to including Java in the enterprise came naturally because it already had developed a loyal following of developers, both within and outside of Sun. The next few years saw continued innovations in the space, and in 2006, Sun renamed J2EE as Java Enterprise Edition (Java EE). This was the same year that Red Hat acquired JBoss. Later that year, Java was formally open sourced by Sun releasing its core Java technologies under the GNU General Public Licence 2.0 (GPLv2). This was one of the most important steps in Java becoming a collaborative, community driven language.

    One of the other major milestones in Java EE was when Oracle acquired Sun in January of 2010. In the years that followed, the Java EE release cadence slowed considerably. At the same time, the enterprise IT landscape was actively shifting from large, monolithic applications toward lighter and more modular application architectures. Java EE was an enabler of the old way of creating enterprise apps, so it also needed to shift to keep up with the times.

    To meet this need, members of the Java community came together in 2016 to create MicroProfile, now a part of the Eclipse Foundation, which is designed to help optimize enterprise Java for microservices architectures. This shift aligns with the general trend of enterprises moving to smaller and lighter applications and making them cloud native. MicroProfile took into account the needs of the developers while still enabling Java to be used front and center. This played a role in Oracle’s decision to donate Java EE to the Eclipse Foundation in 2017, where innovation around microservices could happen quicker and more efficiently. Java EE has since been renamed to Jakarta EE and has a robust community behind it to support the development of even more innovations in enterprise Java.

    In fact, Java has become such a staple in the creation of enterprise apps that there are now projects and frameworks popping up designed to better support it, such as Quarkus, which aims to help Java developers use enterprise Java for new workloads that take advantage of things like containers and serverless. The Quarkus project aims to give enterprise Java a better cloud-native future.

    Enterprise Java has had a long history, bringing with it many innovations and new ways of thinking and working. I am excited to see what the next 20 years (and beyond) hold.

    — Mark Little

  • Why COBOL Still Matters After 60 Years

    Why COBOL Still Matters After 60 Years

    In the world of DevOps, the Agile Manifesto and countless other application delivery frameworks, one has to wonder how an anachronism such as the programming language COBOL (common business-oriented language) has managed to remain relevant. After all, COBOL has its roots back in the 1940s, and was built upon Rear Admiral Grace Hopper’s work on the FLOW-MATIC programming language (a text-based programming language). Hopper, who worked as a technical consultant on the FLOW-MATIC project, is sometimes referred to as the grandmother of COBOL.

    Last century, COBOL quickly became one of the most used programming languages in the world and it is still quite popular, claiming more lines of code in active use today than any other programming language. It offered a huge advantage over the other programming languages of the era. One that can be summed up as portability. From the outset, COBOL was the first popular language designed to be operating system-agnostic. In other words, it could be run on numerous different systems with little change made to the source code. What’s more, as a text based language, COBOL used English words and phrases to make it easier to understand and also made it somewhat self-documenting. 

    While much of the programming world has moved onto JavaScript, Python, PHP and even C and C#, COBOL can not be ignored. It continues to evolve and remains relevant, even in the age of the cloud. Simply put, it still has some chops to it. Take for example:

    • COBOL is a Language of Business: It is still used by the majority of major banks and insurers. The language can be found in widespread use across numerous other sectors, such as retail, healthcare, government and automotive. For most of those businesses, no other programming language has displaced COBOL and it remains as the back-office business language of choice.
    • COBOL is Extremely Portable: From the outset, COBOL was designed to be operating system agnostic, meaning the same applications developed under it could run unchanged across many different platforms. That allows COBOL developers to focus on building applications, instead of worrying about the intricacies of operating systems. That fuels DevOps and agile by allowing developers to test and deploy across a wide range of supported platforms.
    • COBOL Continues to Evolve: It supports and integrates with numerous platforms and works with operating environments such as Linux, mainframes, Windows and UNIX. What’s more, COBOL also integrates with Java, C#, Docker containers, mobile, .NET and JVM as well as Azure and AWS cloud environments. It can be used today to build cloud, containerized and managed code apps. And continues to evolve to meet the challenges of the future.
    • COBOL is Easy to Learn and Understand: It was created with the objective of making it easier for programmers to work with computers and each other. That objective has translated into a language easy to learn and understand by using English phrases and commands. The readability aspects of COBOL make it self-documenting, along with an ease of use not found in other languages. What’s more, the language costs less to maintain and its readability means it is easier to maintain.
    • COBOL is Future-Proof: It has continually evolved and now works with industry-standard IDEs, meaning programs can code with COBOL using familiar tools that support teams. COBOL developers are able to use the language alongside contemporaries, without having to forgo the latest IT tooling and processes.

    While many in the DevOps world sell COBOL short, there are many reasons why the language remains popular today. It continues to meet the needs of business and embraces many of the changes the cloud and new techniques can throw at it. COBOL is even now embracing APIs, micro services, the cloud and distributed platforms, making it a worthwhile tool for business today.

    — Frank Ohlhorst

  • Pivotal Software Embraces OpenJDK

    Pivotal Software Embraces OpenJDK

    Pivotal Software has officially thrown its weight behind OpenJDK, the open source version of the standard edition of Java, by adding support for OpenJDK to the Pivotal Spring Runtime on its Spring framework.

    At the same time, Pivotal announced it is extending its commercial support for open source Apache Tomcat servers in addition to providing commercial support for all the major open source Spring projects, including Spring Framework, Spring Boot, Spring Cloud and Spring Cloud Dataflow.

    Since 2011, Oracle, IBM and SAP have been making a case for employing OpenJDK. Ryan Morgan, vice president of engineering for the application platform at Pivotal, said that while other languages have become increasingly popular, the primary workhorse for building back-end applications in the enterprise remains Java. Now that Oracle has formally relinquished control over Java source code to The Eclipse Foundation, research and development into the legacy programming environment should accelerate. Oracle retains licensing rights to the name Java, but versions 8 and higher of Java Enterprise Edition are being converted to an open source platform known as Jakarta.

    Morgan said much of the work going forward would be focused on modernizing monolithic Java applications to make it either to turn them into microservices or at least make it easier for microservices developed in other languages to make calls via application programming interfaces (APIs) to those back-end applications. As enterprise IT organizations make the shift, they increasingly will rely on DevOps processes to manage the transition. The effort should accelerate the extent to which many organizations will need to rely on modern best DevOps practices.

    As both OpenJDK and Jakarta continue to move forward, Morgan said Pivotal is committed to continuing investment in the Spring framework, which has done much to make developing Java applications a much more agile endeavor. The most immediate benefit, of course, is the reduction of licensing fees associated with employing Java platforms. Many IT organizations that have mandated open source code-first and adopted alternative programming languages now may want to reconsider their options, especially when the number of developers who know how to write applications in more modern languages is comparatively small.

    Of course, it will take many years for enterprise IT organizations to fully make this transition. In the meantime, many of them will continue developing applications in Java simply because they have large teams that have mastered a programming construct that has been in place for three decades or more. Many of those same organizations may be making greater use of rival programming constructs, but Java and its descendants will play a major role in the enterprise well into the next decade. The primary challenge Pivotal will face is maintaining dominance of the frameworks employed to build new applications based on Jakarta and OpenJDK, in addition to updated existing Java applications.

    — Mike Vizard

  • Application Monitoring Using Stagemonitor

    Application Monitoring Using Stagemonitor

    This article covers important steps to monitor a typical Java application using Stagemonitor tool, Kibana as a dashboard viewing tool and Elasticsearch as a data processing engine.

    Stagemonitor is an open source Java application performance monitoring (APM) tool that provides everything you need in development, quality assurance and production to monitor the performance of your Java web application.

    Using this tool, we can have different dashboards such as JVM dashboards, application server, request metrics, host, request analysis, web analytics, etc.

    Architecture of the Stagemonitor

    Figure 1

    The Stagemonitor agent sits inside the application and sends metrics and details about requests (request traces) to Elasticsearch. Metrics can optionally be sent to Graphite, Influx DB and Prometheus.

    Prerequisites

    • Minimum of 2GB RAM and 200GB hard disk
    • Java version of 1.8 or more
    • Install latest versions of Kibana and Elasticsearch

    Steps to Monitor Java App with Stagemonitor

    Dev Time Monitoring With Browser Widget

    This step illustrates how to enable a widget in dev time monitoring, adding the Stagemonitor plugin inside the Java app. We can do this in two ways: We can directly edit the pom.xml/build.gradle file by adding the required stage monitor plugins, or we can add dependencies in the application’s LIB directory.

    Some of the important plugins we must have in pom.xml/build.grade to get monitoring dashboards are Stagemonitor configuration, Stagemonitor tracing Elasticsearch, Stagemonitor tracing, Stagemonitor-jdbc, Stagemonitor-jvm, Stagemonitor-os, Stagemonitor-web-servlet and Stagemonitor alerting.

    We’ll get the Stagemonitor plugins from the following location: https://mvnrepository.com/search?q=stagemonitor

    After installing the agent, will have to create one Stagemonitor configuration file as stagemonitor.properties file under src/main/resources in case of maven application. Otherwise, the file must be located at the root of class path. At the end, it has to be under the WEB-INF/classes section.

    The following is what the stagemonitor.properties file looks like:

    stagemonitor.applicationName=My Application

    stagemonitor.instanceName=dev

    stagemonitor.instrument.include=org.example.app

    Request Dashboard

    In this section, we focus on setting up the time series database to collect the data and visualization tool to view the metrics in detail. Here we’ll use Elasticsearch as the time series database engine and Kibana as the visualization tool.

    To get the data from Elasticsearch database, we will include properties in the stagemonitor.properties file:

    stagemonitor.reporting.elasticsearch.url=value,

    stagemonitor.reporting.elasticsearch.username=value

    stagemonitor.reporting.elasticsearch.password=value

    stagemonitor.reporting.interval.elasticsearch=60

    After adding all the required values and restarting the server, we will be able to open the (automatically added) request analysis dashboard in Kibana. Along with that, we will be able to see different dashboards automatically.

    To use Influx DB as a time series database, we’ll have to configure the values in stagemonitor.properties file:

    #following the details contains influxDB

    stagemonitor.reporting.influxdb.url=http://localhost:8086

    stagemonitor.reporting.interval.influxdb=60

    stagemonitor.reporting.influxdb.username= value

    stagemonitor.reporting.influxdb.password=value

    Logs Monitoring using Kibana/Stagemonitor

    We can track logs using Kibana/Stagemonitor. In the metrics dashboard, we can see matrices such as what URL address we’ve hit and the time to complete the request (Figure 2). We can track the host details such as how many servers our applications are running, the status of the server, memory stats, CPU stats, network stats, disk usage stats, networks processed, network packets errors, network packets dropped and how many cores of the CPU the host is using.

    Stagemonitor provides all the required dashboards under the request analysis dashboard. To open the request analysis dashboard, click on: Dashboard – Load Saved Dashboard and select “Request Analysis.”

    Figure 2

    Figure 3 shows the details of the CPU, such as CPU usage and CPU load.

    Figure 3

    Below, Figure 4 shows total page views, unique number of visitors to the site and call tree, and how much time it takes to complete.

    Figure 4

    Figure 5 shows the transaction history and individual transaction details.

    Figure 5

    Figure 6 shows the JVM details and all the other memory matrices.

    Figure 6

    As mentioned above, we can monitor various application metrics and infrastructure metrics.

    — Sai Babu Tanguturi

  • Python Benefiting From Increase in DevOps Use

    Python Benefiting From Increase in DevOps Use

    DevOps and Python have developed a mutually beneficial relationship.

    In a recent survey released by the Python Software Foundation and software development company JetBrains, researchers found that more and more developers are using the program language for an array of versatile projects, including DevOps and machine learning.

    In fact, Python developers told the researchers that DevOps is increasingly part of their professional development work.

    “In 2018 we had significantly more respondents specifying they’re involved in DevOps (an increase of 8 percent compared to 2017). In terms of Python users using Python as their secondary language, DevOps has overtaken web development,” according to the “2018 Python Developers study,” which is based on responses from 18,000 developers in 150 countries.

    Over the last two years, Python has grown more important to developers thanks to its flexibility, especially when it comes to web development. It’s no surprise that as other projects have gained popularity in the enterprise—DevOps and machine learning—developers have started adopting the language to other disciplines, especially as businesses invest more in application development.

    In TIOBE’s February 2019 index, Python now ranks third behind favorites such as Java and C, edging out C++ for its current position.

    Digging into the numbers, the survey finds that 43 percent of developers are using Python for DevOps projects, as well as system administration and writing automation scripts. That’s an increase from the 35 percent who reported the same types of uses for the programming language in 2017.

    The report notes that these numbers reflect a combination of Python used as either the primary or secondary language for various projects. As the report notes: “DevOps/system administration/writing automation scripts has moved into first place among Python users using it as a secondary language.”

    Machine learning is another up-and-coming category, with 38 percent of developers using Python for these projects compared to 31 percent last year.

    Overall, data analysis remains the No. 1 use case for Python developers, with 58 percent reporting that it’s their main focus when it comes to development.

    In second place is web development, according to the report.

    In terms of the top cloud platforms for Python developers, Amazon Web Service is the top choice, with 36 percent of respondents reporting that they use AWS. From there, it’s Google Cloud Platform (29 percent) Heroku (26 percent), DigitalOcean (23 percent) and Microsoft Azure (16 percent).

    About a third of those surveyed responded that they don’t use any cloud platforms.

    When asked about running code in a cloud production environment, 47 percent responded that they use virtual machines, although 40 percent of Python developers reported that they prefer containers. Another 28 percent use platform as a service (PaaS) and 21 percent are taking the leap to serverless computing.

    Additionally, when developing for the cloud, about 35 percent of those in the survey report that they use Docker containers.

    This increase use of Python within DevOps, as well as other connected areas such as serverless computing, does not surprise Anshu Agarwal, the CEO and co-founder of Nimbella, a cloud-agnostic, serverless cloud platform for developers. She noted the language’s use within a wide range of projects, specifically machine learning and AI, are driving this change.

    “Python developers are driving serverless requirements in new and unique ways, primarily because of the interest in data analysis, ML and AI,” Agarwal wrote in an email. “These data analysis and ML/AI-centric serverless use cases are different than request/response style serverless functions which run for much shorter durations. Python functions in serverless may have much longer durations (10s of minutes or hours), and consume a lot more memory. For such functions a different kind of serverless framework needs to be adopted that can handle long running workloads.”

    When it comes to continuous integration systems, about a third of respondents don’t use any. However, when they do, Jenkins is the most popular at 25 percent, followed by Gitlab CI and Travis CI, with 18 percent each. For configuration management, 20 percent reported using Ansible, while 9 percent used custom tools. Puppet, Salt and Chef also appeared in the list.

    Finally, about two-thirds of Python developers (69 percent) use Linux as their main operating system of choice for development. Microsoft Windows comes in a distant second at 47 percent and Apple’s macOS in third at 32 percent, according to the study.

    — Scott Ferguson

  • The State of the Kotlin Programming Language in 2018

    The State of the Kotlin Programming Language in 2018

    Pusher, the communications and collaboration API provider, recently released the findings of its “State of Kotlin 2018” research report. Over the past 24 months, adoption and use of the Kotlin programming language among developers has seen tremendous growth. Pusher has seen this growth firsthand, with more developers using Kotlin while building applications with the company’s products.

    Earlier this year, Pusher surveyed more than 2,500 developers to get a better understanding of the ecosystem, specifically around usage, features and demographics.

    Key report findings:

    Kotlin is used both in work and personal projects, as confirmed by 60 percent of respondents. Kotlin is even more prominent in side projects, as they tend to be smaller, easier to convert and more experimental.

    Android is hugely popular across the board, used by professional developers and students alike. However, when it comes to backend applications, Kotlin’s users tend to be more experienced developers.

    Most Kotlin developers come from a Java background, or also work with Java. More than 87 percent of respondents have migrated existing Java code to Kotlin. However, more than a quarter of respondents who migrated Java to Kotlin needed to revert back due to both technical and organizational reasons. Tools that use reflection or generate code were mentioned most often as technical reasons to revert to Java.

    Null safety is the favorite feature for 80 percent of respondents, whereas co-routines and multi-platform support are the least important.

    The report concluded that Kotlin is overwhelmingly popular in the Android circles. This raises the question, Will Kotlin break into communities outside Android?

    “We expect to see new generations of developers taking their first steps into programming with Kotlin,” said Pusher Developer Evangelist Zan Markan in an email. “It’s a modern, versatile, cross-platform language that can cross between OO, functional, scripting, and declarative paradigms with ease. This could mean that Kotlin will affect the wider programming language landscape by becoming a benchmark for what a programming language should be able to do.”

    Read the full report here.

    — Malia Powers

  • Eclipse Foundation Charts Cloud-Native Path Forward for Jakarta

    Eclipse Foundation Charts Cloud-Native Path Forward for Jakarta

    A new era begins for the Java community today with a commitment to a Jakarta EE specification that the Eclipse Foundation expects will become cloud-native in short order.

    Jakarta EE formally marks the end of a Java era. While the term Java will still apply to any technologies developed prior to Oracle transferring stewardship of the venerable programming language to the Eclipse Foundation, all future innovations will be delivered under the Jakarta brand.

    A survey of 1,800 Java developers shows that in addition to increasing the overall pace of innovation, the top two priorities of the developer community is to see more emphasis being placed on microservices and integration with the emerging de facto Kubernetes container orchestration platform.

    A full 95 percent of the respondents building microservices said they are employing Java as part of those efforts, while nearly one-third of respondents are already working with Kubernetes. Mike Milinkovich, executive director of the Eclipse Foundation, said that although it’s yet to be determined precisely how Java and Kubernetes will be more tightly coupled, it’s clear the Jakarta community wants to be able to deploy cloud-native applications based on Jakarta. Half of survey respondents said they ran only one-fifth of their Java applications today in a cloud. But more than 30 percent said they expect to be running 60 percent of more of their applications in the cloud within the next two years.

    Milinkovich said with Jakarta under the auspices of the Eclipse Foundation, many more developers from different vendors will be contributing code to advance it. Previous advances to Java have been slow in coming over the years because all contributions to the code base were controlled by Oracle. One of the first things to change under the stewardship of the Eclipse Foundation, he noted, is that Oracle has committed to open-sourcing the Test Compatibility Kits (TCKs), which vendors previously were required to license at significant expense.

    Also expected to witness a faster innovation cycle, Milinkovich said, is Eclipse MicroProfile, a Java framework developed by IBM and Red Hat optimized for microservices, which the Eclipse Foundation expects to be as widely embraced as the Spring framework based on Java that Pivotal Software helped popularize. In fact, there will be a lot more cross-pollination of ideas and concepts across all the major frameworks from writing applications, he added.

    Tighter integration between Jakarta and Kubernetes and a general simplification of the effort required to develop microservices is likely to have a significant impact on DevOps for years to come. Many organizations today are contemplating the degree to which they may want to lift-and-shift existing Java application into the cloud versus rewriting them completely in a new language. With the Eclipse Foundation’s commitment to a cloud-native implementation of Jakarta EE, it’s clear that organizations can have greater confidence that existing investments in Java applications likely will remain relevant in the age of the cloud. In fact, the only decision left for many of them to make is the degree to which they might want to turn monolithic applications written in Java into highly portable microservices based on Jakarta EE.

    — Mike Vizard