Reddit's "Ask Me Anything" (AMA) forum has attracted some brave souls since the "I Am A" (IAmA) subreddit was established in 2009. Everyone from Snoop Dog to Donald Trump (set to host an AMA on July 27) has signed up for this unique, almost-anything-goes public Q&A. Last week Google's Android engineering team took the AMA plunge for the first time, just a few days after the release of the fifth and final developer preview of Android Nougat (v7.0).
My colleague, David Ramel, covered the event and pointed out to me the flood of questions about Java.
Android applications are developed in Java, so the high level of interest wasn't surprising. But we live in a polyglot world, and many of the questions about Java were actually about how (and whether) the Android team will support other languages in the future. A question from "mastroDani" was typical:
Java is a good programming language but [its] age is starting to feel, a modern language would make the development easier and faster. The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. This shows there's a request for it. However, choosing one of those language comes with some level of risk or unexpected side effects because of its unofficial support. Is any of those language gonna become officially supported? Or is there any plan to move from Java to something else?
Anwar Ghuloum, engineering director for the Android Core Platform group, fielded that question: "We don't have any plans to move to a new language. Java has a lot of advantages to it and the versions 8, 9, and 10 have some pretty interesting stuff for developers. We are planning to track more closely in time to the Java language standard...."
Another questioner, "elkaramba," also wondered if the team might be at least considering support for Kotlin, a statically typed language similar to Scala developed by JetBrains. The question prompted a lively exchange among several participants. mastroDani observed: "Look at how many question [have] been asked about it. Someone even suggested we should use Swift to develop Android apps. I would be really surprised if Google kept ignoring all those voices and I don't want to jump on a language risking having to change it again in a few years."
Later "Inkprk114" brought the conversation back to the question of Android support for Kotlin: "... I personally doubt that Google will officially endorse any other language for a long while, but I would like to know how your team feels about some of the alternative languages that are popping up -- Kotlin being the one I'm most interested in. Do you feel it's in stable enough condition to use for production applications? Would you recommend using other languages, or do you feel sticking with Java is still the correct decision for developers? Have there been any discussions regarding Kotlin on the team, and are you guys in touch with any of the developers of the language over at Jebrains?"
Ghuloum's response: "We don't have any plans to officially support a new language in Android, so we'd encourage folks to continue to use Java :) That said, you should continue to use what works for you."
mastroDani wrapped up the discussion with this observation: "The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. I believe the reason behind this is that those language [make] writing software easier, less tedious and more boilerplate-free. However, choosing one of those language comes with some level of risk or unexpected side effects because of [Google's lack of support].... "
It's clear from this conversation (which you'll want to read in its entirety) that Google is solidly wed to Java on Android and has no plans at the moment to support anything else. That's not surprising, either; the company has invested a lot in Java (in court costs alone). And earlier this year Google announced plans to replace its Apache Harmony implementation of the Java libraries in upcoming versions of the Android OS with Oracle's OpenJDK, effectively replacing the code that has been at issue in the long-standing legal dispute between the two companies.
I'm sure it's useful to a get clear, from-the-horse's-mouth answer to this question for Android developers, a growing number of whom are very interested in Kotlin, Groovy and Scala, "just to name a few." How long the company will be able to stick with this monolingual strategy remains to be seen.
Posted by John K. Waters on July 26, 20160 comments
Sonatype has just released its second annual report on managing open source components. The "2016 State of the Software Supply Chain" report is available now, and well worth reading.
Among the things I like about this report is that it's based on the analysis of 31 billion download requests of open source software components from the Central Repository, which Sonatype manages, and that it's the result of an analysis of the patterns and practices of more than 25,000 developers and 3,000 organizations.
The company started out as a core contributor to the Apache Maven project, which is now the largest public repository of open source Java components. That 31 billion figure represents an increase of 82 percent between 2014 and 2015, according to the company. Sonatype also introduced repository managers into the software supply chain with its Nexus products.
Easily the most disturbing revelation in this report is that defective components in the software supply chain are routinely making their way into applications, which is costing enterprises millions of dollars. In fact, 1 in 16 downloads from the repository had a known security defect, the report's authors found, and 6.8 percent of components in use among the 25,000 applications analyzed had a known security defect.
And it gets worse: "However, because a single component may contain multiple vulnerabilities, it's important to understand that an average application consisting of 106 components -- of which 6.8% are known bad -- could contain numerous unique vulnerabilities," the report stated.
The problem here is twofold: not all components are created equal -- as the report puts it, the "massive variety and volume of software components vary widely in terms of quality -- and components "age and grow stale quickly."
"Last year, the average enterprise downloaded 229,000 open source components," the report warned. "If properly sourced and managed, open source components are a tremendous source of energy for accelerating innovation. If not, they lead directly to security vulnerabilities, licensing risks, enormous rework, and waste."
I touched base about this particular finding via e-mail with John Matthew Holt, founder and CTO of Dublin-based Java security vendor Waratek.
"That's an overwhelming statistic when you consider that it represents about 2 billion components downloaded with a known vulnerability," he said. "Security risks are a fact of life and will always be with us in some form. What this statistic points to is the need to move beyond trying to 'fix the code' or 'just writing better code.' Those are not viable solutions to address all vulnerabilities."
Holt is an enthusiastic proponent of Runtime Application Self Protection (RASP), which Gartner has defined as "a security technology built in or linked to an application or app runtime environment, and capable of controlling app execution and detecting and preventing real-time attacks." Holt's company makes a containerized RASP product, called Locker, which provides security monitoring, policy enforcement, and attack blocking from within the Java Virtual Machine (JVM).
"The Sonatype report points to two major Java risks that can be mitigated by RASP delivered by virtualization: known (and unknown vulnerabilities) as well as legacy code," he said. "A RASP solution can virtually patch known vulnerabilities on a permanent basis or temporarily while you rewrite the risky code, without shutting down the app. RASP can also be used to bring out-of-date components, whether they represent a vulnerability or not, to current Java standards without having to change an app's code. That's important when you look at the Sonatype's finding that 10% of components in 1,000 repositories had not been updated in five years or longer."
I also wondered about the implications of these findings for Java SE 9 and Jigsaw (componentization), due later this year.
"There are problems throughout the entire app stack today," he said, "not just with components downloaded from repositories. You'll find problems in the business logic layer, open source components from libraries, and even the code that comes with the JVM platform. So in that sense, a new version of Java and Jigsaw won't expand the problem; they will only add more hay to the stack while we search for needles of vulnerability."
The Sonatype report looked at more than security vulnerabilities, of course. Its other key findings include:
- Developers are "gorging" on an ever expanding supply of open source components. The use of third-party, open-source components "exploded" last year, the report found, and the trend is accelerating.
- "Vast networks" of open source component suppliers are growing rapidly. These networks created 1,000 new projects and delivered 10,00 new versions per day, according to the report.
- Software supply chain management practices are gaining traction. Top performing enterprises, federal regulators, and industry associations have embraced the latest supply chain management best practices, which include things like using fewer and better component suppliers, procuring only the best parts from those suppliers, and continuously tracking and tracing the precise location of every component.
There's much more in this report, including tons of stats and some useful infographics. As far as I'm concerned, it's a must read.
Posted by John K. Waters on July 13, 20160 comments
Oracle has finally responded to my -- and I'm sure many others' -- requests for comment on the future of Java EE, on which the formation of the Java EE Guardians threw a spotlight a few months ago. A member of the Oracle PR team sent me an e-mail in which Mike Moeller, Oracle's vice president of marketing communications and global public relations, offered the following:
"Oracle is committed to Java and has a very well-defined proposal for the next version of the Java EE specification -- Java EE8 -- that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the cloud. Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."
The Guardians, a group of volunteers committed to supporting enterprise Java, has been making the case that Oracle has been "conspicuously neglecting" Java EE. I've been reaching out to Oracle for a reaction to that claim since the Guardians made its public debut in March, but it's been radio silence from the blue silos in Redwood Shores until now.
It would be easy to conclude that that silence was broken in response to a petition posted by the Guardians last month calling for Oracle "to cooperate with us as a responsible, community-focused steward to move Java EE forward." (More on the petition here).
According to Reza Rahman, a former Oracle enterprise Java evangelist and one of the founders of the Java EE Guardians, response to the petition has been strong and "is proving instrumental in getting Oracle to listen." More than 2,800 people have signed the petition so far, Rahman told me in an e-mail, and more are signing at an average rate of 20 to 25 per day.
"For a deeply technical issue, I think that's a very good response rate," he said. "Most technical surveys usually garner around 500-1,000 input points (and struggle even to get that). It is certainly enough to empower our allies within Oracle to renew the struggle to do the right thing for the community."
Although the Moeller quote is short on details, Oracle's response should be viewed as a positive development, Rahman said. "The community should treat the lack of detail as an opportunity to continue to constructively engage Oracle, while remaining vigilant," he said. "We all need to work together to continue to ensure the well-being of the Java and Java EE ecosystems. Hopefully the forward plans for Java EE will be developed collaboratively and with direct community input."
Rahman also reminded me that the Guardians has been attracting some high-profile support to its cause. The growing list of community movers and shakers that have joined the group now includes James Gosling (the father of Java) and Java User Groups from all over the world.
Posted by John K. Waters on July 8, 20160 comments
The Java EE Guardians launched their public Web site last week and simultaneously posted a petition on the change.org Web site aimed at Oracle executives.
The original core group of volunteers committed to securing the continuing evolution of enterprise Java founded the formal organization in March with a Google Group and a Twitter handle (@javaee_guardians). But the Web site provides what founding member Reza Rahman calls "the essential public face of our movement."
"It makes us public in a way that the Google Group and Twitter account do not," Rahman told me in an e-mail. "It basically gives our movement identity, structure and presence. It says, we are here, we are serious and we are persistent."
The Web site includes a home page that explains the group's purpose, an "Evidence" page that makes their case that Oracle is neglecting Java EE, a page that tracks the group's activities, and one that lists its growing membership, which currently includes James Gosling (the Father of Java) and Java User Groups from all over the world.
The Web site also links to the change.org petition page, which Rahman said the Guardians posted to provide a wider range of people who might be interested in this issue with a place to take some action. "It's a way to empower average people and engage them with our movement," he said.
The title of the petition reads: "Tell Oracle to Move Forward Java EE as a Critical Part of the Global IT Industry," and it's directed specifically at Oracle Executive Chairman and CTO Larry Ellison, co-CEOs Safra Catz and Mark Hurd, president of Product Development Thomas Kurian, EVP of Fusion Middleware Development Inderjeet Singh, and Group VP of the Microservices-Cloud group Anil Gaur.
The document lays out the case again that "Java EE is incredibly important to the long term health of the entire Java ecosystem," and that "Oracle is conspicuously neglecting" it. And it asks visitors to the site to sign up to petition Oracle to do three things:
- Clarify how it intends to preserve the best interests of the Java, Java EE, and servers-side computing ecosystems.
- Commit to delivering Java EE 8 in time with a reasonable feature set that satisfies the needs of the community and the industry.
- Effectively cooperate with the community and other vendors to either accept contributions or transfer ownership of Java EE 8 work.
"As committed as we are," the document states, "we still need Oracle to cooperate with us as a responsible, community focused steward to move Java EE forward."
Shortly after the Web site and petition went up, I chatted via e-mail with one of my favorite industry watchers about the Java EE Guardians and their efforts. Forrester principal analyst Jeffrey S. Hammond believes that they are sincere in their efforts, but also that, despite those efforts, the future of Java EE is uncertain.
"I take them at their word that they are concerned about the pace of Java innovation," Hammond said, "especially Java EE. For years it was a pretty basic choice in the dev world: Java or .NET. But the reality these days is that there are more options than ever when it comes to building modern systems, including full-stack JavaScript, PHP, Python, Go, Ruby and more. If a framework like Java EE doesn't adapt to the needs of modern developers, those who've built their careers on it have a different choice: shift gears, accept becoming legacy, or try to reinvigorate the technology. My sense is these folks are pursuing option three."
What about the charge that Oracle is neglecting enterprise Java?
"We see evidence that Oracle is investing in both its cloud capabilities and in JavaScript runtimes, and it's possible some of this is taking away from or slowing down the standards process," Hammond said. "That said . . . it's not clear whether the status quo with Java EE is even preservable any more. Hopefully [the Guardians'] genuine concerns will elicit a positive response, but I think I'd be inclined to also consider other alternatives in the event that Oracle continues its benign neglect."
Posted by John K. Waters on June 22, 20160 comments
Apple announced the first Developer Preview of Swift 3.0 at its annual Worldwide Developer Conference in San Francisco (WWDC) this week, marking the next phase in the rapid evolution of this increasingly popular open-source programming language. The growth of the Swift ecosystem among third-party developers is something of a phenomenon, and IBM appears to be leading that burgeoning pack.
Since Apple released the language to open source last December, Big Blue has become one of the largest users of Swift for mobile app development. It was the first cloud provider to enable the development of applications in native Swift. The company likes to say it was "first to the table" with Apple to bring Swift to the enterprise. "We jumped in full-force in December," said John Ponzo, an IBM fellow and vice president and CTO of IBM's MobileFirst group. "We saw the potential right away to move this out to the server. We were all in right away."
To date, IBM has built more than 100 enterprise applications using Swift, and it has developed a range of tools for the language -- things like the newly announced IBM Cloud Tools for Swift (ICT), which is aimed at developers creating Swift apps "that span both client and server-side code." ICT is a Mac app designed to simplify the management and deployment of server-side assets, Ponzo explained. It allows developers to group client-side and server-side code written in Swift, deploy the server-side code to IBM's Bluemix cloud platform, and then manage projects using ICT.
Ponzo also pointed to the success of IBM's Swift Sandbox, a cloud environment that allows devs to write Swift code and execute it in a server environment on top of Linux. Each sandbox runs on IBM Cloud in a Docker container.
The company claims more than 1.5 million code runs on the Sandbox, up 200 percent since February.
IBM also announced Swift 3.0 beta on LinuxONE, IBM's Linux-based mainframe servers. Developers are now able to use Swift on LinuxONE, Ponzo said. The company plans to have a production-ready release when Swift 3.0 goes GA.
IBM sees great potential in Swift on the server side, Ponzo said. The company has been focusing its efforts on maturing the language at the backend and adding "first-class support" in the cloud. "This is really about addressing the key issues that enterprise developers are having," he said. "Swift has this combination of scripting-language-like syntax with a core systems language, and we're looking at how it can help developers who are building the next generation of cloud-based workloads. We'd like to make Swift a very big part of how those next generation services are built."
Big Blue also claims more than 1,500 client and server-side packages on the IBM Swift Package Catalog (up 400 percent since February), and more than 100 apps across 14 industries built on the IBM MobileFirst for iOS solution, which combines IBM's data and analytics with Apple's consumer experience.
Back in February, IBM introduced Kitura, an open source Web framework, written in Swift, that enables both the mobile front-end and back-end portions of an application to be written in the same language.
Launched at the 2014 WWDC, Swift is the successor to Apple's Objective-C. It sheds the "baggage of Objective-C," the company said at the time, to provide "an innovative new way of coding for Cocoa and Cocoa Touch." Where Objective-C relied on defined pointers, the Swift compiler infers the variable type. But it kept such features as well-defined namespaces, generics and operator overloading.
Posted by John K. Waters on June 15, 20160 comments
Hewlett Packard Enterprise (HPE) is inviting open source developers to write and contribute code to The Machine project, an effort to juice up its ambitious plan to reinvent computing. During my reporting on that news I had the opportunity to talk with a real veteran of the Open Source Wars. (Not officially a thing, I know, but it should be.)
Bdale Garbee, HPE Fellow and Office of the CTO at Hewlett Packard Labs, has been involved with open source software professionally since the early 1990s. He was one of the first Debian developers, and set up the original developer machine for that open source OS in 1995. Garbee said he actually made his first contribution to what would later be called free and open source software (FOSS) in 1979. He has been continuously involved ever since.
Garbee had been working at HP for 26 years when he took early retirement from his job as Chief Technologist for Linux and Open Source in 2012. He was called out of retirement in late 2014 by Martin Fink, EVP, CTO and Director of Hewlett Packard Labs. Garbee agreed to come back and help with The Machine in no small part because of Fink's reputation as an exec who gets open source.
"He twisted my arm to come back, because he saw that there was an opportunity to grow the company's open-source strategy into a major pillar of its general technology, development, and evolution strategy," Garbee said. "We're now working with others inside the company, thinking about our future technology roadmap and our development activities as an opportunity to be more open and collaborative by default."
Of course, nowadays everybody gets open source. During one of his first conference keynotes, Microsoft's newish CEO, Satya Nadella, famously declared "Microsoft loves Linux!" But HPE opened The Machine much earlier in that project's lifecycle than is typical, and Garbee expects that to happen more often at HPE. And HP has been involved in the open source world for decades, chiefly around the Linux kernel, but also as a big contributor to OpenStack and other projects.
"Somewhere between the time I took early retirement and when Martin brought me back, we turned a corner," Garbee said. "It's just different today. I'm no longer beating on people's doors to get them to open up and listen. It's very much the other way around. It's no longer a question of whether open source is a good idea. It's all about finding the right way to structure the work and build communities of interest around the pieces of technology and the work that are most interesting to us."
"I've had this conversation with some of my peers in the industry who have also been involved with free and open source for a very long time, where we look at each other and say, 'Oh my god, we won! Now what?'" Garbee added. "It's immensely satisfying, but the stress level does go up a bit. We've convinced everybody that these are good ideas. We've shown the world that you can run successful businesses around this model of collaborative development. HPE is making what amount to company sized bets on doing things this way. We definitely have to deliver. We have to make it all work."
BTW: "Bdale" is a non-punctuated contraction of "Barksdale," Garbee told me, which was his maternal grandfather's last name. His full name: Alfred Dickenson Barksdale Garbee II.
Posted by John K. Waters on June 13, 20160 comments
Oracle's decision to shut down the java.net and kenai.com collaborative Web sites by next April has the Java community -- especially the Java EE community -- buzzing. The company announced plans last year to move the content and services of Kenai to java.net, but now says both portals will be "sunsetting" on April 28, 2017.
Java EE evangelist Reza Rahman, in a letter to members of the Java EE Guardians, called the decision "tragic," and "very troubling for Java EE."
"The problem is that Java EE JSRs and GlassFish itself is heavily reliant on java.net," Rahman wrote. "Oracle so far has not announced a transition plan and is basically asking everyone with java.net projects to do any migration on their own. This is especially troubling since our current projections show Java EE 8 scoped work is highly unlikely to be delivered by April 2017 -- which raises the question of how Java EE 8 will be delivered at all."
Oracle moved the so-called community content of the sites to the community.oracle.com Web site last fall, and insists that this portal will be a "much better platform for collaboration" because of new spaces provided for Java Champions, Java User Group (JUG) leaders, and the Java Community Process (JC). But for future code collaboration, Oracle is pointing developers to other social coding platforms.
"As for the forge half of the site, there has been a tremendous amount of innovation in the code collaboration space, and developers have migrated to a small set of very popular platforms like GitHub," the company said in a statement. "In light of this, we felt we could contribute more value to the community through other programs and by investing in GitHub, because our community is increasingly active there."
The Java community has been talking about the shortcomings of java.net for some time, but what some see as the abrupt termination of these two portals has been unsettling.
Ondrej Mihályi, a Java EE trainer, consultant and senior services engineer at Payara Services in the Czech Republic, allows that java.net and Kenai haven't kept up with modern trends. It makes sense for Oracle to reconsider their roles in the Java ecosystem, he said in an e-mail, but the abruptness of the shutdown announcement makes him question the company's motives.
"The way Oracle announced the plan to shut them down makes many members of the community wonder whether it was carefully planned or just a desire to cut costs and shut down projects they cannot monetize," he said. "The latter is more likely, as even many people from Oracle, who stand behind existing projects hosted on java.net, don't yet have a plan how to migrate their projects to somewhere else."
Oracle underestimates the value of these collaboration platforms for growing community involvement, Mihályi said, and perhaps the value of community involvement itself.
"There are many valuable resources on both java.net and kenai.com, including project sources and documentation, forums, blogs, and other sorts of information, such as JUG profiles and documents," he said. "[Oracle's decision] poses high risk that a certain amount of that information will be lost after the shutdown of both sites. We can remember the losses from recent history, when all sun.com sites were migrated under Oracle domains, but not all links are properly redirected to date. They say the Internet has very good memory, but it can also forget badly when a site goes down completely."
Werner Keil, DevOps Build Manager at Visteon Corp., is a member of the JCP Executive Committee, spec lead on JSR 363 and an Apache committer. He likens Oracle's decision to shutdown the forge sites with its decision to enfold the JavaOne developer conference within its own OpenWorld event.
"The Java community becomes less visible in a giant pool of various products and technologies from Oracle DB to Fusion Middleware or Siebel, just to name a few," he said in an e-mail. Fully assimilating Java as a product rather than supporting an open, community-based project is "consistent with Oracle's approach," he said.
"As other portals (for example, Google Code) faced before, it seems, Oracle wants to save the cost of maintaining its own separate forge and project hosting for Java," he said.
Both Werner and Mihályi are members of the Java EE Guardians, an independent, volunteer advocacy group formed a few months ago to support enterprise Java. Mihályi sees the java.net shutdown as especially threating to Java EE.
"The important fact to point out here is that java.net has been a standard place to host all the official resources for most Java EE JSRs, including project sites, history of public communication on mailing lists, tracked issues, sources of the reference implementations," he said. "If java.net was shut down right now, it would practically mean death to Java EE, or in a better case, a hibernation lasting for many months. We as Java EE Guardians intend to keep reminding this fact to Oracle, the JCP board, and JSR specification leads and actively offering our cooperation in finding a new home and in migration for all JSRs and related projects. We certainly want to make sure that no valuable resources are lost and that the new tools and hosting is even more appropriate than current solutions."
"In the end," he added, "if we are successful, we can all benefit from making the Java EE process more transparent and accessible to an even wider community. There is always a room for improvement in the Java EE JSR processes (licensing issues, accessibility to TCKs and certifications -- just to name a few). And we all hope that we are able to contribute to overall openness of the platform in order to foster cooperation and standardization."
Posted by John K. Waters on June 8, 20160 comments
The recent decision by a federal district court jury that Google's use of 37 Java APIs in the development of its Android OS was a "fair use" of that technology and did not infringe on Oracle-owned copyrights came as a relief to the developer community, generally speaking, if a temporary one. The reaction of Josh Juneau, a Chicago-based app developer, blogger and author, was typical:
"I think this is a win for the developer community," Juneau said in an e-mail. "APIs are different from fully functional and completed applications or products. Many of us developers utilize open sourced APIs every day, and it would be a huge burden if we had to worry about licensing, etc. That is one of the reasons we use and develop open source software: so that others can make use of it as they see fit."
Gartner analyst Mark Driver has been a vocal critic of "the absurdity of Oracle's case" for some time. He reiterated his position in an e-mail that "copyrighting APIs is ridiculous and threatens innovation across the entire industry." He doesn't love the fair use argument, but he allows that it effectively addresses the mistake the court made with the earlier decision.
Oracle is going to appeal the latest decision, of course, so this story -- this long, long story -- has a few chapters left. But in the telling of it, says former Oracle Java EE community evangelist Reza Rahman, a larger point is being lost.
"I think both sides in this case are wrong," Rahman told me, "because neither side is serving the interests of developers."
Rahman, as we reported earlier, was the driving force behind the recently formed Java EE Guardians, a group of volunteers committed to supporting enterprise Java. He left Oracle earlier this year and now works as a consultant with CapTech Consulting.
"These guys should be working together and providing a standard API that Java developers can rely on without having to hitch their wagons to either Oracle or Google," Rahman said. "That would be the right thing to do. That's what Sun Microsystems wanted to do when it was the steward of Java. And that's what these two companies would be doing if they truly cared about developers. I see only self interest in all of this."
But Rahman has what I would call mixed feelings about the copyrightability of APIs.
"If I create an API, it should be within my rights to copyright it," he said. "Fair use, which is always judged on a case-by-case basis, acknowledges that sometimes there's a greater purpose than that served by copyright, and that should be accommodated also. In a perfect world there is no IP, and yet, when you create value you should be able to monetize that. This as a very slippery slope we're on right now."
To be clear, U.S. District Judge William Alsup's original ruling that the Java APIs at the center of the lawsuit were not subject to copyright was overturned on appeal, and the U.S. Supreme Court refused to hear Google's appeal, which effectively means that APIs are copyrightable. Historically, APIs have not been protected by copyright, but Oracle has argued that the "structure, sequence and organization" of the API packages in Java are sufficiently complex to merit protection.
"It's time to leave the bickering and uncertainty that has been hovering over the Java community behind," Rahman added, "and let's arrive at an API that moves the standard forward."
Amen to that.
Posted by John K. Waters on June 6, 20160 comments
Containers offer a number of advantages over traditional virtualization software, but easy visibility isn't one of them. Modern modular application architecture has, in fact, created a kind of "black hole" of complexity swarming with packages and dependencies developers can't readily sort out.
It's no surprise to see a growing number of container scanning products emerge to address this problem, but the latest entry into this market, JFrog's newly announced Xray, promises unprecedented visibility into the contents of software components, which the company calls "radical transparency."
JFrog CEO Shlomi Ben Haim described his company's fourth major product release as a one-of-a-kind tool that will give organizations an unparalleled level of understanding about all their container images, software packages and binary artifacts.
"Xray will not only tell you that you have a security vulnerability or a licensing issue," he told ADTmag, "it will also provide you will a full graph of all dependencies. It tells you where you are exposed and how your Ops environment is suffering from this specific software package. You have the chance to zoom in and magnify a vulnerability, security, or license issue and put things on hold before blessing a production environment."
Xray's ability to provide this kind of impact analysis is the product's key differentiator, Ben Haim said.
A fully automated platform, JFrog Xray comes with a REST API that supports integration and automation with an organization's continuous integration and continuous delivery (CI/CD) pipeline, and allows other inspection and security tools to fit into the full build-to-production automated flow, Ben Haim said
It also includes notification technology from VersionEye, a Mannheim, Germany-based start-up that provides a system for tracking open source libraries and alerting developers in real time to security vulnerabilities, license violations and outdated dependencies. VersionEye technology monitors more than a million open source projects on a daily basis, said company founder and CEO, Robert Reiz, in a statement.
"Integrating the VersionEye technology with the JFrog platform creates an unparalleled capability for deep understanding of the quality and provenance of the software components organizations depend on," Reiz said.
The tool also integrates with other vulnerability and license compliance databases, such as Black Duck and WhiteSource.
Xray integrates tightly with JFrog's binary repository manager, Artifactory, which stores binary artifacts and the metadata that describes them in a defined directory structure. Artifactory was one of the first cloud-based binary repository managers. The company also makes Bintray, a distribution-as-a-service (DaaS) platform designed to give development organizations full control over how they store, publish, download, promote and distribute their software.
The software management and distribution tools provider unveiled Xray at its annual swampUP user conference, under way this week in Napa, Calif. The company also announced at the show the availability of Artifactory running as a SaaS application on the Google Cloud Platform, as well as a collaboration with Atlassian to integrate that company's Bitbucket cloud-based DVCS hosting service and the JFrog platform.
JFrog expects to ship Xray in early Q3.
Posted by John K. Waters on May 24, 20160 comments