Scala拾趣--从Java7说开来

　　我们知道，关于当前正在进行中的Java7在Java社区有很多讨论。其焦点集中在要不要在Java7中引入一些新的语言特性，尤其是闭包：不仅有要不要加入闭包的争论，还有采用那种实现方式的问题。在javapolis举行的关于JAVA7语言特性投票的结果一文中列出了Java7中可能会加入的语言特性，那么我们先来看看在Scala中对于这些语言特性有何解决方式呢？
　　首先把闭包撇出来，因为对闭包不甚了解，所以就不多说。不过以我的看法，因为Scala本身就支持函数式编程，而Java还需要向后兼容性的考虑，所以我觉得Java7中无论以那种方式来实现闭包，也不太可能比Scala中的实现更加有效，或更加优雅。
　　下面我们就逐条来分析Java7中的十种语法提议：

1.Property declaration
2.Property access
　　这两条都是为了简化书写代码，这里用一个具体的例子来说明：
　　考虑一个Person类，这个类有两个属性，一个是表示姓名的forename，在JAVA7中可能的实现方式：

public class Person {   
 public property String forename;   
 public property int age;   
} 

 

　　而使用Scala，则可以使用下列方式（参考资料:Defining a BeanProperty）：

class Person(@BeanProperty var forename:String,@BeanProperty var age:Int)

　　一行代码搞定！



3.Improve generics
　　Scala中也支持泛型，而且貌似比JAVA中的更灵活。不过其实现方式与目前的JAVA一样，都是使用擦除化。因此对于JAVA中泛型存在的一些问题，Scala中也存在（唔，至少这条提议中列出的两个问题在Scala中也同样存在。其他的我不太清楚，目前对Scala中的泛型理解尚浅）。


4.Access List and Map using []
　　在Scala中可以像下面一样使用Map：

import scala.collection.mutable.HashMap
object MapAccess extends Application{
    var map =new HashMap[Int,String]
    map(0) ="Zero"
    map += 1 -> "One"
    map += 2 -> "Two"
    var value =map(2)
    println(value)
}

　　可以看到，在Scala中可以通过map(key)来读取value，通过map(key) =value来写入值对...
　　事实上，Scala中并没有对Map提供特别的语法支持。也就是说，对任意的类，你都可以像操作Map一样。只要你在一个类a中定义了apply方法，你就可以把这个类当作一个函数来使：
   　　a(something)
　　这等价于：
   　　a.apply(something)
　　如果你还定义了update方法，你就可以使用
   　　a(key) =value
　　这等价于
   　　a.update(key,value)
　　怎么样，不赖吧？

5,10.Null-handling and chaining
　　之所以有这两个提议，是由于在Java中存在null以及void类型的方法。在Java中，很多方法会返回一个null表示没有得到预期的结果或结果为空。事实上大部分情况这样做是不恰当的，这时抛出一个异常或返回一个表示“空”的对象（比如字符串“”，或空的List）可能更合理。而且这样造成的后果是对于很多方法调用后需要对其结果是否为null进行判断。
　　幸运的是，Scala中没有这些问题。
　　第一：在Scala中没有void，也就是说每个方法都会返回一个实实在在的对象（Java中的void在Scala中有一个对应的类Unit）。
　　第二：对于标准的Scala程序，null不应该出现。相对应的Scala中有个Option类来处理这种返回结果为“空”的情形。
　　这里我也不细说了，有兴趣的可以参看opensdp同学的 用Scala语言中的 Option 对象来处理 null-like 返回值。



6.Extension methods
　　这个有点像Ruby中的“open class”，就是允许在不修改原有代码的情况下给已有的类添加新的方法。
　　由于JAVA是静态类型语言，并且不允许两个名字完全一样的类的存在，所以在这一点的实现肯定会有很多限制，不可能做到像Ruby那样。目前有两种解决方案：

Neal Gafter的提议 写道

example:

import static java.util.Collections.sort;
…
List<String> list = …;
list.sort();

Peter Ahé's 的提议 写道

"Declaration-Site Extension Methods"

example:

package java.util;
interface List<E> … { 
… 
void sort() import static java.util.Collections.sort; 
…
}

