XStream所支持的JDK版本

XStream支持JDK1.3及以后的版本

在不同的JVM中XStream运行会有差异吗？

XStream有两种运行模式：存Java模式和增强模式。

在存Java模式下，XStream在不同JVM中的运行是一样的，但由于不同JVM对reflection机制的支持有所差异，会导致一些类或字段将无法序列化。

在增强模式下，XStream没有上述限制，然而这种模式并不被所有的JVM所支持。

哪种JVM支持XStream以增强模式运行？

       目前Sun、Apple、和HP的JVM 1.4或更新的版本支持增强模式。所有的JVM均支持以存Java模式运行。

两种模式下差异比较

       仅以Sun JDK 1.4为例说明两种模式下，XStream运行的差异。

功能                            存Java模式                 增强模式

公有类                         YES                             YES

非公有类                     NO                              YES

静态内部类                  YES                             YES

非静态内部类              NO                              YES

匿名静态内部类           NO                              YES

无缺省构造函数           NO                              YES

有缺省构造函数           YES                             YES

Private字段                  YES                             YES

Final字段                     NO                              YES

如何序列化集合对象？

参考下面的代码示例：

class Person {

  private String name;

  private List toys = new ArrayList();

  // ...

}

class Computer {

  String type;

}

class Car {

  String color;

}

xstream.alias("person", Person.class);

xstream.alias("computer", Computer.class);

xstream.alias("car", Car.class);

Person person = new Person("Joe");

person.addToy(new Computer("apple"));

person.addToy(new Computer("spectrum"));

person.addToy(new Car("blue"));

String xml = xstream.toXML(joe);

示例返回结果：

<person>

  <name>Joe</name>

  <toys>

    <computer>

      <type>apple</type>

    </computer>

    <computer>

      <type>spectrum</type>

    </computer>

    <car>

      <color>blue</color>

    </car>

  </toys>

</person>

如果使用XStream序列化对象，对象必须要实现Serializable接口吗？

       不必

动态代理类能被序列化吗？

       可以

当对象发生改变时，XStream如何处理？

       当对象新增加一个字段时，XStream在反序列化旧版本的对象时，会忽略这个新增的字段，不作任何处理。

       当对象删除一个字段时，XStream在反序列化旧版本的对象（包含该字段）时，会抛出异常信息。

       如果对象的字段改名了，将被视作删除了一个字段，然后再新增一个字段。

       对于更高级别的类移植，我们在发送信息到XStream之前，必须要对XML对象进行预处理。

       XStream还在不断的开发过程中，相信在未来的版本中，上述操作会更成熟，更容易。

XStream是线程安全的吗？

上个世纪90年代初，Gosling发起并领导了一个名为Green的项目，此项目最终演变为Java。Java 的基本理念是创造一种可以在不需修改的情况下执行在各种运算设备上的程序。例如，一个装备了Java虚拟机器的手机游戏软件也应该可以在别的手机上使用。

过去十年，这项技术身经百战。早期的合作伙伴微软发现Java程序的平台无关性对Windows带来不利，于是稍做修改，另创适合Windows的Java版本，从而引发了七年的官司。由于消费性设备、PC及服务器需要有不同的Java，Sun一直努力想找到合适的方法与其他各方分享Java的掌控权。以至于到现在，包括IBM在内的许多公司都在不断呼吁Sun开放Java主体部分的源码。

尽管如此，Java已经在计算机领域站稳脚跟。Sun首席执行官Scott McNealy可能还是会发布冠冕堂皇的演说，但在上周二Sun JavaOne大会上他的一番讲话话却十分中肯，他说：“七、八年前的JavaOne演说现在听起来真是寒碜，我们那时实在是太小看它了。我们根本不知道这项技术要做什么。”

Gosling全程参与了JavaOne上周的活动，现在的他头发已经花白，但牛仔裤、T恤衫和Birkenstock运动鞋的装束始终未变。“他看来像是一个老嬉皮，”Gosling的女儿在周二大会的影片中现身说法，惹得这位知天命的Java教父在台上满脸通红。

