Why MS JVM?

R

Raymond DeCampo

As I'm sure you've noticed, there are still people posting asking how to
get their Java programs compiled to work on MS JVM. My question is why
do people want this? If it is for applets, why not use the Sun java
plug-in? By using HTMLConverter or <jsp:plugin>, HTML code is generated
that downloads and installs the plug-in if it does not exist. Are there
other reasons I am not aware of?

Ray
 
M

Mickey Segal

Raymond DeCampo said:
As I'm sure you've noticed, there are still people posting asking how to
get their Java programs compiled to work on MS JVM. My question is why do
people want this? If it is for applets, why not use the Sun java plug-in?
By using HTMLConverter or <jsp:plugin>, HTML code is generated that
downloads and installs the plug-in if it does not exist. Are there other
reasons I am not aware of?

1. The MS JVM runs pure Java 1.1 programs with far better GIU speed than
the Sun JVM and with better stability.
2. Some managed computing environments do not allow the users to install a
different JVM such as that from Sun.
3. A small number of programmers may be stuck with MS-specific J++ code not
already ported to pure Java or to .NET.

When we give do demos using our own computers we always use the MS JVM
because of #1. When we use other people's computers we often use the MS JVM
because of #2. We had the sense to avoid ever getting into #3 in the first
place.
 
L

Leon

Mickey Segal said:
1. The MS JVM runs pure Java 1.1 programs with far better GIU speed than the
Sun JVM and with better stability.
2. Some managed computing environments do not allow the users to install a
different JVM such as that from Sun.
3. A small number of programmers may be stuck with MS-specific J++ code not
already ported to pure Java or to .NET.

When we give do demos using our own computers we always use the MS JVM because
of #1. When we use other people's computers we often use the MS JVM because
of #2. We had the sense to avoid ever getting into #3 in the first place.

Were you ever confronted with multi platform issues?

Greetings, Leon.
 
T

Tim Tyler

Raymond DeCampo said:
As I'm sure you've noticed, there are still people posting asking how to
get their Java programs compiled to work on MS JVM. My question is why
do people want this? If it is for applets, why not use the Sun java
plug-in?

Because all your clients would have to use the Sun Java plug-in too.

Not all of them will have that on their machine, and not all of them
will have the authority to install third-party sofware on their machine.
 
R

Raymond DeCampo

Tim said:
Because all your clients would have to use the Sun Java plug-in too.

Not all of them will have that on their machine, and not all of them
will have the authority to install third-party sofware on their machine.

Given the lack of support for MS Java and the fact that it is not
present on all versions of Windows (IIRC, there was a window where MS
did not ship it), wouldn't it make more sense to use another plug-in
technology for these cases? Presumably Flash is out because it might
not be installed, what about ActiveX?

Ray
 
T

Tim Tyler

Raymond DeCampo said:
Given the lack of support for MS Java and the fact that it is not
present on all versions of Windows (IIRC, there was a window where MS
did not ship it), wouldn't it make more sense to use another plug-in
technology for these cases? Presumably Flash is out because it might
not be installed, what about ActiveX?

Active X is a trust-or-reject technology.

As such it is not much use on the internet.
 
M

Mickey Segal

Leon said:
Were you ever confronted with multi platform issues?

Since we kept to pure Java 1.1 our applets can run on both the MS JVM and
the Sun JVM. The main multi-platform issues have been with the Macintosh
JVM, as chronicled at www.segal.org/macjavabugs/, but with the release of
Mac OS 10.4, almost all of those are now fixed.
 
R

Raymond DeCampo

Tim said:
Active X is a trust-or-reject technology.

As such it is not much use on the internet.

Hmm, based on your earlier assumption that the users could not install
applications, I assumed we were talking about a controlled environment,
like a corporate intranet. On an intranet, it is safer to trust code,
as it is being served by the Company.

I suppose you could be concerned about internet cafes and kiosks,
although, I would imagine that the good ones already have every plug-in
under the sun installed.

Ray
 
T

Tim Tyler

Raymond DeCampo said:
Tim said:
Active X is a trust-or-reject technology.

As such it is not much use on the internet.

Hmm, based on your earlier assumption that the users could not install
applications, I assumed we were talking about a controlled environment,
like a corporate intranet. [...]

*Many* companies offer access to internet services such as Google. Some
need access for work. Others do so to help hang on to their employees.
 
R

Raymond DeCampo

Tim said:
Raymond DeCampo said:
Tim said:
Raymond DeCampo <[email protected]> wrote or quoted:
Given the lack of support for MS Java and the fact that it is not
present on all versions of Windows (IIRC, there was a window where MS
did not ship it), wouldn't it make more sense to use another plug-in
technology for these cases? Presumably Flash is out because it might
not be installed, what about ActiveX?