　　第一种实现可以看成是static import的一种扩展；第二种实现同样用到了static import，并且需要修改已有代码。
　　总之，这两种方案看起来都不甚优雅，甚至可以说丑陋。其意义也不大，并且对代码的可读性会造成一定的影响。
　　那么我们来看看Scala中能够如何解决这个问题。Scala中有一个功能很强大的机制：隐式类型转换。这个机制威力巨大，用处远不止Extension methods，这里我只举个例子说明如何解决Extension methods，有兴趣的可以参看fakechris同学写的scala学习笔记(5) -- implicit type

　　在Ruby中，我们可以通过如下方式向String类中添加print_self方法：

class String
  def print_self
    puts self
  end
end

　　然后我们就可以对普通的String调用print_self方法：

"Daniel Spiewak".print_self    # prints my name

　　那么Scala中怎末实现这个呢？很简单：

object StringTest extends Application{
    
    "Eastsun".printSelf         //对String调用printSelf方法
    
    implicit def stringWrapper(s:String) =new {
        def printSelf = println(s)
    }
}

　　并且在类StringTest可见的范围内，这个方法都是有效的。（参考资料：Getting Over Java）



7.String switch
　　在Scala中没有switch关键词，但是有另一个强大得多的机制（不过，也复杂得多）：Pattern match。实现String switch功能，那只不过是小菜一根。

object MatchTest extends Application{
    
    test("hello")
    
    def test(obj:Any):Unit = obj match{
        case 1|2|3|4 => println("A integer between 1 and 4")
        case "hello" => println("Hi")
        case _       => println("something else")
    }
}

8.Typedef
　　唔，对于这个功能...但是Scala中恰好就有这样一个关键词type，typedef就是这个关键词的作用之一：

import scala.collection.mutable.HashMap
object TypeTest extends Application{
    type ISMap =HashMap[Int,String]
    var map =new ISMap
    map(1) ="One"
}

9.Multi-catch
　　这里我们又可以来感受一下Scala中Pattern match的威力了：

import java.io.IOException
object ExceptionCatch extends Application{
    
    exceptionCatch(ioexceptionThrow)
    
    def ioexceptionThrow():Unit = throw new IOException
    
    def exceptionCatch(func:()=>Unit) =
        try{
            func()
        }catch{
            case _:IllegalArgumentException|_:IllegalStateException => println("RuntimeException")
            case _:IOException => println("IOException")
            case _             => println("Something else")
        }
}

　　结论：可以看到，目前在JAVA中想方设法想要加入的语言特性，在Scala中要么是根本不需要的东西，要么是以一种更加优雅的方式实现了。但同时，在学习Scala的过程中，一方面感受到Scala语法所带来的巨大便利与威力，另一方面其语法比起JAVA来复杂了许多。譬如在Java中粗略来说有interface,abstract class与普通的class。而Scala中除了普通的class与abstract class还有case class，sealed class,trait,object这些类型的类。更不用说Scala中那些函数式有关的语法了。
　　因此，可能有人会有疑问：有着这么复杂语法的语言有存在的必要吗？会不会成为下一个C++（恐龙）呢？Daniel Spiewak 在他的博客Is Scala Really the Next C++?中也提出了这个问题，他的答案是否定的。主要的理由是：C++由于兼容的目的背上了C这个沉重的包袱，由于C的影响，很多语言特性不能很好的实现；而Scala不同，Scala与Java在源代码上是不兼容的，因此Scala可以更加自由的发挥。
　　我比较赞同这个观点，同时觉得Java7不应该添加太多的东西进去了。虽然现在Java代码相对其他新式语言来说显得啰嗦，但是Java简单，这就是它最大的优点。如果Java即要考虑向后兼容性，又想把新的特性一股脑加进去，到后来只可能走向C++的老路。这些新的特性应该由JVM上的其他语言来实现，比如Groovy，比如Scala。你觉得呢？
　　PS:根据达尔文的理论，生物的进化包括遗传与变异。而目前的JAVA是只“遗传”不“变异”，这对于语言的进化也是很不好的。

评论

48 楼 groovyzhou 2008-06-16  

泡 泡 写道

icanfly 写道

Eastsun 写道

问题是如果需要兼容，就不太可能实现的很优雅
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包，其实现方式也够呛。
这种打补丁式的改进总不会太完美。

PS：弄一个JAVA3000出来也不错，抛弃向后兼容性。

