1. New Security Control Enhancements Java 8 and 9

2. A little background dirt…
@manicode
Author of "Iron-Clad Java, Building Secure Web Applications” from McGraw-Hill/Oracle-Press
20+ years of software development experience
OWASP Volunteer and Former OWASP Global Board Member
Kauai, Hawaii Resident

3. Java Enhancement Proposals

4. 'ohana
(oh-ha-na) MEANING: Family. MOST COMMON USE: In referring to the WHOLE family.

5. JEP IT UP JEP stands for a JDK Enhancement Proposal
JEP's are how you drive change in the Java ecosystem.
Involvement is actually a lot of work.
Attention is given to people that put in the work.
The way to make improvements or get ideas seriously considered is to do them via the JEP proposal process.
Mike Ernst and Werner Dietl are good examples. They are the duo that built type annotations which we we will talk about soon.
There is a lot of OpenJDK activity and I'd like to encourage you to get involved with the process if you have specific changes you want to see.
Involvement is actually a lot of work, and most attention happens from people that put in the work.
People make a lot of requests or suggestions, but the way to make improvements or get ideas seriously considered is to do them. The process is also important. Ideas almost always change as you publish and have the community review them. This process of evaluation is critical.
I want to mention some people who followed the JEP process and put in major contributions. For example Mike Ernst and Werner Dietl – they are both here at JavaOne and they did type annotations which have significant impacts for security tool writers and developers.

6. Java 9 Security JEP's

7. Java 9 Security Enhancements
There are 8 main security related JEPs for JDK 9: : Datagram Transport Layer Security (DTLS) 229: Create PKCS12 Keystores by Default 232: Improve Secure Application Performance 244: TLS Application-Layer Protocol Negotiation Extension 246: Leverage CPU Instructions for GHASH and RSA 249: OCSP Stapling for TLS 287: Support SHA-3 Hash Algorithms 288: Disable SHA-1 Certificates
There are 8 security related JEPs for JDK 9: 219: Datagram Transport Layer Security (DTLS) 229: Create PKCS12 Keystores by Default 232: Improve Secure Application Performance 244: TLS Application-Layer Protocol Negotiation Extension 246: Leverage CPU Instructions for GHASH and RSA 249: OCSP Stapling for TLS 287: SHA-3 Hash Algorithms 288: Disable SHA-1 Certificates I would probably highlight the following 4: 219: DTLS 244: ALPN 246: Leverage CPU Instructions for GHASH and RSA 288: Disable SHA-1 Certificates

8. (ah-ka-my) MEANING: Smart or Clever. MOST COMMON USE: Smart.
akamai
(ah-ka-my) MEANING: Smart or Clever. MOST COMMON USE: Smart.

9. JEP 219

10. JEP 219 Datagram Transport Layer Security (DTLS) http://openjdk. java
TLS is not sufficient for a variety of datagram applications.
Datagram applications still need transport security!
JEP 219 defines an API for Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347).
Small implementation that is transport-independent and similar to javax.net.ssl.SSLEngine.
Motivation
It is important to support DTLS to satisfy secure-transport requirements for the increasing number of datagram-compatible applications. RFC 4347 lists a number of reasons why TLS is not sufficient for these types of applications:
"TLS is the most widely deployed protocol for securing network traffic. ... However, TLS must run over a reliable transport channel---typically TCP. It therefore cannot be used to secure unreliable datagram traffic."
"... an increasing number of application layer protocols have been designed that use UDP transport. In particular, protocols such as the Session Initiation Protocol (SIP) and electronic gaming protocols are increasingly popular."
"In many cases, the most desirable way to secure client/server applications would be to use TLS; However, the requirement for datagram semantics automatically prohibits use of TLS. Thus, a datagram-compatible variant of TLS is very desirable."
Protocols that support DTLS include, but are not limited, to:
RFC 5238, Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
RFC 6083, Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
RFC 5764, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
RFC 7252, Constrained Application Protocol (CoAP)
Google Chrome and Firefox now support DTLS-SRTP for Web Real-Time Communication (WebRTC). DTLS version 1.0 and 1.2 are supported by the major TLS vendors and implementations including OpenSSL, GnuTLS, and Microsoft SChannel.

