OpenJDK on Solaris Dev Express 1/2008?

Erik Trimble Erik.Trimble at Sun.COM
Thu Jun 5 12:23:16 UTC 2008


Andrew John Hughes wrote:
> 2008/6/4 Kelly O'Hair <Kelly.Ohair at sun.com>:
>   
>> 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)




More information about the build-dev mailing list