paxton
Uploaded by
18 SLIDES
306 VUES
180LIKES

Java 7 Adoption Strategies: Feedback and Testing Results for 2012 Operations

DESCRIPTION

This document outlines the considerations for migrating to Java 7, focusing on feedback from developers, operations, and security teams. It highlights key terminology, the significance of Java 7 over Java 6, and the necessity of 64-bit architecture for larger memory capacities. Testing results show various "fixable" issues, with developers expressing hesitation towards the upgrade. Security implications of using Java 6 are discussed, with a recommendation for a gradual transition to Java 7 by the end of 2012. The document emphasizes the importance of coordinated testing and feedback to ensure a smooth migration.

1 / 18

Télécharger la présentation

Java 7 Adoption Strategies: Feedback and Testing Results for 2012 Operations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Operational Java for 2012 Technical Committee

  2. Outline • Terminology • Spoiler • Original Motivation for Java 7 • Testing Results • Feedback from: • Developers • Operations • Security • Industry • Summary

  3. Terminology • JVM vs JDK • Java Virtual Machine is the runtime executor of Java software • Java Development Kit includes the compiler and other development artifacts • Possible to run Java classes compiled for Java 6 with Java 7 (no recompilation needed) • 32-bit vs64-bit • Explained by Alastair on previous presentation • Ability to use files or memory > 4GB

  4. Spoiler Java 6 (x64) for 2012 NotJava 7

  5. Original Motivation for Java 7 • Why Java 7? • EOL Java 6 July 2012 • Java 7 released July 2011 • Sufficient time to test for 2012 run • Requested features • NIO2: file WatchService API, non-blocking IO • Limit technical debt • Why 64-bit? • Upgrade by IN to 64-bit platform • Several projects already have 64-bit hosts/JVMs • Access large memory sizes > 4GB

  6. Testing Results • “Fixable” issues • Collections throw new Exceptions • GUI annoyances: • JTextPane cant get focus to type • Compilation issues • E.g. API changes in DataSource, AWT • “Blocking” issues • AspectJfails: affects LSA, InCA, Sequencer, ... • Requires Spring 3+ • java.security.SignatureException: RBAC

  7. Developer Feedback • Short shutdown and plenty to do already • New Java 7 features are nice but not essential • Happy with Java 6 for 2012 • Improvements: • Easier switch between Java 6 and 7 • More coordinated Dev&Test environment • Including full Java 7 support in Eclipse • Earlier availability of testing platform

  8. Operations Feedback • Introducing Java 7 + SLC6 + 64bit together: • Higher probability of failure • Addeddifficulty investigating failure • Increased combinations and candidates • Is it Java 7, SLC6, something else? • Reduce impact: • Introduce fewer changes at any one time

  9. Security team feedback • Requested position on using “unmaintained” Java 6 • Response: • OK to run 2012 with Java 6 • Java 6 very mature implieslow security risk • Must move to Java 7 at end 2012 • Option B: Buy “Oracle Premier Support” • Note on Oracle new release strategy: • Evolutive major updates • Less features but more regular releases • Expect Java 8 release in summer 2013

  10. Industry Adoption? • Industry adoption is low • Spooked by well-publicized “loop optimization” bug • Other “serious” defects unresolved • E.g. FTP protocol failure on Windows • New NIO2 features have complex APIs • Consequences: • Lower level of industry-wide testing • 3rd party products remaining with JDK1.6

  11. Summary for Java 7 • Failure to provide new features is not a problem • Testing shows Java 7 adoption needs additional time • Developers overall prefer Java 6 for 2012 • Operations can focus on SLC6 64-bit adoption • Security team will allow Java 6 use for 2012 • Industry adoption is currently low • Conclusion: remain with Java 6 / JDK 1.6

  12. Summary for 64-bit • Clarification: No need to re-compile any Java code • Java compiled with 32-bit JDK runs “transparently” on 64-bit JVMs • But watch out for native libraries! E.g. DIP • 32-bit Java interoperates with 64-bit by design • JMS servers run as 64-bit since start 2011 • 32-bit JVMs can run on 64-bit Oses but... • 64-bit consoles to have 64-bit JVM only installed • Conclusion: Low risk, adopt.

  13. Summary • Java 6 for accelerator run 2012 • With 64-bit JVM for consoles • Java 7 (+ Spring 3): goal for end 2012 • Thank you to everyone who found time to test! • Effort not wasted, needed for November 2012 • And those who contributed advice, concerns, etc.

  14. Java 7(& 64-bit / SLC6) Why  Plan Action -End Of Life JDK6 July 2012 • arrived in time for next run • 64-bit larger memory heap - JDK7 (64-bit) on SLC6 - in CCC/CCR for run 2012 - TC end October for a decision • PLEASE TEST YOUR PROJECTS! • Feedback / Testing info see wiki  Spoiler http://wikis/display/CMMNBUILD/Moving+to+Java+7

  15. Timeline • Alastairs timeline graph • Point of slide to show running gap of unaminted • Oracle’s future schedule of J8, 9 / EOLs etc

  16. Points to make • Testing feedback, show some real errors • Developer attitudes – no real desire to move • Risk analysis • Tsting feedback • Positives (recap of new features) • Desired features (NIO, file WatchService API) • Push by Oracle EOL July 2012 • 3rd Party libs • Technical showstoppers, aspectj/Spring • Other considerations: • Environment change to SLC 64 bit • Operator / developer confusion of bug either SLC6 or JDK7

  17. More points • ? To be completely sure, would need to re-compile, test, release all software.

More Related