11. JEP 244

12. JEP 244 TLS Application-Layer Protocol Negotiation Extension http://openjdk.java.net/jeps/244
JEP 244 extends javax.net.ssl package to support the TLS Application Layer Protocol Negotiation (ALPN) Extension.
When different protocols are supported on the same TCP or UDP port, ALPN allows a negotiation to determine which protocol will be used with a TLS connection.
An important consumer of this enhancement is the HTTP/2 client (JEP 110).
Motivation
In order to support TLS clients and servers wishing to use multiple application-layer protocols over the same transport-layer port, the ALPN extension allows a client to provide a list of the application-layer protocols it supports, in order of preference. A server can then select one of the advertised client protocols and tell the client which protocol will be used in the TLS connection.

13. JEP 249

14. JEP 249 OCSP Stapling for TLS http://openjdk.java.net/jeps/249
JEP 249 implements OCSP Stapling for TLS clients.
Revocation (in general) does not work well.
It takes at least 10 days for the revocation Information to fully propagate
Browser soft fail policy makes revocation ineffective
OCSP request can be intercepted (more on this than later)
Motivation
Checking the revocation status of an X.509 certificate is a critical part of valid certificate-based authentication. However, certificate status checking using OCSP typically involves a network request for each certificate being checked. Because of the additional network requests, enabling OCSP checking for TLS on the client side can have a significant impact on performance.
OCSP stapling allows the presenter of a certificate, rather than the issuing Certificate Authority (CA), to bear the resource cost of providing OCSP responses. In a TLS context, it is the responsibility of the TLS server to request the OCSP response and send it to clients during the SSL/TLS handshake. This also allows the server to cache OCSP responses and supply them to all clients that are connecting to it. This significantly reduces the load on the OCSP responder since the response can be cached and periodically refreshed by the server rather than by each client.
Most browsers ignore revocation for all certificates but EV certificates

15. Online Certificate Status Protocol (OCSP) An alternative to certificate lists (CRL)
OCSP Responder
Port 80 to OCSP: Request status for webserver
Port 80 to Client: Status OK. Signed by OCSP Responder
No Privacy
Cert Auth
App Talks to Server
Online certificate status protocol created as an alternative to certificate revocation lists (CRL) – the idea was to avoid the burden of a large CRL (Cert revocation list): it uses a lot less bandwidth. According to GoDaddy, their CRL grew from 158KB in 2007 to 41MB in 2013!
When an SSL client encounters a cert that contains OCSP information, it contacts the designated OCSP server to determine if the cert has been revoked.
The key that signs a response need not be the same key that signed the certificate.
OCSP requests are sent over HTTP
One issue with OCSP is privacy because the client must ask the CA for the OCSP information.
Does the usual… Not shown here for simplicity sake.
Web Server

16. Attacks against OCSP Port 80 to OCSP: Request status for webserver
OCSP Responder
Port 80 to OCSP: Request status for webserver
Port 80 to Client: Status OK. Signed by OCSP Responder
MitM
Cert Auth
App Talks to Server
OCSP used to include a nonce but this didn’t scale well when caching and CDN became the norm. As a result clients don’t send nonce and if they send servers ignore them. For this reason, OCSP can be vulnerable to replay attacks, where a signed, 'good' response is captured by a malicious intermediary and replayed to the client at a later date after the subject certificate may have been revoked. The only defense is the built-in time limit.
Does the usual… Not shown here for simplicity sake.
Web Server