我同意，JAVA顾虑得太多，应该学学Python，要使用旧JAVA语法的用JAVA旧的版本，要使用新的语法可以用新的版本，这样不但JAVA类库中有些“鸡肋”可以踢除，本身语言简洁性也得到提高！希望JAVA语言的开发工程师们不要老停留在要兼顾以前版本的陈旧思想里了！

那么庞大的开源类库，谁去转成新版本，不向下兼容导致的问题更多

开源类库有很多是半死不活的, 如果没有人维护, 即使java保持兼容性, 这些类库最终也是会被用户抛弃
如果用的人多, 自然有人会转过来
python3000在python社区里面并没有引起多大的反对声音

java并没有兼容c和c++, 不照样是流行起来了
兼容性根本不是问题

47 楼 groovyzhou 2008-06-16  

Eastsun 写道

ray_linn 写道

总的看来，Java 7将是C# 3.5的一次大抄袭而已。

说起“抄袭”，谁抄谁还不好说。
C#整个语言不就是模仿Java的么？
现在这些特性还只是提议而已，最终会不会加到Java7中去还未有分晓。
除了闭包我不是太肯定需不需要加入到Java7中去，其他的特性我觉得还是不要加的为好。
保持Java的简洁优雅比加入那些乌七八糟的特性更重要，我以为。

我觉得提议都不该,提议的人多了,sun公司头脑一发热就加进去了
应该向c学习,几十年不变
要么就学习python,勇敢的破坏向后兼容

46 楼 ray_linn 2008-05-13  

Eastsun 写道

avaj 写道

这典型的就是java.io包，这里头的烦琐到接近委琐的状态

==============
同意这句话。

保留意见

我觉得Java很多API从设计上来说还是蛮不错的。
比如IO，Swing etc.
给使用者提供了很大的灵活性。
但使用起来确实不那么方便，也容易把新手搞晕~

M$的东西偏向与傻瓜式，上手容易。
但灵活性估计就没那么好了，一切都在M$的掌控中，你只能跟着他转。

Java.io的复杂在thinking in java中有颇有诟病。

灵活性必须要在用必要的方面。比如对Micirosoft提供Data Provider的灵活性。至于替换一个XML dom，则大大值得考虑。

我从来没觉得Microsoft的东西是傻瓜式，这种所谓的傻瓜式只是对初级程序员而言，（当然大部分从业者都是初级程序员吧？），牛人照样能写出I4O（Indexed Linq）这样的东西。从某种意义上，Microsoft推出Linq to Collection这种东西，使得C#更接近自然语言。

45 楼 Eastsun 2008-05-13  

avaj 写道

这典型的就是java.io包，这里头的烦琐到接近委琐的状态

==============
同意这句话。

保留意见

我觉得Java很多API从设计上来说还是蛮不错的。
比如IO，Swing etc.
给使用者提供了很大的灵活性。
但使用起来确实不那么方便，也容易把新手搞晕~

M$的东西偏向与傻瓜式，上手容易。
但灵活性估计就没那么好了，一切都在M$的掌控中，你只能跟着他转。

44 楼 avaj 2008-05-13  

这典型的就是java.io包，这里头的烦琐到接近委琐的状态

==============
同意这句话。

43 楼 ray_linn 2008-05-13  

hax 写道

用Factory和Builder能提供灵活性，比如使用其他的XML DOM实现。M$的习惯一向是只此一家，别无分店，所以直接new就可以了。当然，我也认为java的XML可以简化，但是这不是什么大不了的问题。

XPath那个你冤枉Java了。Java的API是遵循W3C DOM Level 3 XPath的。如果你要骂，应该骂W3C去，嘿嘿。还有，骂之前请注意了，W3C的API允许对XPath表达式进行重用（当然也可以不重用），而MS的selectNodes方法虽然方便，但是没法重用XPath。还有返回值上的类型有限定。XPath其实可以返回并非节点和节点集类型的。所以MS的API是不严谨的。

你得承认，对于大部分状况下,MS的方案更简单，更容易。
拿XmlDocument来说，如果真有替换XML DOM API的必要性，Microsoft也会采用别的方案来实现更换XML dom，可能比如更换DomProvider（在MS的DataReader中就是如此）。

此外就拿XmlDocument的Load动作来说。

