The Artima Developer Community
Sponsored Link

Java Community News
Sun Open-Sources Java Implementations

8 replies on 1 page. Most recent reply: Nov 17, 2006 5:26 AM by Achilleas Margaritis

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 8 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Sun Open-Sources Java Implementations Posted: Nov 13, 2006 12:27 PM
Reply to this message Reply
Summary
Sun made available the source code of its implementations of Java SE, EE, and ME, as well as several tools in its Java Developer's Kit. To host the new JDK open-source code, Sun created the OpenJDK and Mobile and Embedded Community projects on Java.net. In addition, Sun also released the popular Java mascot, Duke, under a BSD-style license.
Advertisement

This morning Sun made official a change in the licensing terms of the company's three Java distributions, Java SE, ME, and EE. As of today, Sun will license its implementations of those technologies under a dual licensing scheme, with one of the available licenses being the GNU Public License (GPL) Version 2.

For Java SE, Sun created the OpenJDK community on java.net, where it made available the source code for the HotSpot virtual machine and the Javac compiler under the GPL. Separately, Sun also released the source for JavaHelp under the GPL. By the end of the first quarter of 2007, Sun executive vice president for software Rich Green promised a fully buildable JDK on the OpenJDK project as well.

For Java ME, Sun created the Mobile and Embedded Community on java.net. While Sun initially planned to release only the code-base for the Connected Limited Device Configuration (CLDC), Green announced at this morning's press event that the Connected Device Configuration (CDC) profile is also released under the GPL. Because CDC is at the core of many current ME implementations, the GPL-based CDC code means that an entirely open-source ME-based phone can now be built. CDC also drives many consumer-electronics devices, including BlueRay discs, according to Green.

The Glassfish project has been Sun's venue for developing the reference implementation of the Java EE platform. To Glassfish's original license—Sun's Common Distribution and Development License (CDDL)—Sun added the GPL as a licensing option, offering developers a choice of the two licenses.

In choosing the GPL, Sun's Green noted that the GPL met Sun's three objectives in open-sourcing Java:

No single license can satisfy every community... But we had [in mind] several optimization points in releasing Java in open source code. One was maximum adoption and distribution... Developers are very focused on many license qualities. We wanted to adopt a license that have the qualities ... that minimizes mismatch [with the broadest community expectations], and one that people are familiar with. There seems to be general consensus that this was the right way.... We wanted to drive compatibility as well. Compatibility [can be achieved] by doing everything visibly in the market place. No going off and running and hiding.

Green noted that the license Sun chose for Java is the latest version of the GPL, and that:

It's compatible with the world's largest transport system, which is Linux. The [GPL] has the property of enabling the distribution of Java.

Sun also adopted the Classpath exception to the GPL. In an interview with Sun's Developer Network, James Gosling summarized the benefits of the Classpath exception as follows:

The Classpath exception was developed by the Free Software Foundation's GNU/Classpath Project. Basically, it allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL's requirement to be itself offered to the public under the GPL.

This is a licensing paradigm in common use within Free software communities such as GNU/Classpath and Kaffe for the components of a Java technology implementation including the virtual machine and class libraries. We consciously chose the same licensing method so that there would be no temptation to second guess our intention to make Sun's Java SE implementation available under a genuinely Free and open license.

Green noted that with the license change of its Java implementations, Sun became the largest contributor to the open-source community. Java SE has approximately six million lines of source code, the same as the core Unix codebase, according to Green. The business rational for open-sourcing the company's precious IP is that "innovation doesn't happen elsewhere, it happens everywhere," observed Green, altering Sun co-founder Bill Joy's famous dictum.

At the release announcement event, Sun CEO Jonathan Schwartz pointed out that Sun's "entire business model is predicated on ... bringing more people to the network. The more people join the community, the more valuable that network becomes," providing Sun with additional business opportunities not directly tied to Java licensing. Schwartz also noted in the Q&A session following the event that the Java source code's sheer size, and the scope of Sun's Java implementations, warranted the initiation of new open-source projects, as opposed to donating that source code to an existing project or foundation, such as the Apache Foundation.

Green noted that existing commercial Java licensees will still be able to license Java under commercial terms. Rich did not mention, however, what benefits, if any, commercial Java licensees will enjoy above those opting for the GPL license terms.

The first major impact of the licensing change will be that Linux distributions can freely bundle Sun's JDK, according publisher Tim O'Reilly, who was interviewed for the event by Sun. Sun also vowed to work with existing open-source Java projects, such as the GNU Classpath project, to coordinate development so as to minimize overlap.

The open-source Java implementations will also integrate with the NetBeans IDE, making it easy to generate JDK-related projects in NetBeans. Sun's Green noted that this will add additional value to NetBeans, a project that, according to Green, is already gaining about a seven percent month-to-month increase in its number of users.

