Question

Java(TM) 6 Update 7是用来干什么的啊？可以删除吗？

装了Java(TM) 6 Update 7可以删除Java(TM) 6 Update 5吗？不知道为什么我的机里面两个程序都有，能删一个吗 。
还有是用来干什么的？？？？删除对系统有影响吗？
晕不好意思。我搞错了。我电脑里有jre1.6.0_07和jre1.5.0_09，这两个可不可以删了或者删一个？？？

Answer 1

完全可以删了。

听你这样一说·
看来你不是搞java的

装jdk1.6的时候。自动就装了Java(TM) 6 Update 7 这个东西(这是自动更新jdk版本的)
从上面可以判断你装的是jdk1.6。是最新版本了。我估计。3年内。jdk1.6还将是主流.所以根本用不着更新
完全可以删了.....

Answer 2

可以删除的.
这个不是什么java平台,所谓的java平台其实是jre,就是让你能运行java程序.
这里的Update是更新用的,像我们做java开发都直接把这些删除,随机启动烦人
所以是可以删除的,不用担心

Answer 3

最好别删，又不占什么空间
这个是个java平台，
如果不是你自己装的，就是装别的软件的时候，装上的
因为有的软件需要这个平台才能使用，对软件有影响，对系统应该没影响。

Answer 4

Devoxx大会上，Java SE首席工程师Mark Reinhol，做了一个关于Java 7（2010年初发布）最新发展方向的演讲。虽然，Mark称这次演讲的内容只是暂时的计划、不具约束力，但是仍然在社区中引起了很多反响，特别是针对闭 包特性（Closures）的遗漏。
出席会议的Hamlet D'Arcy提供了一个Mark演讲中有关Java 7特性的总结。其中一些比较重要的变化包括：
模块化——294和Jigsaw项目
292——JVM对动态语言的支持
JSR 203——更多新的I/O API已基本完成，包括真正异步的I/O（不仅仅是非阻塞I/O）和一个真正的文件系统API。
JSR TBD：小的语言变化（见下）
安全重抛出——允许一个广泛的catch语句，编译器可以更加智能的基于try语句块中抛出的异常管理重新抛出。（我以前没有见过，不过看起来不错）
Nulll解引用（dereference）表达式——Null通过'?'语法检查，类似于Groovy...使开发人员避免一连串null检查。
更好的类型推断（type inference）——与泛型实例化有关，但目前还不清楚这种推断会达到什么程度（我觉得越多越好）。
多捕捉（Multi-catch）——（是的！）允许在catch语句中用逗号分割一系列异常类型。
Joe Darcy正在领导Open JDK开发，他的博客地址是http://blogs.sun.com/darcy
JSR 296——Swing应用框架——仍然需要更简化以方便Swing应用开发。
6u10特性的向前兼容（Java Kernal、QUickstarter、新Plug-in等）。
他同时提到了曾经考虑过但可能不会引入到Java 7的特性：
闭包——围绕提议没有形成一致意见
具体化泛型（Reified generics）
第一类属性（1st class properties）
操作符重载
BigDecimal语法
JSR 295——Bean绑定
Java.net开展了一次有关“哪些Java 7未采纳的特性是你最感兴趣的”的调查，其中闭包明显处于其他特性之前：
闭包 47.4% (734 Votes)
具体化泛型 17.2% (266 Votes)
第一类属性 10.4% (162 Votes)
操作符重载 4.3% (67 Votes)
BigDecimal语法 3.4% (54 Votes)
JSR-295 Bean绑定 7.3% (113 Votes)
我对任何特性都不感兴趣 9.7% (150 Votes)
Ricky Clarkson认为没有闭包Java将灭亡：
果然被证实了。虽然James Gosling想要闭包，虽然已经有了3个闭包原型编译器，虽然其他JVM语言支持闭包，Java 7还是没有闭包。
Martin Kneissl也认为Java 7中没有闭包是个坏消息：
应该增加闭包而不是Java 5中的“for”循环新形式。在Java 6中就应该有闭包。现在似乎Java 7中也不会有了。
闭包并不难以理解。至少当你把它们与Java中的匿名内部类作比较时是这样的。有的人不赞同。他们觉得总有一些愚蠢的程序员，所以应该限制语言以防止他们引起太多破坏，我不认同这个理由。这是不可能的。不称职的程序员在任何语言中都会搬起石头砸自己的脚。
幸运的是，JVM上还有其他语言可以使用Java的优点：库、可移植性和工具（某种程度上）。
Dustin Marx在关于Java 7中最期待的特性的帖子中对闭包有一些矛盾的看法：
就在我写这篇帖子的时候，已经有160票投完（不过很快就会出现新的投票），其中Java SE 7中最期待的落选特性是闭包。目前，闭包特性已经得到了总票数的几乎一半。从某种意义上说，这并不奇怪。闭包似乎主宰了Java SE 7的讨论直到被宣布不会在Java SE 7中引入。但是讨论是围绕着闭包的概念和如何实现闭包进行的争论。虽然闭包是Java SE 7最期待的落选特性之一，但是我个人对此非常矛盾。我有时会偶然的在工作中意识到闭包是多么有用，但是多数情况下没有它我也可以应付。也就是说，我不介意它被引入，但是当我听到没有被包含在Java SE 7中时这并没有困扰我。但是，如果我们相信目前的投票结果，那么接近一半的Java开发人员最想要这个特性。这与Java.net有关开发人员最想要Java SE 7引入闭包的问卷调查是一致的。

Osvaldo Doederlein对新特性感到兴奋，不过仍然很期望闭包：
Java 7是多年基础设施智能化的最好版本：294/Jigsaw，并发类加载——我认为这会提高大应用程序的启动时间，特别是类似于JavaEE服务器和IDE 等基于微内核的应用，XRender——将最终使Java成为Linux桌面应用的一等公民，G1，全64位支持（将在6u12中首次亮相，获取beta版），ForkJoin。
这么多的好特性，我几乎都快忘了失去闭包的悲伤了。我猜是时候转移到Scala、JavaFX或者其他现代JVM语言上了（只要不是类似于Ruby 或者Python的动态类型语言）。我认为从现在开始五年，如果我编写某种低层次的运行时，我会只写“标准”Java代码。多亏社区的保护，Java语言 正在慢慢转为一种遗产和低层次的角色。
另一方面，Matt Grommes关注于BigDecimal语法：
我致力于一个金融系统有一年多时间了，BigDecimal语法简直太痛苦了。我真的非常不满意。
Stephen Colebourne向Devoxx和JavaEdge的与会者展示了JDK7语言的10种可能变化，并请他们投票：
绝对的胜者是——null处理。Null处理获得了50张最优先支持票，是排在第二位的字符串切换（string switch）特性票数的两倍，几乎是全部最优先支持票数的三分之一。而且，几乎有三分之二的与会者把它放在了前四位优先支持的特性里。
其他受欢迎的特性包括字符串切换、异常的多捕捉、对Map的增强型for-each循环（能够删除或者查找索引）和ARM风格的资源管理。
不受欢迎的特性（特别认为是糟糕建议的）是通过[]访问List/Map和字符串插值（字符串中的${variable} ）。
泛型推断和多行字符串处于相对较低优先级但与会者不是特别反感。
值得一提的是，在Devoxx上对闭包特性的投票结果是50:50。