Export (0) Print
Expand All

Visual J# 64-bit Development

Visual Studio 2005

Microsoft Visual J# 2.0 Redistributable Package – Second Edition enables Visual J# applications to run natively on 64-bit platforms. The packages contain support for a subset of features that shipped in previous 32-bit versions of the Visual J# Redistributable (version 2.0 and earlier). This section discusses the feature set that is enabled for 64-bit editions.

Supported components

Component Description

Class library support

Class library support equivalent to most of the Java Development Kit (JDK) level 1.1.4 packages that were included in Visual J++ 6.0 are enabled to run natively on 64-bit platforms. Some classes which support functionality equivalent to that of JDK level 1.2 (for more information, see Additional Class Library Support) are also enabled for native 64-bit execution using Visual J#.

Visual J# compiler

The Visual J# compiler now supports the /platform option.

MSBuild support

The changes are discussed in detail in the section named MSBuild Support.

WoW support

Apart from support for native 64-bit execution, Windows on Windows (WoW) support is enabled by default for Visual J# applications after you install Microsoft Visual J# 2.0 Redistributable Package – Second Edition on 64-bit platforms (x64 and IA64).

MS Build Support

Microsoft Visual J# 2.0 Redistributable Package – Second Edition has MSBuild support enabled (including cross compilation) from a command prompt. This enables you to build Visual J# project files (.vjsproj) and solution files (.sln) that are created by using Visual Studio 2005 from a command prompt by using MSBuild.

All Visual J# project and solution files that are created by using Visual Studio 2005 use the x86 architecture type. Modify the project and solution files to build them to a different architecture type as specified here:

  • anycpu, x64, or IA64 architecture types if using the 32-bit (or WoW) MSBuild task.

  • x86, x64, IA64 or anycpu type if using the 64-bit MSBuild task.

The reason for this behavior is that the 32-bit or WoW MSBuild task, which is present at %SystemRoot%\Microsoft.Net\Framework\v2.0.50727, by default emits 32-bit (x86) architecture type binaries. The 64-bit MSBuild task, which is present at %SystemRoot%\Microsoft.Net\Framework64\v2.0.50727, by default emits anycpu binaries. This behavior differs from the default behavior that is expected from Visual J# project and solution files that are generated by Visual Studio 2005.

There are two ways to build applications using MSBuild:

  • Build the *.vjsproj files by using the /property:platform=xxx option.

  • Build the *.sln file with the /property:platform=xxx option.

Each method is described in the following procedures.

In the following procedure, xxx specifies the targeted platform type, one of: anycpu, x86, x64 or Itanium.

To build applications for a specific platform architecture type by using MSBuild

  1. Build the *.vjsproj files by using the /property:platform=XXX option.

  2. Add a new PropertyGroup section to the *.vjsproj file that is generated by Visual Studio 2005:

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'YYY|XXX' ">
                  <DebugSymbols>true</DebugSymbols>
                  <DebugType>full </DebugType>
                  <Optimize>false</Optimize>
                  <OutputPath>bin\Debug\</OutputPath>
                  <PlatformTarget>XXX</PlatformTarget>
                  <DefineConstants>DEBUG;TRACE</DefineConstants> 
    </PropertyGroup>  
    

