MORE ON THIS TOPIC Java in 2020, Part 2: Anne Thomas on Java Subscription, Jakarta and MicroProfile Wait, what? Java's not dead? Irrelevant? Replaced by Kotlin? Python? (Swift?)
Nope. Java weathered the predictions of its demise yet again, and though it missed being named TIOBE's programming language of the year for the second year in a row (good old C earned that title, which tells you something about this Who's the Most Popular dance), it remains one of the world's most valuable and widely used languages and platforms.
Once the holiday dust has settled and the annual prediction parade has rounded the corner, I like to get a few comments from Java community leaders and industry watchers about where we've been and where we're going in the coming year -- especially now, as we start a new decade (or end an old one, depending on how picky you are about when we started counting).
Heather VanCura, chair of the Java Community Process (JCP), sees 2020 as the year developers and vendors, now fully adapted to the faster Java release cadence, take full advantage of the more incremental release schedule.
"I spent a lot of my time in 2019 demonstrating, teaching and working with developers and teams about the practices they can implement to take advantage of all the new things happening in Java," VanCura said. "With the more incremental releases, they have a chance now to learn and study some of the smaller innovations that get missed in the bigger releases. Java 9, for example, had hundreds of new features, but everyone focused on modularity. The more digestible releases give people the opportunity to really focus on the benefits of those features."
Among the trends the JCP is addressing in the coming year, AI and machine learning are probably the buzziest.
"AI and machine learning definitely come up in most of the conversations I'm having these days," she said, "and people are excited about the technologies, and they want to know how they can leverage their Java skills in that space. We're definitely looking at how to optimize Java to do well for this kind of development. We have a JSR [Java specification request] on visual recognition. The work Brian Goetz is doing with Project Panama looks promising. And with the new release cadence, we don't have to wait for that project to be finished. Whatever comes out of it over time will be integrated into the platform."
"It's less now about the version and just more about what's happening with Java in the moment," she added. "Java is a living, breathing thing that is continuously evolving to meet the needs of developers."
Georges Saab, VP of software development in the Java Platform Group at Oracle, agrees that people are finally getting used to the faster release cadence Oracle implemented for Java. And he said we're starting to see a significant transition from the Java 8 long-term support (LTS) release to the Java 11 LTS. And once people make that big jump, the move to the six-month releases (Java 12 and 13) will be much easier.
"That's the big trend I see continuing in 2020," Saab said.
He also predicted that three projects -- Valhalla, Amber and Panama -- will bear fruit in increments over the next six months. He also sees the evolution of Java over the next year moving the language and platform into even more cutting-edge areas, such as AI and microservices.
"I'm really optimistic about things right now," he said. "From where we are, both with the technology and my group at Oracle, things have never been better. There's a lot of experimentation happening with things like Valhalla and with other languages. I think most of the major changes and investments we've made in things like modularization, the faster release cadence and the subscription offering, both from us and the other players in the Java space, have put Java in a place where we're poised to take the next steps that are really going to help people see that Java is something that's worth their continued investment."
Enterprise Java is now fully relocated to the Eclipse Foundation, and the Eclipse Jakarta EE 8 specification was released in August. The plan for Jakarta EE 9 is evolving quickly, with a "big bang" approach to package naming -- switching everything from javax.* to jakarta.* all at once -- in the offing. Mike Milinkovich, the Eclipse Foundation's executive director, sees 2020 as the year Eclipse really starts delivering on the promise of this new stewardship.
"Once we get everything into the Jakarta namespace, this year will be about innovation," Milinkovich said. "That's the theme for Jakarta in 2020. Eclipse MicroProfile has been delivering innovation since its inception, and that will continue. And this looks to be an exciting year for frameworks, like Quarkus."
Milinkovich also expects to see tighter integration between the Java and Kubernetes communities.
"I think there's a real opportunity there to help bring together the largest enterprise developer ecosystem -- that's Java -- with the fastest growing infrastructure ecosystem -- that's Kubernetes," he said. "I think there's a lot of potential there in bringing these two technology platforms and communities into tighter alignment. It solves problems that folks in each community have. Kubernetes is a fantastic infrastructure, but it's not necessarily the easiest to develop for. The Java ecosystem brings millions of developers and a generation of experience in building enterprise systems. Kubernetes brings relevance in this new cloud-data world. The potential for tighter synergies between those two platforms and communities is going to be something to really watch in 2020."
Milinkovich's message to developers: "Java is going to be around for a long time, and I see an amazing alignment of vendors, communities and innovation. Keep your skills up with the new things happening in Java. There's no reason for you abandon the skills you have today in Java for some shiny new toy."
Posted by John K. Waters on January 15, 20200 comments
A number of small companies and tech organizations joined the Mozilla software community in a friend of the court brief, filed this week, urging the Supreme Court of the United States (SCOTUS) to reverse a federal circuit court's decision that Google infringed on Oracle's copyrights to Java code in its Android mobile operating system.
The list of organizations on the Mozilla amici curiae includes Medium, Cloudera, Creative Commons, Shopify, Etsy, Reddit, the Open Source Initiative, Mapbox, Patreon, the Wikimedia Foundation, and the Software Freedom Conservancy.
"Competition and innovation are at the heart of a healthy internet and the field of software development that fuels it," the brief states. "For decades, software engineers have relied heavily on reimplementation, including reuse of functional protocols such as the software interfaces in this case, to create competing alternatives to incumbent industry players and develop new markets without fear of copyright infringement…."
The federal court's ruling against Google "upended decades of industry practice and the well-established expectations of developers, investors, and consumers," the brief states. the brief urges the Court to reverse the lower court's finding that the structure, sequence, and organization ("SSO") of Oracle's Java API package was copyrightable, and also that Google's use of that SSO was not a "fair use" under copyright law.
The brief makes its argument from the perspective of small, medium, and open-source tech organizations, said Abigail Phillips, head of the Mozilla Foundation's legal department, in a blog post. "Mozilla believes that software reimplementation [the process of writing new software to perform certain functions of a legacy product] and the interoperability it facilitates are fundamental to the competition and innovation at the core of a flourishing software development ecosystem."
The federal court's ruling would upend the tradition of reimplementation "not only by prohibiting it in the API context of this case," Phillips wrote, "but by calling into question enshrined tenets of the software industry that developers have long relied on to innovate without fear of liability."
The consequences of a ruling against Google are especially dire for small software developers, she wrote, who are already disadvantaged in the industry by their size and relatively limited resources. The result would be fewer innovations from small companies and a reinforcement of the positions of the tech industry's largest enterprises, as well as a "decline in incentive" among the big companies to improve their products.
"We believe that a healthy internet depends on the Supreme Court reversing the Federal Circuit and reaffirming the current state of play for software development, in which copyright does not stand in the way of software developers reusing SSOs for API packages in socially, technologically, and economically beneficial ways," the brief states.
In November, SCOTUS agreed to decide whether Google should have to pay Oracle billions of dollars for infringing on its copyright of 37 Java APIs Google used in its Android operating system. (Our earlier report includes a summary of the long history of this case, which started when Oracle sued Google in 2010.)
Google, which is a subsidiary of Alphabet, Inc., filed a writ of certiorari with the Supreme Court last year, asking for a review of the earlier judgment of the U.S. Court of Appeals for the Federal Circuit in this case. Google described the dispute as "the copyright case of the decade."
"Above and beyond the broader implications for copyright law, this case warrants the Court's attention for its sheer practical importance," the petition reads in part. The ruling "…threatens the prevailing approach to building computer software…"
The court granted the certiorari. Google filed its opening brief last week.
Oracle is seeking $8.8 million in damages from Google for what it sees as the "epitome of copyright infringement," which has done "incalculable market harm."
Kent Walker, Google's SVP of Global Affairs and Chief Legal Officer, wrote a blog post, stating his company's position. And the Business Insider has reported that IBM will be supporting Google with its own brief this week.
Posted by John K. Waters on January 14, 20200 comments
The Java EE Guardians, the all-volunteer organization formed in 2016 to secure the continuing evolution of enterprise Java, is considering a name change -- and not just because "Java EE" has become "Jakarta EE." With the platform now securely evolving under the stewardship of the Eclipse Foundation, the members don't feel they have much to guard these days. In fact, they feel more like ... ambassadors.
The renaming of the organization to The Jakarta EE Ambassadors is all but a done deal, and it's clearly a milestone in the evolution of enterprise Java and the Guardians' years-long effort to save it from Oracle's neglect. So, I reached out to members of the organization to ask about the process of choosing a new moniker and the group's changing mission.
"'Guardians' was appropriate for the change in stewardship and governance, because many who relied heavily on the Java EE standard had a sense the transition may go awry," said Dennis Gesker, CTO at Alamon, Inc., in Kalispell, Missouri. "But, boy, things are looking good, and I think it's a positive development that this trepidation has eased. There's traction in EEs new home, and it's moving forward under the new governance model."
Ondrej Mihályi, a Prague-based engineer at Payara, said "Ambassadors" received a wide consensus within the Java EE Guardians community very quickly. In fact, no other names were proposed that were popular enough to compete with it.
The Guardians got an assist in their name selection from the Eclipse Foundation, Mihályi explained. "The new name was actually suggested by the Eclipse Foundation, which means there are no legal obstacles to using it."
"I can't remember who suggested 'Ambassador,' but I think it captures the right tone," said Mike Milinkovich, the Foundation's executive director. "As a community-based, member-supported organization, we don't feel that Jakarta EE needs to be 'guarded' from the Eclipse Foundation, and we're happy to see that they agree."
The renaming sends a signal that a core part of the Java EE community is ready to embrace the Jakarta EE transition, said Reza Rahman, principal program manager for Java on Azure at Microsoft, and a founding Guardian. "There is no reason to think Jakarta EE should not surpass Java EE in adoption and relevance," he said, "though there is clearly work to be done ahead."
And what exactly will that work entail? What will be the role of The Ambassadors in the Jakarta EE era?
"The next step for the group is to begin to strengthen and rebuild the community around the technology," Rahman said, "as well as contribute directly towards accelerating multilateral, forward momentum, now that the transfer from the JCP is complete."
"We will continue to ensure that the community's voice is heard," said Josh Juneau, application developer, system analyst, and database administrator at the Fermilab particle physics and accelerator laboratory in Illinois. "We want to make sure that it's not only the big vendors who are being heard."
Gesker agreed that a key role of the Ambassadors going forward will be to represent the smaller members of the enterprise Java community in the governance of the platform. "The big guys -- Oracle, IBM, etc. -- have the resources to directly represent themselves," he said. "So, yes, a group that represents the needs and concerns of little shops and individuals, acting and communicating in a positive and constructive manner, is a good thing, and the branding should reflect that."
The Ambassadors will also continue to promote enterprise Java, said Mihályi "We hope to help promote Jakarta EE, spread word about it, teach it, represent the voice of the user community, and positively influence the evolution of Jakarta EE and related processes within the Eclipse Foundation," he said.
Milinkovich acknowledged the "instrumental" role the Guardians played in raising awareness of issues related to Oracle's stewardship of the Java EE Platform. Their work has, in fact, also helped Oracle, other Java EE vendors, and the community to "achieve what many considered impossible: the migration of Java EE to an open, vendor-neutral, community-based organization."
"We're thrilled that the Java EE Guardians will be renamed as the Jakarta EE Ambassadors," he added. "Having this group advocating for this important technology will be a key part of our community's success going forward. Plus, I am sure that, regardless of what they're called, if they think we're messing something up, they won't be shy in telling us so!"
Posted by John K. Waters on November 6, 20190 comments
Google researchers claimed to have reached a major milestone in the evolution of quantum computing called "quantum supremacy" in a paper published last week in the journal Nature. IBM quickly disputed that claim in a blog post that threw shade on the Alphabet subsidiary's conclusions. The headlines they generated notwithstanding, the claim and counterclaim involve a branch of computing most industry watchers say is still in the budding stage, so why should anyone care who's right?
"Whether or not Google achieved true quantum supremacy or it's more like quantum advantage, what's exciting here is that what they did shows real progress," said Gartner analyst Matthew Brisse. "Assuming the paper survives scrutiny by all the academic folks, this is a fantastic achievement by Google."
Brisse is a Research Vice President for the Data Center and Cloud Infrastructure group within the Gartner for Technical Professionals service. He provides strategic and technical advice for CIOs and tech pros on a range of topics, including quantum computing. Gartner currently has several analysts tracking 62 companies in the quantum computing space, he said, from hardware and software providers to consultants.
"Our guidance to CIO's is that they shouldn't ignore this space, because it's likely to be a real competitive differentiator in five to ten years," he said. "But they wouldn't want to go all in just yet, because it's not clear exactly what it's going to do for them. Let the hardware and software mature, let the algorithms start unfolding. But don't throw a lot of money at it now."
Developers, however, should take the leap sooner rather than later, Brisse advises.
"If you're a programmer interested in quantum computing, get involved now," he said. "Take advantage of the free quantum systems that are available -- things like Microsoft's QDK, D-Wave System's Ocean SDK, Rigetti's Forest SDK, and IBM's Qiskit. Microsoft has developed a domain-specific programming language for expressing quantum algorithms called Q#. And there's a plethora of libraries out there. They should check out the Quantum Algorithm Zoo, for example, which is a repository of quantum algorithms."
The Quantum Open Source Foundation maintains a curated list of open-source quantum software projects on GitHub. Last month, IBM opened a quantum computational center in Poughkeepsie, New York, designed to "support the growing needs of a community of over 150,000 registered users and nearly 80 commercial clients, academic institutions, and research laboratories to advance quantum computing and explore practical applications," the company said in a statement.
Another reason to get started now, Brisse said, is that quantum computing is complicated. It takes time to learn quantum computing algorithm development, and mapping business problems to quantum computing is difficult to get right. Plus, there's a lot of physics involved.
"There's a shortage of physicists in the industry today who know computers and business," Brisse said. "So we're seeing organizations like Microsoft and IBM actually going into the universities and cultivating a new type of quantum computing engineer."
Gartner defines quantum computing as a type of "nonclassical" computing that operates on the quantum state of subatomic particles. The particles represent information as quantum bits (qubits). In classical computing, bits represent information as either 0s or 1s; qubits represent both at the same time until they are read, thanks to a quantum state called superposition. Qubits can be linked with other qubits, thanks to another quantum property called entanglement. As Gartner explains it, "Quantum algorithms manipulate linked qubits in their undetermined, entangled state, a process that can address problems with vast combinatorial complexity."
In other words, quantum computing has the potential to solve some of mankind's greatest technical and scientific puzzles and problems. That potential might explain why companies like Google, IBM, Intel, and others are investing heavily in the technology. An analysis by Nature found that in 2017 and 2018 quantum technology companies received at least $450 million in private funding, a fourfold increase from the $104 million of the previous two years.
So Google's efforts are about more than just bragging rights to the coveted quantum supremacy, a kind of black belt earned by computing devices that can solve problems no classical computer can handle. (Quantum advantage is the brown belt; faster, but not unbeatable, though it's sometimes used as a synonym.) In that peer-reviewed Nature article, Google researchers describe how a team led by experimental physicist John Martinis used Google's Sycamore, a 53-qubit quantum processor, to solve a random number generation problem in 200 seconds, a calculation they said would take a state-of-the-art supercomputer 10,000 years to complete.
"For those of us working in science and technology, it's the 'hello world' moment we've been waiting for," wrote Google CEO Sundar Pichai in a blog post, "the most meaningful milestone to date in the quest to make quantum computing a reality."
In its quickly published rejoinder, IBM claimed that its Summit supercomputer, which it built for the Department of Energy, can do the calculation in two and a half days with greater fidelity.
"This is, in fact, a conservative, worst-case estimate, and we expect that with additional refinements the classical cost of the simulation can be further reduced," Big Blue's team wrote. "Because the original meaning of the term 'quantum supremacy,' as proposed by John Preskill in 2012, was to describe the point where quantum computers can do things that classical computers can't, this threshold has not been met."
Preskill, a professor of theoretical physics at the California Institute of Technology, wrote about Google's claim and the apparently controversial term he coined in a recent Quanta Magazine column. He regrets how the word "exacerbates the already overhyped reporting on the status of quantum technology," he wrote. But that didn't stop him from coining another term a few sentences later. The term is "NISQ," which rhymes with "risk" and stands for "noisy intermediate-scale quantum."
"Here intermediate-scale refers to the size of quantum computers that are now becoming available: potentially large enough to perform certain highly specialized tasks beyond the reach of today's supercomputers," he explained. "Noisy emphasizes that we have imperfect control over the qubits, resulting in small errors that accumulate over time; if we attempt too long a computation, we're not likely to get the right answer."
"The Google team has apparently demonstrated that it's now possible to build a quantum machine that's large enough and accurate enough to solve a problem we could not solve before," he added, "heralding the onset of the NISQ era."
Posted by John K. Waters on October 29, 20190 comments
Google says the Supreme Court should ignore the recent recommendation of the Solicitor General of the United States, which advised the court to refuse to review a 2016 appeals court's rulings that Google infringed on Oracle's copyrights to Java code in its Android mobile operating system.
Google filed a writ of certiorari with the Supreme Court earlier this year, asking for a review of the judgment of the U.S. Court of Appeals for the Federal Circuit in this case. Then, last month, the Solicitor General filed an amicus curiae brief to express the views of the United States that Google "identifies no sound basis for further review” by the court.
That this nine-plus-year-old case is still alive should surprise no one. If that earlier ruling stands, Google and its parent company, Alphabet, lose billions—$8.8bn to be exact; if it's overturned, Oracle won't recover the billions it claims to have lost.
Still, the argument Google made in a supplemental brief, filed last week, is a reminder that money isn't the only thing at stake here, and that the company's position is shared by some thoughtful people.
"The Solicitor General's further effort to cabin the Federal Circuit's fair use ruling as fact-bound is refuted by the 175 individuals, companies, and organizations that filed 15 amicus briefs in support of the petition to explain that it is imperative that this Court grant certiorari,” Google's petition reads. "Those submissions recognize that the Federal Circuit has effectively prohibited the widely accepted industry practice of reimplementing software interfaces, inevitably causing serious harm to current practices and future innovation in the software industry.”
But the SG's response to Google's argument is worth keeping in mind: "[L]ower courts have wrestled with issues, not presented here, about whether making temporary copies of existing code to ‘reverse engineer' a system, in order to create compatible works that do not incorporate the pre-existing code, constitutes fair use…. But here, petitioner took lines of code from a rival software platform to make a competing platform that is not interoperable with the Java platform.”
Following this story has been improving my vocabulary -- and not just my Latin. Who knew "cabin” could be used as a verb? (It means "confine within narrow bounds.”) And it has been a long haul. Oracle originally sued Google in 2010, and the search engine giant's argument that its use of 37 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 opinion.
Why doesn't the U.S. Solicitor General, Mr. Noel Francisco, feel compelled to weigh in on this case? Judging from the amicus curiae brief, he buys Oracle's argument, but why get involved in this long, long battle? My calls to the SG's office were not returned by press time, but it's a good question, so I'll keep asking, though I'm pretty sure the end is near.
Update: The Solicitor General hasn’t returned my calls, but a reader sent me an email answering my question. The SG is responding to an order from the Court itself requesting his views on whether the Court should hear the case. Here’s a link to the April 29 order list. Apparently, the Court gets a lot of these. Also, Hannah Coleman, who was an intern at the National Immigration Law Center at the time, wrote a nice article in 2017 explaining how a “Call for the Views of the Solicitor General” (CVSG) works. “Even though CVSGs are described as ‘invitations,’ the Solicitor General’s Office views them as orders, and the Solicitor General responds to every invitation it receives from the Supreme Court,” she wrote.
Posted by John K. Waters on October 23, 20190 comments
The Eclipse Foundation announced the released the Eclipse Jakarta EE 8 specification just over two months ago and we’re already seeing the solidifying outlines of Jakarta EE 9 -- not especially fast by current release-cadence standards, but warp speed when you consider how enterprise Java had languished before the Foundation accepted the stewardship of the platform two years ago.
Oracle software architect and Eclipse committer Bill Shannon posted his company’s proposed plan for Jakarta EE 9 on October 1 on the jakartaee-platform-dev mailing list, sparking a great deal of discussion in the community. About a week later, he returned to the mailing list with a “recast plan” based on the feedback he received.
“Nothing here is final,” he wrote in that first post, “and we're open to discussion on all these items. Feedback is strongly encouraged. Counterproposals are welcomed. Our intent is to put a stake in the ground to start the planning for Jakarta EE 9.”
Shannon’s subsequent post included a bunch of changes, which suggests that Big O won’t be bigfooting the process. He received the most feedback, said, around the removal of SOAP support.
“I think we've adequately explained that products can continue to provide SOAP support based on the Jakarta versions of the corresponding specifications,” he wrote, “which will have no changes to their APIs and will continue to use the javax namespace.”
If platform project committers believe SOAP support must be included in version 9, he added, they should speak up now, but also keep in mind that including SOAP support “would have a significant impact on the amount of work to be done for Jakarta EE 9.”
Oracle’s modified plan would “prune” several specs from the version 9 release, including:
-
Jakarta XML Registries
-
Jakarta XML RPC
-
Jakarta Deployment
- Jakarta Management
= -
Jakarta Enterprise Bean entity beans
-
Jakarta Enterprise Bean interoperability
- Jakarta Enterprise Bean 2.x and 1.x client view
- Jakarta Enterprise Web Services
The plan would also not add some API’s corresponding to Java SE 8 APIs, including:
- Jakarta XML Web Services
- Jakarta SOAP Attachments
- Jakarta Web Service Metadata
- CORBA and RMI-IIOP
Two APIs corresponding to Java SE 8 APIs will be added to Jakarta EE 9:
- Jakarta XML Binding
- Jakarta Activation
Oracle favors the “big bang” approach to package naming -- switching everything from javax.* to jakarta.* all at once.
Some sort of backwards compatibility will be required, of course, to allow existing applications to work unchanged on Jakarta EE 9 products using the jakarta.* namespace, but Oracle is against defining that backwards compatibility in a Jakarta EE spec.
“We strongly encourage the creation of an open source project to produce backwards compatibility support that can be shared by multiple implementations of Jakarta EE 9,” Shannon wrote.
Although no additional profiles are being proposed for Jakarta EE 9, Oracle is apparently open to the idea of creating two additional profiles “to help additional vendors enter the Jakarta EE market.”
“We believe that the need of developers to ‘right-size’ their application deployment is best addressed by the use of Java platform modules, not profiles, defined by a future Jakarta EE release,” Shannon wrote.
Oracle also believes all Microprofile work should be done under the Eclipse Foundation Specification Process, should be considered additions to the Jakarta EE platform under that process, and should be deferred to a future Jakarta EE release. When and how Microprofile APIs should be added to the Jakarta EE platform is “an open issue.”
Big O is also backing what appears to be strong community support for the idea of splitting up the Jakarta EE TCK project, so that each specification project can manage its own TCK. But the company believes the work involved would be too much to include that change in this release.
“Possibly incremental progress can be made in the Jakarta EE 9 timeframe,” Shannon allowed. “It's essential that work in this area not make it more difficult to test a Jakarta EE 9 product.”
Oracle also wants to keep up the pace with a Jakarta EE 9 release12 months or less after the release of Jakarta EE 8.
Posted by John K. Waters on October 22, 20190 comments
The U.S. Justice Department has urged the Supreme Court to deny Google's latest petition to review rulings that the Alphabet subsidiary infringed on Oracle's copyrights to Java code -- rulings that could cost Google billions.
This petition keeps alive the nine-year legal struggle over 37 Java APIs Google used to develop its Android operating system, which Oracle has maintained were copyrighted, and for the violation of which Oracle is demanding $9 billion in damages. The courts have gone back and forth on the issues in this case, but eventually came down on the side of Oracle's claim.
Google filed a writ of certiorari with the Supreme Court earlier this year, asking for a review of the earlier judgment of the United States Court of Appeals for the Federal Circuit in this case.
"Above and beyond the broader implications for copyright law, this case warrants the Court's attention for its sheer practical importance," the petition reads. The ruling " ... threatens the prevailing approach to building computer software ... "
Google cited changing practices among software developers to support its petition. "Developers are not coding programs entirely from scratch," the company argued, "as they may have been in the early days of programming. Instead, new programs now incorporate and rely on preexisting interfaces to trigger certain functions, which saves the wasted effort of reinventing and retesting what came before."
In late September, the Solicitor General filed an amicus curiae brief to express the views of the United States on Google's petition. "Computer code can be used in transformative ways," it reads, "such as by excerpting it in a textbook to illustrate a coding technique. And lower courts have wrestled with issues, not presented here, about whether making temporary copies of existing code to 'reverse engineer' a system, in order to create compatible works that do not incorporate the pre-existing code, constitutes fair use ... . But here, petitioner took lines of code from a rival software platform to make a competing platform that is not interoperable with the Java platform."
"Petitioner copied 11,500 lines of computer code verbatim, as well as the complex structure and organization inherent in that code, in order to help its competing commercial product. The record demonstrates, moreover, that petitioner's unauthorized copying harmed the market for respondent's Java platform ... ."
"Petitioner identifies no sound basis for further review of the fair-use issue," the Justice Department concluded.
Oracle originally sued Google in 2010, and the search engine giant'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 opinion.
The Supremes are certainly free to consider Google's petition, but they have stayed out of the fight so far. We're surely approaching the conclusion of this seemingly immortal struggle, but given what it will cost the loser, I wouldn't bet on it.
Posted by John K. Waters on October 9, 20190 comments
One of the most-mentioned keynote topics at this year's Oracle OpenWorld-adjacent Code One 2019 conference, wrapping up this week in San Francisco, was the rapid release cadence for Java SE and the JDK, which Oracle announced in 2017 and launched in March of last year.
The rapid release cadence has proved to be one of those slap-the-forehead innovations that revivified the process of evolving the Java platform. Instead of allowing years to pass between releases and putting intense pressure on, well, every contributor in the community, to deliver and bet on big, fully formed enhancements, the new process runs on a cycle that calls for a feature release every six months, update releases every quarter, and a long-term support release every three years.
"That's fast enough to minimize the pain of waiting for the next [release] train," wrote Mark Reinhold, chief architect of Oracle's Java Platform Group, in the blog post in which he first proposed the faster cadence, "yet slow enough that we can still deliver each release at a high level of quality, preserving Java's key long-term values of compatibility, reliability, and thoughtful evolution."
JDK 10 was the first feature release of the new cycle; Java 11, which was released six months later, was the first long-term support (LTS) release. The next LTS release will be Java 17, scheduled September 2021. Java 13, which went GA this week, is not an LTS release, which means it will be obsoleted with the release of Java 14 in March, 2020.
And yet it seems people are still getting used to the idea, which I suppose underscores the depth of the change. Java Language Architect Brian Goetz reminded conference attendees during his Code One keynote to remember that the rapid release cadence imposed a truly fundamental change on a long-established process.
"A lot of people, including, quite honestly, us, were pretty skeptical at first," Goetz admitted. "It seemed inconceivable that we could turn a ship as big as Java that quickly. There were even fears that Java 10 and 11 might have no features at all. But looking back, it would be really hard to overstate what a significant change the rapid release cadence has been."
Among the benefits of the new cadence, he said, are the obvious: "We can deliver value more often, and you don't have to wait as long for any particular feature to come out." And the not-so-obvious: "It has brought about this fundamental change in how we design, plan, and deliver new features by lowering the cost of a feature missing the boat. Missing by six months is a whole lot different from missing by several years. [The faster release cadence] has drastically reduced our release-management overhead internally, which allows us to spend more energy on designing and building features and less energy on managing releases."
"And at the same time, having more releases has encouraged us to learn how to break down complex features into smaller ones, so we can deliver in phases," he added. "The results, which has sort of been an unexpected one, is that our feature pipeline has become richer than it has ever been. The whole thing has been one big virtuous circle."
Adapting to the faster release cadence has required the Java community to "recalibrate our expectations," Goetz said, "about what constitutes something worth upgrading.
"In the old world, when we had these big releases every few years, and those big releases tended to have big features, like Generics and Lambda's, there was already plenty of motivation to upgrade. The reality now is, we're not going to be seeing a lot of those big features in the future. And that's not because we're not innovating. It's because those big features are going to get broken up into smaller features and delivered in phases. There's just as much innovation going on -- perhaps more -- but it's going to be spread out over a large number of smaller deliveries."
During his Code One presentation, Georges Saab, VP of Oracle's Java Platform Group and OpenJDK chairperson, also reminisced about the launch of the new release cadence into skeptical waters.
"Many folks were excited about the faster cadence," he said. "Many folks were apprehensive about it. And there are a lot of people who were actually both ... . Some of the most apprehensive people were on my team at Oracle working on Java! When we floated the idea of six months releases, they really thought I was crazy. They said because of the Java Community Process (JCP), through which the Java platform evolves, it just takes too long. This process requires that there be a specification, a reference implementation, and a certified compatible testing kit ... .But I had faith that, like us, many in the JCP Executive Committee (EC) wanted to see a faster and more gradual evolution of Java."
And then he brought out the big guns: Bruno Souza, leader of the Brazilian Java community known as SouJava, and Gil Tene, CTO and co-founder of Azul Systems, maker of the Zing Java runtime, among other products, the only vendor focused exclusively on Java and the JVM. Both are JCP EC members. (The lively Souza wore a cape that has yet to be explained.)
Tene said he and the other EC members were very skeptical when they first heard about the rapid release cadence for Java. "The benefits of the faster cadence were obvious," he said, "if it could be done, but the shortest we had ever done a spec process at the time was 10 months."
The challenge for the EC, Souza said, came down to one question: "How do we do a fast open-source model and at the same time retain the stability Java has."
"As we moved to a fast cadence process," he said, "we had to take a very critical look at what [we were] doing a the JCP. And so we removed everything that prevented us from going to an open-source-friendly-early-release-often model, but at the same time we kept and improved on everything that guarantees the stability, long term, of the specification that is so important to the Java community."
Tene agreed that the rapid release cadence was a welcome idea that had to prove itself to the EC in specific ways. The JCP is where the specification, the reference implementation, and the Technology Compatibility Kit (TCK) come together, he said.
"The reason the Java ecosystem has such a rich set of code and libraries -- the reason Maven Central works on all the differentiated cases out there -- is because we do this work, because the specification is specific, and because the TCK lets us verify that all these implementations really will run the same way," he said.
How did it work out?
"We think it's worked out great," Tene said.
Posted by John K. Waters on September 20, 20190 comments
The Eclipse Foundation today announced the released the first Jakarta EE specification, almost exactly two years after Oracle declared its intention to transfer the responsibility for enterprise Java to that open source standards organization.
Two years seems like a long time, but the Foundation's executive director, Mike Milinkovich, says that's just how long it took to get the specs right. I talked with Milinkovich last week about the road to the Eclipse Jakarta EE 8 release.
I've been calling the Foundation's adoption of enterprise Java and the development of a standards process for it "the road to Jakarta EE 8." I'm just assuming it was a bumpy one, but how was it really?
When we started down this road, we always said that our first order of business would be to ship a set of specs that were exactly the same as Java EE 8, so we had that baseline. When we first started saying that, it just seemed like a good, solid, conservative thing to do to make sure that we got it done. It turns out that we were really darned lucky we did it that way. It would have been borderline crazy to do anything else.
How do you mean?
The first time you run through a very large and complex process you inevitably run into unforeseen circumstances. In this release cycle, we took exactly the same specs and ran them through a new process, but we changed a few things -- the TCKs are now open source, the specifications are under a new license, there's no more reference implementation, there are multiple compatible implementations -- but those are all process changes. We're not delivering new technology to developers yet. But every one of those process changes, introduced somewhere along the way, had its own little bit of complexity that you just couldn't foresee.
Seems like it was a ton of work.
We rewrote our IP policy -- twice -- we developed a spec process from scratch, and we updated all of our contribution agreements and got tens of thousands of people to resign them. So, yeah, you could say that.
And, as you've often said, you weren't doing this alone.
I can't stress enough how many good people pitched in and worked hard to make this possible. Oracle, Red Hat, IBM, Tomitribe, Payara, Fujitsu, to name a few. It was a community effort to get this thing out the door.
There are a lot of people with skin in this game.
Well, Java is old technology -- more than 20 years old -- but it's a multi-billion-dollar ecosystem, and there are millions of developers who have skills with this platform. Basically, everything we're doing right now is about establishing a baseline that's going to allow us to re-invigorate this platform for the next 20 years.
Why is re-invigorating the enterprise Java platform so important?
Enterprises want to see that there's a way to modernize their applications, in many cases, to take what they have now inside the corporate firewall to the cloud. They want to leverage this new infrastructure model with existing applications that are known to solve their business problems. Also, enterprises have thousands of developers with skills on this platform -- people who understand the businesses they work for. We need to demonstrate to those people that the technology platform they have skills in is still relevant and will keep them gainfully employed for the next 20 years. And then there's the need to attract young talent to a platform by making it exciting again.
So, all the work you've done on this release is essentially about setting the stage, so to speak, for innovations to come?
We had to get this part right. Large companies are making big bets on their product plans and this technology, so we focused on doing something concrete that would reassure the market and the community.
And no small part of your challenge was the fact that the Eclipse Foundation was not a specification organization when you accepted the stewardship of enterprise Java.
That's right! We were creating a brand-new specification process from a blank piece of paper, rewriting our IP policy to handle patents correctly, which is very different from how you do things in open source. Luckily, we were doing all this with smart engineers, experienced standards people, and lots of opinionated lawyers from software companies around the world.
Talk about "Incremental versus Big Bang."
What we ended up with in our negotiations with Oracle, remember, is that every time we add a new API, or we make a change to an existing API, that has to happen in the Jakarta namespace. The javax package names cannot be evolved by the Jakarta EE community. So, do we switch everything from javax.* to jakarta.* all at once -- that's the Big Bang -- or do we make the change a little bit at a time, as needed -- in other words, incrementally? In other words, do we rip the band aid off, or do we deal with these compatibility issues with every single release for the next 20 years?
Sound like you favor the Big Bang.
That's my personal preference. Let's just get it over with. But there are valid arguments for an incremental approach. Ultimately, this is about what's best for the customers, what's best for the ecosystem. The vendors have varying opinions on this, based on what they think their customers perspective would be. But what a lot of it really boils down to is, to what degree can we offer a reasonable set of technical solutions to the backwards compatibility problem? This is a really big decision that has to be made over the next couple of months.
The decision to move enterprise Java to the Foundation elicited a largely positively reaction from the community. Did you get any significant pushback?
Java developers are not shy, and they always let us know what they think. But they were onboard for this.
Were you surprised at how long it took to get here?
I was a little bit. I'm an optimist by nature, and I had a very clear idea from the beginning of where I wanted this end up. And we got very close to what I hoped for. But it takes a long time to pull a thing like this together. I remember someone saying, "There's no way you're going to get this done in less than a year." And they were right, of course. You can't change legal documents willy-nilly, and you have to take the time to explain to the community -- thousands of people around the world -- what the changes are and why we're making them. But I believe it was time well spent.
Posted by John K. Waters on September 10, 20190 comments