MORE ON THIS TOPIC: Java in 2020, Part 1: What To Expect According to the Experts
Talking with Gartner VP and distinguished analyst Anne Thomas about Java at the start of a new year is becoming a habit. (Let's call it a tradition.) Thomas is a longtime industry watcher with deep industry knowledge, she understands the tech and she doesn't mind stirring the pot, so to speak, if that's what her observations demand.
We started with Oracle's Java SE subscription service, which Big Red launched in June 2018. As virtually all Java users know, starting in January 2019, public updates for Java SE 8 were no longer available for business, commercial or production use without a commercial license. I heard mostly upbeat reports when I asked about how Oracle's customers were adapting to the new model in earlier what's-next-in-2020 interviews. The reactions Thomas tracked last year were mixed.
"For the companies that purchased the commercial versions of Java -- Java SE Advanced and Java SE Suite -- it gave them a nice reduction in cost," she said. "But the vast majority of organizations did not purchase those commercial licenses, and they've been using Java for free for the last decade-and-a-half. Those folks all of a sudden have these bills -- sometimes enormous bills… sometimes in the millions -- that they didn't have before."
When Oracle unveiled its Java SE subscription service, it was positioned as a complement to Oracle's existing free releases and OpenJDK ecosystem. It would "remove enterprise boardroom concerns around mission critical, timely, software performance, stability and security updates," the company said at the time. The advanced groundwork notwithstanding, most organizations were simply not prepared for it, Thomas said.
"It hit their budgets pretty hard," she said. "I've taken about 250 calls on this topic in the last year. Paying Oracle for a commercial license is clearly the easiest way to deal with this situation, and you might find the support agreements in the apps you're using actually stipulate that you use Oracle Java. But for some organizations, an alternate distribution, such as AdoptOpenJDK, Amazon, Azul, IBM or Red Hat, is pretty much their only option. The good news is, they have those options."
Another reason the pay-Oracle option might be worth the expense, even with so many alternative distributions to choose from: Third-party distros can be challenging.
"It's a huge amount of work to identify which programs are using Java, which versions they're using, and then test and verify that all those applications will run on an alternative distribution," Thomas said. "And OpenJDK does not include support for the Java plug-in, which you need if you're running applets or Java Web Start. There's an open source project called IcedTea-Web that supposedly supports it, but I've heard conflicting reports from people about their success."
Some vendors have licensed Java from Oracle and taken on the cost. Thomas cited Adobe as an example. Other vendors, such as Atlassian, have moved to support alternatives, such as AdoptOpenJDK, in their offerings.
But the core issue for organizations struggling with all this change is that the vast majority of Java applications -- certainly more than 80 percent -- still have a dependency on Java 8 or earlier, Thomas said.
"If you want free Java from Oracle with updates on the new six-month cadence, you have to upgrade to the latest version," she said. "At this point, you need to be on Java 13. But hundreds -- probably thousands -- of vendors have Java 8 dependencies, and you have all these third-party applications you run within your organization that don't run on Java 13."
Oracle says it will end regular support for Java 8 in 2022 and cease extended support in 2025.
Why are so many sticking with Java 8? "At some point, organizations are going to have to think about moving off Java 8," Thomas said, "but so far, none of the features in Java 8, 9, 10, 11, 12 or 13 have been compelling enough to get them moving. But my advice if you're building new Java applications: They should not be based on Java 8, but Java 11."
Thomas speculated that the subscription model could influence decisions in the enterprise about future commitments to Java.
"Java is a really nice, mature programming language," she said, "and it continues to be enormously popular for good reason. But Oracle's licensing is an issue for many of the organizations I talk to. Some of them are definitely reconsidering their Java commitments."
Thomas saw the writing on the wall for Java EE, now Eclipse Jakarta EE, at least a year before that startling standards-body hand-off. During a 2017 interview with ADTmag, she described Java EE as "overgrown and not right for cloud-native app development." And she advised those responsible for modernizing an enterprise's application infrastructure to "develop a strategy to deal with the obsolescence of Java EE and other three-tier application frameworks." She doesn't have higher hopes for Jakarta EE, even under the more involved stewardship of the Eclipse Foundation.
The Foundation released the Jakarta EE 8 specification last August with the primary goal of providing a version that is 100 percent compatible with Java EE 8. The plan for Jakarta 9, which was just announced, is to deliver a set of specifications that are functionally similar to Jakarta EE 8, but in the new jakarta.* namespace.
"It took three years to deal with the namespace issue," Thomas said. "Eclipse needed to do it, but they're now at parity with where we were five years ago."
Thomas pointed to a lack of innovation in such Java EE-based offerings as WebSphere, WebLogic and JBoss. "That's old technology and not where you should be targeting your applications anymore," she said.
Thomas does have high hopes for Quarkus, the Kubernetes-native Java framework Red Hat released last year, which is now compatible with the latest version of the Eclipse MicroProfile.
"MicroProfile is where it's at," she said.
Posted by John K. Waters on 01/28/2020 at 8:52 AM0 comments
Kohsuke Kawaguchi, creator of the open source Jenkins continuous integration/continuous delivery (CI/CD) server, and Harpreet Singh, former head of the Bitbucket group at Atlassian, have launched a startup that's using machine learning (ML) to speed up the software testing process.
Their new company, Launchable, which emerged from stealth mode on Thursday, is developing a software-as-a-service (SaaS) product with the ability to predict the likelihood of a failure for each test case, given a change in the source code. The service will use ML to extract insights from the massive and growing amount of data generated by the increasingly automated software development process to make its predictions.
"As a developer, I've seen this problem of slow feedback from tests first-hand," Kawaguchi told ADTmag. "And as the guy who drove automation in the industry with Jenkins, it seemed to me that we could make use of all that data the automation is generating by applying machine learning to the problem. I thought we should be able to train the machine on the model and apply quantifiable metrics, instead of relying on human experience and gut instinct. We believe we can predict, with meaningful accuracy, what tests are more likely to catch a regression, given what has changed, and that translates to faster feedback to developers."
The strategy here is to run only a meaningful subset of tests, in the order that minimizes the feedback delay.
Kawaguchi (known as "KK") and Singh worked together at CloudBees, the chief commercial supporter of Jenkins. Singh left that company in 2018 to serve as GM of Atlassian's Bitbucket cloud group. Kawaguchi became an elite developer and architect at CloudBees, and he's been a part of the community throughout the evolution of this technology. His departure from the company was amicable: Its CEO and co-founder Sacha Labourey is an investor in the startup, and Kawaguchi will continue to be involved with the Jenkins community, he said.
Software testing has been a passion of Kawaguchi's since his days at Sun Microsystems, where he developed Jenkins as a fork of the Hudson CI server in 2011. Singh also worked at Sun and served as the first product manager for Hudson before working on Jenkins. They will serve as co-CEOs of the new company. They reportedly snagged $3.2 million in seed funding to get the ball rolling.
"KK and I got to talking about how the way we test now impacts developer productivity, and how machine learning could be used to address the problem," Singh said. "And then we started talking about doing a startup. We sat next to each other at CloudBees for eight years; it was an opportunity I couldn't pass up."
An ML engine is at the heart of the Launchable SaaS, but it's really all about the data, Singh said.
"We saw all these sales and marketing guys making data-driven decisions -- even more than the engineers, which was kind of embarrassing," Singh said. "So it became a mission for us to change that. It's kind of our north star."
The co-execs are currently talking with potential partners and recruiting engineers and data scientists. They offered no hard release date, but they said they expect a version of the Launchable SaaS to become generally available later this year.
Posted by John K. Waters on 01/23/2020 at 7:18 AM0 comments
The Eclipse Foundation's Jakarta EE Working Group today announced unanimous approval of a release plan for version 9 of the Eclipse Jakarta EE Platform.
The Working Group is proposing to deliver the specifications in a series of eight "waves," starting with an Independent (stand-alone) Wave, followed by Waves 1-7. Wave 1, for example, comprises the following specs:
- Jakarta JSON Processing
- Jakarta Dependency Injection
- Jakarta Expression Language
- Jakarta Bean Validation
- Jakarta WebSocket
- Jakarta Servlet
- Jakarta Activation
- Jakarta SOAP with Attachments
- Jakarta Interceptors
Details of the specs planned for each wave are available on the project page. So is the release timeline, but the Working Group emphasized that the schedule is "aggressive" and the dates are early estimates that will be reviewed and adjusted at each release. For now, the final release is planned for mid-2020 on the following release schedule:
- Individual Component Plan Reviews (Feb 1)
- All API jars available (Feb 14th)
- Platform TCK changes complete (March 13th)
- Full Profile and Web Profile First Release Candidate (May 4th)
- Full Profile and Web Profile Final Release Review Votes Start (June 12th)
The Foundation's executive director, Mike Milinkovich, announced the plan in his "Life at Eclipse" blog. (If you're not reading it, you should be.) The primary goal of the Jakarta EE 9 release, he said, is to deliver a set of specifications that are functionally similar to Jakarta EE 8, but in the new jakarta.* namespace .
"Moving a platform and ecosystem the size and scale of Jakarta EE takes time and careful planning," Milinkovich said. "After a great deal of discussion, the community consensus was that using EE 9 to provide a clear transition to the jakarta namespace, and to pare down the platform would be the best path to future success. While work on the EE 9 platform release is proceeding, individual component specification teams are encouraged to innovate in their individual specifications, which will hopefully lead to a rapid iteration towards the Jakarta EE 10 release."
The Working Group is also developing a program plan, as well as marketing and budget plans for 2020, Milinkovich said.
Milinkovich's post also includes a recap of some the enterprise Java community's accomplishments over the past year.
Posted by John K. Waters on 01/16/2020 at 12:17 PM0 comments
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 01/15/2020 at 8:53 AM0 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 01/14/2020 at 10:43 AM0 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 11/06/2019 at 9:17 AM0 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 10/29/2019 at 11:07 AM0 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 10/23/2019 at 9:35 AM0 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 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 10/22/2019 at 7:13 PM0 comments