Moving Java Forward Faster

2017-09-07 Thread Rory O'Donnell

Hi Mark,

Oracle is proposing a rapid release model for Java SE going-forward.

The high points are highlighted below, details of the changes can be 
found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].


Under the proposed release model, after JDK 9, we will adopt a strict, 
time-based model with a new major release every six months, update 
releases every quarter, and a long-term support release every three years.


The new JDK Project will run a bit differently than the past "JDK $N" 
Projects:


- The main development line will always be open but fixes, enhancements, 
and features will be merged only when they're nearly finished. The main 
line will be Feature Complete [3] at all times.


- We'll continue to use the JEP Process [4] for new features and other 
significant changes. The bar to target a JEP to a specific release will, 
however, be higher since the work must be Feature Complete in order to 
go in. Owners of large or risky features will be strongly encouraged to 
split such features up into smaller and safer parts, to integrate 
earlier in the release cycle, and to publish separate lines of 
early-access builds prior to integration.


The JDK Updates Project will run in much the same way as the past "JDK 
$N" Updates Projects, though update releases will be strictly limited to 
fixes of security issues, regressions, and bugs in newer features.


Related to this proposal, we intend to make a few changes in what we do:

- Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to 
make it easier for developers to deploy Java applications to cloud 
environments. We'll initially publish OpenJDK builds for Linux/x64, 
followed later by builds for macOS/x64 and Windows/x64.


- We'll continue to ship proprietary "Oracle JDK" builds, which include 
"commercial features" [6] such as Java Flight Recorder and Mission 
Control [7], under a click-through binary-code license [8]. Oracle will 
continue to offer paid support for these builds.


- After JDK 9 we'll open-source the commercial features in order to make 
the OpenJDK builds more attractive to developers and to reduce the 
differences between those builds and the Oracle JDK. This will take some 
time, but the ultimate goal is to make OpenJDK and Oracle JDK builds 
completely interchangeable.


- Finally, for the long term we'll work with other OpenJDK contributors 
to establish an open build-and-test infrastructure. This will make it 
easier to publish early-access builds for features in development, and 
eventually make it possible for the OpenJDK Community itself to publish 
authoritative builds of the JDK.


Questions , comments, feedback to OpenJDK discuss mailing list [2]

Rgds,Rory

[1]https://mreinhold.org/blog/forward-faster
[2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[4]http://openjdk.java.net/jeps/0
[5]http://openjdk.java.net/legal/gplv2+ce.html
[6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
[8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61491] IllegalArgumentException thrown by PerMessageDeflate sendMessagePart()

2017-09-07 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61491

--- Comment #2 from Mark Thomas  ---
I've managed to reproduce this.

It is triggered by a zero length message after a non-zero length message when
the compression context is retained between messages.

I'm starting to think about a fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 57767] Websocket client proprietary configuration

2017-09-07 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57767

--- Comment #15 from Christopher Schultz  ---
None of the Java classes in the authentication support patch have any Javadoc.
I'm -1 on accepting the patch on that basis alone. I've skimmed the code and it
otherwise looks good, but I have not tested it at all.

For authentication, I wonder how much code can be re-used from Tomcat's
existing HTTP Basic and HTTP Digest authenticators. I'd prefer not to have
competing implementations of WWW-Authenticate handling in Tomcat.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 57767] Websocket client proprietary configuration

2017-09-07 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57767

--- Comment #16 from Mark Thomas  ---
If there is a possibility of reuse ( this is client side and the existing code
is server side) we'd need to be careful about which package / jar we put it in
to avoid adding unwanted dependencies for the WebSocket client JAR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 57767] Websocket client proprietary configuration

2017-09-07 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57767

--- Comment #17 from Remy Maucherat  ---
Yes, I would rather integrate it (if it works) then see about reuse. I also
don't think javadoc is a big issue either for this kind of code.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org