doc.Load("http://www.w3c.org/some.xml");
doc.Load("C:\W3C\some.xml");
doc.Load("\\w3c\\some.xml");

Microsoft接替了java程序员大部分的工作，使得程序员可以专注于当前的问题（要加载某一个xml文件），而不需要象Java一样，还要关注要如何加载。。。

我的重点不是在于它的烦琐，而是在于，Sun缺乏一种更简单，更明白的表达方式，这导致的Sun的语法象绕口令，而MS的语法则接近自然语言。另外Microsoft淘汰SAX,而采用Pull的方式，也是出于直观的考虑。

这典型的就是java.io包，这里头的烦琐到接近委琐的状态。

42 楼 sniperking 2008-05-13  

同意，太灵活了，反而会使学习成本加大，看别人的代码会更难理解
一行搞定一个功能看起来不错，可以让别人看你写的代码就麻烦了

41 楼 warren 2008-05-13  

对其他语言了解不多,只熟悉点Java和Ruby.对于Java这个规范语言来说,我的感觉就是这些特性让Java变得越来越乱.大概看了一下Defining a BeanProperty,整体感觉既不像Java又不像Ruby,有点不伦不类,这种结合使得没了Java的严谨和Ruby的简洁,总体感觉就是乱.

40 楼 deeprising 2008-05-13  

Java应该保持简洁～～

39 楼 hax 2008-05-12  

ray_linn 写道

