is on very large "Pure java" type of application that will not run
under MS's JVM and they are RMI applets and application.
The classes.zip that is shipped with IE4.x , NT 4.0 and 95/98 do not
contain
the java.rmi.* core package which makes it impossible to write pure
java RMI
applications/applets without downloading a patch from MS( its hard
to find on their
web site!!) . Remember all core packages must be included
by all licensee's in their
implementations.
It is clear that MS doesn't want to support RMI because it does not want competition for COM/DCOM.
Cheers
Chris.
dan wrote:
I'm not one to normally defend Microsoft, but their JVM is a "true" JVM.The area that they depart from the Java standard is in their choice to leave out
support for JNI (Java Native Interface). The reason they chose to do this is that JNI
specifies that Java objects can be moved around in memory, at the whim of the JVM.
This requires that java memory accesses from native code first explicitly request the
value of the variable from the JVM, rather than simply checking the value pointed to
by a pointer (after all, the object may have moved after the native pointer was set).Pure Java code that works other JVMs will work with Microsoft's. Pure Java code that
works on Microsoft's JVM will work on other JVMs.Why did Microsoft do this? Because they were trying to optimize the performance of
WFC calls (their Java interface to MFC). MFC is, of course, native code. If WFC
required memory copies for every access to Java memory, the performance of WFC would
suck. So Microsoft chose not to implement JNI.The answer to this, of course, is simply to avoid WFC like the plague. Besides, WFC
is a really lousy UI.However, Microsoft's JVM is actually pretty decent. In the same way that I get upset
when I hear FUD from Microsoft, I also get upset when I hear FUD directed *to*
Microsoft.Oh, and for the record, their security model is also different than Sun's. But, then
again, so is Netscape's. This isn't too bad, though. It simply means that you need
to do a little more work in JavaScript if using signed applets.-dan
[EMAIL PROTECTED] (home)
[EMAIL PROTECTED] (work)"Matola, Tod" wrote:
> I agree it is good to see (yeah Linux), but it is also a strange comparison.
>
> But my point was, is Micro$oft's sdk really a TRUE JVM? Didn't they buy performace
> at the cost of portablity? Don't they play funny games with the low level calls
> that get close to the OS?
>
> I have no first hand knowledge, but I question: is a High Performance compiler
> that different from a vendor that doesn't follow the standard and regularly adjust
> the OS to make an application perform (have you ever notice what DLL's get loaded
> in the system directory during an install).
>
> Just my $.02.....
>
> Cheers Tod...
>
> Bryce McKinlay wrote:
>
> > Although this is good to see, it is hardly fair to compare a native code
> > compiler (a commercial one, at that) against a true JVM (which in Microsoft's
> > case was only slightly slower)
> >
> > regards
> >
> > [ bryce ]
> >
> > Mario Camou wrote:
> >
> > > Hi all,
> > >
> > > Check this out (I'm not including the full text in the interest of conserving
> > > bandwidth):
> > >
> > > http://www.internetworld.com/print/current/webdev/19981123-java.html
> > >
> > > Way to go!
