Visual Studio 2010
erik.trimble at oracle.com
Wed May 19 18:00:58 UTC 2010
One more thing about that:
Due to resource constraints on developer time (we haven't figured out
how to clone Kelly ;-)
we (Oracle) are really only ever going to support building the JDK with
a single OS/C compiler combination, which we slowly change over time.
The OpenJDK project itself is happy to include support for non-"blessed"
combinations (look at the amount of work done in linux to support
various version of GCC, and the additional support for GCC as another
compiler on Solaris), but Oracle will not be using them itself to build
the Oracle JDK (i.e. Sun JDK), and we're not going to spend any time on
them other than checking that community submissions actually do work.
Note that I'm not making an Official Oracle statement here, I'm just
pointing out the obvious reasons why we do things the way we do
currently, and why I don't think they'll change (without a heap of good
reason and cash from somewhere).
Kelly O'Hair wrote:
> What Phil says... ;^)
> Zeroing in on VS2010 will remove many complex situations in the builds.
> On May 19, 2010, at 9:42 AM, Phil Race wrote:
>> On 5/19/2010 8:38 AM, Pete Brunet wrote:
>>> >no time will be spent on VS2005 or VS2008
>>> Thanks Kelly, I'd like to understand why they won't be supported.
>> 1. We won't be using them at all internally so we will have no idea
>> if they work.
>> Folks will complain if we say they are supported but don't work.
>> We have
>> absolutely zero cycles to even investigate this.
>> 2. We we will be updating to the Windows 7 SDK to get access to
>> newer windows features. Since the VS2010 compilers include a
>> Windows 7 SDK
>> it makes things a whole lot cleaner. One install that supports 32
>> and 64 bit.
>> To support VS2005 at that point would require a mix of the SDK and the
>> compiler. More complexity. Especially tricky for 64 bit where
>> the compiler we've always used is the one from the April 2005 SDK.
>> 3. 2008 requires uses of side-by-side assemblies for MSVCR90.DLL
>> Whilst that has some benefits for MS, its a real pain for any one
>> trying to
>> create their own installer. So much so that MS changed their mind
>> and went back to MSVCR100.DLL being a regular DLL (phew).
>> So we don't want to deal with that. It might not matter for a
>> "developer build"
>> but its a real problem when you need to go further.
>>> *Pete Brunet*
>>> a11ysoft - Accessibility Architecture and Development
>>> (512) 238-6967 (work), (512) 689-4155 (cell)
>>> Skype: pete.brunet
>>> IM: ptbrunet (AOL, Google), ptbrunet at live.com (MSN)
>>> Ionosphere: WS4G
Java System Support
Santa Clara, CA
More information about the build-dev