Andrew John Hughes wrote:
2008/6/4 Kelly O'Hair <[EMAIL PROTECTED]>:
Not sure what you mean by the Sun Studio trap.


I'm referring back to the Java trap - before Sun released their JDK
under the GPL,
it was possible to have applications under a Free Software license
written in Java
which couldn't be run in a Free environment because they would only work under
the proprietary JDK.  GNU Classpath was the community's attempt to free Java
from this trap.

Only being able to build the OpenJDK using the proprietary Sun Studio
compiler on Solaris creates
a similar issue, though the scope of the problem is fortunately more
restricted.  I'm not sure OpenSolaris
itself can even be built with GCC, which is an even worse issue - it's
not truly Free Software if it can only
be built with proprietary tools.

This is NOT a trap. This is a CHOICE OF PREFERENCE made by the FS Community. It is no more a trap than using GPL'd programs in conjunction with the Apache http server is. Just because we don't play exactly in your world doesn't mean there is a trap. Traps are when you cannot replace a whole component layer easily with something else. So, if your GPL'd Java program had to run on a Sun JDK under Solaris, that would certainly be true. However, you can run your Java program on one of about 4 major JDKs now, under over a dozen OSes, so that hardly qualifies as a trap.

Remember, not everyone wants everything in one particular format (or, license). We've got end-users who can't stand the GPL, for some _very_ good reasons. We've got other folks who are sore at us for not using an MPL-style license. So, I take license-criticism extremely poorly.

Each release of a compiler requires some kind of work to the Makefiles,
happened with gcc4, and will happen with SS12 and VS2008.

While I can understand some changes being necessary for major releases
(e.g. the move from GCC 3 to 4),
every single release shouldn't need work; this suggest an issue with
the build system itself.
Sadly, no, this is an issue with the COMPILERS, not the make system. GCC, SS, and all other compilers has a nasty tendency to subtly break all sorts of things without rev-ing the major version number. In GCCs case, this is often directly related to changes in GLIBC, particularly on Linux. GCC has some bad (recent) history, as major changes were implemented without obvious notice, with no major version bump, and occasionally with no minor version bump either. gcc 3.2 is considerably different than 3.3 or 3.4. And, in Microsoft's case, their myriad of different compiler 'distros' within the same general release (i.e. Visual Studio vs Express vs VS Professional) is even worse, as they support very different library sets and compiler flags. So, every time we want to support a new compiler, there's some work to be done to discover these differences, and adjust the makefiles to compensate.

It would certainly be nice for the JDK to be able to build with more than one compiler on any given platform. But that's what a community is for - people interested in using a specific compiler should certainly not be prevented from doing so. Our (Sun's) interest is primarily in supporting our own compilers.

That said, the make system could use some serious streamlining, and the code itself could _really_ do a much better job of disentangling itself, so that it could be built in a more modular form.

Andrew John Hughes wrote:
GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it
won't
work under Solaris/x86 or Solaris/x64.   There are some significant
GCC-isms
which the JDK does not currently support.

That said, it would not be terribly difficult to modify the source to get
GCC to work, but you'd definitely have to spend a bit of time doing so.
Maybe the next logical campaign is to avoid the Sun Studio trap then... :)


--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

Reply via email to