以下是Gosling畅谈Java理念的记录。

问：在Java的设计之初，你心中有想像过它会是什么样子吗？

Gosling：回想设计Green项目的时候，我们对长远未来大谈了许多。我们曾写过一本很多场景组成的小册子，许多Java设计都是依据这些场景构想出来的。我觉得那比较像是科幻小说的做法，你从来都不知道世界会走向何方，你可以任意预测技术的发展，但想象归想象，和实际还是有很大差距的。我非常相信摩尔定律会成为现实，轻而易举地而把一个个的点连成一了快速传播信息的网络。

我大胆预测许多科技一定会那样发展，当然会只是存在安全、可靠及便携等方面的问题。我们参与对这些问题的绝大部分给出答案，最后的结果一定会让大家惊奇万分。

问：最初，你的Green项目不是把重点放在消费性电子设备上吗？

Gosling：项目设计初期，我们花费很多时间和各界人士交谈，我们看到同样的问题发生在消费性电子设备、新兴手机及嵌入式控制系统领域。我们和电梯、机车、电力控制系统的制造商及汽车界的工作人员交谈过。我们也和VCR和电视机开发商交流过。在Green项目初期，我们决定做个原型，我们必须把精力集中在这一点，我们选择了消费性电子设备，很大程度上是因为这个领域更有趣。

虽然许多人都觉得很这个计划有意思，但我们还是疑惑是不是能把这个计划用在自我支持上？差不多同时期，时代华纳为全方位服务网络公开招标，那正是我们梦寐以求的事──网络连到家庭、在网络上传递语音和影像、内容互动等等。“是的！这正是我们想要的，是我们为之奋斗的目标！”于是我们就一头扎了进来。

问：那实际上是在互动电视的发展初期吧？

Gosling：没错，那真是一个具有远见的计划。很多人都说：“我们也想这样做。”

时代华纳的计划因为各种原因后来变得十分奇怪，我们没能拿下他们的标。回想起来，我还很庆幸我们那时输了。赢家SGI后来不知花了多少钱做那个单子，但没得到多大回报。

问：你认为Java是用在这种狭窄领域上的技术呢，还是可能深入到在整个电脑业的技术？

Gosling：我们并没有计划要把它推向整个业界，但我们看到整个产业在做类似的事，每个系统内部都装有数码控制器。但是存在着严重的相互操作性问题，所有东西都在相互整合，这事实引起了我们的注意。就像你站在暴力赛车场外看到所有车子都在朝竞赛场中心开去，一定会撞成一团糟。

问：Java解决了相互操作性的问题，但微软另辟蹊径创出了.Net，引发了更高层的兼容性问题。有什么方法可以把.Net 及Java整合起来吗？

Gosling：某种程序(比如Web services)，就像一座桥梁。但是我们不能把不愿融在一起的东西硬往一块拉。微软很明显地就是想要走自己的路，他们向来喜欢标新立异。他们曾作为Java社区里非常优秀而可爱的成员，可惜只持续了半年多，后来他们认为这样不好。

问：那是1995年还1996年的事吧？

Gosling：应该是在1996年。共同合作双方的意向。对微软而言这是一个长期的教育过程，他们好像不太喜欢这种方式。他们貌似在跟你走更近，例如我们之间合作开发了不少不错的产品，但其实彼此间还隔了一步之遥。我们之间的确有共通点，像Web services或相互操作性，都是很好的说明。

问：你们不能把用C#开发成的.Net程序上融入到Java虚拟机器中吗？

Gosling：我们的差别在于他们大量使用这种不安全的方式，但我坚决认为不应该用不安全的方式。

问：不安全？您的意思是……

Gosling：源代码有受管的和不受管的之分。受管源代码是可以确保安全与稳定性的，而不受管的源代码你无法保证什么。有时正确的做法也会引起内存损害，程序运作十分不容易分析。C程序是一种不受管程序，可能莫名其妙就挂了，最后造成安全上的重大影响。使用C语言，你可以假造事物的身份，但用Java，是绝不容许伪造身份的。