Active X is a trust-or-reject technology.

As such it is not much use on the internet.

Hmm, based on your earlier assumption that the users could not install
applications, I assumed we were talking about a controlled environment,
like a corporate intranet. [...]


*Many* companies offer access to internet services such as Google. Some
need access for work. Others do so to help hang on to their employees.

Right. This is not really in contradiction with my assumption you
quoted. However, the details are not really relevant and are probably
uninteresting.

So I am gathering that people are using MS JVM for public websites ,
presumably for a commercial purpose, where a user that cannot access the
site represents a lost sale.

I have a few more questions, if you do not mind. First, I am curious if
you (or others) have worked on such a project. Second, I am curious as
to the nature of the applets.

Thank you,
Ray
 
T

Tim Tyler

Raymond DeCampo said:
I have a few more questions, if you do not mind. First, I am curious if
you (or others) have worked on such a project. Second, I am curious as
to the nature of the applets.

Many of my programs run under Java 1.1.

I want to be able to do things like run on embedded devices, and Kaffe -
and I want to be able to migrate my code away from Java - as soon as that
becomes practical.
 
R

Raymond DeCampo

Tim said:
Many of my programs run under Java 1.1.

I want to be able to do things like run on embedded devices, and Kaffe -
and I want to be able to migrate my code away from Java - as soon as that
becomes practical.

I do not understand how having the code run under Java 1.1 abets the
goal of migrating the code away from Java as soon as practical.

Thanks,
Ray
 
T

Tim Tyler

Raymond DeCampo said:
Tim Tyler wrote:

I do not understand how having the code run under Java 1.1 abets the
goal of migrating the code away from Java as soon as practical.

Look at one of the existing migration paths:

http://msdn.microsoft.com/vjsharp/jump/default.aspx

No Java 2 support.

Probably the main problem with supporting Java 2 in this context is
that there's mountains of copyrighted, proprietary Sun code, which would
need reverse engineering if one was moving away from Sun. By contrast,
the Java 1.1 platform is relatively small - and has been mostly
reverse-engineered already.

I plan to migrate in two steps: first replacing Java the language - and
only at a later date replacing the VM - if that proves necessary. I'm
not /too/ worried about portability while taking the first step - since
I'm prepared to discard 90% of my existing codebase while making this
step - but I am concerned about portability while making the second step.
 
R

Raymond DeCampo

Tim said:
Look at one of the existing migration paths:

http://msdn.microsoft.com/vjsharp/jump/default.aspx

No Java 2 support.

Probably the main problem with supporting Java 2 in this context is
that there's mountains of copyrighted, proprietary Sun code, which would
need reverse engineering if one was moving away from Sun. By contrast,
the Java 1.1 platform is relatively small - and has been mostly
reverse-engineered already.

I plan to migrate in two steps: first replacing Java the language - and
only at a later date replacing the VM - if that proves necessary. I'm
not /too/ worried about portability while taking the first step - since
I'm prepared to discard 90% of my existing codebase while making this
step - but I am concerned about portability while making the second step.

This leaves me even more puzzled at what you hope to accomplish to be
honest. Perhaps I should have asked a different question as well. What
currently makes it impractical for you to move away from Java?

Also, if you are willing to discard 90% of your codebase, what is it
that prevents you from discarding that last 10% and doing a
straightforward conversion?

Finally, a question concerning .NET that is not really directed
specifically at you. I thought that one of the benefits of .NET was
that the runtime is based on the CLR and that it would be possible to
compile any language into the CLR, Java included. Is this not true, or
perhaps no-one has attempted it with Java?

Thanks,
Ray
 
T

Tim Tyler

Raymond DeCampo said:
Tim said:
Raymond DeCampo said:
Tim Tyler wrote:
[...] I want to be able to migrate my code away from Java - as soon
as that becomes practical.

I do not understand how having the code run under Java 1.1 abets the
goal of migrating the code away from Java as soon as practical.

Look at one of the existing migration paths:

http://msdn.microsoft.com/vjsharp/jump/default.aspx

No Java 2 support.

Probably the main problem with supporting Java 2 in this context is
that there's mountains of copyrighted, proprietary Sun code, which would
need reverse engineering if one was moving away from Sun. By contrast,
the Java 1.1 platform is relatively small - and has been mostly
reverse-engineered already.

I plan to migrate in two steps: first replacing Java the language - and
only at a later date replacing the VM - if that proves necessary. I'm
not /too/ worried about portability while taking the first step - since
I'm prepared to discard 90% of my existing codebase while making this
step - but I am concerned about portability while making the second step.

