 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
|||||||||||||||||||||||||||||||||
|
PMO |
|
|
|
Oracle |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 11 |
Total attendance: 16 |
| Since 75% of the ME EC was not present, that EC was inquorate for
this meeting Since 75% of the SE/EE EC was present, that EC was quorate for this meeting |
|
PMO |
|
|
|
Oracle |
|
|
|
ME EC |
SE/EE EC |
Total attendance: 11 |
Total attendance: 16 |
| Since 75% of the ME EC was not present, that EC was inquorate for
this meeting Since 75% of the SE/EE EC was present, that EC was quorate for this meeting |
|
Prior to this meeting Doug Lea proposed and Tim Peierls seconded the following motion:
It is the sense of the Executive Committee that the JCP become an open independent vendor-neutral Standards Organization where all members participate on a level playing field with the following characteristics:
- Members fund development and management expenses.
- A legal entity with by-laws, governing body, membership, etc.
- A new, simplified IPR Policy that permits the broadest number of implementations.
- Stringent compatibility requirements.
- Dedicated to promoting the Java platform.
Furthermore, the EC shall put a plan in place to make such transition as soon as practical with minimal disruption to the Java Community.
The results of the ballot, which was carried out through email, were as follows:
ME EC |
SE/EE EC |
|
|
The motion was therefore carried.
The EC stats presentation was inserted into the record.
Patrick reported that Steven Chin replaces Wayne Carr as Intel's primary rep with Doug Sommers as his alternate. He also reported that Max Lanfranconi is leaving the PMO.
Don Deutsch reported that Oracle has spent several months in consultation with EC members, with developers, and with Java customers trying to work out a way forward. They have looked at a wide range of options and discussed various working arrangements, and finally concluded that Apache Harmony sets the stage for an inevitable fork. Even if Apache Harmony itself strictly complied with the TCK there is no ability to enforce compliance downstream (Apache cannot guarantee that either Apache communities or downstream users will strictly comply with compatibility requirements.) Consequently, Oracle has concluded that they cannot grant Apache a TCK license. Don stated that this decision is final - it will never change. He said that Oracle doesn't believe that the Java community fully understands the risks and consequences of a fork, noting that the Google Android situation is analogous to that which caused Sun to take legal action against Microsoft several years ago.
Don acknowledged that the community is frustrated by the lack of technical progress caused by this licensing dispute and said that Oracle plans to move forward with delivering new Java technologies through OpenJDK. Developer reaction to the plans announced at JavaOne was very positive. He said that Oracle will submit umbrella JSRs for Java SE 7 and Java SE 8 shortly after this meeting and that Mark Reinhold will present details of their contents later today. The JSRs will be presented with similar license terms as previous umbrella JSRs.
Don stated that the developer community did not want a licensing dispute to halt the evolution of the Java platform, and argued that it was in the interests of both Oracle and the community to move forward. Oracle very much wanted to make progress within the JCP, but if this was not possible it would be necessary to find another way to advance the platform.
Don concluded that it is in Oracle’s interest to have partners who increase their use of Java. He said that Oracle wanted to make OpenJDK more collaborative and more useful to licensees, since other Java vendors have a vested interest in moving forward with Oracle. He said that all partners are welcome to join Oracle, and emphasized that Oracle wants to enter into long-term and stable contracts with licensees to reduce the risks to both parties. He promised that Oracle will be a trusted and stable Java partner and reiterated that Oracle's primary economic interest is in furthering Java rather than in extracting revenue from it.
Geir Magnusson responded that this was not a surprise to him since Don had given him a heads-up. He said that he wanted input from others, and would keep his own remarks short. Geir pointed out that this is not just a licensing dispute, arguing that it is fundamental to Java's future that it be possible to create independent implementations. He said that although Apache is a not-for-profit organization, independent implementations are necessary for all to be able to monetize Java. Geir pointed out that in Java EE Apache had worked hard to enable compatible independent implementations; the process had worked well there with multiple competing implementations, some commercial and others open-source. The market was healthy. He argued that permitting Apache to create a compatible Harmony implementation would not in any way reduce the value of Oracle's assets - rather it would strengthen them. He noted that many people have contributed to Harmony, and concluded that Apache is not happy with this decision, and that he hoped EC members would not be happy either.
Jason Gartner said that IBM was disappointed with this decision - it wasn't what they wanted. He expressed the hope that if he was in Don's position he would be giving a different message, but of course he was not. He argued that Oracle is not Sun, and will not change their minds. The important question was what to do next. He pointed out that the JCP had been in stalemate since 2007, and it was necessary to be constructive and to move forward. He said that he was looking forward to hearing about the plans for Java SE 7 and SE 8.
Scott Jameson said that the topic under discussion was licensing
and Field of Use (FOU). He noted that FOU restrictions were the root cause
of the dispute, and asked Don to comment on whether or not FOU restrictions
violate the JSPA. Don responded that Oracle intended to continue to offer licenses
on the existing terms.
Doug Lea pointed out that there is no Java 7 JSR because the EC believes
that members should conform to JSPA. He argued that FOU-restricted licenses
violate the JSPA and suggested that the JSPA be changed. Josh pointed out
that Oracle is on record as saying that FOU restrictions violate the JSPA.
He asked whether they still feel that way. Ken Glueck responded that Oracle
came to talk about the Apache issue. He pointed out that Don
had been straightforward and candid.
Doug responded that EC members accept Oracle's determination not to grant
Apache a license, but argued that they cannot vote to approve
a violation of the JSPA. He argued that if Oracle wished to withhold a
license from Apache it must be on different
grounds or the JSPA must be changed.
Mike DeNicola asked whether Oracle was saying that they wouldn't grant a license to Apache under any circumstances or whether - like Sun - they ware saying that they wouldn't grant a license except with FOU restrictions. Ken Glueck confirmed that Oracle's position is the same as Sun's. Geir Magnusson said that this was the impression that he also had. Don Deutsch confirmed Oracle's position was that no unencumbered license would be offered to Apache.
Doug asked Oracle to acknowledge that it was asking the ECs to condone
breaking the JSPA rules. He said that if he was put in a position where
he had to condone breaking the rules he would have to resign. Ken said that
he understood, and would regret it if Doug resigned, but pointed out the
importance of allowing the conversation to go forward. Josh Bloch asked again
whether Oracle, who were on record as saying that to deny Apache a license
without FOU restrictions is a violation of the JSPA, still feel that way.
Ken Glueck responded that Oracle were not prepared to answer a legal question.
Josh responded that Oracle had been willing to vote on this matter twice in
the past. Ken responded that this is the situation now. Tim Peierls noted
that Oracle has had plenty of time to prepare an answer
Ken pointed out again that the platform is stuck and we need to move forward.
Doug Lea suggested that Oracle propose JSPA changes to legalize
the situation, making it possible for ECs to approve the SE JSRs since they
would no longer be in violation of the JSPA. He argued that this would be
a simple matter, and should be done as part of the JCP.next proposal. The
JSPA could be changed so that Oracle is no longer
obliged to grant Apache a license. Ken thanked Doug for his constructive suggestion,
noting that the JCP.next discussion hadn't yet happened. He asked others for
their thoughts on this matter. Several members pointed out that modifying the
JSPA was a more complex task than Doug had suggested, and might take months or
even years.
Don Deutsch asked whether member companies' lawyers and business people - as opposed to the standards representatives - really wanted this issue to be addressed. Tim Peierls, Scott Jameson, Josh Bloch, Rod Johnson, and Michael Bechauf all responded that they favored a clarification of the JSPA. Adam said he was pleased that people were willing to address this matter and suggested that it be discussed at a future meeting. Scott Jameson pointed out that it might take years to modify the JSPA, and argued for moving forward in parallel; Mike DeNicola and Susanne Cech Previtali agreed. It was later agreed to hold a follow-on meeting to discuss this topic. The meeting took place later in October, in private session.
Michael Bechauf asked what the function of the EC was, since it did not carry out technical work. Josh Bloch said that he didn't want to travel thousands of miles simply to rubber-stamp JSRs. Adam Messinger pointed out that the JCP used to work on technical matter, arguing that it should be focusing on what is of interest to engineers rather than spending all its time on licensing and legalistic issues. There were interesting technical problems to be solved, such as how we support multi-core and how we implement data binding. It was important to compete with .NET. Oracle wanted to work on these issues through the JCP and didn't want it to be simply a rubber-stamping body. He argued that the current situation was not useful or effective and suggested moving on to the technical items on the agenda.
Don Deutsch responded that the JCP's Process Document states that the duties and responsibilities of the EC are to select JSRs for development, to approve, to decide appeals, to review maintenance revisions, to provide guidance to the PMO, and to promote efficient organization with dedication to the principles of full & open competition. They vote to promote the Java platform. He pointed out that there is nothing in the Process Document to suggest that the EC should own or control Java. Oracle would be happy for the EC to exercise these powers.
Mike DeNicola addressed the question of why the EC was focusing on
licensing given its supposed charter. He noted that the JSPA requires
the submission of a JSR and that the ECs were the Expert Group for the JSR
that defined the JSPA. They wrote the rules (he was involved.) This is how
they got involved in licensing. When the FOU issue was first raised EC members
said "when we wrote the current version of the JSPA we intended to
move towards standardized open licenses. We removed restrictions from the
spec license, but we overlooked the TCK license." Sun lawyers had argued
that the JSPA didn't restrict what could be written in TCK licenses but
EC members disagreed. Oracle's lawyers now seem to have reached the same
conclusion as Sun did. He argued that it was necessary to move forward and
that this discussion was not constructive. Lawyers should review the JSPA
and if necessary they should suggest changes to clarify its intent.
Geir Magnusson asked for an explanation of the difference between
the OpenJDK and the Harmony situation (both were open source, but
with different licenses.) Adam responded that he couldn't answer legal questions,
but noted that the concern was with the danger of forks.
Geir Magnusson responded that Harmony was a different matter from Android.
Adam and Ken responded that they couldn't address the Google lawsuit. Michael
Bechauf noted that Oracle had concerns about fragmentation in the context
of Harmony and asked whether OpenJDK posed the same risks. Adam responded
that fragmentation is an inherent risk in all open source projects but that
with OpenJDK the risks are lower since there are less commercial incentives
to support it due to the reciprocity requirements.
Josh Bloch asked about open competition.
Adam responded that he was sitting next to a fierce competitor (Jason
from IBM.) He noted that they have common interests in moving
things forward. He reminded EC members that at OpenWorld/JavaOne there was
a talk showing how Java had moved forward faster than Moore's law
would have predicted; JVMs have improved significantly because of benchmark
races between IBM and Oracle. Josh responded that denying Apache the freedom
to create an independent implementation is not pro-competitive.
Adam encouraged all member companies to participate in OpenJDK.
He said that he wanted the organization to be more open, and while he was
not in favor of unbounded political discussions he did want wide participation
in technical discussions. Josh responded that discussion in OpenJDK is too
broad and argued for focused Expert Groups. Adam agreed
that Expert Groups are needed, arguing that spec work should happen in the
JCP while prototyping took place in OpenJDK. He noted that the stalemate in
the JCP has prevented the JCP from moving forward and that the deadlock must
be broken.
Patrick asked whether there was a consensus to move forward. He noted that
while a minority wanted to dig deeper into licensing issues most people
seem to think that these couldn't be resolved during this meeting.
Josh responded that he would rather discuss the governance issues and
take a vote.
Doug suggested moving on to technical issues, saying that these could be completed
very quickly and then they could come back to the licensing issues.
Rod Johnson agreed.
Patrick noted that a majority seemed to be willing to move on to
the technical discussions, and that some wanted to revisit the questions of
governance and licensing later. He suggested waiting to see how the JCP.next
discussion progressed.
Mark Reinhold led a discussion of the plans for Java SE7 and SE8 (see
presentation.)
He summarized the proposal for two JSRs, the first (SE7) to be delivered in
2011 (this would consist of work that was essentially complete in OpenJDK) and
the second in 2012. He noted that this proposal had received broad developer
support.
Mark then summarized the various component JSRs that are planned for SE7. On
Project Coin he noted that it would have been preferable to have an Expert Group,
since this would have provided more focus than the wide-open developer aliases.
Josh Bloch suggested that having two aliases (coin and coin-interest) might have
brought many of the same benefits.
Summarizing the SE7 discussion, Mark noted that he is still interested in feedback,
but he hoped that since Oracle had tried not to put anything controversial on
the list for SE7 he hoped that it would be possible to move quickly on this JSR.
He proposed to focus the technical discussion instead on SE8.
Jason Gartner said that IBM wasn't sure that the proposed contents of SE7 were
sufficient to ensure broad adoption. He asked for other EC members' opinions.
Josh Bloch responded that he thought this would be well-received. Mike DeNicola
suggested that the proposed ship dates still seemed optimistic. Jason responded
that "plan A" (a single release with the entire contents) would have
been even more of a problem, potentially leading to a reduction in adoptions
of current systems while people wait for a major release in 2013.
Doug Lea suggested that SE7 could be called 6.9, and if the work really was complete
it could be shipped "next week." Josh asked whether it really would
take so long to ship. Mark responded "yes." Adam Messinger noted that
he had to believe what his engineers told him, but that he hoped to improve release
efficiency in the future.
Scott Jameson noted that HP had similar concerns about two releases as IBM. Some
of HP's big customers had told them that they might not adopt SE7 but instead
would "wait for eight." Adam reported that Oracle's Fusion Middleware
products also need the SE8 features, but he pointed out the importance putting
something out for the developer community to show momentum.
Discussion continued after lunch when Mark Reinhold described the proposed contents
of SE8. The relationship between OSGI and the proposed SE8 module system was
raised, and it was suggested by IBM that the Java SE team collaborate with the
OSGI Alliance. Mark responded that they had tried in the past. Adam asked RedHat
and IBM to help the two groups reach an agreement. (A more extensive discussion
on modularity followed later in this meeting - see below.)
Doug Lea asked whether there were any plans for further work to support dynamic
languages (after JSR 292 "invoke dynamic"), such as the work being
carried out in the OpenJDK DaVinci Project. Mark responded that all ideas were
being considered. Adam pointed out that enhancing the VM to run languages other
than Java is an interesting problem. He asked for feedback on the question of
how much effort to put into non-Java languages as opposed to Java, suggesting
that this might undermine the primary strategy and confuse the market.
Geir asked "didn't that boat sail years ago?" Adam agreed, but noted
that it was still necessary to make resource allocation and prioritization decisions.
Doug Lea noted that it was important that the non-Java languages be supported,
since they tend to develop faster than Java, and help us to debug the VM.
Scott Jameson asked how soon the JSRs would be filed. Mark responded that they
would be filed as soon as possible after the meeting - hopefully in time for
the next ballot. Adam pointed out that they didn't want to file the JSRs if there
were any concerns about the technical content. Mike Milinkovich responded that
any problems with the ballot would be about licensing rather than the technical
content, and recommended filing the JSRs as soon as possible. Scott Jameson agreed,
saying that the JSRs should be filed right away - the technical details could
then be worked on in the Expert Group. He said that from what he had seen at
JavaOne the content seemed reasonable.
Adam asked one last time whether there were any other concerns about technical
content (he agreed that more work was needed on modularity.) No further concerns
were raised, and the discussion concluded.
Because this discussion finished sooner than planned, and because those leading the ME discussions were not yet ready to proceed, the ECs then moved on to address the JCP.next topic.
Patrick introduced the JCP.next topic, pointing out that he had annotated
the previous presentation noting where changes would need to be made.
He asked whether the Transparency proposals were non-controversial.
Josh Bloch responded that he was happy with the proposals, noting that Bob Lee's
dependency injection JSR had operated in this manner and it went very smoothly.
He pointed out that there were two public mailing lists: one for the core group
and one for casual observers. John Rizzo asked how the proposed requirements
would be enforced. Patrick responded that initially at least he did not propose
any formal enforcement mechanisms. He suggested that it ought to be enough to "shine
a light" on the activities of Expert Groups.
On the question of open EC meetings Mike DeNicola pointed out that in
the past EC meetings were held at JavaOne, which would enable JCP members to
participate. Alternatively, the EC could encourage local user-groups to meet
with them during face-to-face meetings. Mike Milinkovich suggested that community
members ought not to entirely set the agenda, but that they should be encouraged
to suggest topics for discussion, from which the EC would select items for inclusion
in the agenda of open meetings.
On the proposal to refactor the JSPA Scott Jameson noted that all three
member roles have IP implications and suggested that it might be wise to create
a separate IP policy document. Patrick agreed that this might be necessary, but
argued that it still ought to be possible to simplify the existing JSPA to make
it less intimidating.
Josh Bloch expressed some concerns about the proposal that rejections of requests
to join Expert Groups must be made in public, arguing that it might sometimes
be necessary to do so privately. However, he had no concerns with stating this
as a general policy.
On Agility someone pointed out that the Eclipse Foundation actively
review ongoing projects, find those that appear to be inactive, and then publicly
ask them to justify their existence. Inactive projects are "archived." Jason
Gartner noted that this proposal was presented as a goal rather than in the form
of a specific suggestion. He suggested trying to expand the scope and to articulate
specific goals.
On Collaboration, Cuihtlauac Alvarado pointed out that the multiplicity
of licenses used within the JCP is an obstacle to other Standards Developing
Organizations referencing JSRs. Scott Jameson noted that there are significant
structural issues in this area since strictly speaking the JCP is not an organization,
but rather a series of agreements between individuals or organizations
and Oracle. Don Deutsch responded that it ought therefore to be sufficient
for Oracle to make a bilateral agreement with the other SDO. Aguinaldo Boquimpani
noted that a direct relationship would not always be necessary. The International
Telecommunications Union (ITU) wanted to normatively reference Java specifications.
In order to do so a Memorandum Of Understanding would need to be drawn up.
The JCP would need to be recognized by the ITU as an organization that produces
standards through a formal process. Scott noted that recognition requires
that certain conditions be met, and suggested that there are indeed structural
obstacles to such recognition.
Patrick asked whether we should we pursue this. Members noted that it could
be dangerous to try and fail. Patrick promised to raise the matter within
Oracle. Aguinaldo pointed out that normative references to JSRs are being
removed from ITU specs, while Cuihtlauac pointed out that there had been attempts
to incorporate Java into tests for mobile phones in Europe. Patrick asked
them both to send him details by email and he would raise the matter within
Oracle.
No progress was made in the discussion of Standardized Licenses.
Patrick then suggested taking a step back, and defining some problems to be
addressed or goals to be worked on. Jason Gartner suggested the following,
arguing against a "low hanging fruit" approach:
1) speed (agility) in developing & implementing JSRs.
2) encouraging implementations before developing specs
3) review/modify the governance model (which was not addressed in the JCP.next
proposals)
4) simplified licensing (common inbound and outbound licenses), so that the
ECs could debate license issues once rather than every time a JSR is submitted.
Patrick noted that three out of Jason's four suggestions were already on the
list, suggesting that Jason was asking the EC to take a broader view.
Josh read the resolution recently proposed by Doug Lea (as recorded at
the beginning of these minutes.). He noted that it was passed without objection,
but without a vote from Oracle. He had asked why Oracle didn't vote. Don Deutsch
asked why Josh was raising this again. Josh responded because he still hoped
to see an independent organization. Don responded that he had originally proposed
this motion back in 2007, and expressed his surprise that Josh cast Google's
vote in favor of the motion since the wording included a statement about the
importance of compatibility, which Google did not seem to care about. He pointed
out that nobody had offered to pay for the Java assets, nor for the very significant
ongoing expenses of developing the Java platforms. Oracle did not vote on
the resolution because it was orthogonal to the issues the EC was addressing.
Later in the discussion Josh responded that Google does care about compatibility
- when they build something that they claim is standards-compliant they work
hard to make it so.
Don's comments about Java assets prompted a discussion about the difficulty
of forming an independent organization without control of the Java brand and
without ownership of the core assets of the Java platform. (Josh Bloch and
Geir Magnusson argued that it would not be necessary for an independent organization
to own the Java assets.) Jason Gartner pointed out that Oracle owns the Java
brand and will not give it up. EC members could still work to influence Oracle.
There was general agreement (if not approval) of this situation.
At the conclusion of this discussion the ECs adjourned for the day.
Roger Riggs led a discussion of the plans for Java ME (see
presentation,) noting that EC members were already familiar with most
of the material.
In response to Roger discussing the possibility that the size of the CLDC stack
might double, Cuihtlauac Alvarado and John Rizzo expressed concerns about the
effect this would have on feature phones in emerging markets. Roger agreed that
we must be market-aware, and pointed out that there would be no need to phase
out existing specs.
John Rizzo asked for a commitment that access to the Expert Group will be open
to all. Roger responded that most of what the Expert Group will need to do is
to select components and technologies that already exist in SE6. The EG will
have to work the tradeoffs (footprint, functionality) but no new APIs will be
created. The process should not be very contentious.
Cuihtlauac Alvarado reported that Orange would like to support this plan, but
noted that their decision would not be be based on technical considerations but
entirely on the prospects for Java applications in the market. He hoped that
discussions during this meeting would help Orange with that decision, but so
far Oracle has not convinced them that Java's prospects are good.
Calinel responded that Oracle will share the text of the JSRs next week and will
look for members' feedback. Roger agreed that there is obviously a much larger
context to discuss.
Roger then moved on to discuss the proposed phase 2 changes. Initial responses
focused on the question of how many JSRs should be filed.
Gero Schultz noted that narrowly-focused JSRs promote agility but may increase
fragmentation. Roger responded that optionality of APIs is only one aspect of
fragmentation, and not necessarily the most significant. Gero responded that
in MSA they had to define three different profiles for footprint reasons, which
indicates the need to be very aware of footprint limitations.
Roger noted that finer granularity permits more reuse. Calinel quoted the example
of a JSR that was filed for idle-screen functionality. EC members voted this
down, recommending that the functionality be incorporated into MIDP3 instead.
This meant that it took longer to develop and release.
John Rizzo argued that Sun/Oracle were a significant cause of the delay
in MIDP3, and that it was unfair to argue that we need lighter/smaller JSRs because
MDIP3 took so long. Craig Gering said that this was a fair comment, but argued
that we must recognize that one of the major problems in ME is "pace" (time
to market.)
John Rizzo agreed with Roger that fragmentation at the API level is not the major
issue.
The discussion then moved on to the question of whether APIs should be device-specific
or broader and hence more reusable.
John Rizzo argued that MIDP would have been used across many different kinds
of devices - including set-top boxes - if Sun had not imposed FOU restrictions.
Calinel responded that they were not specifically addressing MIDP, and that the
TV market uses standards specified outside of the JCP. Roger noted that they
have considered using MIDP on other types of devices (eg, set-top boxes) and
argued that a common platform that would allow services to be deployed across
many devices would be very helpful. John insisted that the root problems are
contractual - that they hadn't been permitted to use MIDP more broadly. He argued
that there is no need for spec changes - all that is required are license changes.
Craig agreed that licensing issues need to be addressed, but argued for more
commonality across platforms. Roger noted that the focus of MIDP spec has been
phones and that little consideration was given to requirements of other devices
such as set-top boxes. John agreed that there is a need for more commonality
(a single platform) across all devices.
Roger Mahler asked whether Oracle have decided how package the proposed new features.
Roger and Calinel explained that they deliberately haven't tried to specify whether
the new functionality might be delivered in optional package JSRs or into another
revision of the platform.
Edin Bektesevic asked whether consideration had been given to creating profiles
for different devices (e.g. smartphones and TVs.) Calinel responded that there
are lots of "invisible" devices running Java ME, not just phones
and set-top boxes. Many of these devices are headless. Oracle want to give developers
more reusability and to to make the APIs device-agnostic wherever possible, in
order to support many different types of devices.
John Rizzo agreed, arguing that the definition of what Java ME covers should
be expanded to deal with the "Internet of things." He argued that licensing
restrictions are an obstacle, and that technologies should not be limited to
mobile phones. Josh Bloch agreed, arguing that there is a continuum of devices
from cellphone to laptop, and that there's no point in trying to distinguish
types of devices. he asked whether an iPad a laptop without a keyboard or
an overgrown phone, noting that trying to make these kind of distinctions at
the licensing level made no sense. Doug Lea agreed, arguing that the distinction
between Java ME and Java SE was an obstacle to further development of Java technologies.
He suggested that Java needs modularity and profiles right now and that we can't
afford to wait until Java SE 8 for this support in SE and perhaps longer for
support in ME (the distinction between SE and ME should
be dissolved.) Mark Reinhold agreed that the long-term goal should be to unify
Java ME and SE, noting that Oracle has already prototyped a subset of Java SE
for small devices.
Craig noted that things get more complicated below the smartphone level (with
CLDC, where there is no full OS and a minimal footprint.) Building a module system
that goes down that far is difficult. Doug Lea responded that for the lowest-end
devices a "frozen modular profile" could be defined at device-manufacture
time. Mark agreed with the need for a module system. Roger Mahler suggested that
something like OSGI on mobile phones would be very difficult to handle. The amount
of testing required to ship static configurations is extremely high - manufacturers
could not handle dynamic updates. Adam Messinger replied that they weren't necessarily
suggesting that - static configurations could be constructed from modules.
Roger Mahler pointed out that there are two possible approaches: to shrink SE
down to run on a constrained device or to take something that runs on a constrained
device and grow it. Roger Riggs emphasized the importance of defining the
semantics of the module system, noting that implementation might be very different
on constrained and high-end devices.
Calinel noted that the presentation lays out several phases, of which Phases
0 and 1 are evolutionary. Oracle believed that these changes needed to be implemented
quickly in order to improve the situation for Java ME. A more radical modular
approach was also important, and could only be discussed and solved within the
JCP. It should be addressed soon. He asked for feedback on the current proposals.
Cuihtlauac again asked whether Oracle was committed to the future of ME, arguing
that Orange sees viable alternatives to Java in the mobile space and are increasingly
removing requirement for Java from our specs.
Patrick noted that this question provided a good segue into the ecosystem discussion.
Sean Sheedy led a discussion on Java
ME's Ecosystem Challenges, noting that previous attempts had been made
to solve these problems - through the ME Working Group, for example.
Roger Mahler noted that it is important to identify the problems that the JCP
could hope to solve and those it could not influence. John Rizzo noted that competing
platforms have their own (separate) developer support communities and asked whether
Oracle had any plans to address this. Craig Gering responded that Sean's presentation
was heavily biased towards the cellphone business and pointed out that Java
ME is much broader than that. He argued that it would be useful to divide the
problems into different categories:
1) Technical issues that can be relatively easily fixed (e.g. the security issues.)
He noted that the world has moved on - people download apps much more than they
used to - and it ought to be possible to fix this problem.
2) The other issues might be classified more as Oracle business issues than as
JCP matters. He stated that Oracle is motivated to address business issues and
promised to raise them within Oracle.
Roger Mahler said that if Java loses the mobility market it may lose the back-end
too since people don't like to mix and match environments - they want unity across
all platforms. Craig agreed that there are larger Java ecosystem issues, but
noted again that the technical issues should be relatively easy to solve. He
promised that Oracle would drive the business issues while agreeing that
ecosystem issues are more problematic. Roger responded that he would want to
know that the business issues are being addressed before committing resources
to solving the technical issues. Cuihtlauac noted that this is what he had said
at the end of the previous discussion.
Roger Mahler noted that most other SDOs have business and marketing efforts -
the JCP should too. He asked Oracle must show leadership, noting that he was
trying to sell Java within AT&T. John Rizzo
stated that PR issues are magnified in the mobile phone space, pointing out that
there are five operators on the ME EC, but only one (AT&T) has Java
as a mandatory requirement (for the others it's optional.) Roger responded
that AT&T's mandatory requirement for Java probably won't last long, and
repeated that losing in the mobile space could affect adoption in SE and EE also.
John Rizzo noted that although Sun was generally good at developer evangelism,
the JCP had failed to win developer mindshare in the mobile space.
Craig thanked members for the valuable feedback. He pointed out that Oracle is
spending a great deal of money and has many engineers working
on Java. He acknowledged that there are real problems in the ecosystem that must
be addressed, but suggested that things are not quite as bad as some EC members
suggested. He noted that while smartphones get all the attention,
Java ME still ships on very large numbers of phones. He agreed that the barrier
between Java SE and ME needs to be addressed. Finally, he stated his opinion
that there is a need for common tools and shared pools of developers and argued
that the most important issue was to deliver tools that make it easy to develop
high-quality applications for Java ME.
Aguinaldo agreed that while we are facing serious problems there is a future
for ME. He suggested that the innovation outlined in the previous (ME.next) presentation
could re-energize developers. However, he warned that time-to-market could be
a problem. Cuihtlauac and Roger Mahler argued that the device manufacturers are
the key, and that they need to be persuaded of the value of Java.
Doug asked what an ideal world would look like. John Rizzo responded that although
large numbers of ME devices are still shipping there is significant fragmentation.
He said that we need a consistent addressable market and a way to reach that
market - an easy way for developers to get access to the hundreds of certifications
needed to get on to the networks.
At this point the meeting broke for lunch.
After lunch EC members once again addressed the question of modularity.
Jason Gartner pointed out that many problems could be solved by modularity. It was very important to define a core system - possibly based on CDC - that could scale to support different types of appliances (for example, database appliances.)
Craig Gering reminded the group that the goal is to dissolve the boundaries between Java ME and SE, and noted that a significant proportion of the Java ME devices shipping today are smaller than CDC. The goal is to provide one Java that runs on everything from embedded systems upwards (many of the lower-end devices don't run CDC.) Adam Messinger suggested that the core might be based instead on CLDC. Jason agreed that this would be advantageous. Adam argued that it might be necessary to have two profiles - one for SE-like devices and one for smaller devices.
Doug Lea noted that the Java SE proposal for modules is for enhanced packages - there is no granularity at the method level. He pointed out that the modularity JSR is missing static configurability. Josh agreed, arguing that it ought to be possible to resolve references at built time or at runtime (with or without reflection.) Doug argued for another modularity JSR involving both ME and SE people. He suggested that this could be started today. Jason supported the idea. Josh Bloch argued that the implementation should be as simple as possible (stripped to its essentials.)
Calinel argued against allowing arbitrary mixes of modules and versions, and suggested that profiles (collections of modules) would be useful as the final deliverable. Josh argued that this would be up to the Expert Group. Craig noted that it was very likely - in the medium term at least - that there would be two sets of modules: one that runs well on less powerful devices and one that runs well on larger devices. Adam asked when that resolution would happen. If it happened at build time a makefile could generate the appropriate implementation.
Roger Riggs noted that it would be helpful if modules could be annotated with information about possible uses. Doug stated that based on his experience in a previous modularity Working Group the minimum requirements are imports, exports, and versioning. What we need technically is merely a way to define modules. We need processes to say "what is the granularity of modularization." The technical and non technical issues are completely intertwined.
Josh Bloch then proposed, and Doug Lea seconded the following motion:
"The EC believes it to be in the interest of the Java Community to complete a JSR as quickly as possible to modularize the Java platform, so as to allow for compliant implementations spanning the widest possible array of computing devices. This JSR must be voted on by both the ME and SE ECs, as it affects both platforms. The scope of the JSR must be as small as possible consistent with these goals. To that end, we will immediately assemble a working group to bring forth this JSR."
All EC members present voted in favor of the motion, but since the ME EC was inquorate, the formal vote was considered to be only of the SE EC. A Working Group was then formed with the following members: Josh Bloch (chair), Sean Sheedy, Jason Gartner, Erki Rysa, John Rizzo, Roger Riggs, David Bosschaert, Roger Mahler, Werner Keil, Doug Lea, Tim Peierls, Geir Magnusson, Adam Messinger, and Mark Reinhold. EC members agreed that it was appropriate for non-EC members to participate in the Working Group and that the group could include invited experts as it saw fit.
After thanking Gero Schultz and TMobile for hosting the meeting the ECs adjourned.
