Alphabet's Google subsidiary has petitioned the Supreme Court to review its long-running copyright dispute and re-evaluate a Federal Circuit court's decision that copyright protections extend to software interfaces, and whether, as a jury found, "petitioner's use of a software interface in the context of creating a new computer program constitutes fair use."
If you're tired of this seemingly immortal struggle between Oracle and Google over those 37 Java APIs, you're not alone (it's been nine years), but the stakes are existentially high. In a blog post announcing the move, Google's SVP of Global Affairs and Chief Legal Officer Kent Walker rightly asserted that the Court's decision on the copyrightability of software "will have a far-reaching impact on innovation across the computer industry."
"Standardized software interfaces have driven innovation in software development," Walker wrote. "They let computer programs interact with each other and let developers easily build technologies for different platforms. Unless the Supreme Court steps in here, the industry will be hamstrung by court decisions finding that the use of software interfaces in creating new programs is not allowed under copyright law."
Oracle originally sued Google in 2010. Google's argument that its use of the Java APIs was allowed under the "fair use" provisions of the federal copyright law, and therefore did not infringe on Oracle-owned copyrights 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 their March opinion.
The U.S. Copyright Office defines fair use as "a legal doctrine that promotes freedom of expression by permitting the unlicensed use of copyright-protected works in certain circumstances."
What the appeals court found initially was that the declaration code in Oracle's API packages, which Google copied verbatim, was copyrightable. Google developed the implementation code independently, so that wasn't at issue. The court found that the Oracle code had not been merged with the functions performed by the code; that combinations of short code phrases, such as those used in the APIs, can be copyrightable; and the fact that the code serves a function does not preclude its copyrightability if, as the court put it, "the author had multiple ways to express the underlying idea" at the time of creation of the code.
In its latest filing, Google asserts the following:
"Google has never disputed that some forms of computer code are entitled to copyright protection. But the Federal Circuit's widely criticized opinions -- in an area in which that court has no specialized expertise -- go much further, throwing a devastating one-two punch at the soft- ware industry. If allowed to stand, the Federal Circuit's approach will upend the longstanding expectation of software developers that they are free to use existing software interfaces to build new computer programs. Developers who have invested in learning free and open programming languages such as Java will be unable to use those skills to create programs for new platforms -- a result that will undermine both competition and innovation. Because this case is an optimal vehicle for addressing the exceptionally important questions presented, the petition for a writ of certiorari should be granted."
In his blog post, Walker points to support for Google's position on the copyright question from companies such as Red Hat (now owned by IBM), Yahoo and others, as well as a long list of computer scientists and academics, who have spoken out and filed court petitions of their own.
"The U.S. Constitution authorized copyrights to 'promote the progress of science and useful arts,'" Walker wrote, "not to impede creativity or promote lock-in of software platforms."
What happens next could be the final stake in the heart of this conflict, but I wouldn't bet on it. Meanwhile, check out our coverage of this case on the WatersWorks blog and throughout the ADTmag Web site.
Posted by John K. Waters on January 29, 20190 comments
2018 was a year of big changes for the Java community, among which none were bigger than the transition of the stewardship of enterprise Java from Oracle and the Java Community Process (JCP) to the Eclipse Foundation. But that Herculean task wasn't the only Java-related challenge faced by that organization last year. I talked with Mike Milinkovich, who has served as executive director of the foundation for all its 14+ years, about these and other changes, and what he sees coming for the Java community in 2019.
It would be hard to overstate the importance of moving enterprise Java, which is now Jakarta EE under the Eclipse Foundation's stewardship. Was it the greatest challenge you faced last year?
Oh, without a doubt. This has been an enormous undertaking, and the teams here have been working very hard, as have all the developers involved. I also want to give a shout-out to the Oracle development teams we have been working with. They have been fantastic. There has been participation by the other vendors, of course, but Oracle gets the credit for the heavy lifting, of getting Glassfish and the TCKs migrated to the Eclipse Foundation.
Accepting the stewardship of enterprise Java has also required some fundamental changes for the Foundation itself, hasn't it?
You could say that. We have created an entirely new specification process for Jakarta, which has been an enormous amount of work. Remember, the Eclipse Foundation didn't do specifications before we started this; we've essentially created a specification process from a blank sheet of paper.
Obviously, there are some parts in there that were inspired by the JCP, but there were a lot of things we knew we wanted to change. And there's also the fact that this is a vendor-neutral organization, rather than single-vendor organization, which is a big change, as well.
What do you see as the long-term impact of and Eclipse stewardship of enterprise Java?It's important to keep in mind that the Eclipse Foundation is an open community process that doesn't have a single vendor in charge of it, which means there's an opportunity here for enterprises. Historically, they have bought black-box products from vendors, and the idea that they can engage with and help to shape the technologies they're running their businesses on through their direct contribution and involvement is still new to many. But they're starting to get it, and we're hoping that Jakarta EE will lead to them to get more engaged going forward.
Of course, enterprises are still going to want vendors, but by participating directly in the Jakarta EE specification process, they can help to shape what becomes the products they get from their vendors.
I'm a little confused about the status of Jakarta under Eclipse. Is it "Eclipse Jakarta" or "Jakarta EE?" And what's the difference?
It's Jakarta EE, under the stewardship of the Eclipse Foundation. But as a brand, it is a peer of Eclipse. Eclipse projects are supposed to call themselves "Eclipse" something: Eclipse Glassfish Eclipse Vert.x, Eclipse Jetty, etc., because they are subordinate brands. But when it comes to the specifications that are coming out of Jakarta EE, they're the "Jakarta" specs.
Did you ever consider not accepting the stewardship of enterprise Java?
We definitely wanted Java EE to come to the Eclipse Foundation. Yes, this has been a ton of work, but the Eclipse Foundation has deep roots in the Java community, and with enterprises. We felt this was a natural fit, and great opportunity for us. Among other things, I think Jakarta EE was the trigger to make a lot of developers finally recognize that the Eclipse Foundation has projects other than our Java IDE.
Our goal is to help drive a whole new generation of innovation in the Java ecosystem. It's going to be a lot of fun!
Any other accomplishments around Jakarta you'd like to mention?
We were able to onboard all of Glassfish last year, which has a huge, very mature code base. And we open-sourced the Java EE TCKs [Technology Compatibility Kits], which was an enormous change for the Java EE ecosystem. Historically, the TCKs have been confidential and proprietary. People could not get access to them, which means they had no chance of finding out exactly what was being tested. All of this is now open source. And we are actually running these TCKs on Eclipse Foundation hardware, and doing testing for Glassfish using them, and moving all that forward.
The fact that the TCKs are now open source and have become an integral part of migrating this code base forward -- that ability to do this open, public testing all the time is really going to help us innovate. And the community now has the ability to inspect tests and give feedback, and to give us more, better tests, which means we can expand the test coverage over time.
If Jakarta EE represents the biggest change for the Java community and challenge for the Foundation last year, was there a close second?
Nothing comes close, really, but we did make some pretty big changes to adapt to the new rapid release cadence for Java, which Oracle began implementing last year. We think it's a good thing, and we support it, but it did cause us to shift from our annual release train model, where we shipped a major release every June with a couple of maintenance releases though the year, to a rolling release model, where we ship the Eclipse Java IDE every quarter.
So, no more release train after last June's Oxygen?
That was the last one. We've been doing this release train for a dozen years, and I think it provided a good example of the advantages of regular, predictable releases, which I don't think they were lost on Oracle.
Will you be lining up your releases with Oracle's releases?
When Oracle did that, they upped the game for us, but we don't want to line up our releases exactly with Oracle's, but we do want to make sure we're always current. The approach that we came up with is to ship a couple of weeks after Oracle's releases. As they demonstrate over time that they're going to be able to do this on a regular and predictable basis, that'll only help us.
Any other accomplishments in 2018 you'd like to mention?
I wouldn't call it an accomplishment, but it's very exciting that Oracle joined the Eclipse MicroProfile effort, and their Helidon project is shipping MicroProfile and MicroProfile-compatible implementations.
Helidon is the open-source Java microservices framework designed to run on a fast Netty core. It supports MicroProfile 1.1. Why is that exciting?
MicroProfile is a set of specifications for doing Java microservices, and that community has done a great job in really bringing forward a lot of new specifications and doing it quickly. We're now seeing real multivendor engagement around MicroProfile, and we're seeing lots of people showing up in conferences in talks about it, so there's clearly a lot of interest out there around this technology. MicroProfile is setting us up for having more success for Java in the microservices area. The migration of critical Java applications into the cloud is only going to accelerate, and we think MicroProfile could be a big part of that.
Anything that didn't go as planned in 2018?
Everything took longer than we thought it would, which I guess shouldn't surprise anyone. And I'm a bit disappointed that we didn't get to where we wanted to be with Jakarta at this point. In particular, we're about three months late shipping the first release of Eclipse Glassfish.
The other thing is, we're still not quite where we want to be in terms of being able to evolve the specifications going forward. We still have some work to do with Oracle to make sure we have all the rights in place. It's just taken longer with the lawyers than we ever anticipated. I know your readers will be shocked to learn that the lawyers are taking a long time.
Although we've done a lot of work with Jakarta, what developers want to see from us is innovation, and we're not quite there yet. We've done yeoman's work in migrating Glassfish and the TCKs and the API jar files and all those bits and pieces to the Eclipse Foundation, and we have functioning open source projects that are doing nightly builds, and all that great stuff, but we're still not quite at the spot where we can start moving forward and have a new release of the spec. And that's the whole promise of Jakarta, and that's what we must focus on.
You're not there, but you're getting there?
Right.
Looking forward to 2019, what's on your Java radar?
AI and machine learning. One of the challenges for Java in the AI/ML space is the perception that, if you're doing AI or ML, you're doing it in Python. The major frameworks out there, like Tensor Flow and PyTorch, are written in Python, so there's this perception that Python is the technology of choice for AI/ML. The Eclipse Deeplearning4J Project, which is mostly implemented in Scala, is a deep learning framework that runs on the JVM. Among its many capabilities: you can take a machine learning model that has been taught using something like Tensor Flow, and run it on your JVM-based infrastructure. And that makes machine learning a lot more approachable for enterprises.
Most infrastructure people are more familiar with a JVM-based approach, so having a solid Java -- or at least a JVM -- story is going to help adoption of machine learning in the enterprise. Eclipse Deeplearning4J is providing a real opportunity for the Java ecosystem to start tying in to ML.
I also expect to see Java becoming even more relevant than it already is in the microservices and cloud-native space. We did a survey last year, and we had very large numbers of developers saying they already were now or were planning to soon run their applications in the cloud. About 30 percent said within the next two years they expect to be running 60 percent of their Java apps in the cloud. Nearly half said they're already using Java to build microservices. 21 percent said they'd be doing that in a year. So, there's a lot of activity already happening around Java and microservices, and we think that's only going to accelerate.
There's a lot of work that needs to go into making that better -- better stories around Kubernetes and Docker containers in particular. Kubernetes and Docker is where all the cool kids are hanging out, but there are enormous investments in enterprise code bases that have been built in Java and Java EE. Enterprises want to figure out a way to migrate as much of those code bases and they can into this cloud-native world.
Just as important, they have a lot of developers with Java skills and knowledge about their businesses. They want to make sure that those skills are still applicable as they're migrating to the cloud.
People should keep in mind that Java is still one of the most popular programming languages out there. Reports of Java's demise make great click bate, but they are grossly exaggerated.
Part of our mission, as we see it, is protecting the that franchise. Java developers are passionate about the Java platform, but they also need to believe that that platform is evolving to meet the requirements of the businesses they work for, and that the applications they're building are going to be relevant in the future. They want to see that great multivendor ecosystem that has made Java EE so successful, they want to see those vendors lining up behind Jakarta EE and Eclipse MicroProfile and pushing these technologies forward so that they can get excited about being a Java developer for the next 20 years.
Posted by John K. Waters on January 14, 20190 comments
As Chair of the Java Community Process (JCP), the technology standards and specifications organization behind the evolution of the Java language and platform, Heather VanCura has a lot on her plate. She leads the activities of the JCP Program Office, manages the organization's membership, guides spec leads and experts through the process, leads the Executive Committee (EC) meetings and manages the JCP.org Web site. She's also responsible for the Adopt-a-JSR program, organizing hack days and other events, and promoting the overall growth of the membership. She also blogs, tweets and travels the world on behalf of the ever-expanding Java ecosystem.
So, although I was disappointed that we couldn't connect for a face-to-face interview for one of my annual Looks into the Future of Java stories ("the Future" is big -- huge, in fact -- so there's always more than one), I wasn't surprised. But then she did surprise me with an e-mailed list of her top five predictions for Java and the community in 2019. (Thanks goes to Alex Shapiro at Oracle, who made it possible for me to pursue an interview this very busy exec without seeming like a stalker.)
Topping VanCura's list: There will be more collaboration and increasing contributions from Java community members.
In 2018, VanCura wrote, the JCP began exploring strategies for streamlining and "evolving" the JCP Program to meet the needs of the changes in the Java development ecosystem. And there have been a lot of changes in the past year, most notably the Eclipse Foundation's decision to accept stewardship of enterprise Java and rename it Eclipse Jakarta and Oracle's implementation of its faster Java release cadence.
Under the Java Specification Request "Streamline the JCP Program" (JSR 387), which was completed in December, the JSR lifecycle process was updated "to bring it in line with the way Java technology is developed today," VanCura explained, "in an open and more iterative manner."
"I think the community will be excited about the changes introduced," she added, "and indications from several engaged community members point towards them looking at more substantial ways they can contribute to Java technology evolution, either through OpenJDK or other projects."
Number Two: There will be a focus on the importance of standards and specifications.
"One of the crown jewels of Java is the specifications," she wrote. "Standards increase adoption, allow for choice in implementations and make the technology easier for developers to implement. As standards-based groups focus on how to bring their development process into closer alignment with the open source development model, I think open source groups will put an increasing focus on how to embrace standards and specifications -- for example, with the Jakarta EE development at the Eclipse Foundation, and the establishment of a Specification Process, for use within the Eclipse Foundation."
Number Three: Developers will increasingly work in a polyglot environment.
Although Java continues to be an extremely popular programming language (it consistently tops TIOBE Index), virtually all developers are using more than one language these days. One big piece of evidence that this is a trend with legs, VanCura pointed out, was Oracle's decision last year to roll up the JavaOne conference into a new event with sessions, tracks and keynotes covering an expanded menu of languages, frameworks, tools and tech called Oracle Code One.
The Code One event brought in a range of developer communities, she pointed out, and such languages as Go, Rust, Python, JavaScript and R, as well as other technologies, such as machine learning, blockchain and artificial intelligence.
Number Four: Java developers will embrace a more iterative development style.
"As we transition from a Java SE Platform release once every 3-4 years to a release every six months," she wrote, "Java developer will grow more accustomed to downloading the early access builds available and running their applications against them to determine any changes needed and whether to migrate to the upcoming version. Since the Java SE Platform has transitioned to a release every six months, starting with Java SE 9, that means there are fewer new features in each release. For example: there were over 100 Java Enhancement Proposals (JEPs) in Java SE 9, but only 12 JEPs in Java SE 10 and 17 JEPs in Java SE 11 (the current version, released in September 2018). This means the migration from one version of Java to another becomes a much smaller development project than in the past. In addition, because the new model calls for JEPs to be targeting only when ready, developers will have access to newer features on a more frequent basis to try out in development, rather than having to wait multiple years for the next release of Java to use in production."
And Number Five: The Java community will see an increase in local community events.
"Over the past several years, I have noticed a definite movement towards a stronger Java community," VanCura wrote, "and in particular, more localized leadership. The passion and enthusiasm of the Java community is another crown jewel of Java, and I see this rising, with events in even smaller communities. The community is what keeps me passionate about my work every day, so I am looking forward to visiting a few new communities in 2019, and continuing to see the adoption of Java grow around the world."
Posted by John K. Waters on January 7, 20190 comments
The past year saw another surge in the evolution of Java, thanks to myriad changes that will have long-term impacts on the Java developer community -- everything from the Eclipse Foundation's decision to accept stewardship of enterprise Java and rename it Eclipse Jakarta to IBM's acquisition of Red Hat, the release of JDK 11 to the appeals court ruling against Google in its long-running battle with Oracle over Java copyrights, the latter company's implementation of its faster Java release cadence to its decision to roll up the venerable JavaOne conference (already whittled down to a subset of Oracle OpenWorld) into a new event with sessions and keynotes covering an expanded menu of languages, frameworks, tools and tech called Oracle Code One.
I reached out (as everyone covering this beat does at the start of a new year) to industry analysts, market watchers and Java jocks to find out what they coming in 2019 for this dynamic community.
Gartner analyst Ann Thomas saw the writing on the wall for Java EE, now Eclipse Jakarta, at least a year before that startling standards-body hand-off. She believes Oracle's new subscription model is going to have the biggest impact on Java in 2019.
"Oracle will no longer distribute free bug fixes and security patches except for the latest version of OpenJDK, and Oracle will be releasing new versions every 6 months," she said in an email. Although most Java applications still run on Java 8, she pointed out, users who want to get patches for Java 8 going forward must either purchase a Java Subscription from Oracle or find an alternate distribution, such as AdoptOpenJDK, Amazon, Azul, IBM, or Red Hat.
"Many of my clients anticipate that the annual subscription cost is greater than $1 million," she said. "I anticipate that this new subscription model will encourage most organizations to adopt alternate distributions, and very few organizations will ever adopt Java 11 or beyond. I believe that Java 8 is the end of the line."
She also pointed me to a Snyk survey report ("Which Java SE Version Do You Use in Production for Your Main Application? "), published in October on the JVM ecosystem in 2018, written by Simon Maple and Andrew Binstock, which I recommend.
For Michael Remijan, senior enterprise Java developer and systems architect at the Federal Reserve Bank of St. Louis, 2019 will be the year we see some unique consequences of the enterprise embrace of cloud computing.
"With IBM's acquisition of Red Hat, it is clear IBM is attempting to gain some market share in cloud computing," he said in an email. "Amazon, IBM, Google and Microsoft all seem to be battling in the space, with Amazon the clear leader at the moment. As the industry sees 'cloud computing' as the technical direction to move toward, and as these vendors try to distinguish their cloud offerings, we will see the continued rise of vendor-specific development skills and the decline of industry standards. In other words, companies will have need for Microsoft developers or Amazon developers, not necessarily Java/Jakarta EE developers."
Siddhartha Agarwal, Oracle's VP of product management and strategy usually has a savvy prediction or two at this time of year. (There's a reason I once dubbed him "Oracle's Oracle.") This year was no exception; he sent me his latest list. But one in particular stands out for the Java community: "Serverless functions go big in production."
"The appeal of serverless functions is clear: when there is demand for my code to be executed based on a certain event, a function assures it runs, but only for the amount of time that the code is needed," he wrote. "For example, someone can build a travel booking function to book/cancel flights, hotels and rental cars. Each of these actions can be built as a serverless function written in different languages such as Java, Ruby, JavaScript and Python.
"For developers, these disconnected serverless functions/transactions strung together create some new challenges, such as understanding how these functions work together to deliver a transaction, or, if things go badly during the flow, how to create compensating transactions to cancel. Debugging distributed transactions is also a challenge. But these obstacles aren't enough to stall the adoption of serverless functions, given their economic advantages of significantly reduced operations costs, from only paying for what is actually used. So more and more developers will want to move functions out of the labs and into full production. For that, look for open-source tools, like the FN project, to flourish by helping developers manage composition and debugging, to be able to deploy and test serverless functions on your laptop, or across any cloud. The key is going to be picking a serverless platform that provides maximum portability."
Ivar Grimstad, a Java Champion, Oracle Groundbreaker Ambassador and JUG Leader working as Principal Consultant for Cybercom Group in Sweden, also offered his predictions for the coming year.
"I think we will see the industry embracing the faster release cadence of Java to a higher degree than so far," he said in an email. "I think most organizations were caught a little off guard when the new cadence was introduced and continued acting as they always have done regarding major versions, i.e. reluctantly and still thinking in terms of a required corporate standard VM version. Following the increasing use of container technology, I think we will see more and more organizations lax in this requirement and allow the use of different Java versions. Thus the adoption of newer Java versions will accelerate.
"As for Jakarta EE, I think that 2019 will be the year it really takes shape and we will see enterprise Java evolving in the open. I think we will continue to see a lot of discussions about how the relationship with the Eclipse MicroProfile projects will be."
Forrester analysts John Rymer and Jeffrey S. Hammond pointed me to a report, "Predictions 2019," published by the firm in November, which I recommend. Hammond added a personal observation:
"Based on our client inquires, we're going to see a lot of development shops scrambling to retest and recertify their apps on OpenJDK 8 or OpenJDK 11, to avoid the unanticipated support bills they seem to be getting from their Oracle reps," he said. "There will also be a lot of clients pressuring their third-party ISVs with Java dependencies to do the same, and I'd not be surprised to see net-new sales of 3rd party software sales held up if the ISVs don't certify on OpenJDK."
Two succinctly noted insights from the report that will apply to developers of every stripe in the coming year: "Agile and DevOps are the New Normal for Developers;" and "Cloud-Native, Value Stream and AI-Based tools Are Among the Next frontiers."
Look for my interviews with Eclipse Foundation leader Mike Milinkovich and JCP Chair Heather Van Cura, coming later this month.
Posted by John K. Waters on January 3, 20190 comments
Java developers can now run Gradle builds with JDK 11. The latest milestone release of the popular open source build automation tool (Gradle 5.0) also comes with a production-ready Kotlin DSL, dependency version alignment, and task timeouts, among a long list enhancements and upgrades.
The true headline grabber in this release is the inclusion of Kotlin DSL 1.0. The Kotlin DSL (domain-specific language) provides an alternative syntax to the traditional Groovy DSL (originally introduced in the earliest versions of Gradle) through an "enhanced editing experience" in supported IDEs (according to the Gradle Kotlin DSL Primer). The Kotlin DSL is currently fully supported by two IDEs: IntelliJ IDEA and Android Studio, but other integrated development environments can import and work with Kotlin-DSL-based builds.
Authoring build logic using Kotlin provides "significant additional editing assistance in IDEs," the Gradle teams said in a blog post, "including: improved completion, error highlighting, and refactoring tools ... . "If you prefer the flexibility and dynamic features of Groovy, that's totally okay -- the Groovy DSL will not be deprecated," they added.
The introduction of dependency version alignment in Gradle 5.0 is also an attention getter in this announcement. This capability allows different modules belonging to the same logical "platform" or set of modules that "work together," either because they are published as a whole or because a test showed that they work together, as the Gradle Docs page explains it.
But Java jocks will be happy to learn about the JDK support in this release. The original Gradle plugin focused on Java, Groovy, and Scala, and it's still considered a leading build system for the JVM.
Gradle has always supported build automation across multiple languages and platforms, starting with Groovy, Java, and Scala, but now including Android and C/C++. The system is closely integrated with several development tools and continuous integration servers, including Eclipse, IntelliJ and Jenkins.
The Gradle team has published a detailed guide for developers who need to migrate older Gradle 4.x builds to Gradle 5.0. ("Keep in mind there are some breaking changes and considerations for any developer moving from 4.x up," they wrote.) There's also an installation guide available on GitHub for new developers who want to start using Gradle.
A one-hour, live webcast, "What's New in Gradle 5.0," featuring Gradle Developer Advocate Jenn Strater and Gradle Developer Experience Lead Eric Wendelin, is scheduled for Nov. 29. Register here.
Posted by John K. Waters on November 28, 20180 comments
The recent announcement that Amazon Web Services (AWS) will be providing Java developers with a no-cost, fully supported OpenJDK distribution came as welcome news in the face of Oracle's decision to end free long-term support for OpenJDK after January 2019. Dubbed Amazon Corretto, the new dev kit comes with long-term support that Amazon says will include performance enhancements and security fixes.
Arun Gupta, principal open source technologist at AWS, described Corretto in a blog post as a "multiplatform, production-ready distribution of OpenJDK," which Amazon has used internally on "thousands of production services." And he addressed the support issue directly.
"Many of our customers have become concerned that they would have to pay for a long-term supported version of Java to run their workloads," he wrote. He pointed to the AWS "re-affirmation" in October that the organization will continue to provide free long-term support for the OpenJDK 8 and OpenJDK 11 Java runtimes in Amazon Linux 2 "at least" through June 30, 2023. Amazon Corretto, he wrote, will receive no-cost, long-term support, with quarterly updates that include bug fixes and security patches. AWS runs the Technology Compatibility Kit (TCK) on each Corretto release to ensure compatibility with the Java SE platform, he said.
"We downstream fixes made in OpenJDK, add enhancements based on our own experience and needs, and then produce Corretto builds," Gupta said. "In case any upstreaming efforts for such patches is not successful, delayed, or not appropriate for OpenJDK project, we will provide them to our customers for as long as they add value. If an issue is solved a different way in OpenJDK, we will move to that solution as soon as it is safe to do so."
AWS will also provide "urgent fixes" to customers outside of the quarterly schedule, he said.
Gupta included a supporting quote from James Gosling in his post. Gosling, who created Java back in 1994, joined AWS earlier this year as a distinguished engineer. "Amazon has a long and deep history with Java," the quote reads. "I'm thrilled to see the work of our internal mission-critical Java team being made available to the rest of the world."
Gosling led the official unveiling of the preview release of Corretto (called Corretto 8 and corresponding with OpenJDK 8) at the Devoxx BE conference in Antwerp, Belgium. Not surprisingly, he has been promoting the news on Twitter, where he describes Corretto as "the externalization of the OpenJDK distribution that Amazon uses internally," adding: "If you're an Amazon customer, you're almost certainly using Corretto already."
The Corretto 8 preview is available now for Amazon Linux 2, Microsoft Windows, and macOS platforms and Docker image. The company is planning for a General Availability release in the first quarter of next year. That release will include support for Ubuntu and Red Hat Enterprise Linux platforms, Gupta said. Corretto 11 builds corresponding with Open JDK 11 on these platforms will follow "with ample time for testing" before April 2019, he said.
The source code for Corretto available on GitHub. Corretto 8 is available for download. Documentation can be downloaded here.
Posted by John K. Waters on November 26, 20180 comments
Information security provider Imperva has been in the headlines recently, thanks to news that tech investment firm Thoma Bravo LLC plans to acquire it. But the Redwood Shores, Calif.-based company caught my eye again last week when it announced that it has open sourced a new Java SDK designed to simplify interaction with Microsoft's Active Directory (AD) for small, medium and large development projects using LDAP.
The company created the SDK, which it christened Domain Directory Controller (DDC), as an internal library to help its devs with hassles associated with Microsoft's AD.
"[I]n order to communicate with an AD server," Gabi Beyo, principal engineer at Imperva, wrote in a blog post, "we'd have to handle a host of issues manually: connection retries, switching between primary and secondary servers, performing queries against multiple servers, paging results, and several other known-issues which might not be directly related to the task at hand. An additional pain in the neck was the LDAP protocol we'd have to learn and understand in order to perform our queries against the AD server."
The SDK the company developed to solve these problems comes with a "friendly" API designed to allow developers to quickly compose simple, or complex queries against AD's endpoints without any previous LDAP knowledge, Beyo explained. "The goal of this library is to enable easy interaction with any LDAP Directory Server by hiding all the related communication issues and internal bits-and-bytes," he wrote.
The SDK was an immediate hit with Imperva's developers, the company told me in an e-mail, and the decision was made to open source it. Internally, DDC makes use of apache-directory-ldap API and builds on it with a host of enhancements, which Beyo listed in his blog post:
- Assemble LDAP queries easily via an Object-Oriented syntax instead of concatenating and parsing strings
- Although DDC currently supports Microsoft Active Directory only, it was designed to be easily extended to fit any other LDAP implementation
- Easy Paging API
- Change Requests: Add, Remove, Replace AD's objects
- Secured connection
- Perform automatically connection retries in case of failure
- Automatically resolve host to IP
Support search in Multiple AD servers
- Support Primary & Secondary AD servers
Beyo provides some examples of how Imperva has used the SDK in his blog post, and it's well worth reading.
The source files, full documentation, and a starter kit project for Imperva DDC can be found on GitHub in Imperva's official Open Source repository.
Posted by John K. Waters on November 14, 20180 comments
The Java Community Process (JCP), the standards-development organization for Java technology, has posted the nominees for the 2018 Fall Executive Committee (EC) election. Eight seats are open for this election, including 8 Ratified, 3 Elected and 1 Associate.
The EC oversees the work of the Expert Groups that define Java specifications, essentially guiding the evolution of Java. The committee picks the JSRs that will be developed, approves draft specs and final specs, approves Technology Compatibility Kit (TCK) licenses, approves maintenance revisions and occasionally defers features to new JSRs, approves transfer of maintenance duties between members, and provides guidance to the Program Management Office (PMO).
The EC comprises 16 Ratified Seats, 6 Elected Seats, and 2 Associate Seats, all serving a two-year term, as well as a permanent seat held by Oracle America, the official steward of Java. The Ratified Seats are filled by Full Members nominated by the PMO; the Elected and Associate Seats are filled by members nominated by Full and Partner Members.
This will be the third EC election held under JCP 2.10 rules implemented in 2016. The JCP now offers three membership levels: the Associate level, for unaffiliated individuals; the Partner level, for Java User Groups and other non-profit organizations; and Full Membership, for "legal entities who wish to join Expert Groups, lead JSRs, and/or vote or serve on the Executive Committee."
The list of this election's candidates includes:
- Ratified Seats:
- Kingsum Chow, Chief Scientist at Alibaba
- Jackie Haynes, who works in the core engineering group at Godman Sachs
- Trisha Gee, a Java Champion and Java Developer Advocate at JetBrains
- Hendrik Hoefer, co-founder/technical director of MicroDoc ComputerSystems GmbH
- Volker Simonis, a long-time OpenJDK contributor who works on Java/JVM technologies at SAP
- Prasad Yendluri, Vice President Product Development at Software AG
- Donald Raab, Managing Director and Instructional Coach on the Shared Services Team at the Bank of New York Mellon
- Leonardo Lima is CTO at V2COM
- Elected Seats:
- Gil Tene is CTO and co-founder at Azul Systems
- Simon Ritter is Deputy CTO at Azul Systems
- Janine Patterson, President of the Chicago Java Users Group
- Mike Milinkovich, Executive Director of the Eclipse Foundation
- Martijn Verberg, co-leader of the London Java User Group
- Associate Seats:
- Joseph Aruja
- Marcus Biel
- Ivar Grimstad
- Ceyhun Erturk
The JCP hosted a "Meet the JCP EC Candidates" Birds of a Feather (BOF) session at the Oracle Code One conference in San Francisco last week. The JCP is also planning a meet-the-candidates conference call for this Thursday, Nov. 1, at 10 AM PDT. The candidates' statements are available on the JCP Web site.
Posted by John K. Waters on October 31, 20180 comments
What's in a name? Not much, apparently, as Oracle proved last week with its inaugural Code One event, which replaced the venerable JavaOne user conference, in name mostly. The event included a ton of Java content -- sessions, events, keynotes -- with some new tracks aimed at developers building databases-focused apps and MySQL developers. The program also includes sessions on such languages as Go, Rust, Python, JavaScript and R.
The conference included the all-important Java Technical Keynote on Monday evening, with presentations by Mark Reinhold, chief architect of the Java Platform Group, and Georges Saab, VP of Development, who talked about Java SE updates from the last 12 months, including Java 11, as well as future projects.
For his part of the keynote, Saab focused on the challenge of "preserving Java's virtues," by which he meant the free and open community in which Java has evolved. He also talked about Oracle's contributions to that community, including the open sourcing of such Java platform features as Application Class-Data Sharing, the Z Garbage Collector, Flight Recorder and Java Mission Control.
Matthew McCullough, VP of Field Services at GitHub, gave a presentation in which he talked about the importance of OpenJDK and discussed Project Skara, a prototype GitHub-based mirror of the official OpenJDK upstream Mercurial repositories.
But it was Reinhold's presentation that really brought the "JavaOne" to Code One. Everyone's favorite Java Uber Geek started with a discussion about the impact of the new rapid release cadence for Java SE and the JDK, through which Oracle is now "evolving the Java platform at a more rapid pace."
"We've broken a few things, and we will continue to do so," he said, "but in a careful measured way, in order to make Java a better fit for modern applications.'
Attendees got a real sense of the spirit of JavaOne as Reinhold dispelled five misconceptions about how Java is changing. His list included:
- Every feature release will be as disruptive as past releases: "No, that's not true. The rate of innovation hasn't changed. What's changed is the rate of innovation delivery."
- Non-LTS (long-term support) releases are just a fancy name for a beta: "No. The only difference with an LTS release is it has a longer support timeline. You can use a non-LTS release in production if you like, but know that you'll have to update it in six months, or find someone to support it, or perhaps support it yourself."
- To remove an old feature, it must be deprecated three years in advance: "False. To remove a deprecated feature requires a production-ready build that issues a suitable warning at either compile time or runtime -- because a working build, after all, is the ultimate release method."
- If you maintain an infrequently migrated system you can ignore the non-LTS releases: "That would be a bad plan ... If you test with each feature release, then you'll be ready to migrate to the next long-term support release."
- You can't get more than six months of support for any non-LTS release and never more than three years for any LTS release: "Not true. It all depends on what the non-Oracle members of the JDK community decide to do. They have a proven track record and are already discussing how best to support JDK 8 and JDK 11 for the long haul."
He also made his own strong case for Oracle's approach to open Java. "Oracle builds and OpenJDK builds are at this point functionally interchangeable," he added. "This means that you can switch from one to the other as you please. It also means that all of this code is available under the GPL for anyone to build, test, publish, update and support."
And he covered a number of OpenJDK projects Oracle is pursuing to enhance the language, including Project Valhalla (more efficient JVM memory usage), Project Panama (improving C APIs for interacting with the JVM), Project Amber (making Java more "terse" through the addition of features, such as switch expressions and raw string literals) and Project Loom (a lightweight alternative to threads called "fibers" designed to be more efficient for concurrent code).
All in all, a very Java conference, and with the language and platform evolving in so many directions, it's probably the best we can hope for.
Posted by John K. Waters on October 31, 20180 comments