This leaves me even more puzzled at what you hope to accomplish to be
honest.

No more dreadful Java source code - of course! I'm sick of Java's static,
primitive and class bits, and it's huge complexity - and don't see why I
should suffer from its range of C++ hangovers a moment longer. The Java
language was well out of date at its launch in 1995 - and hasn't improved
much with time.
Perhaps I should have asked a different question as well. What
currently makes it impractical for you to move away from Java?

The target language doesn't exist yet.
Also, if you are willing to discard 90% of your codebase, what is it
that prevents you from discarding that last 10% and doing a
straightforward conversion?

That's a possibility. I would /like/ to be able to port code across
between the environments though - so the environment retains a link
to the existing pool of Java source code. I figure the chances of
losing code in the transfer are reduced if I don't build in
dependencies to loads of complex, proprietary Sun code.
Finally, a question concerning .NET that is not really directed
specifically at you. I thought that one of the benefits of .NET was
that the runtime is based on the CLR and that it would be possible to
compile any language into the CLR, Java included. Is this not true, or
perhaps no-one has attempted it with Java?

There's http://www.ikvm.net/

No use to me - step one for me is replacing the Java language.
 
A

Andrew Thompson

As I'm sure you've noticed, there are still people posting asking how to
get their Java programs compiled to work on MS JVM. My question is why
do people want this?

I'll give an answer somewhat different from that of
either Mickey or Tim..

Take this applet as a 'for instance'..

<sscce>
public class HelloWorldApplet
extends java.applet.Applet {

public void init() {
add( new java.awt.Label("Hello World!") );
}
}
</sscce>

You would expect (hope) that this applet works just fine
in 1.1 - it uses nothing that was not available in 1.1.

One of the few practical ways for most people to *test* that
is to point one of the (dwindling number of) Internet Explorer
browsers armed with the MSVM. It is true that you can still
get versions of NN 4.78 with Symantec's Java 1.1.5, but the
MSVM is even earlier, at 1.1.4.

So the MSVM is the one of the best ways to test *1.1* compatibility,

1) I argue the question is in part, not 'making applets for the MSVM'
so much as 'making applets compatible with 1.1'.

Now consider this source..
<sscce>
import java.awt.*;

public class ImageApplet
extends java.applet.Applet {

Image image;

public void init() {
java.net.URL imageURL =
this.getClass().getResource("bird.gif");
image = getImage(imageURL);

// do lots of calculations
// and component initialisation..
}

public void paint(Graphics g) {
g.drawImage(image,0,0,null);
}
}
</sscce>

Should *this* code work in 1.1?

Yes and no. It is fragile for the fact that the image
may not be loaded by the time of the first 'paint'.

I was dealing with an applet that worked in every VM
this side of the MSVM (including the NN Symantec 1.1.5 VM),
yet broke in the MSVM because the MSVM was able to get
through the initialisation faster than the image took to load.

So - again there are good reason for testing applets in
the MSVM specifically - there are some things it does
better, and faster than any other VM that I know of.
..If it is for applets, why not use the Sun java
plug-in?

As both Tim and Mickey have touched on, if it is a
business critical applet, the tendency is to make
it compatible with as many comers as possible, which
leans heavily towards 1.1/AWT.
..By using HTMLConverter

AaaaaAAAAArrgh! That /abomination/?!?

Only recently have Sun themselves seen the idiocy of
the 'All browsers' template for the HTMLConverter
that was churning out hundreds (thousands) of web
pages using Sun's own incredibly poor excuse for
Javascript (Browser sniffing JS - the worst kind).

Now they recommend the template that simply writes
that same text as HTML directly into the page, and
triggers HTML validation errors because of the use
of the non W3C said:
..or <jsp:plugin>, HTML code is generated
that downloads and installs the plug-in if it does not exist. Are there
other reasons I am not aware of?

Java major versioning can be done for applets
using the JavaVersionApplet[1] more complex
deployment and versioning can be done with
JWS (for which the <applet> element does just fine).

[1] <http://www.physci.org/codes/jre.jsp>

Having said all that, I should add that
- My perception is skewed because I write so many
applets that *must* work with 1.1 to be of use
(mostly support applets for other applets)
- My perception is further skewed because I deal with
so many people new to Java, and developing applets, who
have yet to start using Swing.
- I feel that the number of people actually using 1.1,
who are willing to part with cash over the internet,
is miniscule, and that it is no longer worth jumping
through hoops to accomodate those who will not, or
cannot update.
 
R

Raymond DeCampo

Tim said:
Raymond DeCampo said:
Tim said:
Tim Tyler wrote:
[...] I want to be able to migrate my code away from Java - as soon
as that becomes practical.

