Oracle has directed the Java 8 release towards some much-needed security strengthening engineering work. This development will likely delay the anticipated September release of what is currently labelled "Project Lambda".
- Approaches to DDoS Protection: An Overview on Keeping Your Networks Protected
- Supply Chain Visibility in Business Networks
- Research: Federal Government Cloud Computing Survey
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
- Thwart off Application-Based Security Exploits: Protect Against Zero-Day Attacks, Malware, Advanced Persistent Threats
- Big Data Analytics: Are You Ready?
NOTE: Java 8 is now expected in the first quarter of 2014.
Java's place in the global technology framework has been under close examination in the last year with Apple removing the Java plugin from its Safari browser and all Mac-compatible browsers back in October of 2012.
Chief architect of the Java Platform Group at Oracle Mark Reinhold blogs as follows: "We have upgraded our development processes to increase the level of scrutiny applied to new code, so that new code doesn't introduce new vulnerabilities. Maintaining the security of the Java Platform always takes priority over developing new features, and so these efforts have inevitably taken engineers away from working on Java 8."
NOTE: JSR 335 (Lambda Expressions for the Java Programming Language) supports programming in a multicore environment by adding closures and related features to the Java language.
Industry commentary suggests that Oracle's moves with Java are somewhat reminiscent of Microsoft's efforts to ramp up security in the early 2000s at the time when the firm had been castigated for allowing multiple security flaws to develop.
At that time, Microsoft did indeed make security a top priority and backed up its intentions with a set of new processes and work practice procedures to see that security was (as Microsoft was fond of saying) "baked in" from the start.
Reinhold follows up: "If we sacrifice quality in order to maintain the schedule, then we'll almost certainly repeat the well-worn mistakes of the past, carving incomplete language changes and API designs into virtual stone where millions of developers will have to work around their flaws for years to come until those features — or the entire platform — are replaced by something new."