Talk:Visual J++

compatibility

I just removed the following from the article as its unclear.

The one major difference was that Visual J++ applications could only run on Microsoft's Virtual Machine.

does this mean that they actually changed the classfile format or (as i suspect) does it just reffer to the fact ms added a new load of libraries? Plugwash 18:28, 5 December 2005 (UTC)

I don't think that statement is even true. The open-source Kaffe VM implemented Microsoft's extensions. See [1]. PuerExMachina 17:45, 1 August 2007 (UTC)

I just modified a bit the text to clarify: Visual J++ was still necessary for the compilation (even with Kaffe), and the development was funded by Microsoft. Hervegirod 18:31, 1 August 2007 (UTC)

flop

May J++ be considered a flop for Microsoft? I don't know any applications running on J++. --Abdull 11:26, 17 December 2005 (UTC)

J++ was killed by lawsuit it didn't ever get the chance to flop naturally. Plugwash 15:02, 17 December 2005 (UTC)

The source of the infamous "Let's move on and steal the Java language" quote from the J++ product manager

This link requires authentication.

Inconsistency

The article initially states that Visual J++ was an implementation of Java. It implies in a subsection that it was just an IDE (which is what I thought). Both of these cannot be correct. Probably needs cleanup/merge from someone who knows for sure. Andrewferrier 17:39, 21 December 2007 (UTC)

Date?

I accessed this article to find out when VJ++ was originally released but I still don't know. Djcowbell (talk) 01:45, 29 February 2008 (UTC)djcowbell

MSJVM

MSJVM redirects here. I have added a disambiguation link to Microsoft Java Virual Machine. Joshua Issac (talk) 19:52, 23 April 2008 (UTC)

Platform incompatibility confusion

The difference between JNI and J/Direct is that J/Direct has another way to call native libraries. They basically do the samt thing but J/Direct was more flexible. J/Direct did not make J++ apps any more platform dependent then suns JNI, nor does it do applications dependent. Using native calls directly in an application is always an ugly hack. Instead this are done in libraries like WFC. Now this library is the reason that J++ was hard to port. It supported native libraries that was only available in Windows. However its not a lot different then libraries like SWT. While there are an implementation of SWT for several platfors, each of them is platform-dependent. As this dependency is within the library this does not make an application, like Azureus, dependent.

The WFC lives on in the .NET Framework and Windows Forms. As the Mono project has shown these libraries does not have to be platform dependent, even if thery are originally intended for a speciific platform. —Preceding unsigned comment added by 85.226.177.6 (talk) 20:04, 1 February 2009 (UTC)

The Java Native Interface is actually used by the Sun and Oracle Java Runtime Environment implementations, and the Java Runtime Environment actually contains platform-dependent JNI code within its implementation. In addition, the Java Native Access (JNA) library, which is implemented on top of JNI, can be used to call native libraries from Java. Jplatts (talk) 22:29, 19 November 2010 (UTC)

J/Direct used a kind of annotation in Java code to specify the win32 functions you accessed. It worked only with Microsoft VM and Windows DLL structure. This is very different from JNI which is platform and VM agnostic. JNA and SWT are not really related because they use JNI under the hood to link to the native libraries they use. And again, JNA and SWT interfaces are platform agnostic too. Mono is not a valid comparison IMO, because Mono developers tried to mimic how .NET worked on other platforms, they had no other way to be able to make it work on Linux. For example, there are no dlls in Linux (the equivalent is so libraries), yet .NET libraries in Mono are still called DLL and have the same format as Windows DLL (PE), which is alien to Linux world. Hervegirod (talk) 11:52, 20 November 2010 (UTC)

This is only half right. There are no DLL's in .Net, the DLL suffix is used for Assemblies (think of this as a compiled Jar file) and the Assembly file format has a PE header for historical reasons (the original .Net implementation leveraged a PE stub to kick off the .Net framework, where as from XP onwards, the OS understands how to load a .Net EXE natively.) Mono were bound by compatibility to mimic the file format, but the file only requires a PE header, no other native code needs to be present. Secondly, P/Invoke, the .Net version of JNI, does almost the exact same thing as the J/Direct did. You define the external library you want to call, calling convention etc, and then it will automatically do the rest for you. JNI in comparison is a lot more involved. It's also worth pointing out that J/Direct and P/Invoke is very similar to the way Delphi maps DLL calls - unsurprising, given Anders Hejsberg's involvement. The fact that Mono uses the exact same P/Invoke syntax is actually pretty amazing. This means that one can write a class using P/Invokes on Windows and sol long as the same library is available on MacOS X and Linux, the same code will work on both through Mono... Memsom (talk) 00:18, 31 August 2012 (UTC)