I do not understand how having the code run under Java 1.1 abets the
goal of migrating the code away from Java as soon as practical.

Look at one of the existing migration paths:

http://msdn.microsoft.com/vjsharp/jump/default.aspx

No Java 2 support.

Probably the main problem with supporting Java 2 in this context is
that there's mountains of copyrighted, proprietary Sun code, which would
need reverse engineering if one was moving away from Sun. By contrast,
the Java 1.1 platform is relatively small - and has been mostly
reverse-engineered already.

I plan to migrate in two steps: first replacing Java the language - and
only at a later date replacing the VM - if that proves necessary. I'm
not /too/ worried about portability while taking the first step - since
I'm prepared to discard 90% of my existing codebase while making this
step - but I am concerned about portability while making the second step.

This leaves me even more puzzled at what you hope to accomplish to be
honest.


No more dreadful Java source code - of course! I'm sick of Java's static,
primitive and class bits, and it's huge complexity - and don't see why I
should suffer from its range of C++ hangovers a moment longer. The Java
language was well out of date at its launch in 1995 - and hasn't improved
much with time.

Perhaps I should have asked a different question as well. What
currently makes it impractical for you to move away from Java?


The target language doesn't exist yet.

Also, if you are willing to discard 90% of your codebase, what is it
that prevents you from discarding that last 10% and doing a
straightforward conversion?


That's a possibility. I would /like/ to be able to port code across
between the environments though - so the environment retains a link
to the existing pool of Java source code. I figure the chances of
losing code in the transfer are reduced if I don't build in
dependencies to loads of complex, proprietary Sun code.

Finally, a question concerning .NET that is not really directed
specifically at you. I thought that one of the benefits of .NET was
that the runtime is based on the CLR and that it would be possible to
compile any language into the CLR, Java included. Is this not true, or
perhaps no-one has attempted it with Java?


There's http://www.ikvm.net/

No use to me - step one for me is replacing the Java language.

OK, I think I understand where you are coming from now. Thanks for your
patience in explaining it to me.

At the risk of veering completely off-topic, what features are you
looking for in the new language?

Thanks,
Ray
 
J

Joan

Raymond DeCampo said:
As I'm sure you've noticed, there are still people posting asking how to
get their Java programs compiled to work on MS JVM. My question is why
do people want this? If it is for applets, why not use the Sun java
plug-in? By using HTMLConverter or <jsp:plugin>, HTML code is generated
that downloads and installs the plug-in if it does not exist. Are there
other reasons I am not aware of?

Maybe this has come up before (and I'm to lazy to check), but I think there
are a lot of young people
(elementary school, middle school) that have access to a computer but don't
know too much about how to set up anything if it doesn't come already
pre-loaded when their parents or school buys the computer. Dell seems
to be popular because it runs out of the box and it's cheap. Sun java didn't
come pre-loaded when I got mine though.
 
R

Raymond DeCampo

Joan said:
Maybe this has come up before (and I'm to lazy to check), but I think there
are a lot of young people
(elementary school, middle school) that have access to a computer but don't
know too much about how to set up anything if it doesn't come already
pre-loaded when their parents or school buys the computer. Dell seems
to be popular because it runs out of the box and it's cheap. Sun java didn't
come pre-loaded when I got mine though.

I think the problem there is trying to convince the kiddies not to
install everything they come across, rather than the opposite. When
using the code from HTMLConverter or <jsp:plugin>, the user is walked
through a pretty easy install of the plug-in.

Ray
 
T

Tim Tyler

Raymond DeCampo said:
At the risk of veering completely off-topic, what features are you
looking for in the new language?

Very short short-list:

In the public domain;
Can run on top of the JVM;
Simple, small and easy to learn;
Prototype based - see http://en.wikipedia.org/wiki/Prototype_based
Message based - with support for sending every message asynchronously;
Contracts - implemented using assertions;
Full closures - i.e. every block of code is an object;
Flexible messages - i.e. comma separated lists and keyword arguments;
Straight-forwards syntax - more like Python than Ruby, Smalltalk or Io;

I want a language that's /very/ dynamic - but with the
possibility of enforcing a more static approach when
that's appropriate using contracts.

Java's pretty hopeless for debugging, scripting and RAD.

I want a language that is /much/ better in those areas -
but can still be used to write library code and secure code
where every aspect of the interface is pinned down in
considerable detail.

Traditionally contracts have been used with rather static
languages. However, dynamic languages and contracts seems
like a no-brainer to me - contracts make up for one of the
deficiencies of dynamic languages *far* better than the
introduction of compulsory type checking does.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top