Article ID: 169173 - View products that this article applies to.
This article was previously published under Q169173
This article covers some of the most frequently asked questions (FAQ) about the Microsoft Visual J++ product. For other Java related FAQs, visit the following Microsoft Web site and search for "JAVA" and "FAQ":
This section is organized into the following sub-sections:
1. General Questions[1.01] How do I report Visual J++ bugs?
We appreciate bug reports and product feedback. To report bugs or give us constructive feedback on Visual J++ you can call the Visual J++ technical support line to report bugs. Please note that phone calls will initially be charged against you as a support incident, but if we determine that it is a bug, the charge will be canceled.
[1.03] Why does the MS-DOS Command Prompt window disappear after my Java application terminates when executed from the Developer Studio IDE?
"Close on exit" is the default behavior of an MS-DOS Command window. To have your Java application work around this, you have to declare a "normal exception" of java.io.IOException and add an input statement as the last statement in your Java application:
This code causes the Command window to remain until you press the enter key. This is a useful way to cause the Command window to remain so that you can see output during the development of your Java application.
[1.04] How do I view the error output from my Java applets in Internet Explorer?
The file Windows\Java\Javalog.txt contains information about the last Applet loaded in Internet Explorer. All of the System.out messages and exception information from the last executed applet is stored in the Javalog.txt file when Java Logging is enabled in Internet Explorer. Use the following steps to enable Java Logging:
Navigator requires that the applet class be declared "public." The code sample supplied on the Getting Started card does not declare the applet class as public and will not load in the Netscape browser. Add public to the declaration, and it should run fine in Navigator. The Microsoft virtual machine (Microsoft VM) version that shipped with Visual J++ does not enforce the requirement that the applet class be public. For more information about the Microsoft VM, visit the following Microsoft Web site:
The SDK Developer Classes came from the latest Microsoft SDK for Java and are not compatible with older Microsoft VMs, such as the one shipped with Visual J++ 1.0. You can fix this problem by updating your Microsoft VM. The Microsoft VM and SDK are updated with bug fixes and new functionality more frequently than the Visual J++ Development Environment.
[1.07] Does Visual J++ 1.1 support the new Sun JDK 1.1 language and VM features?
No, the Microsoft VM and class libraries in Visual J++ 1.1 are synched with the Microsoft SDK for Java version 1.5 (Sun SDK 1.02). However, the Microsoft VM and class libraries with the Microsoft SDK 2.0x preview release for Java do contain Sun JDK 1.1 support. The SDK for Java 2.0x preview can be installed and used with Visual J++ 1.1 (see the SDK 2.0x for Java release notes). Because the SDK 2.0 preview is beta code and has not been fully tested with Visual J++ 1.1, Microsoft Technical Support cannot provide you with standard support if you install the SDK 2.0 preview with Visual J++ 1.1.
[1.08] I'm using the DialogLayout layout manager created by the Visual J++ Resource Wizard in my Frame class. In the debugger I get an unhandled Java Exception: "Unhandled exception in java.util.hashtable." Running the application outside of the debugger causes jview to hang.
The DialogLayout class generated by the Resource Wizard tries to manipulate the default Font of the parent Container class. The Frame class does not have a default Font created for it so this causes the unhandled exception. You can work around this by creating a Font for the Frame class:
2. Installation Questions[2.00] The Visual J++ 1.0 Setup program doesn't run, do I have a bad CD- ROM?
The Visual J++ CD-ROM was created using the Joliet file system to enable the use of long file names and file extensions greater than three characters (.java and .html). Older DOS 16-bit "real mode" CD-ROM device drivers cannot read the non-8.3 portions of the CD; this requires a 32-bit protected mode CD- ROM device driver.
The symptoms you will see if you try and install Visual J++ on a system with real mode drivers include the following:
For more information, see the following articles in the Microsoft Knowledge Base:
PRB: Visual J++ Requires a Protected Mode CD-ROM157877
Joliet Specification for CD-ROM 125630[2.01] How can I tell Visual J++ 1.0 setup to not install Internet Explorer?
In certain situations, it can be helpful to install Visual J++ without the Internet Explorer installation portion of setup being run. For instance, if you have downloaded the latest version of Internet Explorer and then need to reinstall Visual J++, you do not want the older version of Internet Explorer to be installed over your current version (Visual J++ 1.0 setup does not check the build number of Internet Explorer). You can run the Visual J++ setup from the \MsDev directory on the CD with the /NOVM option ("D:\msdev\setup /novm") to tell Visual J++ to skip the Internet Explorer setup portion of Visual J++ setup.
The Visual J++ 1.1 setup checks the build version of the Internet Explorer and should not try to update a later version.
[2.02] I've installed Visual J++ 1.0 and now some of my other Developer Studio add-ins behave differently.
Visual J++ 1.0 uses version 4.2 of the Developer Studio shell. If you have an earlier version of the Developer Studio shell the Visual J++ 1.0 setup program updates your current IDE components to the Developer Studio 4.2 versions. This can cause some behavior of other Developer Studio add-ins to change.
For instance, Visual C++ 4.0 or 4.1 will have some shared components updated to the Visual C++ 4.2 versions. The compiler will be updated to the 4.2 version and this can cause some changes in behavior. C++ Code that compiled previously could now give warnings or errors due to the fact that the C++ compiler has significantly changed due to changes in the ANSI C++ standards. More information can be found in the Knowledge Base article:
157618[2.03] I've installed Visual J++ over the Visual C++ 4.0 Standard Edition and now things don't work correctly.
(http://support.microsoft.com/kb/157618/EN-US/ )Installing VJ++ Upgrades Certain VC++ Components
The Visual C++ 4.0 Standard Edition was not designed to be upgradeable in the same manner as the Visual C++ 4.x Professional Editions. Installing Visual J++ into the same directory as Visual C++ 4.0 Standard may cause undefined behavior as the Visual J++ setup updates various Developer Studio 4.0 components to the 4.2 versions. To use Visual C++ 4.0 standard and Visual J++ together on the same machine, you will need to install them into separate installation directories. (Note the default behavior is to install Visual J++ into the same \MSDEV directory as Visual C++).
[2.04] When I try to start Visual J++ 1.1, I get an error saying "Cannot load package DEVDTG" because the internal version number does not match the Developer Studio shell version number. The error message suggests reinstalling the Developer Studio, which I did, but that didn't fix the problem.
This is caused by installing Visual J++ 1.1 (or any other Visual Studio 97 retail product) in the same directory with a previous beta version of the Developer Studio 97 IDE. The IDE shell checks internal version numbers of the package files (.PKG files) that it loads at startup. If the version number of the PKG files do not match the Developer Studio IDE, the IDE will not load the package.
The only publicly available Beta of the Developer Studio 97 was installed with the Site Builder download of Visual InterDev. You should uninstall the Visual InterDev Beta before installing Visual J++ 1.1 (trial or retail versions). For more information about how to remove the Visual InterDev Beta, visit the following Microsoft Web site:
http://msdn2.microsoft.com/en-us/library/ms950412.aspxThe release version of Visual InterDev has the proper internal version numbers and coexists with Visual J++ 1.1.
[2.05] I can't install the Visual J++ 1.1 Trial Edition. After the files are extracted from Vjtrial.exe I get a DOS box with many "Bad Command or File Name" errors.
This can happen on Windows 95 machines if the DOS utility Move.exe is not on the system path. The Trial install uses the DOS command MOVE to move the installation files from the temporary extraction directory to a temporary installation tree before running the Visual J++ installation program. To fix this problem, make sure that Move.exe exists in the \Windows\Command directory and that the command directory is on the system path.
[2.06] I'm trying to install the Visual J++ 1.1 Trial Edition multi-file download and I can't find the GlueVJ.bat file that's mentioned on the download Web page.
GlueVJ.bat is extracted when you "run" the VJTrial4.exe download file. You need to run the four downloaded .exe files (VJTrial1-VJTrial4), which create the four pieces of VJTrial.exe as well as GlueVJ.bat. Make sure that all of these files are in the same directory, then run GlueVJ.bat to merge the pieces and create VJTrial.exe.
3. Compiler Questions[3.00] There are no compiler questions at this time.
4. Debugger Questions[4.00] I'm not able to restart the Visual J++ 1.0 debugger. After debugging my application once, the debugger will not restart a second time unless I exit and restart the Developer Studio.
This is a bug that can be caused by installing the Visual C++ 4.2 Enterprise Edition in the same directory as Visual J++ 1.0. This bug can be worked around by renaming the VC++ 4.2 Enterprise package DLL file, Msvcent.pkg, to some other file name before starting the Developer Studio while you are doing Visual J++ debugging. Note that this disables the VC++ Enterprise package and you must rename to file back to Msvcent.pkg and restart the Developer Studio to re-enable the Enterprise package.
[4.01] I'm having trouble setting breakpoints in my Java code. Breakpoints set from the editor before starting the debugger always seem to be disabled.
For performance reasons, the debugger pre-loads only the main class of your project. The main class is either the class with the same name as the project or the class you specify in the 'Build Menu-Settings-Debug tab- General Category-Class for debugging/executing'. If you set breakpoints in other classes via the editor before the classes are loaded, the breakpoints are disabled. You can force the pre-loading of secondary classes in two ways. One method is to list the classes you wish to pre-load in the 'Build Menu-Settings-Debug tab-Additional classes Category'. The second method is to right-click a method in the ClassView pane of the Project Workspace and select Set Breakpoint from the Shortcut menu. This second method causes a break when program execution enters the method.
[4.02] I'm not able to view a variable in the Debugger Watch window.
The following scoping problem is a known bug in the Visual J++ 1.0 debugger. The resolution is to change the second instance of the variable to a different variable name, or to create the variable at method scope:
[4.03] I can't seem to get debugging to work with Visual J++ and Internet Explorer 4.0.
Internet Explorer 4.0x (IE4) can be installed to run in one of two modes: The mode where IE4 runs integrated with the desktop and in a mode where it runs like IE3 as a standalone browser. VJ++ needs to "tweak" the environment of the browser before spawning it for debugging to work. We can't do this in the IE4 integrated desktop mode. Try uninstalling IE4 and reinstalling in the standalone mode for VJ to work properly. Please see the IE4 release notes for more information
However, beginning with Internet Explorer 4.01 there is a switch in the Advanced tab of the View/Internet Options dialog box that will allow you to start a new instance of the browser each time you run from within Visual J++. This switch is called "Browse in a new process." This will allow you to debug even if the browser is installed in the integrated desktop mode.
5. ActiveX/COM Integration Questions[5.00] Do Visual J++ applets or applications support ActiveX control containment?
Currently, the Microsoft Java class libraries do not support the containment of ActiveX GUI controls. You can't place an ActiveX control that has a user interface or that sources or sinks events directly onto an applet without implementing all of the ActiveX control containment and eventing interfaces yourself. To be clear, you can use ActiveX automation servers from Java and you can write ActiveX automation servers in Java utilizing the Microsoft virtual machine's ability to expose Java classes as ActiveX objects. You can also have ActiveX controls and Java applets on the same Web page and have them interact (see the OLEControls sample in Visual J++).
[5.01] Why do I get an exception when I try and use an OLE Control (a.k.a. OCX) in my Java code?
This can be caused by trying to "new" an OLE Control (OCX) from within your Java code and then calling one of the methods of the OLE Control. The Microsoft Java class libraries and Microsoft virtual machines do not currently support the containment of OLE Controls directly in Java applets. An OLE Control requires that numerous interfaces and methods be supported in the "containing" application. This support is currently not implemented. Therefore, your OLE Control is not fully created and returns an OLE error when any method is called. This error gets expressed in Java as a thrown exception. ActiveX automation servers can be used from within your Java code, and it is possible to write an OLE Control so that it can be created as a simple automation server that does not require full container support. More information on this can be found in the Microsoft Knowledge Base article: 146120
(http://support.microsoft.com/kb/146120/EN-US/ )- How to Use an OLE Control as an Automation Server.
[5.02] I am trying to use an ActiveX automation object written in Java (the COMCallingJava sample) from Visual Basic but I keep getting "Out of Memory" errors.
This is normally caused by the Operating System not being able to find the Java class file that implements the ActiveX automation server. The class file that implements the Server must be copied to the Java classpath (for instance: \Windows\Java\Lib) for OLE object creation to work properly for Java class files. A common example of this is the COMCallingJava sample application supplied with VJ++. It will work fine when the sample is first built because the CEuclid.class is in the local directory (which the Developer Studio adds to the classpath before running Internet Explorer). Trying to run the VBDriver Visual Basic sample code supplied in the VBDriver project subdirectory will then fail with the "Out of Memory" error. This can be remedied by copying CEuclid.class to the \Windows\Java\Lib directory. You can also set the output directory in the project build options so that the class file is automatically built in the appropriate classpath directory.
[5.03] My Java COM object that I'm calling from an ASP script is not getting updated when I compile a new version and copy it to my Server. The old version gets run unless I reboot the Server, which causes the new version to load the next time I download the ASP script. Stopping and restarting the WWW service does not seem to help.
There is a bug in the Active Server Pages where it is not releasing the Java COM object after it exits. You can try shutting down the WWW, GOPHER, and FTP services from the Internet Service Manager, which seems to work for some people. Just shutting down the WWW service is not enough; you must shut down all three services. If this doesn't work, try killing the Inetinfo.exe process, which implements WWW, GOPHER, and FTP. This cannot be done from the Task Manager; you will need to use pview.exe, which can be found in the Win32 SDK and Visual C++. Another way to shut down Inetinfo.exe is to attach the VC++ debugger to the process by right clicking on Inetinfo.exe in the Task Manager (assuming the VC++ is installed on the Server machine), and selecting Debug from the Shortcut menu. You can then use the VC++ debug to exit the process.
[5.04] I keep getting the Run time error "java.lang.ClassFormatError" on certain JAVATLB or the Java Type Library Wizard generated classes when using an ActiveX automation server created with Visual C++.
This problem occurs when you add automation methods using the VC++ ClassWizard that take parameters of type PTR. The ClassWizard is not adding [in,out] attributes to the ODL file that it generates. This causes JAVATLB to generate invalid class files when it is run against the type library for the MFC automation server. You can work around the problem by manually modifying the ClassWizard generated ODL file and adding [in, out] attributes to the automation methods which pass PTR parameters:
[5.05] I'm using the com.ms.com.Variant class in my applet and I am getting class not found errors. Other classes in the com.ms.com package can't be found either.
The com.ms.com package is available only to Java applications and "trusted" applets. An applet can be made trusted by packaging it in a digitally signed CAB file. Note that applets run from the Visual J++ Developer Studio are automatically made trusted in order to facilitate program development and debugging.
If you run your applet from Visual J++ Developer Studio with Internet Explorer 4.0x, you may get class not found errors as well. You should check the following:
If you have installed Internet Explorer in the Integrated Desktop mode then you need to have the browser run in a new process each time you run an applet from Visual J++. You can do this buy adding "-new" after the browser (iexplore.exe) in the browser category of the debug tab of the project settings; or if you have Internet Explorer 4.01 and later, you can simply select the check box labeled "Browse in a new process" in the Advanced tab of the Internet options off the View menu of Internet Explorer. Either method forces a new process each time you start Internet Explorer which will make your applet trusted (again) in Visual J++.
With Internet Explorer 4.0x, you may also need to add the code to your applet to assertPermissions(...) in order to have your code run "trusted" from inside Visual J++ Developer Studio.
[5.06] I can't get the ADOJava sample that comes with the OLEDB SDK to work. It hangs when I click Next.
When you create the COM class wrapper files for ADO using JavaTLB, use the /X:m- option to turn off the auto-marshalling of COM parameters.
6. Microsoft VM and SDK Questions[6.00] I've heard about the Microsoft SDK for Java. Do I need the SDK in order to use Visual J++?
Microsoft has released an SDK for Java that is primarily targeted at Java tool and library vendors. The Visual J++ package is a standalone product and does not require the Microsoft SDK for Java or any of the tools supplied with the SDK. The Microsoft SDK for Java does contain several tools that are not included in Visual J++, which may be of interest to Java programmers, such as the tools needed to create the DLL's used by Java native code method calls. For more information about the Microsoft SDK for Java, visit the following Microsoft Web site:
Visual J++ is a full-featured Java development tool. The SDK is a set of freely available resources for Java developers that will work with any Java development tool, including Visual J++. For more information about the SDK for Java, visit the following Microsoft Web site:
Visual J++ does not contain all of the tools necessary to create native code methods. You will need to download the Microsoft SDK for Java to obtain the tools and documentation for writing Java native code methods in C or C++ for the Microsoft VM. You will also need a C development tool, such as VC++, which is capable of creating Windows DLLs. For more information about the SDK for Java, visit the following Microsoft Web site:
[6.03] When I try to open my html file in Internet Explorer 3.02 I get "exception :com.ms.applet.AppletSecurityException : security Couldn't connect to with origin from file".
This is caused by one of the security fixes in the Microsoft VM with Internet Explorer 3.02. Security has been enhanced such that an applet created via a file URL (double-clicking on the .html file) cannot open files in directories other than the one the applet resides in. This can affect the default App Wizard generated applet since it uses an image subdirectory to contain the image files for the spinning globe animation. This does not affect applets loaded through HTTP, or applets run from the Visual J++ Developer Studio.
For support information for Visual J++ and the SDK for Java, visit the following Microsoft Web sites:
Article ID: 169173 - Last Review: June 27, 2007 - Revision: 4.2