To build applications for a specific platform architecture type by using MSBuild

  1. Build the *.sln files by using the /property:platform=XXX option after you have modified the vsjproj file as described in the previous procedure.

  2. In the GlobalSection(SolutionConfigurationPlatforms) and GlobalSection(ProjectConfigurationPlatforms) sections, add the "configuration | platform" preSolution and postSolution that you have included in your *.vjsproj files. For example, suppose you had added Debug|x64, you would modify your solution file as follows:

    GlobalSection(SolutionConfigurationPlatforms) = preSolution 
                     Debug|x86 = Debug|x86 
                     Release|x86 = Release|x86
                     Debug|x64 = Debug|x64 
    EndGlobalSection 
    GlobalSection(ProjectConfigurationPlatforms) = postSolution 
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.ActiveCfg = Debug|x86 
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.Build.0 = Debug|x86 
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.ActiveCfg = Release|x86 
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.Build.0 = Release|x86
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x64.ActiveCfg = Debug|x64 
                    {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x64.Build.0 = Debug|x64
    EndGlobalSection
    

Because adding new options at the beginning of the .sln file changes the default compile properties of the file, this is not the recommended approach.

If a solution has multiple projects which must be compiled for different platforms, iterate through each Visual J# project and compile them separately instead of compiling them as a single solution file.

NoteNote

Visual Studio does not recognize and open project and solution files that are edited manually. To use Visual Studio 2005 to open and edit project and solution files, it is recommended that you maintain a separate copy of the files for manual editing.

Known Issues

Setup experience for Microsoft Visual J# 2.0 Redistributable-Second Edition Package is not completely localized.

The Setup experience for Microsoft Visual J# 2.0 Redistributable-Second Edition Package is not completely localized. Other than the EN-US and JPN download page, no separate localized download pages are available for the Second Edition of the J# Redistributable. The Setup language is also US-English and JPN, respectively. Parts of the user interface prompts and messages in the Setup user interface (UI) are displayed in US-English when you install the product on non US-EN operating systems.

  • Platforms Affected: x86, x64, IA64

    To resolve this issue

    • No action is needed. The redistributable package is installed and operates on non-US-EN and JPN operating environments.

A synchronized method that has security callouts may not save a return value after control returns to the calling function in an application that is built by using the 64-bit version of the .NET Framework 2.0.

In an application that is built by using the 64-bit version of the Microsoft .NET Framework (version 2.0 or3.0), a synchronized method that has security callouts may not save a return value after control returns to the calling function. This breaks the AWT, Swing and Zip functionality of Visual J# applications on 64-bit platforms.

  • Platforms Affected: x64, IA64

    To resolve this issue

    • Install the software update for the issue. See Knowledge Base article 917882 for additional information.

java.lang.Thread behavior is inconsistent and threads do not start at times.

The behavior of java.lang.Thread is inconsistent and at times the thread does not start.

  • Platforms Affected: IA64

    To resolve this issue

    • Install the software update for the issue. See Knowledge Base article 913469 for additional information.

Values between System.Double.Epsilon (4.94065645841247E-324) and approximately 1/2 Epsilon (2.470328229206232730000E-324) are rounded off to zero instead of Epsilon.

On 64-bit platforms, values between System.Double.Epsilon (4.94065645841247E-324) and approximately 1/2 Epsilon (2.470328229206232730000E-324) are rounded off to zero instead of Epsilon.

  • Platforms Affected: x64, IA64

    To resolve this issue

    • Change the application code-base to suite the above behavior

64-bit Visual J# applications that reference v1.1 Visual J# binaries (compiled with v1.1 Visual J# compiler) crash.

Applications that are built with the 64-bit Visual J# compiler (targeting anycpu or IA64 platform type) that are executed on a 64-bit Itanium platform crash if an assembly compiled with version 1.1 of the Visual J# compiler is passed as reference.

  • Platforms Affected: IA64

    To resolve this issue

    • Build the application as 32-bit platform specific by using the /platform:x86 option on the 64-bit Visual J# compiler and execute them in WoW mode on Itanium architecture

java.util.GregorianCalendar.add method returns wrong value when one month is added to a date like Jan 31st 2004.

The java.util.GregorianCalendar.add method returns a wrong value when one month is added to a date like January 31, 2004. The date is moved to March 2, 2004 instead of February 29, 2004.

Applications by default continue to use java.util.GregorianCalendar.add in a similar way as with previous releases.

  • Platforms Affected: x86, x64, IA64

    To resolve this issue

    • Use the setMonthJustified() method added to the com.ms.vjsharp.util.GregorianCalendarHelper class. Calling this method enables the modified behavior for the GregorianCalendar class in the appdomain.

See Also

Show:
© 2014 Microsoft