DocumentBuilderFactory domfac=DocumentBuilderFactory.newInstance();
try {
 DocumentBuilder dombuilder=domfac.newDocumentBuilder();
InputStream is=new FileInputStream("bin/library.xml");
Document doc=dombuilder.parse(is);

这几句，应该只要一两句

XmlDocument doc=new XmlDocumnet().
doc.load(path)//为了增加/取消validation

DocumentBuilderFactory，DocumentBuilder 都是多余的垃圾类。再比如XPath

XPath xpath = XPathFactory.newInstance().newXPath();
String expression = "/widgets/widget";
InputSource inputSource = new InputSource("widgets.xml");
NodeSet nodes = (NodeSet) xpath.evaluate(expression, inputSource, XPathConstants.NODESET);

和

XmlDocument = new XmlDocument();
doc.Load("widgets.xml");
NodeList nodes=doc.DocumentElement.SelectNodes("/widgets/widget");

.net的写法象英文一样自然，Java的写法则古怪得很，（我估计还得查一下evaluate的API含义）。

用Factory和Builder能提供灵活性，比如使用其他的XML DOM实现。M$的习惯一向是只此一家，别无分店，所以直接new就可以了。当然，我也认为java的XML可以简化，但是这不是什么大不了的问题。

XPath那个你冤枉Java了。Java的API是遵循W3C DOM Level 3 XPath的。如果你要骂，应该骂W3C去，嘿嘿。还有，骂之前请注意了，W3C的API允许对XPath表达式进行重用（当然也可以不重用），而MS的selectNodes方法虽然方便，但是没法重用XPath。还有返回值上的类型有限定。XPath其实可以返回并非节点和节点集类型的。所以MS的API是不严谨的。

38 楼 aninfeel 2008-05-11  

Map在java里怎么说也是个普通的类，怎么能在编译器上为它设计特别的语法呢？哪天发现其它语言的File简单，是不是也要为为File加个特殊语法？然后发现其它实现也要简化，就再为它设计特殊语法？

37 楼 aws 2008-05-10  

OPTIMUS.PRIME 写道

Eastsun 写道

1.Property declaration
2.Property access
　　这两条都是为了简化书写代码，这里用一个具体的例子来说明：
　　考虑一个Person类，这个类有两个属性，一个是表示姓名的forename，在JAVA7中可能的实现方式：

public class Person {   
 public property String forename;   
 public property int age;   
} 

 

　　而使用Scala，则可以使用下列方式（参考资料:Defining a BeanProperty）：

class Person(@BeanProperty var forename:String,@BeanProperty var age:Int)

　　一行代码搞定！

哦，你把两行代码写在一行里面就是“一行代码搞定”了？

Eastsun 写道

4.Access List and Map using []
　　在Scala中可以像下面一样使用Map：

import scala.collection.mutable.HashMap
object MapAccess extends Application{
    var map =new HashMap[Int,String]
    map(0) ="Zero"
    map += 1 -> "One"
    map += 2 -> "Two"
    var value =map(2)
    println(value)
}

　　可以看到，在Scala中可以通过map(key)来读取value，通过map(key) =value来写入值对...
　　事实上，Scala中并没有对Map提供特别的语法支持。也就是说，对任意的类，你都可以像操作Map一样。只要你在一个类a中定义了apply方法，你就可以把这个类当作一个函数来使：
   　　a(something)
　　这等价于：
   　　a.apply(something)
　　如果你还定义了update方法，你就可以使用
   　　a(key) =value
　　这等价于
   　　a.update(key,value)
　　怎么样，不赖吧？

这就“不赖”，你品味也太低了吧。Java设计之初就放弃的运算符重载罢了。而且这种莫名其妙的语法比C++的重载难看不知道多少，好端端的operator()叫什么“apply”，好端端的operator[]=叫什么“update”，命名欲爆发了？

引用

5,10.Null-handling and chaining
　　之所以有这两个提议，是由于在Java中存在null以及void类型的方法。在Java中，很多方法会返回一个null表示没有得到预期的结果或结果为空。事实上大部分情况这样做是不恰当的，这时抛出一个异常或返回一个表示“空”的对象（比如字符串“”，或空的List）可能更合理。而且这样造成的后果是对于很多方法调用后需要对其结果是否为null进行判断。
　　幸运的是，Scala中没有这些问题。
　　第一：在Scala中没有void，也就是说每个方法都会返回一个实实在在的对象（Java中的void在Scala中有一个对应的类Unit）。
　　第二：对于标准的Scala程序，null不应该出现。相对应的Scala中有个Option类来处理这种返回结果为“空”的情形。
　　这里我也不细说了，有兴趣的可以参看opensdp同学的 用Scala语言中的 Option 对象来处理 null-like 返回值。

嗯嗯，Scala没void或NULL，但有个专门的NULL对象。真高级呀，不过到头来还是得判断程序返回了正常的对象还是这个高级的NULL对象。
顺便说一句，有个设计模式叫NULL Object模式。另外这个所谓的“高级特色”在C++中属于常识（事实上复制构造器、赋值操作符重载之类的事情很是烦倒了一批人，以至于Java上手就把所有东西当用指针来handle）

引用

6.Extension methods

莫名其妙的东西，暂不加评论。

引用

8.Typedef
　　唔，对于这个功能...但是Scala中恰好就有这样一个关键词type，typedef就是这个关键词的作用之一：

import scala.collection.mutable.HashMap
object TypeTest extends Application{
    type ISMap =HashMap[Int,String]
    var map =new ISMap
    map(1) ="One"
}

又是C++就有的几百年前的玩意。Java扔了这个怪物Scala又拾起来当卖点。

引用

9.Multi-catch
　　这里我们又可以来感受一下Scala中Pattern match的威力了：

import java.io.IOException
object ExceptionCatch extends Application{
    
    exceptionCatch(ioexceptionThrow)
    
    def ioexceptionThrow():Unit = throw new IOException
    
    def exceptionCatch(func:()=>Unit) =
        try{
            func()
        }catch{
            case _:IllegalArgumentException|_:IllegalStateException => println("RuntimeException")
            case _:IOException => println("IOException")
            case _             => println("Something else")
        }
}

Multi-catch也算是新功能？多写几次catch不是一样么？
“因为case只要4个字符，catch有5个字符，用Scala可以少写几个字符耶！！！”
Puke...

引用

　　结论：可以看到，目前在JAVA中想方设法想要加入的语言特性，在Scala中要么是根本不需要的东西，要么是以一种更加优雅的方式实现了。但同时，在学习Scala的过程中，一方面感受到Scala语法所带来的巨大便利与威力，另一方面其语法比起JAVA来复杂了许多。譬如在Java中粗略来说有interface,abstract class与普通的class。而Scala中除了普通的class与abstract class还有case class，sealed class,trait,object这些类型的类。更不用说Scala中那些函数式有关的语法了。

一堆无用的语法糖衣罢了。

引用

而Scala不同，Scala与Java在源代码上是不兼容的

很好，死得更快。


这帖还精华？再puke...

這种的所謂改進無非就是把簡單明瞭的東西複雜化

36 楼 aws 2008-05-10  

little06 写道

Norther 写道

pancras 写道

Norther 写道

pancras 写道

Norther 写道

个人觉得property那部分，可以用annotation，比引入新的关键字和谐的多，可以在编译期做些手脚，根据annotation生成get,set方法，例如

class Student{
    @Property //代表可以get 和set
    private String name;
    
    @Setter //代表可以set
    private Integer age;
    //省略get set方法
}

同时也可以对"="和"."符号做特殊处理，例如

student.information.content = "hahaha";//会编译成student.getInformation().setContent("hahaha");
student.age = 19;//会被编译成student.setAge(19);

如果这这样了 和直接把属性的访问级别放成public有什么不同？   如果要在set方法中对值进行过滤又如何实现。
典型的滥用annotation。

当然有不同，这个机制没有这么蠢，如果你提供了属性相应的set方法，它就不生成，就用你的，这也可以在set里进行过滤，只是在编译的时候做点手脚，对虚拟机没有影响，真是灰常灰常的简单和灵活。

另外我不明白这怎么算滥用了，就加入两个annotation，就叫滥用了？宁可引入关键字去滥用关键字？那什么不是滥用？

   为了用而用，不是滥用么？何况你这样做根本没有什么实际意义，如果有，能明确表示出来么？你所谓的灵活是什么？分明就是强行把能通过公开访问的东西使用你的annotation实现。
  

怎么是为了用而用？我实在不明白，麻烦你再好好解释一下，这样做可以减少大量无意义的代码，方便程序的可读性，这是参照RUBY的，只不过利用编译手段，不用去改虚拟机，编译出来的代码，和private字段且提供了GET,SET方法的字节码是一样的，这样并不是把FIELD改成public的，你根本没有仔细看我的回帖，我说的很明白，如果你的get或者set有自己的逻辑，自己就写个get或者set方法，编译器编译时判断你已经提供了set方法就不生成了，难道这不是灵活吗？我们写的get,set方法80%的情况是没有逻辑的，就是简单的访问或者设置，这样的重复劳动完全可以省略的，去看看RUBY或者C#怎么做的吧。

简单的问题复杂化
觉得java可以有接口手动控制内存就好了

感觉现在很多问题都是内存泄露上
特别是小型系统

在小并发下，不考虑性能 效率，唯一问题就是内存泄露上

程序除了 人与 计算机的沟通外，无非是 功能，速度，稳定性

那還用java幹嗎？
我不會直接回去用C++

35 楼 williamy 2008-05-09  

if you do need to type more lines , it maters ?
no ,i don't care ,but i'm still wanna more functional apis ,hopes it has the power as c /c ++

34 楼 ray_linn 2008-05-09  

Eastsun 写道

1.同样希望
2.貌似Java7中会加入NIO2，丢弃旧有暂时还不太可能（向后兼容性是个包袱）
3.。
4.同样不太可能，不过现在的用着还不错
5.JAVA 的XML API貌似还可以吧

Java XML的问题是烦琐，名字取得也有点不着调。与.net三步之类必能处理xml比,还是烦琐。 Web service则更差。。（.net大部分都是在method上加一个attribute就完了)。