17. Port 80 to OCSP: Request status for webserver
Attacks against OCSP
Port 80 to OCSP: Request status for webserver
OCSP Responder
MitM
OCSP Request
Cert Auth
When an SSL client encounters a cert that contains OCSP information, it contacts the designated OCSP server to determine if the cert has been revoked. Because the MiTM can suppress all the traffic to the server, this method can fail. Browsers tend to fail quietly in this case. Browsers can be configured to hard fail. In firefox go to about, config and set security.ocsp.required to true. (screen shot slide)
Does the usual… Not shown here for simplicity sake.
Web Server

18. OCSP Stapling Faster, safer and more private
OCSP Responder
Cert Auth
Caches OCSP data and staples in cert response
Port 80
App Talks to Server
To overcome performance, privacy and security issues, OCSP Stapling was created. The webserver is the one to talk to the CA and obtain a fresh response. The server can then cache the OCSP info and submit it to the client along with the cert. Besides privacy, this also improves performance and resolves the man in the middle “drop package” attack seen with OCSP.
Apache supports OCSP stapling starting with the 2.4.x version.
Does the usual… Not shown here for simplicity sake.
Web Server

19. JEP 287

20. JEP 287 SHA-3 Implementation http://openjdk.java.net/jeps/287
FIPS 202 defines four new hash functions: SHA3-224, SHA3-256, SHA3-384, and SHA These can be implemented as new algorithms of the java.security.MessageDigest API under the standard names "SHA3-224", "SHA3-256", "SHA3-384", and "SHA3-512".
No new APIs are necessary, since there are no new parameters required.
Here is the list of providers and the corresponding algorithm enhancements:
"SUN" provider: SHA3-224, SHA3-256, SHA3-384, and SHA3-512
"OracleUcrypto" provider: SHA-3 digests supported by Solaris 12.0
Non-Goals
This JEP will not implement the SHAKE128 and SHAKE256 extendable-output functions (XOFs) because they are not approved as hash functions. The latest PKCS11 v2.40 draft does not contain SHA-3 support. Thus, there is no change to the "SunPKCS11" provider. Also, this JEP will not implement SHA-3 based algorithms for other cryptographic functions such as Signatures, MACs, and Ciphers since there are no standards for them yet. Those will be covered in subsequent enhancements and/or JEPs.
Motivation
SHA-2 was published over 10 years ago, and although no significant attack on SHA-2 has been demonstrated, NIST perceived a need for a dissimilar cryptographic hash function as an alternative to SHA-2. Nine years in the making, SHA-3 is the first cryptographic hash algorithm NIST has developed using a public competition and vetting process. FIPS 202 "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions" was finalized as a standard in August Cryptographic vendors such as BouncyCastle started supporting SHA-3 when FIPS 202 was still a draft. Solaris will also support SHA-3 in the coming Solaris 12.0 release. Since hash functions are used extensively in security applications and SHA-3 implementations are already being added by other vendors, it is important to provide support for SHA-3 in the JDK.

21. JEP 288

22. TLS Benefits Confidentiality Integrity Authenticity
Spy cannot view your data
Integrity
Spy cannot change your data
Server you are visiting is the right one, backed up by the Certificate Authority System
Authenticity

