Whatever else you can say about the past year, 2015 was a good'n for Java. The language turned 20 with much fanfare and well-earned acknowledgement. (Oracle marked the anniversary with a great Web site. Java 8, with its game-changing support for lambda expressions, was adopted at a record-setting pace. And though the release of Java 9 was pushed back, modularization became real.
Now, at the start of 2016, Java gets an extra pat on the back from the industry watchers at TIOBE Software, who named the it "Programming Language of 2015." The reason: The language enjoyed the largest increase in popularity of the 50-plus languages tracked in the TIOBE Index. Java's popularity grew 5.94 percent last year, according to TIOBE, smoking the closest runners up. Visual Basic.NET grew in popularity by 1.51 percent, and Python grew by 1.24 percent.
"At first sight, it might seem surprising that an old language like Java wins this award," the TIOBE researchers wrote. "Especially if you take into consideration that Java won the same award exactly 10 years ago. On second thought, Java is currently No. 1 in the enterprise back-end market and No. 1 in the still growing mobile application development market (Android). Moreover, Java has become a language that integrates modern language features such as lambda expressions and streams. The future looks bright for Java."
TIOBE is a Netherlands-based provider of software quality assessment services based on the ISO 25010 standard. The company ranks the popularity of software languages based on "the number of skilled engineers world-wide, courses, and third-party vendors." The purpose of the Index, the company says, is to provide coders with a kind of contextual yardstick with which to measure their own language skills against current demand.
Altogether, TIOBE ranks 50 programming languages, though it follows many more. The company emphasizes that the Index measures only the popularity of a language, not its actual quality (no "bests") nor the number of lines of code written in it.
BTW: That Oracle Web site is still worth a visit.
Posted by John K. Waters on 01/07/2016 at 2:12 PM0 comments
The Open Container Initiative (OCI) unveiled its technical governance model this week. The nascent coalition of industry leaders and users seeking to establish common standards for software containers is just over six months old, and the establishment of a governance model is a big step in its evolution.
At the core of the OCI model is a Technical Developer Community (TDC) consisting of nine maintainers who have been working on the specification since the coalition was formed. The TDC will be responsible for maintaining the project and handling the releases of both the runtime and the spec. The community is currently made up of both independent developers and employees of founding companies, such as Docker, CoreOS, Google, and Huawei.
The model also includes a Technical Oversight Board, some members of which will be elected by the TDC, and others by the wider OCI membership. That board will work closely with the TDC to ensure cross-project consistencies and workflows. And there's a Trademark Board, which will oversee the development and use of the OCI's trademarks and certifications. A representative from each of the member companies will serve on that board.
"The maintainers are very technical and neutral," said Patrick Chanezon, a member of the technical staff at Docker who has been working on OCI from the beginning. Docker donated a draft specification for the base format and runtime to the OCI, as well as the code associated with a reference implementation of that spec, known as runC. The company donated the entire contents of its libcontainer project and all modifications needed to make it run independently of Docker. libcontainer provides a standard interface for making containers inside an operating system.
The OCI has released two versions of the OCI spec so far (0.1.1 and 0.2), and Chanezon expects several more releases on the road to version 1.0. He was careful to avoid promising a release date. And there have been six releases of runC.
The OCI was formed in the spring of this year and published its charter in July. Its membership roster currently includes, among others, Amazon, Google, IBM, Oracle, Microsoft, Red Hat, EMC, Goldman Sachs, Apcera, Apprenda, AT&T, ClusterHQ, Datera, Dell, Fujitsu Ltd., HP Enterprise, Infoblox, Intel, Joyent, Kismatic, Kyup, Mesophere, Midokura, Nutanix, Pivotal, Polyverse, Portworx, Rancher Labs, Resin.in, Scalock, Sysdig, SUSE, Twitlock, Twitter, Verizon and Weaveworks.
With this announcement, the coalition also published a list of "values," which actually read more like requirement, and which I think are worth including here:
- Composable: all tools for downloading, installing and running containers should be well integrated, but independent and composable.
- Portable: the runtime standard should be usable across different hardware, operating systems and cloud environments.
- Secure: isolation should be pluggable, and the cryptographic primitives for strong trust, image auditing and application identity should be solid.
- Decentralized: discovery of container images should be simple and facilitate a federated namespace and distributed retrieval.
- Open: the format and runtime will be well specified and developed by a community to ensure code development leads specification development.
- Minimalist: The OCI Specifications aim for simplicity, to ensure stability, optimize innovation and encourage experimentation.
- Backward compatible: OCI Specifications and OCI Projects strive to be as backward compatible as possible with prior releases.
A Linux Foundation Collaborative Project, the OCI aims to host an open source, technical community, and build a vendor-neutral, portable, and open specification and runtime for container-based solutions. So there's a big emphasis on openness in its governance model. The OCI's technical roadmap, which was developed by the current members of the TDC, is available on GitHub. And any developer or end user can make contributions to the OCI.
Posted by John K. Waters on 12/09/2015 at 6:30 PM0 comments
GitLab, the company behind the open source code collaboration platform of the same name, has released a new version of one of its Git-based offerings with some additional enterprise muscle, and the company is using the occasion to throw stats at the press like ninja stars in a Kung Fu movie.
GitLab Enterprise Edition (GitLab EE) is an on-premises solution for Git hosted repositories. The newest version, GitLab EE 8.2, comes with a fairly long list of features targeting organizations with more than 100 users. Among the upgrades in this release is the addition of repository mirroring, which allows users to set up a project to automatically have its branches, tags, and commits updated from an upstream repository. GitLab EE is offered on a subscription basis, but the company also provides a free Community Edition, on which GitLab EE is built. GitLab.com is the company's free SaaS offering.
GitLab is also touting new support for Git Large File Storage (LFS) in GitLab.com and both its Enterprise and Community editions. Git LFS is an open source Git extension that replaces large binary files, such as audio, video, and graphics, with text pointers inside the Git repository; the actual file contents are stored on a remote server. GitHub, that other code-hosting site, announced Git LFS in April.
Sytse "Sid" Sijbrandij, the current CEO, believes that GitLab is offering the first open source production implementation of Git LFS.
The company was founded in 2013 by Sijbrandij, who is a Dutch software developer, and Ukrainian developer Dmitriy Zaporozhets, who created the platform. Back in 2011, Zaporozhets was working for a large software consultancy with 200 people who were struggling to collaborate across projects, Sijbrandij told me. The company required that any collaboration software be on-premises, but Zaporozhets couldn't find a solution he liked.
"So, he did what programmers do," Sijbrandij said, "and coded something himself, and then he open sourced it. Within a year, about 800 contributors had been attracted to the GitLab project. We didn't know each other at that time, but I e-mailed him and said that I would like to commercialize what he had developed, and asked if he would be okay with that, and with me not paying him a cent. He said, sure, go for it."
Zaporozhets later tweeted that he wanted to work on GitLab full time, and Sijbrandij went to the Western Union office to wire him some money. "He was in the Ukraine at the time," he recalled, "and the person behind the counter asked me, 'Do you know this person or is it someone you met over the Internet?' She was worried that I was being scammed."
A year later, a company was born. Sijbrandij and Zaporozhets had become friends, but the two co-founders only started working together directly at the beginning of this year.
The startup emerged from the Silicon Valley's Y Combinator accelerator program this summer and promptly raised $1.5 million in seed money. And it announced a $4 million Series A funding from Khosla Ventures in September. The company has grown from 8 employees to 34, and today competes with the much better known GitHub, and with Atlassian's BitBucket.
In October, the company entered into a partnership with SCM provider Perforce Software to create Helix GitSwarm, that company's new Git management platform.
Sijbrandij believes that GitLab is the most used code collaboration platform on premises. The company claims that more than 100,000 organizations are currently using it; that there have been more than 1 million downloads of GitLab to date; and that nearly 30 percent of Fortune 500 companies use the platform. The company currently counts IBM, NASA, Alibaba, CERN, Expedia and SpaceX, among its users.
Since I spoke with Sijbrandij, the company issued a security update, GitLab 8.2.1, and is advising users who installed GitLab 8.2 to upgrade immediately.
A complete list of new features in GitLab 8.2 is available on the company's blog page.
Posted by John K. Waters on 12/02/2015 at 8:52 AM0 comments
The Chief Architect of Oracle's Java Platform Group, Mark Reihold, is asking for a six-month extension of the Java 9 release schedule. The reason: Jigsaw, of course.
Despite the "good progress" made over the past 18 months on the project that will modularize Java, Reinhold said in a post on the OpenJDK mailing list, doing it right will take just a little bit longer.
The current Feature Complete release date for Java 9 is just around the corner, and yet the JSR 376 Expert Group has yet to publish an Early Draft Review specification, Reinhold pointed out. He also expressed concern about "the volume of interest and the high quality of the feedback received over the last two months," which he said "suggests that there will be much more to come."
"[We] want want to ensure that the maintainers of the essential build tools and IDEs have adequate time to design and implement good support for modular development," he said.
Reinhold wants the extra time, but he doesn't want the extension to generate a flood of new features unrelated to Jigsaw or expand the scope of the existing features "without bound."
"It would be best to use the additional time to stabilize, polish, and fine-tune the features that we already have, rather than add a bunch of new ones," he wrote. "The later [Feature Complete] milestone does apply to all features, however, so reasonable proposals to target additional JEPs to JDK 9 will be considered, so long as they do not add undue risk to the overall release."
If the community accepts Reihold's suggestion, the release of the Feature Complete milestone, originally scheduled for Dec. 10, will be pushed back to May 25, 2016, and the rest of the milestone schedule will be adjusted accordingly. If I've got this right (6 months + 15 days), the new JDK 9 schedule could look something like this:
2016-05-25 Feature Complete
2016-07-19 All Tests Run
2016-08-09 Rampdown Start
2016-10-25 Zero Bug Bounce
2016-12-01 Rampdown Phase 2
2017-01-05 Final Release Candidate
2017-03-09 General Availability
The long awaited, much delayed modularization of the Java SE Platform and the JDK is the biggest change to come to Java probably ever; certainly since the support of lambdas in Java SE 8. Brian Goetz, Oracle's rockstar Java Language Architect, has said that support for lambdas in Java 8 would "change the way we program in Java every day." But JSR 376, the Java Specification Request that aims to define "an approachable yet scalable module system for the Java Platform" will bring a fundamentally new kind of programming component to Java. I've talked with industry analysts who wonder if modularizing Java will effectively turn it into a new language.
Another delay is going to frustrate some people -- maybe a lot of people -- but considering the scope of changes coming in Java 9, another six months is probably not too much to ask.
Comments on Reinhold's request from JDK 9 Committers are welcome, he said, as are "reasoned objections." If no one objects (or objections are answered) by 18:00 UTC on Dec. 8, the schedule change will be adopted.
Posted by John K. Waters on 12/01/2015 at 1:57 PM0 comments
While I was talking with people last week about the recently published proof-of-concept exploits that threw a new spotlight on a well-known vulnerability in the Apache Commons Java repository, I had the opportunity to chat with Mark Thomas, a member of the Apache Software Foundation security team and long-time Apache Tomcat committer.
In his day job, Thomas leads the Pivotal security team, so we also talked about a recent vulnerability in the Spring Social core library that was brought to his company's attention by a new kid on the security block, SourceClear, which just emerged from stealth mode.
Developed by Pivotal, Spring Social is a popular extension of the Spring Framework that allows Java developers to connect their applications with Software-as-a-Service (SaaS) API providers, such as Facebook, Twitter, LinkedIn and GitHub. The vulnerability allowed attackers to bypass Spring Social's authentication controls to hijack user accounts.
The vulnerability (CVE-2015-5258) was originally identified by Kris Bosch from Include Security. Software engineer and SourceClear co-founder Paul Ambrosini identified the root cause, vulnerable library, and vulnerable code. Ambrosini explains the issue in a nicely detailed blog post on the SourceClear site. He explains how to fix the problem by updating the library, and also offers a workaround.
"It boiled down to a cross-site forgery issue," Thomas said. "Because the Spring code is open source, SourceClear were able to dive down into it. And they pointed right at where the problem was, which made our job that much easier."
Pivotal fixed the Spring Social issue quickly and coordinated an announcement with SourceClear. A new version of the Spring Social core is available now on Maven Central. The code change can be viewed on GitHub.
San Francisco-based SourceClear provides a solution for securing open source code -- both custom and inherited -- but with a focus on developers and the workflows in which they live today. I'd argue that the company has taken up the build-security-in baton from app security gurus like Gary McGraw and Sammy Migues (creators of the BSIMM) and applied it to the challenges of modern software development.
"The way we build software today is fundamentally different from the way we used to build it," SourceClear's founder and CEO, Mark Curphey, told me. "We used to build it all ourselves, but today we rely on frameworks and libraries. And that change has not been lost on the bad guys. Reusable code, unfortunately, means reusable vulnerabilities."
"The economics of hacking has fundamentally changed," Curphey added. "It's no longer about finding loads of places where you can attack, but finding places where people are pulling in vulnerable software."
Software is being built so fast these days that open-source code is getting pulled into the builds "like a swarm," Curphey said. His company's namesake solution plugs directly into a source code management system, continuous integration server, or build automation tool. Every time a developer checks in code or a build is run, it identifies the open source code and reports to the customer which pieces have vulnerabilities, where they came from, and what they could do inside their codebase. The product supports Java, Ruby on Rails and Node.js today, with plans to support Python and C/C++ in the future.
"The industry historically has built security tools for security people," Curphey said. "Those tools were designed for the way we used to build software. We're building security tools for developers and the way they build software today."
A trial version of the SourceClear solution is available for download from the company's Web site.
Posted by John K. Waters on 11/16/2015 at 6:54 AM0 comments
"Today is a big day ..." the PR note in my inbox proclaimed. As of Monday, JetBrains, maker of the venerable code-centric Java IDE, IntelliJ IDEA, is bundling all its desktop developer tools into the JetBrains Toolbox, and selling those products via a subscription model.
The company announced its plan to switch from a perpetual licensing model to a subscription-only model on Sept. 3, and the news generated more than a little negative feedback from its customers. JetBrains argued at the time that the change would simplify management of its product licenses and ultimately cost less. But unconvinced customers complained about the pernicious spread of software "renting" schemes and the risk of committing to tools they don't actually own.
In a blog post published at the time, Mike Milinkovich, executive director of the Eclipse Foundation, denounced subscriptions in general and JetBrains in particular: "The news this morning that JetBrains is switching to a subscription-only model is a perfect example of why and how trusting a proprietary tools vendor leaves you and your business exposed to the whims of their profit margins. Make no mistake: this is motivated by what's good for their business, not what is good for the developer community. Even if JetBrains backpedals on this decision, it is a lesson worth learning."
JetBrains CEO Maxim Shafirov responded to critics of his company's subscription plan in a blog post of his own: "The discussions and feedback that we received after the announcement went public showed that we had failed to properly account for all considerable groups of our customers and articulate our reasoning for the move in the announcement message. We sincerely apologize for this."
JetBrains would stick to its plan, Shafirov wrote, but it would also address its customers' concerns with a "perpetual fallback" license. Purchasers of an annual Toolbox subscription would be able to use the version they bought (the "exact" version), even if they decided not to renew their subscriptions at the end of the year. This perpetual fallback would also apply to monthly subscribers as soon as they paid for 12 consecutive months. He also promised "continuity discounts" for customers who renewed their subscriptions without interruption.
The company officially launched JetBrains Toolbox with 14 simultaneous updates for all its desktop products, including IntelliJ IDEA 15, PhpStorm 10, ReSharper Ultimate 10, WebStorm 11, PyCharm 5, AppCode 3.3, CLion 1.2, RubyMine 8 and a preview of 0xDBE 1.0. It also shipped the 1.0 beta of its open source Kotlin language.
The new subscription model is now in effect, though the company has said that users with a valid upgrade subscription need not switch to the new model immediately. And apparently the company could use some time to work out some launch-pad kinks. JetBrains responded on Twitter (@jetbrains) to "reports about issues" with its license server: "We're already investigating. Sorry for the inconvenience."
Love the software subscription model or hate it, it's winning over a rapidly growing number of software makers, and we're going to be seeing a lot more of it. We should hope that they're all as responsive to their customers as JetBrains has been during its transition. It's worth noting that I often refer to IntelliJ IDEA as "the venerable IDE" because it was one of tools that survived the Eclipse juggernaut that swept the market about a decade ago, and in my view, it has earned its many devoted fans.
More details are available on the JetBrains blog site.
Posted by John K. Waters on 11/03/2015 at 10:10 AM0 comments
It's been seven years since a group of software security mavens set out to create a "fact-based" set of best practices for developing and growing an enterprise-wide software security program. That set of practices, known today as the Building Security In Maturity Model (BSIMM ), was the first maturity model for security initiatives created entirely from real-world data.
"Our goal was to build an empirical model for software security based on real, observed practices," Gary McGraw, CTO of app security firm Cigital and co-author of the original BSIMM, told me at the time. "We believe that the time has come to put away the bug-parade boogey man, the top-twenty-five tea leaves, the black-box web-app goat sacrifice, and the occult reading of pen-testing entrails. This is an entirely data-driven model. If we didn't observe an activity, it didn't get into the model."
This week, McGraw and co-authors Sammy Migues, principal at Cigital, and Jacob West, chief architect at cloud-based business management software provider NetSuite, released BSIMM6. The latest edition was based on the real-world security initiatives reported by 78 companies, including Adobe Systems, Bank of America, Box, EMC, LinkedIn, PayPal, Salesforce, The Home Depot and VMware. The number of participating companies has grown every year since the first edition was published in 2008, based on studies of nine software security initiatives.
More companies actually participated this year, but the authors chose to focus on firms with data that were 42 months old or younger, McGraw told me. This year's model also includes data from two new verticals: healthcare and consumer electronics. (The other two are financial services and independent software vendors.) The inclusion of data from healthcare organizations was especially timely, following the recent Anthem and UCLA Health data breaches.
"It was interesting to expand the study into health care," McGraw said. "And it's pretty clear that vertical as a whole has some work to do, though there are some very good outliers in the population." McGraw points to managed health care company Aetna and its chief information security officer, Jim Routh, as an example of such an outlier.
"BSIMM continues to be the authoritative source of observed practices and activities from the most mature software security programs across industries," Routh said in a statement, "and BSIMM6 offers excellent trend analysis compared with past data points indicating the evolution of software security maturity." Routh also serves as chairman of NH-ISAC, which is a nonprofit organization responsible for cyber security in the healthcare sector.
A "maturity model" describes the capability of an organization's processes in a range of areas, from software engineering to personnel management. The Capability Maturity Model (CMM) is a well-known example from software engineering. The BSIMM (pronounced "bee-simm") serves as a kind of measuring stick, its authors say, which is best used "to compare and contrast your own initiative with the data about what other organizations are doing contained in the model."
The BSIMM is organized into a software security framework that comprises a set of 112 activities grouped under four domains:
- Governance, which includes practices that help organize, manage and measure a software security initiative. Staff development is also a central governance practice.
- Intelligence, which includes practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.
- SSDL Touchpoints, which includes Software Security Development Lifecycle practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.
- Deployment, which includes practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance and other environment issues have direct impact on software security.
The data in this and other BSIMM releases shows that highly mature initiatives are "well-rounded" and carry out 12 core activities, including:
- Identifying gate locations and gathering necessary artifacts.
- Identifying PII (personally identifiable information) obligations.
- Providing awareness training.
- Creating a data classification scheme and inventory.
- Building and publishing security features.
- Creating security standards.
- Performing security feature review.
- Using automated tools along with manual review.
- Driving tests with security requirements and security features.
- Using external penetration testers to find problems.
- Ensuring host and network security basics are in place.
- Identifying software bugs found in operations monitoring and feeding them back to development.
"We're getting to the stage in the model where, now that we have 29 times more data than we started with, we understand what firms should be doing," McGraw said. "That's the good news; the bad news is, not everybody is doing it yet. We've measured 104 firms with the BSIMM, but there are a lot more companies out there than that."
The BSIMM is a useful reflection of the current state of software security initiatives in the enterprise, and, given how hard it can be to get any organization to communicate honestly about its security practices, something of a miracle. As McGraw likes to say, it was a science experiment that escaped the test tube to become a de facto standard.
"That's very gratifying, personally," McGraw said, "but the important thing is the emphasis here of real data, and the use of facts in computer security. I think we've finally moved past the witchdoctor days in software security."
There's much, much more in the free report, which I consider a must-read. Also, Cigital has scheduled a BSIMM6 webinar for Tuesday, Nov. 10, which organizers say will cover how companies can apply the BSIMM information to their security programs. The event will be led by Cigital's Paco Hope.
Posted by John K. Waters on 10/20/2015 at 1:44 PM0 comments
GitHub last week announced a new partnership with Yubico to expand its authentication system, unveiled a new directory of integrated applications, and made an extension for large binary files available on all repositories on GitHub.com.
CEO and co-founder Chris Wanstrath made the Yubico partnership announcement at his company's GitHub Universe event in San Francisco on Thursday. Yubico is a co-creator (with Google) of the Universal 2nd Factor (U2F) open authentication standard hosted by the FIDO (Fast IDentity Online) Alliance. U2F relies on USB-like tokens that generate login codes unique to the users and the applications being accessed. Yubicomakes the tokens, and the company's CEO and founder, Stina Ehrensvard, was on-hand at the event to give away about 1,000 of them to attendees.
GitHub isn't the first code-hosting site to support two-factor authentication. Both Google and DropBox have partnered with Yubico, and GitLab announced in May the addition of two-factor authentication to its open-source GitHub alternative. GitHub has, in fact, been using YubiKey internally since December 2014, said GitHub app security engineer Ben Toews in an e-mail, and began using FIDO-approved U2F YubiKeys internally in June 2015.
I talked with Sam Lambert, GitHub's director of systems, during the GitHub Universe event about the Yubico partnership. The decision by DropBox, Google, and others to adopt FIDO U2F publicly, he said, helped to validate that standard. He described the partnership as "hugely important" and explained how GitHub is now encouraging developers who use the popular social coding site to build FIDO U2F support into their own applications.
GitHub's expansion of its authentication system is likely to do two things: further the adoption of the FIDO U2F standard among developers and make GitHub look more enterprise-friendly. The social coding site claims 11 million registered users and more than 36 million unique visitors every month, so its potential influence is clear. But providing U2F security also means that more enterprise dev teams will be able to convince management that GitHub is a safe place.
"The truth is, we're making great strides in the enterprise," Lambert said. "Look around [the conference] and you'll see GE, John Deere, Ford Motor Company, Pixar, Etsy -- even NASA uses GitHub. Thousands of developers are working on single GitHub Enterprise instances. And there's more to come for the enterprise next year."
GitHub's decision to support the integration of large binary files into Git workflows is another enterprise-friendly move, and one that addresses a well-known weakness. "Distributed version control systems like Git have enabled new and powerful workflows," writes the mysterious Technoweenie on the company's blog, "but they haven't always been practical for versioning large files. Git LFS (Large File Storage) provides an open source extension that replaces large files (video, big datasets, graphics) with text pointers within Git; the contents of the files are stored on remote servers, such as GitHub.com or GitHub Enterprise. Git LFS was actually released to early adopters in April. Version 1.0 is now generally available.
GitHub also unveiled its new Integrations Directory, which showcases a bunch of developer tools that work with GitHub. It's not as enterprise-oriented as the other two announcements, but it's a very cool resource.
"The Integrations Directory exposes a nicely curated set of applications that are really well integrated with GitHub -- some of them with literally one-click functionality added straight through into your organization's application," Lambert said.
As the less mysterious Kyle Daigle writes in another company blog post, the directory is a collection of developer tools that integrate with GitHub and "let you build sophisticated ChatOps workflows, allow you to deploy software directly from your GitHub repositories, and make it easy to track analytics, customer feedback, performance issues, and runtime errors back to a line of code and the context for code changes."
Since it was launched in 2008, GitHub, which is based on the Git distributed version-control system developed by Linux kernel creator Linus Torvalds, has become one of the world's most popular social coding sites. The service has enjoyed endorsements from the likes of the Eclipse Foundation, which allows the hosting of its projects on GitHub to attract new and maturing projects.
Posted by John K. Waters on 10/06/2015 at 5:44 PM0 comments
The first early access builds of JDK 9 with Project Jigsaw, the initiative that's bringing modularity to the Java platform, are now available for download. Before you jump in, you should definitely read Mark Reinhold's rich and readable "The State of the Module System," which he published online earlier this month. The chief architect of Oracle's Java Platform Group calls it "an informal overview of enhancements to the Java SE Platform prototyped in Project Jigsaw and proposed as the starting point for JSR 376."
JSR 376 is, of course, the Java Specification Request that aims to define "an approachable yet scalable module system for the Java Platform." But Project Jigsaw actually comprises JSR 376 and four JEPs (JDK Enhancements Proposals), which are sort of like JSRs that allow Oracle to develop small, targeted features for the Java language and virtual machine outside the Java Community Process (JCP). (The JCP requires full JSRs.) JEP 200: The Modular JDK defines a modular structure for the JDK. Reinhold has described it as an "umbrella for all the rest of them." JEP 201: Modular Source Code reorganizes the JDK source code into modules. JEP 220: Modular Run-Time Images restructures the JDK and JRE run-time images to accommodate modules. And the recently proposed JEP 260: Encapsulate Most Internal APIs (which I wrote about earlier), which Reinhold proposed to encapsulate unsupported, internal APIs, including sun.misc.Unsafe, within modules that define and use them.
The early access builds of Java 9 with Jigsaw include the latest prototype implementation of JSR 376 and the JDK-specific APIs and tools described in JEP 261, which will actually implement the changes and extensions to the Java programming language, JVM and standard Java APIs proposed by the JSR.
In his "state of" report, Reinhold provides a nuts-and-bolts breakdown of modularization, from the essential goals of the JSR, to detailed descriptions of modularization in the context of Java -- everything from "modules," "module artifacts" and "module descriptors" to the concepts of "readability," "accessibility" and "reflection."
In his conclusion, he writes:
"The module system described here has many facets, but most developers will only need to use some of them on a regular basis. We expect the basic concepts of module declarations, modular JAR files, module graphs, module paths, and unnamed modules to become reasonably familiar to most Java developers in the coming years. The more advanced features of qualified exports, increasing readability, and layers will, by contrast, be needed by relatively few."
He labeled the post "Initial Edition," so I'm expecting updates. I'd keep an eye out.
The long-awaited, much-delayed modularization of Java is going to be the biggest change since Java 8's support of lambdas. In a recent ADTmag post ("Is Oracle Dumping Its Java Evangelists?"), I followed up on a tweet by Gartner analyst Eric Knipp, who called Java a "dead platform." He made the case to me that Java is no longer the default choice for greenfield applications, and that change augurs its eventual demise. But I ran into Forrester analyst John R. Rymer at the recent Dreamforce event, and he posed the question, given all the recent and coming changes to Java -- especially modularization -- is it really the same language?
Posted by John K. Waters on 09/23/2015 at 9:21 AM0 comments