现在可以在接口中定义静态方法了。例如，java.util.Comparator接口中现在拥有一个静态的naturalOrder方法。还能够在接口中提供默认方法。通过该功能，程序员能够在不破坏已有的接口实现代码的前提下添加新方法。例如，java.lang.Iterable接口现在拥有一个默认的forEach方法。函数式接口是只定义了一个抽象方法的接口。Java 8引入了FunctionalInterface注解来表明一个接口打算成为一个函数式接口。例如，java.lang.Runnable就是一个函数式接口。更多相关介绍我们将在本次专辑中为大家带来……
甲骨文最近还为Java添加一个让大家久等的功能“Deployment Rule Set”（部署规则集），即支持白名单。Java 7 Update 40允许系统管理员定义哪些Java程序是值得信任的，更便于管理Java安全。很多个人用户为了防止受到针对Java攻击的影响，而选择在浏览器中禁用Java插件，甚至是卸载Java。但是，这对于大多数企业用户来说是不可行的。 新增的“Deployment Rule Set”可以让系统管理员创建一个XML文件，添加信任的Java RIAs（富互联网应用）。 虽然Java是目前相当重要的一个开发平台，但竞争者总是无处不在的。就在几周之前，我详细介绍了Java 8中值得期待的几大主要功能。不过当时我并没有提到.Net的新变化，事实上Java 8中的大部分（甚至全部）功能都能在.Net中找到。更夸张的是，不少将被推迟到Java 9中实现的功能也将在.Net中出现。我并不赞成将一切功能盲目塞进Java语言的激进行为，不过我认为Java平台（相对于语言本身）确实应该在功能多 样性方面下点功夫。在我看来，.Net技术堪称杰出，C#与.Net平台自Java 3时代就开始在各个方面迎头赶上。就个人而言，我对微软的操作系统非常抵触，而且很担心无法修复讨厌的bug（至少在理论上不行）。 然而Java为什么会落后如此之多？在Java出现的早期，其发展速度同样令人赞叹。从Java 1.0.2到Java 1.1，我们仅在一年之间就迎来了众多根本性（通常也意味着存在兼容性问题）改变。其后，从1.1版本到1.2版本用了一年半时间，之后的1.22——一 个看似小更新、实为大升级的版本——仅在七个月后就火热出炉。短短十个月后，里程碑式的Java 1.3版本整装待发，这也是第一个考虑在服务器端加入垃圾收集功能的版本。 我们可以这样来简单解释Java的逐渐落后：Sun本来就不是一家运转状况良好的企业。Java诞生之初互联网正迅速兴起，Sun公司也将运营重点 放在了销售Sparc及相关产品方面。与此同时，英特尔与AMD产品的价格逐步下降，Sparc的价格却未作调整。尽管T1000及之后平台的陆续出现令 人兴奋不已，但却始终未能形成规模经济、从而将成本缩减到理想范围（没错，最后一款Sparc执行效率更高，但价格却贵得离谱；尽管政府当局要求能耗过高 的用户为碳排放过量状况付费，但即便如此最终的总体成本也远低于Sparc给数据中心带来的硬件支出）。 在归属甲骨文后，甲骨文在一份典型的简要公开声明中，承认某些业务及政治问题拖延了Java 7的发布进度。“众所周知，由于各种业务及政治问题的影响，最新版本的推出被迫延期。” Java社区进程的发展为何受阻？问题不在于开放性，而在于利益争夺。尽管当时我是以旁观者的身份看热闹，但仍然清楚记得Sun在参与EJB3项目 时遭遇的窘境。为什么Java发展进度会一落千丈？这是由于Sun与甲骨文双方需要将购买或者开发出的产品整合到应用程序服务器当中。一旦新的 JavaEE规范出台，他们也必须保证自己能在市场上率先做出反应。 对于甲骨文在Java领域的领导权来说，这是充满挑战的一年。Sun当初做出的许多决定开始回过头给使用者带来困扰。我给出的答案是放弃Java客户端、将JVM与语言的发布周期分离开来，同时专注于将Java打造为一个平台而非万能性解决方案。 在关注过Java之后，我们来看一下MySQL的最新进展。不断扩展的数据规模以及网络、云和移动计算的迅速增长，为数据库管理者带来了越来越严峻的管理挑战。为帮助开发人员和管理者更好地管理这些动态数据环境， 甲骨文发布了MySQL Workbench 6.0，该版本的用户界面得到了重新设计并拥有新功能，从而简化MySQL数据库的开发、设计和管理。
|