23. TLS Certificates TLS uses X.509 Certificates
Used to authenticate the other party
NOT used to help negotiate a symmetric key (beyond authentication)
TLS certificates from certificate authorities help websites prove their authenticity. These certificates contain:
The certificate holder
The domain that the certificate was issued to
The signature of the Certificate Authority who verified the certificate
IVAN: certs don't help negotiate a sym. key, beyond auth of course-
certs can have multiple hostnames via SAN
When using SSL/TLS, understand the Internet’s PKI (RFC 5280) has some problems in practice. The problems lie in both PKI and the Internet profile, and Dr. Peter Gutmann tells us the whole PKI system should be scrapped. Scrapping PKI effectively scraps SSL/TLS (which many can’t do), so you will have to take steps to work with SSL/TLS safely.
Server authentication is a big problem with PKI and the Internet profile. The problem is you never really know whom you are talking to, and it’s the reason basic_auth is so dangerous. In fact, CAs explicitly shed liability for end-entity identification (in addition to nearly all other liabilities) and leaves it up to the Relying Party (which is you) to determine identity.
If you have worked with the Internet PKI in practice, then you know the inconsistent results produced by path validation, validity checking, name checking, key usage and extended key usage. Not only is it the wild, wild, west, the system also rejects valid self-signed certificates providing opportunistic encryption!
To overcome the server identity problem, you can use TLS-PSK or TLS-SRP (only an authorized sever has access to the user’s password from provisioning or account setup); or you can use certificate or public key pinning (only an authorized server holds the private key for an expected public key).
If you access remote systems with a password, you should never use a basic_auth scheme inside a SSL/TLS tunnel. Basic_auth places the password on the wire in the plain text, so whoever has the listening socket open at the other end gets a username and password for nearly no work. Instead of basic_auth, you should use TLS-PSK or TLS-SRP, for which IANA has reserved over 80 cipher suites so there’s no shortage. Pre-Shared Key (TLS-PSK) and Secure Remote Password (TLS-SRP) properly bind the outer encryption tunnel to the inner authentication mechanism, so the password is never directly used in the plain text. Either both sides will have knowledge of the secret, or secure channel setup will fail with no leaks.
Pinning is a key continuity scheme, and the idea is to either (1) carry around a copy of the server’s public key; or (2) note of the server’s public key on first use (Trust-on-First-Use, Tofu). The former is great if you are distributing a dedicated client-server application since you know the server’s certificate or public key in advance. The latter is useful when no a priori knowledge exists, such as SSH or a Browser. Both detect the unexpected change that occurs when an imposter with a fake certificate attempts to act like the real server.
While you have a choice to pin the certificate or public key, it’s often best to pin the public key. That is because some companies, such as Google, rotate its certificate regularly (every 30 days or so) but re-certifies the inner public key.

24. JEP 288 Disable SHA-1 Certificates http://openjdk.java.net/jeps/288
Disable X.509 certificate chains with SHA-1 based digital signatures.
"SHA-1 should no longer be used to apply digital signatures to data"
NIST Recommendation for Key Management, Part 1: General
"CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until January 1, 2017"
v1.3 of the CA/Browser Forum Baseline Requirements (Section 7.1.3)
Motivation
The use of SHA-1 based digital signature algorithms is increasingly a security concern due to the risk of collision attacks. NIST recommends in SP , Part 1that SHA-1 should no longer be used to apply digital signatures to data. The CA/Browser Forum's Baseline Requirements for Publicly-Trusted SSL Certificates state that as of 1 January 2016, Certificate Authorities must not issue any subordinate CA or subscriber certificates using SHA-1. Other software vendors (Google, Microsoft, Mozilla) have published plans to deprecate SHA-1 in certificates. In the JDK, X.509 certificate chains are used for authentication of servers and clients in TLS and for verifying the integrity and authors of signed code. Thus, it is important that we provide a default configuration that includes protection against the security risks of SHA-1 certificates.

25. SHA-1 and the Urgency to Move On
In 2005, cryptographers proved that SHA-1 could be cracked 2,000 times faster than predicted.
At one point 90% of websites used SHA-1 to protect themselves from being impersonated. That number is now below 4%.
As long as browsers need to support SHA-1 for someone, anyone's certificate can be forged because browsers will not know there is a good cert that uses SHA-2
Year
Cost (In US$)
Cost Within Reach For
2012
2,770,000
Government, large corporations
2016
700,000
Medium size institutions
2018
173,000
Organized crime
2021
43,000
University research
SHA1 collision cost: Burce Schneier -
Website for test:
You can impersonate a SHA-2-signed cert with a SHA-1-signed forgery, because the browser will only be looking at the forgery and not know that there's a "real" cert or that that cert is "supposed" to be signed with SHA-2
“CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017.” 

