The Eclipse Foundation is gearing up for the Sept. 10 release of Jakarta EE 8, the first version of the enterprise Java platform under the Foundation's stewardship, with, among other things, a livestream event.
The JakartaOne Livestream is a one-day virtual conference aimed at developers and technical business leaders interested in "the current state and future of Jakarta EE and related technologies," with a focus on developing cloud native Java applications.
Perhaps named with a nostalgic nod to the venerable JavaOne conference, which is now CodeOne, (I'd like to think so, anyway), JakartaOne is scheduled for the same day as the Jakarta EE 8 release. The event features sessions and keynotes organized by an all-star program committee that includes Reza Rahman, principal program manager for Java on Azure at Microsoft, and one of the founders of the Java EE Guardians (and a personal fav speaker); veteran Java SE/EE developer, Java Champion, and popular YouTube educator Adam Bien; Arun Gupta, principal technologist at Amazon Web Services and the guy responsible for the Cloud Native Computing Foundation (CNCF) strategy within AWS (and founder of the Devoxx4Kids chapter in the US); Ivar Grimstad, Java Champion and PMC lead for the Eclipse Enterprise for Java Project (EE4J), the top-level project for Jakarta EE within Eclipse; Josh Juneau, developer, system analyst, and a fav blogger and author; and Tanja Obradovic, who joined Eclipse Foundation as Jakarta EE Program Manager June 2018.
Juneau, Grimstad, Bien, and Rahman will be presenting at the event, which will include keynotes by the Eclipse Foundation's executive director, Mike Milinkovich, and the Father of Java, James Gosling. There's also an industry keynote featuring vendors with lots of skin in the enterprise Java game, such as IBM, Oracle, Payara, Tomitribe and Fujitsu. Payara CEO Steve Millidge will be presenting, as will Tomitribe founder David Blevins, JCP star specification lead Dmitry Kornilov, and Java EE Guardians Arjan Tijms and Markus Karg, among others
Session topics range from Jakarta EE 8 features to a state-of-the-union for MicroProfile, Quarkus to Helidon. And the cloud, of course. Among the key findings of an Eclipse Foundation enterprise developer survey, published earlier this year: "The future of the Java ecosystem and Jakarta EE is increasingly driven by new cloud workloads and capabilities."
"Java continues to dominate as the language of choice for organizations deploying applications in production environments," Milinkovich at the time, "and this latest survey shows the same level of support as our 2018 survey. What's most interesting is to see the acceleration in the adoption of Java in new cloud native architectures. Clearly the future of Jakarta EE is cloud native."
In fact, this free, virtual, time-zone spanning conference was developed, in part, as a reaction to what Obradovic described in a blog post as "huge interest" in the Cloud Native track at the October EclipseCon Europe 2019.
Enterprise Java jocks -- or anyone, really -- can register now for what many (including me) consider to be a must-attend event.
Posted by John K. Waters on August 14, 20190 comments
Jelastic, the Java-focused cloud hosting platform provider, today announced new support for several Java runtimes, including AdoptOpenJDK, Liberica, Zulu, Corretto, OpenJ9 and GraalVM.
Jelastic built the runtimes as certified and secure container-based images with pre-configured automatic vertical scaling, explained Tetiana Fydorenchyk, Jelastic’s VP of marketing, in a blog post. The company made them available across all existing production platform installations, and Jelastic PaaS users are now able to choose the type and version of the OpenJDK distribution while creating the environment or easily change it by redeploying containers afterward.
The Palo Alto, Calif.-based Jelastic (short for Java Elastic), which was founded in 2010 by Hivetext, a Zhytomyr, Ukraine-based start-up focused on Java application development in the cloud, bills itself as the only cloud company whose underlying platform is Java. Originally a Java-based Platform-as-a-Service provider, the company has been evolving a Platform-as-Infrastructure strategy that combines PaaS with Infrastructure-as-a-Service. Jelastic’s unlimited PaaS and container-based IaaS platform is designed to allow developers to deploy Java, PHP, Ruby, Node.js, Python, and .NET enterprise apps for private, public or hybrid cloud.
Although its platform is now multilingual, the company maintains “a major focus on Java,” the company has said.
“We love organizations like Jelastic, who, like us, were created out of a community need by developers for developers,” said Martijn Verburg, director at AdoptOpenJDK, CEO of jClarity, co-organizer of the London JUG, and a member of the Java Community Process (JCP) Executive Committee, in a statement. “With well over 50 Million downloads, AdoptOpenJDK has become the defacto hub for the community to collaborate on, and we’re very happy to be added as a choice to the awesome Java hosting company PaaS that is Jelastic!”
AdoptOpenJDK uses infrastructure, build, and test scripts to produce prebuilt binaries from OpenJDK class libraries and a choice of either the OpenJDK HotSpot or Eclipse OpenJ9 VM. It’s a free and open source implementation supported by a range of companies, from IBM and Microsoft to GoDaddy and Pivotal.
Azul Systems’ Zulu implementation of the Java Standard Edition (SE) specification that contains all the Java components needed to build and run Java SE apps. Azul’s CTO Gil Tene, said his company was happy to see “a wide set of OpenJDK variants added to the Jelastic PaaS that provides customers with elasticity in both scale and runtime choice.”
Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK) certified as compatible with the Java SE standard. It comes with long-term support that includes performance enhancements and security fixes, and it allows developers it build and run Java applications on operating systems such as Amazon Linux 2, Windows, and macOS. Amazon uses it internally.
Eclipse OpenJ9 is an open source JVM optimized for small footprint, fast startup, and high throughput. It can be built as a component of OpenJDK v8 and later, and prebuilt binaries available at the AdoptOpenJDK project for Linux and Windows. Unsurprisingly, Dan Heidinga, Eclipse OpenJ9 project lead, was pleased to hear about the support. “Jelastic user focus comes across loud and clear in the broad choice of OpenJDK variants they provide on their PaaS,” he said in a statement.
Liberica is a certified, Java SE 12-compliant distribution of OpenJDK 12. It’s a 100 percent open source Java implementation built from OpenJDK by BellSoft.
The GraalVM is an extension of the JVM designed to run applications written in a range of languages, including JavaScript, Python, Ruby, and R; JVM-based languages, such as Java, Scala, and Kotlin; and LLVM-based languages, such as C and C++. Graal is the Java-based JIT compiler (JEP 317) that is the basis of the experimental AOT compiler introduced in JDK 9.
“We are glad to see Jelastic join the growing number of cloud services and open source projects that are adopting GraalVM,” said Eric Sedlar, VP and technical director at Oracle Labs. “GraalVM provides zero overhead interoperability between programming languages allowing developers to write polyglot applications and select the best language for your task.”
Posted by John K. Waters on August 13, 20190 comments
Call it "A Tale of Two Repositories."
Mercurial is a free, cross-platform, distributed version-control system (SVM), and current host of the source files and change histories of most JDK projects since 2008. Git is the free, cross-platform, distributed version-control system that is almost certain to become the new home of those repositories.
It has been almost exactly one year since the launch of Project Skara, an investigation of alternative source-code management (SCM) systems and code review options for the JDK -- and in particular, whether Git might not be a better option than Mercurial. Sponsored by the Build Infrastructure Group and led by Joseph Darcy, a member of the Technical Staff at Oracle, the project sparked a serious discussion in the Java community about SCM options for OpenJDK.
For at least two Java jocks (and a whole lot more), that discussion turned into action last week, when Darcy and his colleague on Oracle's Technical Staff, Erik Duveblad, proposed JEP 357, the goal of which is to "Migrate all single-repository OpenJDK Projects from Mercurial to Git."
The list of specific goals of JEP 357 includes:
- Migrate all single-repository OpenJDK Projects from Mercurial to Git
- Preserve all version control history, including tags
- Reformat commit messages according to Git best practices
- Port the jcheck, webrev, and defpath tools to Git
- Create a tool to translate between Mercurial and Git hashes
The JEP's authors also included a list of things they will not do:
- We will not migrate multi-repository OpenJDK Projects, such as the JDK 8 Updates Project. Those Projects can migrate to Git if and when they consolidate into a single repository.
- We will not change the bug system from JBS.
- We will not address the question of whether OpenJDK Git repositories will be self-hosted or hosted by an external provider. That issue will be the topic of a future JEP.
- We will not propose changes to the current JDK development process, though this JEP does enable such changes.
The bottom line for proponents of this move is that Git has the potential to handle larger projects. In the prototypes initially developed via the Skara project, converted repositories showed "a significant reduction in the size of the version control metadata," the JEP authors reported. In one example cited, the .git directory of the jdk/jdk repository, which is approximately 300 MB with Git is about 1.2 GB with Mercurial, depending on the Mercurial version being used.
"The reduction in metadata preserves local disk space and reduces clone times," they wrote, "since fewer bits have to go over the wire. Git also features shallow clones that only clone parts of the history, resulting in even less metadata for those users who do not need the entire history."
And then there's the bulging toolbox Git provides: text editors with Git integration (native and plugins), including Emacs, Vim, VS Code, and Atom; almost all IDEs ship with Git integration out of the box, including IntelliJ, Eclipse, NetBeans, and Visual Studio; and multiple desktop clients are available for local interaction with Git repositories.
The group working on JEP 357 has already prototyped a program to convert a Mercurial repository to a Git repository. The structures of commit messages for both Mercurial and Git jdk/jdk repositories are shown on the JEP page. The group has also prototyped backward compatible ports of several Mercurial tools.
Examples of converted repositories are available at https://github.com/openjdk/.
Posted by John K. Waters on July 17, 20190 comments
Is it time to "reboot" the OpenJDK Mobile Project, which focused on porting the JDK to iOS, Android, and the now deceased Windows Mobile? Johan Vox, co-founder of Gluon, a Belgium-based mobile solutions, and a Java Champion, thinks so.
Vox made his case recently for restarting public work on the fallow project on the mobile-dev mailing list. "After a long time, it is a good moment now to restart the public work in the OpenJDK Mobile project," he wrote.
"In the past, we had a repository with code based on OpenJDK 9 that allows [us] to build the class libraries (including native code) and one or more VMs for Android and iOS," he explained. "While this works, we still have the limitation on iOS, where dynamic code is not allowed, hence a JIT is not an option. The Zero VM works there (interpreter mode) but [it] is slow."
Vox's idea is to use the GraalVM AOT compiler to compile the code at build time. The compiled Java code could be linked with native libraries compiled for the target OS and create executables. Most of the VM functionality is provided by a very small set of files in SubstrateVM, he explained, which are linked to via the GraalVM native image.
"We already did this for iOS, based on Java 11," he wrote, referring to the June release by his company of Gluon Client plugins that support Java and JavaFX on iOS devices. "The [difference] to the upstream code is remarkably small."
The Gluon Client plugins, currently in beta, offer configurations for running Java 11+ and Java FX apps on iOS devices or the iPhone simulator. They're designed to allow developers to create iOS and Android apps in Java. Gluon Mobile provides UI control for the client application, handles communication with the server-side cloud and third-party services, and abstracts the platform-specific APIs. Gluon Client tools can generate a native executable for iOS devices.
The OpenJDK Mobile Project was originally set up to manage two different repositories, each with a different set of integration rules. The mobile/jdk9 forest was allowed to contain only the OpenJDK officially approved changeset that had been reviewed as if it were going to be immediately integrated into JDK 9. The mobile/dev repository was designed to be used for integration of features that were not approved for JDK 9 integration, early prototypes, or sharing of early features not yet ready for integration into mobile/jdk9.
For his part, Voss plans to use Project Skara, an alternative SCM and code review tool, to create a "synchronized fork" of the OpenJDK master and to push the changes required to build the native libs for the core libraries.
"Ultimately, it would be ideal if all required changes can go upstream, he wrote. "At this moment, this is iOS only, but there are no showstoppers to do this for Android as well. The architectures are pretty similar."
Posted by John K. Waters on July 10, 20190 comments
The Eclipse Foundation announced the latest of its stepped-up simultaneous project releases last week. SimRel-2019-06, its second quarterly release, comprises 76 projects, including the latest Eclipse IDE. Actually, the entire list is simply considered part of the Eclipse IDE 2019-06 release train.
Although this new fast-paced release schedule has been largely welcomed by the community, keeping up has taken some getting used to for more than a few. If you're among those who find themselves scrambling to stay abreast of the changes, check out the Foundation's simultaneous release schedule.
Among the new and noteworthy in this release (according to the Foundation) are:
- Eclipse Buildship: Eclipse Plug-ins for Gradle 3.1.0 Eclipse Buildship is a collection of Eclipse plug-ins that provide support for building software using Gradle. Buildship aims to provide a deep integration, and to make the Eclipse IDE more powerful by allowing the user to do more from within the IDE.
Since Gradle 5.4, projects have been able to declare an arbitrary set of tasks in the eclipse.synchronizationTasks configuration. Once configured, Gradle will automatically execute those tasks every time the user synchronizes workspace with the build.
- Eclipse Business Intelligence and Reporting Tools (BIRT) 4.7.0 Eclipse BIRT is an open source Eclipse-based reporting system that integrates with Java/enterprise Java applications to produce "compelling reports." It's used to create data visualizations and reports that can be embedded into rich client and Web applications.
- Eclipse Business Process Model and Notation (BPMN2) 1.5.0 Eclipse BPMN2 is an open source component of the Model Development Tools (MDT) subproject to provide a metamodel implementation based on the forthcoming Business Process Model and Notation (BPMN) 2.0 OMG specification. The goal of this release is to synchronize with Eclipse Photon, a past version of Eclipse. No new major enhancement are currently planned.
- Eclipse C/C++ Development Tooling (CDT) 9.8.0 The Eclipse CDT Project provides a fully functional C and C++ IDE based on the Eclipse platform. Features include: support for project creation and managed build for various toolchains, standard make build, source navigation, various source knowledge tools, such as type hierarchy, call graph, include browser, macro definition browser, code editor with syntax highlighting, folding and hyperlink navigation, source code refactoring and code generation, visual debugging tools, including memory, registers, and disassembly viewers.
- Eclipse CDO Model Repository 4.7.0 The Eclipse CDO (Connected Data Objects) Model Repository is a distributed shared model framework for EMF models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects, such as model scalability, transactionality, persistence, distribution, and queries.
CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the Net4j Signalling Platform.
- Eclipse Collections 9.2.0 Eclipse Collections is a collections framework for Java. It has JDK-compatible List, Set, and Map implementations with a rich API, additional types not found in the JDK, such as Bags, Multimaps, and a set of utility classes that work with any JDK compatible Collections, Arrays, Maps, or Strings. The iteration protocol was inspired by the Smalltalk collection framework. Eclipse Collections originated as an open source project on GitHub called GS Collections. This is also the Photon release of Eclipse Collections project.
- Eclipse Dynamic Languages Toolkit 5.11 The Eclipse Dynamic Languages Toolkit (DLTK) is a tool for vendors, researchers, and end-users who rely on dynamic languages. DLTK comprises a set of extensible frameworks designed to reduce the complexity of building full featured development environments for dynamic languages, such as PHP and Perl. Besides a set of frameworks, DLTK provides exemplary Tcl, Ruby, and Python IDEs ready to use out of the box.
Posted by John K. Waters on June 26, 20190 comments
It's been about a month since Mike Milinkovich, executive director of the Eclipse Foundation, explained in a blog post the status of negotiations between Eclipse and Oracle on the final details of the enterprise Java handoff agreement. The last bone of contention was the use of the javax* package namespace "in the evolution" of Jakarta EE specifications, and the use of Java trademarks in the Java EE spec, but the two organizations got past it.
"[F]ollowing many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax* package namespace or to use the Java trademarks currently used in Java EE specifications," Milinkovich wrote. "Instead, Eclipse and Oracle have agreed that the javax* package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications."
He added that the details of the talks would remain under wraps: "Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community."
Even one of the most vocal critics of Oracle's intractability on these two issues, the Java EE Guardians, seems ready to move on. The group of volunteers who joined forces in 2016 to support enterprise Java, then in the hands of a seemingly indifferent Oracle, declared in a recent blog post their "great excitement" about the final agreement between Big O and the Eclipse community. But that excitement was tempered with a splash of caution.
"One of the critical decisions that needs to be made prior to moving forward is how to proceed with the transition from the javax* namespace," they advised. "The Java EE Guardians agree with the consensus of many in the community, as there is a broad desire to move everything to the jakarta* namespace at once, rather than taking an incremental approach. The Java EE Guardians encourage the community and the Eclipse Foundation to focus on getting a clear consensus about this quickly so that Jakarta EE can confidently evolve with no more delays."
"The truth is, we're thrilled about this agreement," Dennis R. Gesker told me. "I know I'm commenting from out in the cheap seats, but here in my shop, we're like, wow, things have gone from glacially slow to superfast. And that's a good thing."
Gesker is chief technology officer at Alamon Inc., in Kalispell, Mo., and a member of the Guardians. And his "cheap seats" are in a real-world daily work environment.
"We see [the agreement] as a great opportunity to start building cohesion across the ecosystem," Gesker said. "Not to cast aspersions, but we've got an honest broker inside Eclipse now to start moving things along really fast, and then start bringing in some folks who have spun out into other projects. This is a chance to say, come on in and bring your ideas with you. Me in particular, but my guys as well: we're hoping they take a Big Bang approach: rename it, refactor, move on -- and deal with compatibility issues as they arrive."
Going forward, the enterprise Java community will have to steer clear of the "Java" trademark, and the evolution of the APIs cannot take place under the javax* package.
"However," the Guardians noted, "Jakarta EE will be able to use the Java EE APIs and javax* package as-is and be able to evolve the technology forward under the jakarta* package. This will provide a path forward to further evolve widely relied upon Java EE APIs such as Servlet, JPA, JAX-RS, WebSocket, JMS and so many others. It can also be objectively said the transition from Java EE to Jakarta EE represents one the largest and perhaps most significant technology stewardship transfers ever attempted. This includes not just the agreement but the source code transfer of the Java EE compatibility test kit (TCK) as well as the reference implementation GlassFish.
"This is not a big deal for us," Gesker said, "for the day to day, guys, but I fully appreciate that the folks who have been hardcore promoters of Java EE for so long might not be that happy. I get why they might want to hold onto javax. Programmers have tools they like, and they can be really passionate about them. I mean, there's a flareup in my office every couple of weeks about who's using the best IDE! But I want to say, hold on, we're going to get it together. A lot of these growing pains are going to go away, and we're all going to become more effective and efficient."
Posted by John K. Waters on June 12, 20190 comments
It took two and a half years, but the NetBeans Java-based IDE has finally graduated to Top-Level Project (TLP) status at the Apache Software Foundation (ASF). The popular open source development environment, tooling platform and application framework now comprises the largest codebases at the ASF. (It's 20 years old, after all.)
As a first-class-citizen in the ASF, the NetBeans project will now be able to receive more contributions from the open source community. Its previous status as an Incubator Project provided more limited access. That's the official entry path for projects and code bases whose supporters want them to become part of the ASF. It's where those projects are vetted to make sure they comply with the ASF legal standards and their support communities adhere to the ASF's guiding principles.
The stewardship of the IDE shifted from Oracle to the ASF in late 2016. NetBeans 8.2 was the last release by Oracle. It's worth noting that individual contributors from Oracle continue to work on the project "as part of the worldwide community of individual contributors, both self-employed as well as from other organizations," the ASF said in a statement.
NetBeans is literally the first Java IDE. It was originally demoed back in 1998, about two years after Sun Microsystems created the Java language. Sun acquired the IDE in 1999 with the goal of evolving the tooling along with the Java platform.
NetBeans 11.0 was released in April 2019. It's the project's third major release since the IDE entered the Apache Incubator.
"Being part of the ASF means that NetBeans is now, not only free and Open Source software, it is also uniquely, and for the first time, part of a foundation specifically focused on enabling open governance," said Geertjan Wielenga, vice president of Apache NetBeans, in a statement. "Every contributor to the project now has equal say over the roadmap and direction of NetBeans. That is a new and historic step and the community has been ready for this for a very long time. Thanks to the strong stewardship of NetBeans in Sun Microsystems and Oracle, Apache NetBeans is now ready for the next phase in its development and we welcome everyone to participate as equals as we move forward."
Wielenga was an Oracle product manager and developer advocate for open source projects. He reportedly did a lot of the heavy lifting when Oracle donated the NetBeans code to the ASF.
NetBeans continues to be a popular Java IDE (1.5 million active users, according to the community). The project won the 2018 Duke's Choice Award, a well-established industry award in the Java ecosystem. But the development environment has grown beyond its Java roots to support C/C++, Groovy, PHP, JavaScript and the HTML5 and CSS Web development standards.
Posted by John K. Waters on May 8, 20190 comments
Red Hat has again stepped in to assume the stewardship of OpenJDK projects no longer supported, long-term, by Oracle. The Raleigh, N.C.-based open source solutions provider and long-time Java community leader has taken on the role of steward of OpenJDK 8 and OpenJDK 11 update releases. Red Hat will "work with the community to enable continued innovation in Java," the company said in a statement.
Red Hat assumed stewardship of OpenJDK 6 in March 2013, and OpenJDK 7 in June 2015. The company has actually been involved in the OpenJDK, which is an open source implementation of Java, since 2007, when it signed Sun Microsystems' OpenJDK Community TCK License Agreement. The TCK (Technology Compatibility Kit) is the official test suite for compliance of implementations of Java Specification Requests (JSRs); they can only be provided by the spec lead of a JSR. Red Hat was the first big software vendor to license the TCK.
Red Hat is among the largest contributors to the OpenJDK project. Long-time Java technical lead and lead technical engineer of Red Hat's Java Platform team, Andrew Haley, was appointed as project lead for OpenJDK 8 and OpenJDK 11 in February 2019. He has been an active member of the OpenJDK governing board for seven years.
In addition to its work within individual OpenJDK communities, Red Hat leads the upstream development of Shenandoah, a high-performance garbage collector that is now part of OpenJDK 12.
In December 2018, Red Hat announced commercial support for OpenJDK on Microsoft Windows. Red Hat plans to launch OpenJDK in a Microsoft installer in the coming weeks and distribute IcedTea-Web, the free software implementation of Java Web Start, as part of the Windows OpenJDK distribution. JDK Mission Control is available as part of Red Hat Software Collections and for Windows through the Red Hat Customer Portal, enabling developers and administrators to collect and analyze data from Java applications running locally or deployed in production environments.
"My guess is we can expect more news on the transition of Java stewardship over the next few years," said Ovum analyst Michael Azoff, in a statement, "and I believe Red Hat is a safe pair of hands to take on that role. It's also a better fit with Java being open source and Red Hat being a leader in the open source software community."
Rich Sharples, Red Hat's senior director of product management acknowledged frequent public doubts have been expressed about the future of Java, but rumors of its demise, he told ADTmag, have been greatly exaggerated.
"From our point of view, there's still another 20 or 30 years of life left in Java," said Rich Sharples, Red Hat's senior director of product management. "There's a very long way to go for Java, and that's why we're continuing to put our resources behind it and the community."
Red Hat recently addressed some specific concerns that Java isn't competitive in emerging cloud-native architectures, such as microservices, containers, and serverless, with its newly released Quarkus framework, which is designed to significantly reduce the footprint and latency of Java applications.
"We're still all-in on Java," Sharples said.
Sharples also noted that Oracle's new faster release cadence is giving the community of Java users additional opportunities to reconsider what they're currently running on.
"People are going to be very consciously upgrading or thinking about upgrading much more frequently," he said. "Quite frankly, if you're upgrading version numbers, you've got to also be thinking about which vendor you source the JVM from."
"Java is in a renaissance moment," Mike Piech, vice president and general manager of Red Hat's Middleware group, said in a statement. "It continues to evolve and be a key component of new, emerging architectures. There is a developer hunger to bring Java into the next generation of development, and Red Hat is a leader in this movement through our involvement in the OpenJDK project. We are helping to lead the way in our efforts to enable users of JDK to have support and innovation in their existing environments. Red Hat remains committed to Java and is excited to have the opportunity to help steward the OpenJDK community."
Posted by John K. Waters on April 24, 20190 comments
In what is sure to be the last chapter in the seemingly unending courtroom drama that is Oracle v. Google, Oracle has responded to Google's hail-Mary request, filed with the Supreme Court in January, to review the appeals court's ruling that the Alphabet subsidiary infringed on Oracle's copyrights over its use of 37 Java APIs in the Android OS. In its 46-page petition, Oracle disputed Google's claim that the lower court's decision will harm software developers.
"Google claims the Court of Appeals' decision imperils the future of 'interoperable' software," the petition reads. "But Google has conceded that it purposely made its platform incompatible with Oracle's. So this is no case to consider the copyright implications of interoperability ... ."
The Oracle petition also shot down Google's fair use argument: "Google cites not a single case -- in any court -- that has ever held that copying this volume of code (or this much structure and organization) into a competing work is fair."
And it re-asserted that Google's actions "inflicted incalculable market harm" and represented "the epitome of copyright infringement."
The petition wraps up with a zinger: "Google's theory is that, having invested all those resources to create a program popular with platform developers and app programmers alike, Oracle should be required to let a competitor copy its code so that it can coopt the fan base to create its own best-selling sequel. That argument would never fly with any other copyrighted work ... ."
Oracle originally sued Google in 2010, but Google argued that its use of the Java APIs owned by Oracle was allowed under the "fair use" provisions of the federal copyright law, and therefore did not infringe on Oracle-owned copyrights. But that argument failed to persuade the court. "There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform," a panel of three Federal Circuit judges wrote in that opinion.
If my inbox is any indication, more than a few ADTmag readers are tired of this drama, and I don't blame them. But it's important to keep in mind what was originally at stake here; the court effectively ruled that copyright protections do extend to software interfaces. The impact of that decision is still to come.
Posted by John K. Waters on April 10, 20190 comments