问：微软为什么想加入Java Community Process(JCP)？

Gosling：我不清楚，你可以问问Sun 首席技术官Greg Papadopoulos。

问：你希不希望看到双方回到当初半年多的密切合作状态？

Gosling：我很期待看到他们和JCP其他成员合作。

问：你们刚把Java应用服务器软件作为玻璃鱼开放源码，是不是也有可能把Java标准版(Java SE，Java的基础)开源发布？

Gosling：或许会的。我们过去为Java SE做的一切和开放源代码其实差不多，主要差别只是在于我们的授权要求要有测试。在做过调查后，我们认为测试是非常重要的。但开源界人士一方面说他们会接受测试，另一方面又说他们只是不同意测试。我们可能有一天会开放Java SE的源代码，主要得考虑怎么做比较好。

有很多事让我们十分紧张。许多人都有过使用JavaScript的经验，不同JavaScript间也存在相当严重的相互操作性问题，对网页制作者来说是一大梦魇。Java界的人都得拿着JavaScript手册才能做事，真是太可怕了。

问：像BEA等公司会加入一些东西使得Java程序只有在他们的应用服务器上才能执行，到头来Java也会变得不可携，是这样的吗？

Gosling：没错，这的确是个问题。但至少，这还只是在特别功能上而已。Java有个包命名(package naming)工具。当用API时，你得申明用的是公开标准的API──像Java等──或是某公司的专有API──例如com.bea，作为一个开发者就一定要十分小心。开发人员真得很在乎可携性，每次使用com.bea你会觉得很难受。JavaScript的一个困难就是无法判断你用的是不是某个浏览器专用的功能。

另外，事情也会演变成某个应用伺服器厂商具有一些想法，而大家都觉得不错，这个想法就会送到JSR(Java Specification request)，那么这家厂商第二或第三版本也会是在标准的Java框架内。

问：难道不能在开放Java源代码后通过品牌名称来控制兼容性吗？比如说，要求在其Java名称被充许前，就取得认证？

Gosling：这点我们做过许多讨论。Sun是一个十分民主的公司，有人认为这个方法可行，有人反对，目前反对者占多数。

问：你持反对观点吗？

Gosling：我有时是站在赞成的一方，不过我得承认我常常反复不定。

问：能将五年前的Java技术和今天的做一比较吗？

Gosling：最大的差别在于Java已经变成许多大型的关键的系统的中心，这就需要保守一点。当你的系统是一个每晚结算数百亿笔交易的银行系统时，小小一个bug也会酿成巨祸。早期我们有很多异想天开的点子，但现在我们得考虑到哪些人会受到我们影响。现在一切都要考虑周全才行。

问：通过Groovy等项目，Sun正在让Java世界和脚本语言走得更近，但坦白讲我不太清楚编程语言和像PHP、Perl、Python这样的脚本语言有什么不同。

Gosling：你的困惑其实是有根据的。世界上有太多松散的语言，给不同人提供不同的用途。

当人们提到脚本语言时，往往想到的是可以很快让开发人员把东西拼凑好，很快拿出去跟客户做演示。程序的性能怎么样、扩充性如何，或是能不能建成一个大系统到在其次才考虑。但在Java设计上，我们不太在乎能不能很快写成一个程序出门去做演示，我们在乎的是能不能很快写成一个大型的具有良好扩充性的程序，到最后我们做的决定往往比较困难实现。一般来讲，在设计上，脚本语言比编程语言要容易。

Java设计有两个层次：Java虚拟机和Java语言。难点在Java虚拟机及其以下的部分。如果把脚本语言用在Java虚拟机上，就可以兼得两者的优点。

问：你是这么做吗？

Gosling：是的。Groovy开发的东西可以获得所有的Java库，Java应用也可以使用Groovy。