26. The Death of SHA-1 according to Google
Chrome Version
Date
UI Changes
Behavior 39
Sept 2014
Certs that expire in Jan 2017 using SHA-1 or mixed content 40
Nov 2014
Certs that expire between 1 June 2016 to 31 Dec 2016 using SHA-1 in the chain 41
Q1 2016
Certs that expire on or after 1 Jan 2017
Source:
Source:

27. The Death of SHA-1 according to Mozilla
Show the “Untrusted Connection” error whenever a publically issued SHA-1 certificate issued after January 1, 2016, is encountered in Firefox.
Locally installed authorities (like MITM proxy tools) are NOT subject to this rule.
Firefox will show the "Untrusted Connection" error message for all SHA-1-based certificates after January 2017.
certificates-with-validity-period-from-2016-will-not-be-validated/
SHA1 collision cost: Burce Schneier -
Website for test:
You can impersonate a SHA-2-signed cert with a SHA-1-signed forgery, because the browser will only be looking at the forgery and not know that there's a "real" cert or that that cert is "supposed" to be signed with SHA-2
“CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017.” 

28. https://shaaaaaaaaaaaaa.com/
SHA1 collision cost: Burce Schneier -
Website for test:
You can impersonate a SHA-2-signed cert with a SHA-1-signed forgery, because the browser will only be looking at the forgery and not know that there's a "real" cert or that that cert is "supposed" to be signed with SHA-2
“CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017.” 

29. Crypto Note
If Crypto API's are important to you over time, please keep an eye on the Java Cryptographic Roadmap
This will help you keep an eye on planned changes in the Oracle JRE/JDK
Well maintained, last updated 48 hours ago.
Also, take a look at all of the major crypto changes that happened in Java 8. This is one of the largest moves in supporting modern crypto
NSA Suite B Cryptography
Strong Ephemeral Cipher Suites
Better Support for High Entropy Random Number Support
Weak algorithms Disabled by Default (Where is Dr. Depreciator?)

30. Moving Towards a Plugin Free Web