DocumentBuilderFactory domfac=DocumentBuilderFactory.newInstance();
try {
 DocumentBuilder dombuilder=domfac.newDocumentBuilder();
InputStream is=new FileInputStream("bin/library.xml");
Document doc=dombuilder.parse(is);

这几句，应该只要一两句

XmlDocument doc=new XmlDocumnet().
doc.load(path)//为了增加/取消validation

DocumentBuilderFactory，DocumentBuilder 都是多余的垃圾类。再比如XPath

XPath xpath = XPathFactory.newInstance().newXPath();
String expression = "/widgets/widget";
InputSource inputSource = new InputSource("widgets.xml");
NodeSet nodes = (NodeSet) xpath.evaluate(expression, inputSource, XPathConstants.NODESET);

和

XmlDocument = new XmlDocument();
doc.Load("widgets.xml");
NodeList nodes=doc.DocumentElement.SelectNodes("/widgets/widget");

.net的写法象英文一样自然，Java的写法则古怪得很，（我估计还得查一下evaluate的API含义）。

33 楼 Eastsun 2008-05-09  

ray_linn 写道

我希望的java 7.0。

1。彻底修改generic，放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类，使之简单化。
3。改进jar的签名，使之具有版本签名，避免classpath load进同一个jar的不同版本造成错误，应该加入assembly的强签名。（我在eclipse被这个搞得烦死了）。
4。清理java.util，把collection独立出来。
5。提供简单实用的XML API，支持DOM/Pull/push三种方式，以及xml-object的序列化方法。（这个可能有了）以及简单的web service支持。

1.同样希望
2.貌似Java7中会加入NIO2，丢弃旧有暂时还不太可能（向后兼容性是个包袱）
3.。
4.同样不太可能，不过现在的用着还不错
5.JAVA 的XML API貌似还可以吧

32 楼 ray_linn 2008-05-09  

我希望的java 7.0。

1。彻底修改generic，放弃擦除法改用.net的膨胀法。
2。丢弃部分IO的类，使之简单化。
3。改进jar的签名，使之具有版本签名，避免classpath load进同一个jar的不同版本造成错误，应该加入assembly的强签名。（我在eclipse被这个搞得烦死了）。
4。清理java.util，把collection独立出来。
5。提供简单实用的XML API，支持DOM/Pull/push三种方式，以及xml-object的序列化方法。（这个可能有了）以及简单的web service支持。

31 楼 ray_linn 2008-05-09  

Eastsun 写道

ray_linn 写道

C#从1.0开始就保持了自己的创新，Java呢？从6。0开始，几乎是亦步亦趋，几乎看看C#，就可以知道下一个版本的Java大概会出现什么东西

举几个例子说说？
我不太了解Ｃ＃，所以也不清楚Ｊａｖａ６.０哪儿抄了Ｃ＃的。
ＰＳ：貌似Ｃ＃３.０较Ｃ＃１.０有很大改进，我很是好奇Ｃ＃是怎末做到向后兼容的？或者Ｃ＃没有向后兼容性？

应该说是5.0，我把java 1.3升级到java 4.0，当成升级到6。0了。

java 5.0:
for/in循环 = C# 1.0的 foreach
annotation = C# 1.0的 attribute (这点相信是C#对Java的最大贡献，否则JCP那帮人估计还在吵架）
enum =C#1.0的enum
autoboxing/unboxing..
可变参数... C# 1.0都有。

java 6.0更象是一个5.0 patch，语法上改善很少，大部分是API的补强。唯一亮点是支持javascript，不过有啥用我没想出来。

java 7.0里语法亮点在C# 3.0里都有，缺少的是LINQ。


C# 3.0里的很多特点，比如静态方法、var类型，get/set都是在compiler上动手脚的,C# 3.0基于2.0的FX，你可以叫他sugar (.net 3.5=.net 2.0+WPF+WCF..)

.net 1.0与.net 2.0最大的区别是Generic，Microsoft将Generic安排到独立的名称空间去,system.collection.generic，你要用generic，你就得用2.0，因此继续保持后向兼容。

30 楼 Eastsun 2008-05-09  

ray_linn 写道

C#从1.0开始就保持了自己的创新，Java呢？从6。0开始，几乎是亦步亦趋，几乎看看C#，就可以知道下一个版本的Java大概会出现什么东西

举几个例子说说？
我不太了解Ｃ＃，所以也不清楚Ｊａｖａ６.０哪儿抄了Ｃ＃的。
ＰＳ：貌似Ｃ＃３.０较Ｃ＃１.０有很大改进，我很是好奇Ｃ＃是怎末做到向后兼容的？或者Ｃ＃没有向后兼容性？

29 楼 wdlfellow 2008-05-09  

icanfly 写道

Eastsun 写道

问题是如果需要兼容，就不太可能实现的很优雅
譬如JAVA5中的泛型。。。和鸡肋差不多。
以及将要加入的闭包，其实现方式也够呛。
这种打补丁式的改进总不会太完美。

PS：弄一个JAVA3000出来也不错，抛弃向后兼容性。

我同意，JAVA顾虑得太多，应该学学Python，要使用旧JAVA语法的用JAVA旧的版本，要使用新的语法可以用新的版本，这样不但JAVA类库中有些“鸡肋”可以踢除，本身语言简洁性也得到提高！希望JAVA语言的开发工程师们不要老停留在要兼顾以前版本的陈旧思想里了！

严重同意，现在java的发展方向让人更迷茫