With voting on a module system for Java set to close within the Java community, a high-ranking official at Oracle is again defending the plan amid criticism from Red Hat.
Modularity is the main feature in Java 9, which is due to arrive July 27—if the disagreement over modularization does not hold up the release. Oracle's Mark Reinhold, chief architect in the company's Java platform group, sent out an email on an openjdk mailing list Monday, arguing the issues being brought up have already been covered.
"Since then, I've seen no new information that persuades me to change my views on them," Reinhold said. Responding to a post from Red Hat's David Lloyd, Reinhold said every change to existing functionality bears compatibility risk. Lloyd said Red Hat and other Java executive committee members have communicated the "various deficiencies" in the specification. But Reinhold said every addition places hard constraints on how the platform can evolve in the future. "That a change or addition appears useful to some is just the start of what must be a thorough analysis of its wider and long-term consequences," Reinhold said. "That a change or addition is 'quite easy' to implement is completely irrelevant."
Lloyd's criticism follows up a critique of the modularity platform by Red Hat Vice President Scott Stark, who said the addition could cause application compatibility problems and have developers dealing with two realms, one modular and one not. Reinhold, however, called for "responsible stewardship" and said the community must reject any proposal that merely appears useful to some. "To act otherwise would be the height of irresponsibility."
Lloyd called for a revision that would have cycles to exist among modules at runtime. Reinhold responded that a primary goal of the Java Specification Request (JSR) was to create a module system approachable by all developers, not just application server developers. (Red Hat sells the JBoss Java application server.) "One result of that thinking is that this module system imposes some constraints that are intended to make working systems easier to reason about and to guide developers toward better practices," Reinhold said, adding that cycles possibly could be added in a future release.
Reinhold also objected to primitives proposed by Red Hat, saying they constrain the future evolution of the module system. "To design a proper set of such primitives, i.e., a 'meta' module system, is not a goal of this JSR," he said.
Red Hat's Lloyd also suggested package namespace isolation among module path modules, but Reinhold said developers ameliorate this issue by using the reverse-DNS convention for package names. "If an application works properly on the class path today, then it likely does not have conflicting packages to start with, since conflicting packages on the class path so often lead to trouble." The module system places application modules into a single class loader by default, so developers have one fewer behavioral difference to deal with when upgrading components to explicit modules.
Voting on JSR 376 was to conclude Monday, but results may not be announced until as late as June. Last week, Reinhold accused IBM and Red Hat of acting in self-interest in opposing the module system. Lloyd, however, suggested Reinhold not assume Red Hat or others would vote no out of only self-interest after having capitulated on many points. "We're looking for practical solutions to a few critical problems that push this over the minimum line for us and may also solve critical concerns shared by other EG (expert group) and EC members."