In addition to the Java implementation source code, Sun also surprised the developer community by open-sourcing Duke, the Java mascot under a BSD license. Developers and designers can gain access to Duke's graphical specifications through a java.net project at http://duke.dev.java.net, and are free to use and alter Duke's image.

How do you see this licensing change impacting your day-to-day work with Java?


David Ramsey

Posts: 34
Nickname: dlramsey
Registered: Apr, 2002

Re: Sun Open-Sources Java Implementations Posted: Nov 14, 2006 7:52 AM
Reply to this message Reply
The licensing change does not change my day-to-day use of Java. I'd already previously accepted Sun's license. My concern was over whether Sun would go in a direction that I and my customers disliked and leave us stranded. That no longer is the case, so far as I can tell.

However, on another point, I think this is a major blow to Microsoft. It has become clear with the release of powerful, sophisticated desktop applications written in Java, like Eclipse and Netbeans for example, that Java is completely usable on the desktop. Java's "write once, run anywhere" promise has largely come true, meaning that companies can now write Java applications and distribute them to multiple customers on different OSes and even different hardware without maintaining a separate version for each.

This is fatal to Microsoft. Companies that now adopt Java as the language for their applications suddenly gain cross platform distribution capabilities without the additional costs being as high as a development shop that must recompile for every target platform. Companies that develop in this way will be able to grow a larger customer base than otherwise.

Microsoft's counter to this should have been to either open source the CLR (Common Language Runtime - their VM for .NET technologies), or to provide implementations themselves for all major platforms. Since they did not, this means .NET is stuck in the Microsoft world only, in a global tech environment which increasingly is moving back to heterogenous computing. It will take several years but this act of open sourcing Java may be the death knell of .NET.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Sun Open-Sources Java Implementations Posted: Nov 14, 2006 9:28 AM
Reply to this message Reply
> However, on another point, I think this is a major blow to
> Microsoft. It has become clear with the release of
> powerful, sophisticated desktop applications written in
> Java, like Eclipse and Netbeans for example, that Java is
> completely usable on the desktop. Java's "write once, run
> anywhere" promise has largely come true, meaning that
> companies can now write Java applications and distribute
> them to multiple customers on different OSes and even
> different hardware without maintaining a separate version
> for each.

It's interesting that you mention desktop (meaning, presumably, rich-client) Java apps, because there's so much talk these days about rich-client Java apps enjoying a resurgence, but what I really see is rich-client Web apps (aka Ajax) gaining more ground, and especially in high-profile, widely-used applications. I'm a long-time rich-client Java/Swing fan, so I certainly would like to see more Swing apps out there. But, apart from NetBeans, LimeWire, and the usual 6-7 apps being obvious examples, as well as projects such as as SwingLabs, is the resurgence of rich-client Java really happening?

One thing I'd expect to see from open-source Java is a high-quality browser implementation of the JVM, along the lines of what Ethan Nicholas at Sun is working on:

http://www.artima.com/forums/flat.jsp?forum=276&thread=175370

This would really provide a viable alternative to both JavaScript/Ajax and Flash, with the added benefit of having the rich Java APIs available in a browser environment.

BTW, I am aware that applets work quite well now, and are even a practical deployment option (as of JDK 1.5, and especially with JDK 1.6, where the UI really looks nice (finally), with anti-aliased fonts, etc). It's just that the JVM download is still rather big. On the other hand, perhaps with broadband becoming increasingly ubiquitous, perhaps JVM download size is not such a big deal, after all. JVM startup time, memory footprint, etc, are still important, however.

> This is fatal to Microsoft. Companies that now adopt Java
> as the language for their applications suddenly gain cross
> platform distribution capabilities without the additional
> costs being as high as a development shop that must
> recompile for every target platform. Companies that
> develop in this way will be able to grow a larger customer
> base than otherwise.

There is already the Mono project, which does make a substantial part of the .NET runtime available on Linux.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Sun Open-Sources Java Implementations Posted: Nov 15, 2006 1:10 AM
Reply to this message Reply
> This is fatal to Microsoft. Companies that now adopt Java
> as the language for their applications suddenly gain cross
> platform distribution capabilities...

How does Sun's moving Java to a GPL licence increase the language's distribution capabilities?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

A question. Posted: Nov 16, 2006 6:29 AM
Reply to this message Reply
A question: why don't Applets download classes lazily, i.e. on a need basis? the first instantiation of a class would cause the relevant class to be downloaded from Sun's repository, thus terminating the problems of 'large JRE download'.

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: A question. Posted: Nov 16, 2006 11:45 PM
Reply to this message Reply
> A question: why don't Applets download classes lazily,
> i.e. on a need basis? the first instantiation of a class
> would cause the relevant class to be downloaded from Sun's
> repository, thus terminating the problems of 'large JRE
> download'.

