deli 2006-9-27 13:18
开放Java源码,前途将会怎样
[table=98%][tr][td=3,1][b]热点观察：开放Java源码,前途将会怎样?[/b][/td] [/tr] [tr] [td] 来源：http://news.csdn.net/n/20060926/95369.html 发表时间：2006-09-27 07:59 [/td] [/tr] [/table]
千元大奖非你莫属！ 06Sun科技日先睹为快 软件保护成都巡讲 [IT英语学习频道]调查
Alan Williamson 在他最新的博客里提到：为什么要开放Java源代码？通过来自各方面高层的采访，以及Sun 公司最近的新闻发布会，我们知道即将发布Java的源代码。最新的消息来自LinuxWorld 对Laurie Tolson 的一次采访，她给出了一份实施该计划的最新时刻表。
到今年年底之前，将发布javac和Hot Spot Compiler的源代码。
通过引用在以往bug的数目，Alan 比较了开源的利弊。如果是在开源社区里开发Java，大部分的bug都可以清除掉；然而，开源最大的危险是可能性造成Java技术的分支。所谓分支，就是脱离主要部分，创造一种新的发展支流。这可能大幅增长JDK版本数目。
到目前为止，开发者面临的困难已经被大幅的降低到API的变化上。相对来说，这么做更容易地找到一个好的开发环境。例如，你可以很容易的配置Eclipse，只对JDK1.4版本的进行检查编译，而不去调用1.5版本的API。但是，使用分支却比使用未经核准的API还要危险。如果你调用了一个方法，而它做的和你想的根本不是一回事，天知道将会怎样？
按照当前的惯例，任何一家的Java都必须经过一整套的兼容性测试。IBM和BEA的Java虚拟机都做到了这点。然而，怎样在Java的分支上应用这些规则还不清楚。
在这方面，Sun公司行动谨慎并且努力协商各方，但却没有结果。一旦魔鬼从瓶子里给放了出来，它就再也不想被逮回去。
一个可行的方法，是让Sun公司发布相应的证明工具，通过它来测试其他的JDK的执行情况。并非必须测试开发者加入JDK的每项新功能，但这么做会保证这些功能不会破坏在进程中原有的东西。对于大范围的兼容性来说，这具有重要的意义。
总的说来，尽管开放Java源代码会出现新的困难，但前景乐观。但让我们满怀希望，拭目以待。
ythmyf 2007-2-13 13:02
开发狂想曲：如何在开源Java下生存
自Sun公司宣称要将Java代码基础的大部分“发布”之后，网上就充满了这样的疑问：此举措对于Java，开源以及开发者社区来说意味着什么……
自从Sun公司宣称要将Java代码基础的大部分“发布”之后，Internet上就充满了这样的疑问：此举措对于Java，开源以及开发者社区来说意味着什么?
首先，我们来看一条通告：Java的关键部分将会在遵循开源GPL V2许可证以及Classpath例外的条件下发布。这一套重要且遵循开源许可证的Java软件的发布可以看作是对开源社区最大的一次代码贡献，同时也产生了很多反应，从担心企业Java社区会在刹那间坍塌，到许多私有软件不可避免地衰败。那些不了解软件许可证的Java技术人员可能会奇怪有什么值得大惊小怪的，也不清楚这则通告对他们的影响。
GNU通用公共许可证或者GPL，是由自由软件基金会支持的开源软件的许可证。一旦某软件项目中使用了遵循GPL许可证的代码，则该项目也必须遵循GPL，这意味着它的许可证对项目使用不添加任何的附加约束。后面一点也就是我们在开源社区中经常提及的“copyleft”，这也是产生争论的来源。Java的开源是否意味着，如果使用新近发布的遵循GPL许可证的Java虚拟机开发出Java项目也会被强制性地要求遵循GPL许可证呢?批评者称前面的情况为“许可证的病毒天性”：遵循GPL的代码会“传染”其它由其演绎出的代码，并且强迫作者在GPL下公布源代码。
很显然，这会造成一些恐慌——-免费开放源代码的要求会威胁到企业Java开发人员的商业模式。但是Sun公司很快就取消了大家的担忧，对于现有Java开发人员来说，软件的发布意味着一切正常。Sun公司如此有信心的原因就在于前面所说的Classpath例外，Classpath例外是为 Classpath项目而开发的：它是通过开源编写的Java类标准，也在其它开源Java项目中采用，例如Kaffe。Classpath例外的内容较短，所以也值得一读：
静态或者动态地将java库和其它模块链接在一起，完成基于此库的组合工作。这样，GNU的GPL规定和条件将覆盖在整个组合体之上。
作为一种特殊的例外，此库的版权持有者分配给你权限来将用于生产可执行程序的独立模块链接到这一库。无论这些独立模块的授权如何规定，如何复制、发行可执行程序都依赖于你的选择。这里的独立模块是指非来源于或是基于此库的模块。如果你修改这个库，就可以扩展这个例外到你的版本中，然而这并不是必须的义务，如果不想这样做，可以从你的版本中删除这条例外。
这段话的实质就是关于Java代码问题。当你只是通过链接使用Java方法或者对Java类进行扩展时，你的代码就不需要遵循GPL标准。只有当对Java代码进行直接更改的时候才需要遵循GPL的“copylef”规则。例如，如果你扩展了一个遵循GPL许可证的Java类，并且在你的项目中使用它。则Classpath例外意味着你不要按照GPL的要求发布你的项目，但是如果你修改了原来的类，并且期望发布项目的话，则必须要遵循GPL的许可证。这样做的结果就是只有那些从事Java语言本身的开发人员需要公布他们的源代码，而不是那些使用Java语言进行项目开发的人员。
CSDN声明：此消息系转载自CSDN合作媒体，其中细节未经CSDN证实，特此声明