31. Web Plugin Deprecated in Java 9
The Java Web Plugin will be deprecated in Java 9.
It will still be there but will go away fully in a later version.
Start moving to Java Web Start or javapackager.
The tech press ran with this more than what was actually said.
There was already was a big drop of Java plugin attacks due to extensive work fixing those issues.
FUN FACT: Stuart Marks aka Dr. Depreciator is a member of the JDK team.
The Java 9 web plugin will be deprecated (not removed) in Java 9. Please note, the tech press ran with this way more than what was actually said so read those articles with a bit of caution.
The plugin will be deprecated in 9, which means it will still be there for compatibility but discouraged and scheduled for actual removal some time later on.
Also real stats showed a huge drop in Java plugin attacks before we did this, you know since we fixed a bunch of stuff. (
also offers some guidance on what to do instead (use web start or javapackager).
                There’s a guy on the JDK team who plays a fun role of “Dr. Deprecator” if you want a fun call-out for deprecation.

32. Here's a few for the Java Security Analysis Tool Geeks

33. Make Analyzing Java for Security Great Again
A variety of JEP's In Java 9 will help security tool vendors analyze Java for security in more effective ways.
JEP-236: Parser API for Nashorn (ECMAScript abstract syntax tree)
JEP-190: Pluggable Static Analyzers
JEP-243: Java-Level JVM Compiler Interface
JEP-236 is part of the scripting language stuff from when a JavaScript engine (rhino) made its way into Java 6. This is actually all in the openjdk DaVinci machine of how different languages run in the JVM. These ASTs are for Nashorn (German word for rhino)  One advantage to the Nashorn scripting engine is that is allows for quick prototyping of functionality or basic shell scripts that use Java libraries.
JEP-190 This framework, in conjunction with the type annotations provided by JSR 308 (JEP 104), will allow users to define extensions that can perform arbitrary static analysis at compile time. This is a YUGE enhancement for security tool vendors.
JEP-243 Allows for
accessing VM data structures required by an optimizing bytecode-to-machine-code compiler such as classes, fields, methods, profiling information etc.
Installing compiled code along with all the metadata required by the JVM for managing compiled code such as GC maps and information to support deoptimization.
Plugging into the JVM's compilation system to handle servicing JVM requests to produce machine code for methods.
Until now this was all just not possible in reasonable ways.

34. Java Modularity
JDK 9’s big feature is modularity, named jigsaw. They go a few steps beyond what we did in JDK 8 with compact profiles ( where modularity is actually a security benefit because there’s less. Don’t want CORBA? Get rid of it. Don’t want people using some secret internal crypto API on whatever you’re making? Don’t expose it (I think even to reflection). If you’re an admin whose application really really needs to violate this, ok, you can break modularity but you need to do it yourself on your own system.
JLink (JEP-282) is going to go well beyond the Server JRE.

35. Why Reduce JRE Attack Surface?
Asset: My application / runtime.
Threat: Unknown future risk.
Mitigation: Remove unused pieces.
How: Compact Profiles (JDK 8) and Jigsaw (JDK 9)
Difficulty: Removing things that you really do need will break your program.

36. Server JRE Attack Surface Reduction
Server JRE decreases attack surface by not including applets since 2013!

37. Savings from modularization in Java 8
JDK 8 (embedded):
Regular JRE: About 163MB.
Compact 3: Remove graphics, CORBA, and sound. About 21MB.
Compact 2: No Kerberos and JMX monitoring. About 15MB.
Compact 1: No JDBC and XML. About 11MB.

38. Java 9 Modularity (Jigsaw)
JEP 200
Java 9 Modularity (Jigsaw)
Reliable configuration to replace the classpath mechanism with a means for program components to declare dependences (SPEAKER NOTE: WAIT FOR APPLAUSE)
Strong encapsulation to allow a component to declare which of its public types are accessible to other components
Decreases program size
Reduces the attack surface by removing unused features
describes 72 epic levels of modularity.

39. Annotation Enhancements (Java 8)

40. Annotation Security Enhancements (Java 8)
Java 8 introduced an important changes to Annotations
Type Annotations are designed to help developers produce better code and improve the accuracy of automated code analysis
Checker Framework from University of Washington allows for Type Annotations as early as Java 4.

41. Type Annotations
Java 7 and earlier only allowed annotations on definitions.
Java 8+ allows annotations anywhere that a type is used
More info group/entry/java_8_s_new_type
Automating issue detection
annotation allows the compiler (or a static analysis tool) to immediately determine if a developer wrote the wrong method signature.
Other annotations, can be used by analyzers like the Checker Framework, FindBugs, Eclipse, NetBeans, IntelliJ, or a commercial analyzer.
Those analyzers can then be run at compile time, through IDE background compilation, Ant/Maven, or continuous integration.
Type Annotations tell those analyzers what to look for. Without the Type Annotations in place, these analyzers would still be able to locate null-usage and write-modifications but would not know that they are wrong. The result would then be false negatives (no issue reported) or false positives (incorrect issues reported).
Annotation validation versus Business Validation
Type Annotations are best used with common forms of validation that relate to computer science. There are certain types of business validation that are not applicable.
Well-suited for Type Annotations
Null value checks.
Numeric range checks.
Basic type checks, such as regular expressions.
Assignments and updates (e.g. read-only)
Dataflow validation detection (e.g. have the incoming function arguments gone through the right validation functions)
Likely not well-suited for Type Annotations 
This function cannot be executed outside certain hours or on government holidays.
Access to a feature requires a certain account-type.

42. final String retval = @Tainted request
final String retval
This littl' chunk of code makes it clear that the retval String is modifiable by a user (or attacker).
A tainted, or untrusted, value is one that comes from an arbitrary, possibly malicious source, such as user input or unvalidated data. In certain parts of your application, using a tainted value can compromise the application’s integrity, causing it to crash, corrupt data, leak private data, etc.
If the Tainting Checker issues no warning for a given program, then no tainted value ever flows to a sensitive sink. However, your program is not necessarily free from all trust errors. As a simple example, you might have forgotten to annotate a sensitive sink as requiring an untainted type, or you might have forgotten to annotate untrusted data as having a tainted type.

43. private void runCommand(@Untainted String... commands)
Each command must be untainted. For example, the previously tainted String must be validated before being passed in here.
Prevent SQL injection external been checked for SQL syntax.
Prevent cross-site scripting external been checked for JavaScript syntax.
Prevent information secret be displayed to a user.
Once you determine the boundary, annotating your program is easy: the the validation or sanitization routines that are used at the boundary.

44. It's all about the little things

45. “You need to let the little things that would ordinarily bore you suddenly thrill you.”  ― Andy Warhol

46. The Little Things are Bigger Than They Appear
Much of the real work that has a big impact is seeming boring stuff
Take a look a the work from Joe Darcy
Cleaned up thousands of bad lint warnings in the JDK
Done actually fixing the code
dvice
A little irrational exuberance goes a long way
"When you spend time to remove the things that aren’t worth looking at, it’s easier to see the things that are important." – Erik Costlow
MHO a lot of the actual work that makes a big impact is the boring stuff. You get a splash by introducing some new feature or big change, but the stuff that Joe Darcy did to remove tiny warnings and clean house was huge.
                When you spend time to remove the things that aren’t worth looking at, it’s easier to see the things that are important.
Being involved in fixing several thousand warnings, I'd like to share some tips for developers who want to undertake an analogous task of cleaning up the technical debt of javac lint warnings in their own code base. First, I recommend tackling the warnings in a way that aligns well with the build system of the project, with a consideration of getting some code protected by the compiler from some warning categories as soon as possible. While the build of the JDK has been re-engineered over the course of the warnings cleanup, to a first approximation the build has been organized around Hg repositories. (At present, in JDK 9 the build is actually arranged around modules. A few years ago, the build was organized around Java packages rather than repositories.) A warnings cleanup isn't really done until introducing new instances of the warning cause a build failure; new warnings are too easy to ignore otherwise. Therefore, for JDK 9, the effort was organized around clearing the whole jdk repository of a warning category and then enabling that warning category in the build as opposed to, say, completely clearing a particular package of all warnings and then moving to the next package.

47. Conclusion

48. pau
(pow) (OW as in COW) MEANING: Finished, completed, done. MOST COMMON USE: Finished; all done.

49. Erik Costlow Sean Mullan A BIG DUKE THANK YOU TO...
Product Manager, Java Platform Group
Sean Mullan
Technical lead and architect of Oracle's Java Security Libraries team. 
Lead of OpenJDK Security Group
A little story about these two, two of the gentlemen most responsible for Java Security in the Java Platform Group.
They both needed headshots for their profiles and went out to get it done. They ended up buying quality sunglasses together instead. 

50. What can you do?
Create JEP's for enhancements you would like to see in the JDK.
Support existing JEP's you wish to see pushed live with comments, support and code!
Please play with the JDK 9 early access builds at
Check out the Quality Outreach Campaign which helps open source groups handle feedback
Projects which introduce wanton compatibility or performance problems are a bit of a threat because the project becomes the adversary.

51. A BIG DUKE THANK YOU TO... Output Encoding Library for XSS defense
Hey, if we have a JS AST class since Java 6 why not an encoding library?
er_Project
Content Security Policy library abstractions
The future of web security, perhaps JEE?
Better data-driven access control, like the OACC project
More automatic built-in framework security!
SafeString class to force removal of sensitive data.

52. a hui ho
(ah who-EE ho) MEANING: Until meeting again; til later. MOST COMMON USE: See you later.

53. A hui ho, Java Ohana! jim@manicode.com