Because applets don't necessarilly run on machines that have permanent internet connections.
Your suggestion would for example prevent an applet based solution from being deployed on a protected intranet where the workstations have a connection only to their company servers, the outside world being completely invisible.

Those setups are far from rare. They exist in many government and banking environments to name but a few I have personal experience with, and likely in many large companies.

Then there's the historical factor. When Java was first introduced effectively everyone was on dialup connections and got their browsers and JVMs on CD (or a set of diskettes).
Downloading a larger applet would have put many off from visiting a website, having to download a megabyte of classfiles from Sun would have made them disable Java completely.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Sun Open-Sources Java Implementations Posted: Nov 16, 2006 11:48 PM
Reply to this message Reply
> The licensing change does not change my day-to-day use of
> Java. I'd already previously accepted Sun's license. My
> concern was over whether Sun would go in a direction that
> I and my customers disliked and leave us stranded. That no
> longer is the case, so far as I can tell.
>

But the rest of your argument seems to hinge on the fact that Sun open sourcing Java is somehow going to shake things up - with Microsoft somehow suffering.

> However, on another point, I think this is a major blow to
> Microsoft. It has become clear with the release of
> powerful, sophisticated desktop applications written in
> Java, like Eclipse and Netbeans for example, that Java is
> completely usable on the desktop. Java's "write once, run
> anywhere" promise has largely come true, meaning that
> companies can now write Java applications and distribute
> them to multiple customers on different OSes and even
> different hardware without maintaining a separate version
> for each.

Been there, done that. When McNealy was screaming that Java is the platform and the OS is irrelevant back in the mid-late 90s, there was suppose to be some big Java desktop presence. That never happened.


>
> This is fatal to Microsoft. Companies that now adopt Java
> as the language for their applications suddenly gain cross
> platform distribution capabilities without the additional
> costs being as high as a development shop that must
> recompile for every target platform. Companies that
> develop in this way will be able to grow a larger customer
> base than otherwise.
>

Once again, you're living in the past. The license doesn't change anything of what you're talking about.

> Microsoft's counter to this should have been to either
> open source the CLR (Common Language Runtime - their VM
> for .NET technologies), or to provide implementations
> themselves for all major platforms. Since they did not,
> this means .NET is stuck in the Microsoft world only, in a
> global tech environment which increasingly is moving back
> to heterogenous computing. It will take several years but
> this act of open sourcing Java may be the death knell of
> .NET.

There's already Mono, so there is an open source implementation. Microsoft still doesn't have a threat to its desktop, and its server sales continue to displace proprietary Unix.

Sun has terrible financial problems. They're hoping that they can get free labor out of this move. Microsoft has more money than God, and doesn't need free labor.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Sun Open-Sources Java Implementations Posted: Nov 17, 2006 2:06 AM
Reply to this message Reply
> How does Sun's moving Java to a GPL licence increase the
> language's distribution capabilities?

Of course, what I should have referred to was Sun's implementation of Java since the Java language itself remains propietary. Make any changes to the source code that they provide and you can no longer call it Java.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: A question. Posted: Nov 17, 2006 5:26 AM
Reply to this message Reply
> > A question: why don't Applets download classes lazily,
> > i.e. on a need basis? the first instantiation of a
> class
> > would cause the relevant class to be downloaded from
> Sun's
> > repository, thus terminating the problems of 'large JRE
> > download'.
>
> Because applets don't necessarilly run on machines that
> have permanent internet connections.
> Your suggestion would for example prevent an applet based
> solution from being deployed on a protected intranet where
> the workstations have a connection only to their company
> servers, the outside world being completely invisible.
>
> Those setups are far from rare. They exist in many
> government and banking environments to name but a few I
> have personal experience with, and likely in many large
> companies.
>
> Then there's the historical factor. When Java was first
> introduced effectively everyone was on dialup connections
> and got their browsers and JVMs on CD (or a set of
> diskettes).
> Downloading a larger applet would have put many off from
> visiting a website, having to download a megabyte of
> classfiles from Sun would have made them disable Java
> completely.

OK, forget about Sun's repository; what about lazy downloading from the company's servers? instead of downloading the whole .jar file, classes are downloaded from the server that the applet was downloaded from on a need basis, i.e. in the first instantiation of a class.

I think minor modifications are needed for such a setup, even with current APIs: applets could come in a jar, but they would not contain any other classes, except for the main class. Then each time there is a request, the class loader checks if a class is not present, and if it is needed (either not present or there is an update), it calls the applet's origin server to send the relevant class file...then the class is stored in the local repository for further use.

Flat View: This topic has 8 replies on 1 page
Topic: Sun Open-Sources Java Implementations Previous Topic   Next Topic Topic: TIBCO Releases General Interface 3.2

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use