8.2 became generally available last week, marking the last release under Oracle's stewardship. Big O's proposal
to hand off the open source development environment, tooling platform and application framework to the Apache Software Foundation
(ASF) has been accepted. Next stop: the Apache Incubator Project
The ASF Incubator Project is the official entry path for projects and code bases whose supporters want them to become part of the ASF. It's where those projects are vetted to make sure they comply with the ASF legal standards and their support communities adhere to the ASF's guiding principles.
This release of what the community is already calling Apache NetBeans comes with a number of fixes and enhancements. Topping the list is an improved Java profiler, which includes new SQL Queries profiling modes, which enable profiling calls from Java processes to databases using a JDBC connection. The profiler displays a live list of executed SQL queries with times and execution counts, including the invocation paths, Oracle's Jiri Sedlacek explained in a blog post. Filtering based on statement type, command type, and related tables is available, and the collected data can be saved to a snapshot for offline analysis.
All SQL queries are displayed, regardless of the target database, Sedlacek wrote, and the profiler now enables coloring of results based on user-defined filters. "This is especially useful for the SQL call trees, but works in all profiler views," she wrote. The defined filters can be also easily added to results filters or instrumentation filters.
The list of key features in the NetBeans IDE 8.2 release also includes:
- ECMAScript 6 support
- NodeJS enhancements
- Oracle JET support enhancements
- PHP7 support
- Docker support
- New editor multicaret features
- New pinnable watches feature
- C/C++ enhancements
Although NetBeans is already open source, moving it to a neutral place like Apache, with its strong governance model, is expected to help get more contributions from various organizations. For example, large companies are using NetBeans as an application framework to build internal or commercial applications and are much more likely to contribute to it once it moves to neutral Apache ground. At the same time, though Oracle will relinquish its control over NetBeans, individual contributors from Oracle are expected to continue contributing to NetBeans after it has been contributed to Apache, together with individual contributors from other organizations, as well as self-employed individual contributors.
The wiki also provides the very long list of Initial Committers to the project.
NetBeans has been dual licensed (CDDL + GPL v2 with Classpath Exception), but will be migrated shortly to the current Apache license.
Posted by John K. Waters on 10/10/2016 at 9:32 AM0 comments
I am deeply bummed that I had to miss the NetBeans party at the Tonga Room and Hurricane Bar in San Francisco on Saturday night. The 71-year-old tiki bar's cocktails are legendary. And it would have been great to talk with the JavaOne attendees IRL about this Apache NetBeans business.
Fortunately, Geertjan Wielenga, principal product manager in Oracle's Developer Tools group, and Bill Pataky, VP of product management for Oracle's PaaS, Mobile Software and Developer Tools groups, gave me a call.
It was Wielenga who announced Oracle's proposed contribution of the venerable Java IDE to the Apache Software Foundation, via the ASF's Incubator Project. As I reported earlier, the open source project will be called Apache NetBeans, and will, as Wielenga wrote, "continue to primarily focus on providing tools for the Java ecosystem, while also being focused on tools for other ecosystems, languages and technologies...."
Wielenga reminded me that moving the NetBeans development platform is going to require some heavy lifting. More than 30 NetBeans repositories must be moved from the NetBeans.org Mercurial source control manager to Apache's repository (Git or Subversion).
"This is going to be one of the largest projects Apache has ever had to deal with," he said. "They're excited about it, but it's going to be quite a bit of work figuring out how things match up."
The process of sorting out the licensing and IP issues is going to take some time, too, Pataky pointed out. Oracle has a number of products that depend on NetBeans, including the Oracle Developer Studio, and even the JDeveloper IDE shares a lot of code with NetBeans.
"When Sun open sourced NetBeans 16 years ago, open source had a very different role in the enterprise," he said. "Sun set itself up as a benevolent dictator, and did a fairly good job of building a community over the years. But that model is pretty stale, and the community is asking for a broader role. Our solution was to open up the governance model."
Oracle has resources (people) committed to NetBeans through the NetBeans 9 release, Pataky said. More than two dozen oracle employees are included on the initial committers' list (which, BTW, includes James Gosling, the Father of Java).
"We will be adding additional folks to that list once we get through initial process with Apache," Pataky said.
There's a dot-dot release in the offing, Pataky said, but NetBeans 9 is likely to be the first official Apache NetBeans.
"We are committed to NetBeans for the foreseeable future, and we're welcoming the many community members, large and small, to take a much larger role in the planning and building of releases through NetBeans 9 and beyond."
I also heard from one of the proposed committers on that list: Martijn Verburg, CEO of jClarity and co-leader of the London Java Users' Group. "It looks like Oracle has a large number of committers on the initial list," he said in an e-mail, "so I'm hopeful that with that core strength and extra community contributions, NetBeans will continue to add value to the ecosystem."
NetBeans has a solid following, Verburg noted, ranking behind only IntelliJ and Eclipse among popular Java development environments. But that third-place spot means the IDE is unlikely to be a major commercial success for Oracle.
"However, it makes sense for Oracle, as the stewards of Java, to continue supporting NetBeans and open up the door to more contributions from the outside to help keep the Java IDE tooling ecosystem competitive," Verburg said. "The community certainly should be happy after years of campaigning to have NetBeans and other important parts of the Java ecosystem put into a software foundation where it's treated more as a public service or utility than a single vendor's product."
IDC analyst Al Hilwa sees Oracle's decision as one that will have positive consequences for the Java community, and for the company. "Oracle has gotten a lot of undeserved flack around NetBeans," he said in an -email, "even though they have continued to evolve it and share it internally with JDeveloper, and even though it has, in fact, gained more users in the last few years. Apache is a highly respected open source foundation with a solid governance model, and so I expect NetBeans to be even more popular as a result of this move. A battle of IDEs, including Eclipse, JDeveloper, and IntelliJ, is always a good thing for a programming language, as it is a mark of the size of the community."
I also heard from Forrester analyst Jeffrey S. Hammond: "NetBeans has long had a close following, so it will be interesting to see if that community blossoms under an Apache governance model," he said. "From Oracle's perspective, this could be construed as another step in slimming down commitments to Java in terms of the tools they directly support that target the languages. Supporting multiple IDEs (JDeveloper, Eclipse and NetBeans) always seemed like an expensive proposition to me. This move may end up being a win-win for the community and Oracle, assuming there's a community ready and willing to keep up support."
The NetBeans community is larger than ever, with approximately 1.5 million active users, worldwide, according to the NetBeans Web site.
Here's hoping there are enough tiny pink umbrellas for all their Mai Tais.
Posted by John K. Waters on 09/19/2016 at 4:44 PM0 comments
In March we announced that ADTmag is participating this year in the very popular Live! 360 conference, scheduled for December 5-9 at Loews Royal Pacific Resort at Universal Orlando. This multi-conference conference comprises Visual Studio Live!, SQL Server Live!, Office/SharePoint Live!, Modern Apps Live!, TechMentor and now AppDev Trends 2016. We don't have the exclamation point in our title, but we're as excited as if we did.
We're especially thrilled to announced our keynote speaker: Reza Rahman. As regular readers of this column know, Rahman has been one of the chief drivers behind the Java EE Guardians and an expanding effort to encourage Oracle to give enterprise Java the attention it deserves and to preserve the overall interests of the Java EE community.
I first spoke with Rahman shortly after he left his position as Java EE evangelist at Oracle in March. "Java EE is very much key to the overall server-side Java ecosystem, and maybe even the health of Java itself," he told me. "Without core investments from Oracle into Java EE, there's a very large part of the ecosystem that will be severely weakened."
A lot has happened since then: the Guardians published their charter, launched a public website, and published a petition aimed at Oracle executives. Google won its "fair use" argument against Oracle's charge that it infringed on a copyright of 37 Java APIs. Oracle shut down the java.net and kenai.com collaborative Web sites. And another effort to support enterprise Java, the MicroProfile.io project, got underway.
And between now and our show in December: JavaOne, during which Oracle has promised to provide "a very well-defined proposal for the next version of the Java EE specification."
Rahman's keynote, entitled "You Are the Future of Enterprise Java!" couldn't be more timely. (Notice that he got into the spirit of the conference with his own exclamation point!) And I can't think of a better speaker to present it.
Rahman has been working with enterprise Java since its inception, developing on almost every major application platform, from Tomcat to JBoss, GlassFish, WebSphere, and WebLogic. He implemented the EJB container for the Resin open source Java EE application server, and he has served as a member of the Java EE, EJB, and JMS expert groups of the Java Community Process (JCP). He also co-authored EJB 3 in Action (with Debu Panda and Derek Lane), and contributes to a number of industry publications. He's also a winner of the JavaOne Rock Star Speaker award.
"Java EE remains one of the most important technologies for global IT," Rahman said in an email. "It has come a long way since J2EE and has grown to become highly community-centric. Indeed, the process of defining the scope of Java EE 8 was the most community-opinion-driven process in the history of the platform. In fact, it was the community that helped to smooth the many bumps along the road to Java EE 8 for the entire IT industry."
Rahman's keynote will tell that unique story, focusing on what's inside Java EE 8 and how it got there, and exploring the critical role Java EE and APIs currently play in maintaining the health of the entire Java and IT ecosystem. And perhaps most importantly, he will attempt to answer the question, What do we need to do now to move enterprise Java forward?
Our goal was to tweak the ingredients of an already great conference with dash of Java and some sessions specifically aimed at ADTmag readers, and I think we've succeeded. This is a show you won't want to miss. Find out more here.
Posted by John K. Waters on 09/14/2016 at 12:12 PM0 comments
The annual JavaOne conference, which kicks off on Sunday (Sept. 18), looks to be chock-a-block with sessions, workshops and keynotes, and I'm expecting significant news from the Oracle Java team and tons of third-party product announcements. One of the best components of this consistently great conference, in my opinion, is NetBeans Community Day, which focuses on what continues to be one of the industry's favorite open source IDEs.
As the no-frills NetBeans Day Web site puts it, "The NetBeans team, NetBeans Dream Team, and NetBeans community will share highlights of how the NetBeans ecosystem has evolved, the work that developers around the world are doing with NetBeans IDE, what's new and noteworthy in NetBeans IDE 8.2, and together we'll explore what's up ahead in the coming period."
The speaker lineup includes NetBeans community members from around the world -- from Serbia to Burkina Faso (a country I confess I haven't actually heard of). Two of my personal favs will be presenting: Arun Gupta, VP of developer advocacy at Couchbase and founder of the U.S. chapter of Devoxx4Kids, and the Father of Java himself, James Gosling, now applying his considerable experience to the challenges of writing software for an unmanned ocean robot at Liquid Robotics . There are some juicy-looking sessions on Java 9 and Jigsaw, open-source tools for teaching Java, so-called DukeScript, Big Data, MVC 1.0 and more.
One session that caught my eye is being presented by Gluon's Johan Vos (CTO) and José Pereda. The session, "Java Mobile and Embedded Development with Gluon and NetBeans," promises to show "how the flow between writing a Java application and deploying it on mobile and embedded devices is extremely easy with NetBeans and the Gluon plug-in."
Gluon is the company that stepped in to fill a serious mobile-development gap left when RoboVM was acquired
by Xamarin, which was then acquired by Microsoft. The end of development and distribution of that ahead-of-time (AOT) compiler and runtime library for Java was later announced on the RoboVM Web site
Gluon provides plug-ins for the leading Java IDEs (including, of course, NetBeans), that allow Java developers to build apps for Android and iOS using a single code base. In June, the company unveiled the Gluon VM, which it bills as a high-performance virtual machine that leverages the OpenJDK class libraries and supports Java 8 and 9 on Android and iOS. The Gluon VM can operate in three modes: interpreter, just-in-time (JIT) compilation and AOT compilation. The VM is the foundation of the company's Gluon Mobile and Gluon CloudLink products.
Gluon is run by serious Java Jocks, so I'd expect this to be a great session. Catch it and the other promising NetBeans sessions on Sunday, Sept. 18, in Rooms 102 and 104 in Moscone South.
Posted by John K. Waters on 09/13/2016 at 6:09 AM0 comments
In its ongoing effort to make its workings as transparent as possible, the Executive Committee (EC) of the Java Community Process (JCP) publishes the minutes of its meetings. The Aug. 9 minutes are online now, and though these kinds of documents tend to provide reliably dry reading, this one proved to be a real page turner for anyone interested in the future of Java EE. (Or would have been if it were, you know, printed on paper.)
A couple of things caught my eye: Anil Gaur, Oracle group vice president with responsibility for Java EE and WebLogic Server, reportedly gave a short presentation on Oracle's Java EE strategy. As recorded in the minutes, he talked about how enterprise programming styles are changing to focus on apps deployed in the Cloud via modular runtimes, and how "we," by which I'm presuming he meant Oracle, would like the future of Java EE to be "viable to the next generation of applications."
Elsewhere in the minutes, JCP Chair Patrick Curran reportedly talked about a meeting he'd had with Oracle execs "on the subject of relations between OpenJDK and the JCP." Curran reported that Mark Reinhold, chief architect of Oracle's Java Platform Group, "had argued that much of the process required by the JCP was duplicative and unnecessary, and that Mark had even suggested that Expert Groups added little value to OpenJDK's existing processes."
We've been hearing predictions like Gaur's that the future of enterprise Java is in the cloud for a while now, and I continue to hear about the uncertain future of the JCP. But felt the need for some elaboration, so I reached out to some Java EE mavens to see what they had to say.
EC member and London Java User Group leader Martijn Verburg attended that meeting (virtually). "I think Anil is echoing the overall market trend for cloud based applications and services, with a subset of that trend being microservices and serverless," he told me via e-mail. "That is, less and less applications will be developed for on premise, requiring the sort of transactions support and connectivity with traditional on-premise systems. For example, with today's Java EE you have standards for Batch processing, transactions, persistent messaging with JMS and so forth.... So that means Java EE needs to evolve and produce standards around service discovery, configuration, logging, JSON processing, and binding, etc., and be less about heavyweight messaging, transactions and so forth."
On the subject of the future of the JCP, he added that he expects it to be "alive and well for some time yet."
"I think the community at large wants to see standards around Java in order to make long terms plans based on the technology," he said, "so the JCP should remain, or some other standardization effort would, I think, naturally take its place."
I also heard from Mike Milinkovich, executive director of the Eclipse Foundation, another EC member listed among the attendees. "Java EE was originally designed for on-premise IT infrastructure," he said. "As more IT moves to public and private cloud infrastructures, Java EE needs to change. Enabling Java to support multi-vendor standards for elastic scalability and DevOps-style deployment models will be key to its future success."
He, too, felt the JCP had a few miles left on it. "I don't think the JCP is going anywhere," he said. "Open source is great, but OpenJDK only provides a single implementation. The team there is effectively building a single product, not a multi-vendor standard and an ecosystem. That may be inconvenient for some Java platform developers, but I am confident that Oracle's executive management understands how important the JCP is to the success of Java as a platform. Without the JCP there could be no WebSphere or JBoss or J9 or Zulu."
EC member Werner Keil, also on hand for the meeting, acknowledge the shift of Java EE 8 toward the Cloud, but argued that that change is not necessarily based on Oracle's recent interests. "Several members of the Java EE Umbrella [Expert Group] repeatedly asked for better support of what once was called 'multitenancy' (aka being able to serve multiple clients/tenants in the cloud more easily)," he said via e-mail. "It took until the Java EE 8 release train (or even beyond) to get those voices heard. Well, it also took till Java SE 8 to get lambdas and 9 to get modularity, first intended at least for Java SE 7."
On the JCP vs. OpenJDK question, Keil said: "Despite the 'Open' in its name, OpenJDK isn't more open than the Open Handset Alliance or .NET Foundation, while the JCP… is a vendor-neutral industry body…. To [paraphrase] Orwell, Oracle isn't 'more equal' than others in the JCP, while they're a lot more equal in OpenJDK. Not everything is rosy and efficient there, either. For example: Project Kona was announced during a BOF last year at JavaOne, and yet, as you can see from its repository, there has been no activity since before JavaOne, and some parts are even inactive for almost two years now."
I also touched base with Josh Juneau, a Chicago-based app developer, blogger and author. He wasn't at the EC meeting, but he's a thoughtful industry watcher who, like me, could read the minutes.
"The foundation of the JCP relies upon the community-centric approach that involves many different voices, and not just those of the big players," he said in an e-mail. "The community, including vendors, developers, and user groups alike, need to have the ability to help steer the direction of enterprise Java, because there are so many different pieces to the enterprise puzzle. One company cannot have all of the answers in this space, so if the JCP were taken out of the decision making and the evolution of Java EE in the future, I feel that it would make Java EE a less healthy platform for development. It would force the vendors and developers to change the way they did business based upon one company's idea of what the enterprise should look like. However, if Mark's statement was not addressing the removal of the JCP process, but rather a revision, then I could understand his position a bit more. Perhaps Mark has different ideas for how the process should be executed. That said, we need the JCP in place, whether in its current form or in a revised format, where the community still has just as much influence."
Surely everyone who reads this blog knows that the JCP is the group that certifies Java specifications, and the EC is charged with guiding "the evolution of Java." What might not be such common knowledge -- and what I want to acknowledge here -- is how hard the JCP has been working since Oracle acquired Sun Microsystems and took over the stewardship of Java to rework some of its knottier components. It started in late 2013 with Java Specification Request (JSR) 348, which was all about transparency, participation, agility, and governance. That JSR was approved without much fuss, and a year later, the JCP sought to merge two ECs -- the Java SE/Java EE committee and the ME committee -- under JSR 355. That plan was also approved.
Posted by John K. Waters on 08/24/2016 at 10:18 AM0 comments
In an earlier post I wrote about a new independent effort to support Enterprise Java, the MicroProfile.io project, which aims to create a baseline platform definition that optimizes Java EE for microservices architecture. I connected this week with Martijn Verburg, co-leader of the London Java Users Group (LJC), one of the initiative's founding organizations, to get some additional details on the project. Verburg is also the CEO of jClarity and a very knowledgeable Java maven.
(He lives in the UK and I'm in Silicon Valley, so our conversation took place over e-mail.)
JKW: The MicroProfile.io initiative is also sponsored by Red Hat, IBM, Payara and Tomitribe. How did these organizations come together?
Verburg: There has always been collaboration among these vendors on various open-source software projects, in particular around Java EE. For the MicroProfile initiative they'd been having separate discussions for two to three months leading up to the announcement. The first discussion was around the future of Enterprise Java and how it needed to adapt to the new world of Microservices, Cloud native and reactive, without losing the longevity, interoperability, and standards that the marketplace was used to having.
The second discussion was around the lack of progress on several key Java EE 8 specifications (about six to nine months of no movement from Oracle as it was figuring out its internal strategy for Java in this space). The LJC was involved in those early discussions, representing the Enterprise Java developer community and their myriad needs and wants.
(When I say "Enterprise Java developer," I broadly mean engineers that work primarily with some set of Java EE components at the core of their applications, such as Servlet or JAX-RS.)
JKW: Why is the project necessary?
Verburg: As a group we decided that there needed to be stronger and faster collaboration for working on new APIs and implementations that would make this new world of Microservices accessible to millions of Enterprise Java developers. It was important that this collaboration happened pre standardization, as it needed to be fast, throw away bad ideas, and provide the freedom to try new ideas! This is so that we can validate these ideas amongst the vendors and amongst the developers that will be using these new APIs.
JKW: The project goal of creating a baseline platform definition that optimizes Enterprise Java the for microservices architecture is pretty clear. Is there anything else you'd like to say about that?
Verburg: That [the initiative] is very much a partnership between the developer community and the vendors. In fact, I'd even say that it's leaning toward a relationship in which the developers are expressing their requirements in this space and the vendors are responding by rapidly prototyping ideas and getting feedback and refinement from the community.
JKW: Will the initiative become a JSR in the Java Community Process or an Oracle JEP, or is that even necessary?
Verburg: We'd like to see parts of the platform go through a standardization effort (when ready), yes. I guess you could see it as an incubator for potential standardization work. It's something that the JCP has actually always encouraged; they like to see multiple implementations of a technology, with a baseline of those competing implementations being standardized.
JKW: Have you all thought about how you'll manage the project -- organizational governance, that sort of thing?
Verburg: There's a mailing list thread that started today about the potential move to a Software Foundation. All of the partners agree that it would be a good step for the initiative and would help enshrine its neutrality and collaboration.
JKW: MicroProfile.io seems likely to put even more pressure on Oracle to pay attention to Java EE. Am I right about that? Have you heard anything from Oracle about the project?
Verburg: Oracle have started to shed some light on some of their ideas around this area, and we've invited them to join in the effort. They recently stated at the JCP EC meeting (minutes to be released shortly) that they'll look into doing that, as well as making their plans on Java EE 8 clearer going forward. We find that encouraging.
Posted by John K. Waters on 08/12/2016 at 1:27 PM0 comments
Oracle may have been neglecting Enterprise Java over the past few years, but it's sure paying attention now. The Java EE Guardians threw a spotlight on what they saw as a lack of core investments in the technology when the volunteer advocacy group went public in March, and they cranked up the intensity when they posted a petition on the change.org Web site aimed at Oracle executives. In July, Oracle seemed to be responding to the Guardians' charges in a statement about its commitment to Java EE 8, and a growing number of Oracle execs are actually talking to the press.
Now comes a new independent effort to support Enterprise Java: the MicroProfile.io project. Sponsored by Red Hat, IBM, Payara, Tomitribe and the London Java Community, the goal of the project is to create a baseline platform definition that optimizes Enterprise Java for microservices architecture.
"Enterprise Java technologies like Java EE have evolved with the industry for nearly two decades to support distributed application architectures based on RMI/IIOP, Web Services, and REST," the Web site explains. "The MicroProfile is the next step in that evolution."
Project contributor Antonio Goncalves, a Paris-based Java EE developer and architect, agrees that the MicroProfile represents another step in the evolution of Java EE, whose origins he traces to the Enterprise JavaBeans component model. "The EJB component model was a Micro component," he wrote in a blog post, "just embed the needed business code, as small as you can, package it as a unit in a single jar, link it with other components/EJBs via RMI/IIOP, and the container will look after the rest.... But since then, Java EE containers have evolved. They have been lighter, smaller, faster ... so it was time to have a MicroProfile: micro components running in a micro container."
The project is focused initially on providing a baseline for a group of specifications: JAX-RS, the Java API for RESTful Web Services, Contexts and Dependency Injection (CDI) and JSON-P (JSON "with padding"). The project's organizers are aiming to release a public version in September.
"We want to ensure, as we move forward into this new, containerized, cloud-native world, that we do it responsibly, and customers don't get left with some proprietary single vendor technology stack," said Rich Sharples, Red Hat's senior director of product management during an interview following the announcement of the project at the recent Red Hat Summit.
The project's organizers are emphasizing the need for community participation in developing the MicroProfile definition and project roadmap. "I think there's a real chance that we can bring the whole Enterprise Java community together around this," Sharples said.
Posted by John K. Waters on 08/10/2016 at 6:29 AM0 comments
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 07/26/2016 at 2:30 PM0 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 07/13/2016 at 1:11 PM0 comments