Wednesday Apr 27, 2016

JavaOne 2016 Call for Proposals

JavaOne 2016 has opened its Call for Proposals to speak at the conference. This year, security topics take place in the Core Java Platform track.

Speaker Proposals must be submitted by May 9th. The conference itself takes place from September 18-22 in San Francisco. Accepted speakers will receive a gratis pass to attend.

Before each JavaOne conference, we receive a number of great submissions from Java community members around the globe, about different security topics. Our review committee also tries to call attention to help solicit interesting proposals and guide speakers. If you are familiar with running or coding Java and want to speak at JavaOne, consider applying your expertise to the following areas:

  • Architecture & Analysis – how should security architects and developers build/integrate applications to evaluate and verify security?
    • How does this change for green-field versus inherited applications?
    • How should you build and maintain a threat model of an application and its environment? (bonus for breaking a threat model down into JDK 9 jigsaw modules)
    • What is the importance of library code, and how/when/why should it be updated? What are strategies to test compatibility?
    • When micro-services are connected, how does that impact trust boundaries?
  • Development – how can developers evaluate and test their own applications?
    • Code analysis (both for what you write and use)
    • Penetration testing or scanning of Java applications
    • There are many different secure development standards frameworks. What are they and how can they be used to test applications?
  • Operations – when running Java, what are the proper strategies for configuring, managing, and upgrading JVMs?
    • What are strategies between minor versions (e.g. 8uA to 8uB) and major versions (e.g. from JDK 8 to JDK 9)? How is the compatibility guide used?
    • What are monitoring strategies to analyze JVM security events? What are connections between current logging frameworks and/or the planned Unified Logging API for JDK 9?
    • How should a JVM or Java web server be tuned to achieve an A+ rating on SSL Labs? What about TLS for non-HTTPS uses, such as JDBC?
      For helpful tools, see Diagnosing TLS, SSL, and HTTPS as well as Deep Violet.
  • Other ideas – there are many great ideas in the Java ecosystem, so please submit yours!

Thursday Mar 24, 2016

G1: from garbage collector to waste management consultant

Java’s garbage collection capabilities make it easier for developers to write software and focus on the task at hand, without focusing on freeing up unused memory. In JDK 9, the G1 garbage collector will likely become the default collector and can do more than simply freeing memory. Instead of a simple garbage collector to free up memory, G1 takes the role of a waste management consultant: freeing unused memory and identifying ways to reduce the overall amount of garbage.

String Deduplication may decrease heap usage by about 10%

String objects are among the most commonly used object by almost all applications. Applications often store the same String multiple times for a variety of reasons, either within one class or across many classes. By analyzing these Strings, the JDK can decrease the overall memory needed to store them.String Deduplication may decrease heap usage by about 10%

String deduplication was first introduced in JDK 8 update 20 and operates as a background task. As the G1 garbage collector walks through memory references to clean up, it analyzes Strings to find duplicates and create memory-saving links between them. Similar to other garbage collection tasks, developers do not need to modify any code in order for it to work. An analysis by Fabian Lange from Codecentric found that String deduplication “adds no runtime overhead as it is performed asynchronously and concurrent during garbage collection.”

The following flags are needed to enable String Deduplication on JDK 8:

-XX:+UseG1GC Enables the G1 garbage collector.
-XX:+UseStringDeduplication Enables the String Deduplication feature within G1.
-XX:+PrintStringDeduplicationStatistics Optional flag to analyze what is happening through the command-line.
-XX:StringDeduplicationAgeThreshold=3 Optional flag to change when Strings become eligible for deduplication.

Example: Decreasing memory used by the Eclipse IDE

Eclipse is a popular Integrated Development Environment, helping developers read, write, and construct source code. The G1 garbage collector will typically perform better for long-running applications focused on throughput (e.g. servlet containers), but it can also function well for client applications.

The following example was run on JDK 8u72 with Eclipse Mars. I am also turning on a Java Flight Recording to see the impact on garbage collection, object allocation, and overall memory consumption. I ran the same operations twice: once without –XX:+UseStringDeduplication and the filename of before.jfr, so that I could do somewhat of a comparison.

The following lines can go inside your eclipse.ini at the end:The following lines can go inside your eclipse.ini at the end:

#The lines below are not necessary for G1, I am including them to benchmark the difference
-XX:StartFlightRecording=filename=after.jfr,dumponexit=true,maxage=5m,settings=c:/Users/ecostlow /desktop/Everything-Costlow.jfc

As a background task, String deduplication was taking about 0.0000908 seconds during my brief usage. It probably took longer to print statistics. Although my laptop is not a controlled environment and I manually did the same actions, the overall heap usage went down about 9% from 233MB to 213MB during my five minutes of usage.

JFR of G1 String Deduplication: before and after

Here are the details from the final output of the String Deduplication Statistics (using -XX:+PrintStringDeduplicationStatistics) with some cumulative numbers:

[GC concurrent-string-deduplication, 14.5K->6120.0B(8744.0B), avg 38.6%, 0.0000908 secs]
   [Last Exec: 0.0000908 secs, Idle: 0.8590383 secs, Blocked: 0/0.0000000 secs]
      [Inspected:             142]
         [Skipped:              0(  0.0%)]
         [Hashed:              89( 62.7%)]
         [Known:               21( 14.8%)]
         [New:                121( 85.2%)     14.5K]
      [Deduplicated:           96( 79.3%)   8744.0B( 58.8%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:                 96(100.0%)   8744.0B(100.0%)]
   [Total Exec: 52/0.1772395 secs, Idle: 52/103.0713572 secs, Blocked: 2/0.1476086 secs]
      [Inspected:          322160]
         [Skipped:              0(  0.0%)]
         [Hashed:          164740( 51.1%)]
         [Known:            61960( 19.2%)]
         [New:             260200( 80.8%)     20.3M]
      [Deduplicated:       144975( 55.7%)   8037.4K( 38.6%)]
         [Young:                2(  0.0%)     72.0B(  0.0%)]
         [Old:             144973(100.0%)   8037.3K(100.0%)]
      [Memory Usage: 4213.1K]
      [Size: 131072, Min: 1024, Max: 16777216]
      [Entries: 132446, Load: 101.0%, Cached: 3622, Added: 170306, Removed: 37860]
      [Resize Count: 7, Shrink Threshold: 87381(66.7%), Grow Threshold: 262144(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
      [Dropped: 0]

Wednesday Jan 27, 2016

Java Advanced Management Console 2.2

Today, the Java Platform team is pleased to release Java Advanced Management Console version 2.2.  Available for production use with appropriately licensed Java SE Advanced products, the Advanced Management Console helps system administrators track and manage Java across their organization. Its usage tracking capabilities help system administrators create a Java application inventory to know which Java versions are used for which applications, and by whom. Administrators can then manage exposure of the browser plugin: allowing known-safe applications to run against older Java versions based on compatibility, and potentially blocking unknown applications altogether. 

This newest version of Advanced Management Console makes a number of improvements designed to streamline Java usage across client endpoints across a large organization:

  • This version supports zero-configuration endpoints to better handle cases of multi-user systems and walk-up terminals. In previous versions, each agent installation needed a post-install configuration to identify the user. In AMC 2.2, this step is optional and the system offers more visibility on the hostname.
  • Another streamlining capability helps simplify the certificates used by endpoints to verify the Deployment Rule Set. When installed, the DeploymentRuleSet.jar file must be signed by a trusted certificate. A number of organizations use self-signed certificates or act as their own internal certificate authority. As clients download updated Deployment Rule Set files from a trusted Advanced Management Console server, clients will apply transitive trust and import the Deployment Rule Set’s certificate. As a result of this change, systems will see fewer cases of "DeploymentRuleSet.jar is not valid."

If your organization is looking to manage the security and compatibility of many different Java versions, please download an evaluation copy of the Advanced Management Console.

Moving to a Plugin-Free Web

By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Flash, Silverlight, Java and other plugin based technologies.

With modern browser vendors working to restrict and reduce plugin support in their products, developers of applications that rely on the Java browser plugin need to consider alternative options such as migrating from Java Applets (which rely on a browser plugin) to the plugin-free Java Web Start technology.

Oracle plans to deprecate the Java browser plugin in JDK 9. This technology will be removed from the Oracle JDK and JRE in a future Java SE release.

Early Access releases of JDK 9 are available for download and testing at More background and information about different migration options can be found in this short whitepaper from Oracle.

Update:  Technical information about the planned deprecation step in JDK 9 can be found in JEP 289 .

Tuesday Jan 19, 2016

Now Available: Migration Guide from Oracle JRockit JVM to HotSpot JVM

During the 2010 JavaOne conference Oracle announced that it would merge the Oracle JRockit JVM and HotSpot JVM by incorporating the features that were only available in JRockit into HotSpot.

With JDK 7 Oracle started delivering on that vision. It completed the work with JDK 8. Customers using the Oracle JRockit JVM, in the meantime, have been receiving periodic security updates and bug fixes. CPU releases and bug fixes for Java SE 6 JRockit (R28 only) will continue to be provided until the end of JRockit for Java SE 6's extended support phase, currently scheduled for December 2018.

Migration Guide for customers moving from the Oracle JRockit JVM to the HotSpot JVM has been published. It provides information on many common tools and options available for JRockit and their HotSpot counterparts.

Sunday Dec 06, 2015

A New JDK 9 Version String Scheme

One of the smaller, but rather important planned changes for JDK 9 is an updated JDK version string scheme. It is described in detail in JEP 223.

The new version string scheme makes it easier to distinguish major, minor and critical patch update (CPU) releases, by encoding each property into a separate numerical component as part of a JDK version string. Following the new MAJOR.MINOR.SECURITY convention, JDK 9 version strings would start with ‘9’ for the MAJOR release component.

For example, if the JDK 9 GA release (with the version string: ‘9’) were to be followed by a CPU, then that CPU would carry the version string ‘9.0.1’. If that CPU were to be followed by a minor release with additional changes on top of those already found in the ‘9.0.1’ release, than the new release would carry the version string ‘9.1.1’. If in turn, that minor release were to be followed by another CPU, the new CPU would be designated as ‘9.1.2’, leading to the following hypothetical sequence of release versions:

 9  GA
 9.0.1  CPU: 9 + critical changes
 9.1.1  Minor release: 9.0.1 + other changes
 9.1.2  CPU: 9.1.1 + critical changes
 9.2.2  Minor release: 9.1.2 + other changes
 9.2.3  CPU: 9.2.2 + critical changes
 9.2.4  CPU: 9.2.3 + critical changes
 9.3.4  Minor release: 9.2.4 + other changes


The individual components of the version string would start at 0 and then increase based on the type of a release, making it easy to check whether a local installation meets a given security baseline by looking at the third, i.e. SECURITY, component of the JDK 9 version string.

Due to the changes in the version string scheme, code that parses JDK version strings could need to be adjusted - for example if it assumes that the first element of a JDK version string always has the value of ‘1’ (as in ‘1.9.0_ea-b19’), and therefore always skips to the second element when comparing releases. Details on the adjustments can be found in the JEP text.

In addition, the JEP text describes other types of information that can be encoded in a JDK 9 version string, like build numbers, as in ‘9.0.1+63’.

Developers, who would like to test the planned changes, can do so by downloading a JDK 9 Early Access Build at Feedback on the planned version string scheme changes should be directed to the verona-dev mailing list.

Monday Nov 16, 2015

Strengthening Signatures part 2

The scheduled Critical Patch Update of Oracle Java SE on January 19 2016 is planned to disable X.509 certificates signed with MD5. Plans are also being developed to disable X.509 certificates signed with SHA-1 and further details will be announced in a future post.

Specifically, this change will treat certificate chains containing a certificate with an MD5-based signature to be invalid and blocked by default. This affects Java clients and servers using TLS (via the JSSE API), signed applets and Web Start applications, and any application using the PKIX implementation of the CertPath API to validate certificate chains.

This was previously covered in a post, Strengthening Signatures, and is similar to announcements from other platform providers like Microsoft, which deprecated MD5 in June 2014 and is focusing on SHA-1 efforts for 2016.

System Administrators wanting to test their systems can update their JAVA_HOME/lib/security/ file and add MD5 into jdk.certpath.disabledAlgorithms.

Change "jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024" to "jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024"

After this change, the MD5 algorithm will still be available for other non-certificate uses. For example applications that use MessageDigest.getInstance("MD5") for alternate reasons will continue to function.

For System Administrators that must re-enable the weaker MD5 algorithm

In cases where a system authenticates itself through MD5 signatures, system administrators are encouraged to generate newer certificates that use SHA-256 or higher.

Users are encouraged to accept the default security settings and not re-enable MD5 in X.509 certificates. However, if necessary, MD5 can be re-enabled in either of the following ways:

 Option A (preferred if weak MD5 is needed), by using a startup flag that will only impact specific applications.
  1. Create a file that copies the jdk.certpath.disabledAlgorithms line from JAVA_HOME/lib/security/
  2. Remove MD5 from that line
  3. In your startup command, add
  4. Plan your migration away from weak algorithms and undoing this change.
 Option B, editing a configuration file that will affect all applications used by a JRE:
  1. Open JAVA_HOME/lib/security/
  2. Remove MD5 from the line jdk.certpath.disabledAlgorithms
  3. Plan your migration away from weak algorithms and undoing this change.

SHA-1 plans

We are also working with industry groups on a plan to migrate away from certificates signed with SHA-1. The Certificate Authority Browser Forum previously set guidance to avoid issuing new SHA-1 certificates after January 2016. This guidance assists in our planning, as well as that of peer programs such as Microsoft, Mozilla, and Google


Thursday Nov 12, 2015

When is the next Java update?

"Java update available -- a new version of Java is ready to be installed..."

This occurs four times a year: January, April, July, and October.

Oracle Java SE is updated on the Oracle Critical Patch Update schedule. The date for these updates is published a year in advance. This schedule helps system administrators manage software across a fleet of systems. Combined with another feature, the security baseline, client systems can detect newer security updates and adjust their behavior by offering an update and decreasing the client’s attack surface.

System Administrators can use Deployment Rule Sets to control compatibility if they need a version below the security baseline.

The Security Baseline

The security baseline received new behavior in Java 7 update 10 (December 2012), combining it with the JRE expiration date. Prior to this, it has identified which Java versions contain the latest security patches since JDK 1.4. There is a different baseline version for each major Java version: Java 6, Java 7, and Java 8. The JRE will identify that it should be updated in two main ways:

  • The JRE will periodically check the security baseline to see if a new version is available. If it detects that it is below the security baseline, it will consider itself to require an update to a version that meets the security baseline requirement.
    The schedule for this periodic check can be controlled by system administrators.
  • If clients cannot obtain the security baseline for any reason, they will eventually reach their built-in expiration date. This expiration date is published in every release note, but it is typically a month after the next scheduled critical patch update.
    This expiration date is built in and cannot be controlled.

In addition to Critical Patch Updates, there is another release type called a Patch Set Update(PSU), which contains additional non-critical changes. Although a PSU version is numerically “above” the security baseline, the PSU contains the exact same critical patches as the corresponding CPU at the security baseline. Example: At time of writing, the security baseline is 1.8.0_65. A different patch set update, 1.8.0_66, is available with additional changes. Users that only want critical patches do not have to deal with these changes yet, and can test them separately. In the next scheduled Critical Patch Update, we will include those changes from 1.8.0_66.

What happens when the security baseline changes or the expiration date passes

When clients detect that it is below the current security baseline, they will typically do two things: prompt end-users to install the newer update, and decrease the potential attack surface of the installed JRE.

These changes are described in the Rich Internet Application Deployment Process under the question, “Is the JRE expired or below the security baseline.” Desktop administrators that need to control prompts and/or use Java versions below the security baseline may do so through Deployment Rule Sets, under the question, “Does a rule exist for this RIA.”

The attack surface reduction applies to Rich Internet Applications (through browsers).

Planning for updates

With the dates of Critical Patch Updates published a year in advance, system administrators should plan ahead to roll out Java updates onto client systems. Deployment Rule Sets should be used with applications that cannot use the latest Java Runtime Environment for one reason or another, to whitelist which known-safe application can use specific older JREs. Critical Patch Updates are available to Java 6 and Java 7 through the commercial Java SE Advanced, along with other management tools.

Administrators needing to deploy Java across thousands of managed systems every quarter may consider the commercial Java SE Advanced, which offers tools to better manage Java at scale. Examples of these commercial features include:

Additional Resources

Thursday Oct 08, 2015

NPAPI Plugin Perspectives and the Oracle JRE

Java’s rapid rise to fame 20 years ago began with a tumbling duke applet running in the HotJava browser. Applets allowed richer development functionality at a time when browser capabilities were very limited, and provided centralized distribution of applications without requiring users to install or update applications locally.

HotJava’s support for applets was picked up by Netscape. In 1995 Netscape Navigator 2.0 and plugins became more popular to expand the kind of content that could be displayed. Navigator’s plugin interface (NPAPI) was adopted by other browsers and supported since 2004. Support for Java applets across several different browsers was implemented relying on the common NPAPI plugin interface to provide cross-browser compatibility of Java applications running on the web.

As Java evolved to become one of the leading mainstream development platforms, so did the applet’s hosts – the web browsers.  The rise of web usage on mobile device browsers, typically without support for plugins, increasingly led browser makers to want to restrict and remove plugin support from their products, as they tried to unify the set of features available across desktop and mobile versions. Coincidental with the rise of mobile was the emergence of the “app store” model rather than “plugin based” models for application delivery. The “app store” model grew for reasons related to simplicity, security, and centralized availability. Given these evolutions in mobile, delivery, and capabilities, the set of browsers that continue to support standards based plugins has shrunk over time.

The announcement from Mozilla provides a timeline for developers and users who rely on Mozilla Firefox for applets to evaluate and migrate to alternatives. You should consider using plugin-free technologies, like Java Web Start, or move to other supported browsers, before NPAPI functionality is removed from Firefox in their regular and/or Firefox Extended Support Releases.

As with other browsers, the Oracle JRE can only support applets on Firefox for as long as Mozilla provides the requisite NPAPI support. Having been in regular contact with the Mozilla engineering team over the past years, we have worked together to ensure that our common users benefit from improvements made in Firefox and the Oracle JRE.  We'll continue to collaborate on enabling a smooth transition to plugin-free technologies like Java Web Start.

Meanwhile, we don’t plan to provide additional browser-specific plugins, as such plugins would require application developers to write browser-specific applets for each browser they wish to support. Moreover, we would only be able to offer a subset of the required functionality, different from one browser to the next, impacting both application developers and users.

As with previous transitions, any additional information specific to Oracle products will be provided by the corresponding product teams. Internet Explorer and Safari browsers are not impacted by this change.

System administrators who want to prepare for the transition and learn more about applets (and other kinds of Java applications) running inside their organization should evaluate the Java Advanced Management Console

Monday Aug 31, 2015

Launching Web Start applications

Java applications can be distributed to clients through download capabilities like Applet and Web Start. These applications are delivered to users through web browsers, allowing for convenient access on client systems.

Web Start applications can be launched from any web browser by opening the application’s JNLP file. Once opened, these applications no longer rely on browser plugins or integrations. Instructions for launching JNLP files can be located in "What is Java Web Start and how is it launched" on In short, this involves associating the .jnlp file association with Java’s javaws command.

Desktop Administrators can control Web Start dialogs/prompts by using Deployment Rule Sets (DRS). This DRS feature enabled administrators to create an application whitelist that can control execution of known-safe applications as well as manage compatibility between different versions of Java on the same system.

System Administrators can use the Java Advanced Management Console to track Java usage within their organization, identifying Applet, Web Start, and other Java application types. This usage tracking enables them to identify which versions of Java are used by which applications, and create Deployment Rule Sets to manage compatibility between versions.

Wednesday Aug 05, 2015

Strengthening Signatures

Later this year, the Oracle JDK team plans to restricting the use of MD5 signatures within X.509 certificates used by SSL/TLS and code-signing. This will take place in the public versions of JDK 9 (early access) and JDK 8, as well as the commercially supported JDK 7.

The IETF has recommended a move away from MD5 since 2011.

Most Certificate Authorities followed this guidance by requiring stronger signatures (typically in the SHA family). Although the default JDK options switched away from MD5 in the past, additional time was necessary for organizations to phase out their use of MD5 and reissue certificates with stronger hash algorithms.

System Administrators that still actively use certificates with MD5 hashes should consider revoking and/or re-issuing those certificates with stronger signatures. Developers that have previously signed artifacts with MD5 signatures should consider re-signing and timestamping these artifacts.

This change will only affect MD5 usage in regards to certificates. This will not affect other uses, such as MD5 hashing of files to generate checksums or perform simple checks.

System Administrators can control algorithm availability by adjusting their JRE configuration. For example, some organizations may still rely on internal systems that require MD5. Users of these systems will likely see a message "constraints check failed: MD5withRSA" in their application logs.

This configuration change takes place within the jre/lib/security/ file. The specific property is jdk.certpath.disabledAlgorithms.

Wednesday Jun 24, 2015

The 2015 Leap Second’s impact on the Oracle JDK

On June 30, the official Universal Coordinated Time will experience a leap second. Many technical news sites have written about this upcoming leap second’s impact on various technical systems.

System Administrators concerned about leap seconds should focus on it as a standard maintenance problem of updating Java’s time zone information and using operating system time tools like NTP.

Update Time Zone Information

Time Zone updates were covered in a previous post, Understanding Time Zone Updater 2.0. System Administrators looking to update their systems can simply use the tzupdater tool to update JDK installations. Alternately, each JDK release always contains the latest time zone information for users that upgrade.

Check the Operating System

Java relies on the operating system clock for time. Each operating system has its own method of handling date changes such as leap seconds. Consult your operating system information for details on handling the leap second. Linux users may consult the Wired interview with Linus Torvalds, "Linux’s creator wants us all to chill out about the leap second."

Details for Windows can be found in KB-909614 How the Windows Time service treats a leap second. Hosting providers like Amazon and Google will be doing a time skew over the course of a day.

Some applications may still require restarts

Although the Java API defines a second as a number between 0 and 61 to accommodate leap seconds, some applications may have taken short-cuts to assume that there are 60 seconds in a minute or 86400 seconds in a day. Systems that perform synchronized time-based transactions with other systems may run into issues if one system updates and another does not.

The 2015 leap second takes place at exactly 23:59:60 UTC on June 30, 2015. I advise system administrators to monitor processes during this time and pay extra attention to systems for a short while.

Monday Jun 15, 2015

Deferring to Derby in JDK 9

Java DB is simply a re-branded distribution of the Apache Derby open source database. It contains the same binaries as Apache Derby.

As of JDK 9, it is no longer being planned to include it in the 'db' directory of Oracle JDK downloads.

Developers looking ahead to JDK 9 should plan to get and bundle Apache Derby independently for the same purpose.

 - Don 

Tuesday Apr 21, 2015

Understanding Time Zone Updater 2.0

The JRE uses the IANA Time Zone Database for its time zone calculations. To keep this information up to date users must keep their JRE versions up to date or use a utility called TZUpdater available from Oracle. Until recently a new version of TZUpdater was needed for each Time Zone Database update. An enhancement to the tool lets users get the latest information directly from IANA allowing users to rely on the same tool for all future update. [Read More]

Tuesday Mar 31, 2015

JavaOne 2015 Call For Proposals Is Open

The call for proposals is now open for JavaOne 2015. If you are interested in speaking, please submit your abstract to the site.

Key Information

  • JavaOne 2015 will run from October 25th to the 29th in San Francisco.
  • The call for proposals ends on April 29 at midnight PDT. Submit your talk by then.
  • Accepted speakers receive complimentary passes to attend the conference.

Choose the best track for your topic

JavaOne features several different tracks based on different roles and interest. These tracks include core platform, security, JVM languages, DevOps/Cloud, Internet of Things (embedded), Server-Side development, Clients, and Tools & Agile methodologies. The 2015 tracks page provides a complete listing and description of each track.

Videos and materials from the 2014 conference are available for on-demand replay and access through both ActiveEvents and Parleys.

Security Track

This is the third year for a dedicated Security track at JavaOne, and I am honored to be on the review committee. Last year’s security track featured many great presentations. Among them, Frank Kim was recognized as a JavaOne Rock Star presentation for his talk on "Five Keys for Securing Java Web Apps." Typical talks on this track were about methodologies, analysis techniques to find threats/vulnerabilities, and advanced tool usage.

For those submitting talks, a few good topics would be:

  • Explain the relation between new Java 8 features and security. For example Java 8 introduced type annotations and their ability to annotate data such as local variables. By storing this information in bytecode, how can tool authors and library writers support each-other to make it easier to write secure code? What opportunities are present for things like the checker-framework’s tainting checker?
  • Designing code for security analysis, or designing security analyzers. As developers write code and as users run applications, how can we detect or prevent security issues before code gets released? How does the Java platform facilitate this detection both for Java as well as other languages featured on the JVM Language track?
  • Tools, libraries, and techniques. How does your team or organization make security decisions? If you have mastered usage of certain techniques or tools, share guidance and experience with your peers.

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.


  • Oracle
« July 2016