Microsoft Java almost gone in Vista

[Mickey Segal]

If you upgrade Windows XP to Vista and have the Microsoft VM selected in
Internet Explorer 7 and the Sun JVM also installed, you arrive in Vista with
the Microsoft VM nonfunctional. If you try to enable the Sun JVM from the
Control Panel, Vista doesn't let you do so. However, after uninstalling and
reinstalling Sun Java it is set as the default in IE7. Then, one can
un-select Sun Java and the Microsoft VM works a bit. It will run some
simple applets but hangs on some simple applets such as the one at
www.segal.org/java/just_checkbox/ and on all signed applets I tested.

I haven't tried re-installing the Microsoft VM. If this works, it would be
useful to know, since we still have lots of users of our applets who are
running the Microsoft VM and it would be good to be able to test that
environment without finding an XP computer.

 

[Randolf Richardson]

If you upgrade Windows XP to Vista and have the Microsoft VM selected in
Internet Explorer 7 and the Sun JVM also installed, you arrive in Vista
with the Microsoft VM nonfunctional. If you try to enable the Sun JVM
from the Control Panel, Vista doesn't let you do so. However, after
uninstalling and reinstalling Sun Java it is set as the default in IE7.
Then, one can un-select Sun Java and the Microsoft VM works a bit. It
will run some simple applets but hangs on some simple applets such as
the one at www.segal.org/java/just_checkbox/ and on all signed applets I
tested.

I haven't tried re-installing the Microsoft VM. If this works, it would
be useful to know, since we still have lots of users of our applets who
are running the Microsoft VM and it would be good to be able to test
that environment without finding an XP computer.

Why bother worrying about non-standard stuff? It would probably be
easier to just test for the Microsoft JVM in your applet at the start, and
then tell the users that they need to update Java and direct them to
useful informational web pages like these (because Sun keeps changing the
URI for the download pages; I've had many bookmarks go bad on me because
of this):

Installing Java - Java Glossary
http://www.mindprod.com/jgloss/installingjava.html

JRE: Java Glossary
http://www.mindprod.com/jgloss/jre.html

Roedy Green, by the way, has been keeping his web site up to date since
the very beginning.

 

[Steven J. Sobol]

easier to just test for the Microsoft JVM in your applet at the start, and
then tell the users that they need to update Java and direct them to
useful informational web pages like these (because Sun keeps changing the
URI for the download pages; I've had many bookmarks go bad on me because
of this):

The easiest thing to do is to point the user to java.com. Not
java.sun.com, that's their developer site. java.com is the consumer
site where you can download browser plugins.

 

[nukleus]

Yep, many of those poor developers do not realize
what kind of a battlefield they are participating in.

Microsoft and Sun will fight this battle
on the highest level there is, going up to the level
of Supreme Court, needs be, shelling out gigabux
on lawyers alone.

Because this is the battle for the corporate world
information systems, which is a pretty, pretty fat field
in itself.

So, with just about every single step you have to make
as a developer, you'd be walking on a mine field,
LITERALLY.

And who do you think is going to win this battle?
Any bets?

I can just tell you one thing, by the time their
new "deal" expires, there will be a total devastation,
and, for all practical purpuses, there will be only
one player left in the field, and who do you think
it might be?

Sun?

Anyone wants to bet on it?

In a year or so, what is left of those very concepts
Java is built upon, will be nothing but a laughing stock.

You know why?

Because Microsoft will continue developing their own
version of Java and the ace in their pocket is, first
of all, they control vast majority of the world
software business and operating systems. They have
developed technologies in other languages, operating
systems and development environments that are far
superior to that what Sun has to offer with all its
limited impact on what is happening in the software field.

I can bet you that within a year or two,
you won't even need to bother about all this JVM
stuff cause it'll all be wired into all sorts of
MS architectures and people wouldn't even have
to bother about dowloading some JVM bloatware,
code named "the latest version forever".

They will be able to just double click on an app,
and run it, without even bothering about all this
JVM fat. Because that is what people are used to
and that is what they want. They don't need all
this added complexity for no reason at all.

Just about everything that JVM does or java is
capable of, is ALREADY available in the ms
equivalent.

So...

In order for Sun to win that deadly battle,
they'd have to buy out the Microsoft itself
and utilize their existing technology, going
back generations in time.

Just take the simpliest thing imaginable,
laying out your GUI with your gui designer.

I can design the entire gui system with about
10 different frames in hours, and with the
modern Java tools, I have to sit and think
about gridbag contraints, that behave in violation
of the simpliest logical principles:
when you increase some coefficient or constraint,
the result should be a bigger something.

When you lay out your gui elements,
you don't think in terms of "fills" or paddings.
You think in terms of how it looks.
And you don't think about rendering on different
platforms, screen resolution and font sizes.

Doing gui work on just about the best tools there are,
at least according to those raving reviews, calling
them the LEADING something in Java field,
is like writing a modern, fully distributed app,
using your hex calculator.

I designed a number of gui screens with MS forms.
A piece o cake affair. Grid snaps, drag and drop,
immediate resizing, any font you like, repositioning
components and not even worrying about what kind
of layout gadget is best suited for you job.

And with java?
Well, you have the whole layout business going
as a result. They can not even generate the code
setting those constraints properly so that their
own design time version reconciles with RUN time
version of the same thing, under the same environment.

Not only that, but just by dragging things in the
"wrong" direction, which they allow you to do,
you, all of a sudden may start getting the error
messages "incorrect constraint set, please look
at your source code" or things like that.

What?

But WHO have set it?
It is YOU, mr. java gui design code developers
and assorted architects of they very underlying
machinery.

How come you even allowed me to drag things to
the places that you consider illegal?

Why did you ACCEPT my dragging
and then issue the error message in some other
window, i may not even have noticed with all the
clutter on your main screen?

All of a sudden, a perfectly valid gui element
is not selectable any more and it is not clear why.
But others are.
If you have a real life nested layout,
and change one of the elements in one nested layout,
all of a sudden, other layouts start producing you
all sorts of errors, and they worked just fine
just a moment ago.

What kind of "progress" do you expect to achive
with all this superjazz,
and how many light years is it going to take you
to get there?

What a petty affair in modern age.

 

[Mickey Segal]

Why bother worrying about non-standard stuff? It would probably be
easier to just test for the Microsoft JVM in your applet at the start, and
then tell the users that they need to update Java and direct them to
useful informational web pages ...

Many of our users go from computer to computer in large institutions, and
they don't go around changing JVMs. We try to support the landscape that
exists, and many still have the Microsoft VM. We only recently dropped
support for Macintosh OS 9, and the equivalent point of declining use for
the Microsoft VM is probably years away.

 

[Mickey Segal]

Microsoft will continue developing their own
version of Java and the ace in their pocket is, first
of all, they control vast majority of the world
software business and operating systems. They have
developed technologies in other languages, operating
systems and development environments that are far
superior to that what Sun has to offer with all its
limited impact on what is happening in the software field.

For Web-based tools, what about the Google Web Toolkit:
http://code.google.com/webtoolkit/ approach, which uses a subset of Java
code to generate JavaScript to run on browsers without the need for a JVM?
How limited is Google's approach when compared to Java applets? Should Sun
be developing an equivalent tool that uses a larger subset of Java
functionality? Does it make sense for Microsoft to go the same route?

 

[nukleus]

For Web-based tools, what about the Google Web Toolkit:
http://code.google.com/webtoolkit/ approach, which uses a subset of Java
code to generate JavaScript to run on browsers without the need for a JVM?
How limited is Google's approach when compared to Java applets? Should Sun
be developing an equivalent tool that uses a larger subset of Java
functionality? Does it make sense for Microsoft to go the same route?

I can not comment on this because first of all,
i do not have time to go chasing all those gadgets
and i do not have any need for it.

Secondly, there are way to many "may be"s to even begin
to consider it.

Thirdly, I do not see the very idea of JVM or ANY "vm"
for that matter as a viable approach.

Unless something becomes, applicable to ANY language
and ANY operating system, and ends up being wired
into your standard hardware chipset,
all it is to me is but a pipe dream
and will fade away just like that Pascal P machine idea,
people wasted millions on.

Has anyone heard of P machine?

Well, it is EXACTLY the same idea as JVM,
for any and all practical purposes.

 

[Randolf Richardson]

Thirdly, I do not see the very idea of JVM or ANY "vm"
for that matter as a viable approach.

That's your choice. But your needs undoubted differ from mine, which
could very well make your choice the right choice for what you need to do;
you didn't elaborate on your needs though (and you don't need to), so I'm
merely making an assumption.

In my view, the JVM has been a fantastic step in software progress,
especially with the "write once, run anywhere" aspect that makes it
possible for me, as a programmer, to not have to be bothered to learn
every Operating System that my compiled code will execute consistently on.

Unless something becomes, applicable to ANY language
and ANY operating system, and ends up being wired
into your standard hardware chipset,
all it is to me is but a pipe dream

That's not a logical assumption because Perl and PHP were never
"hardwired into any standard hardware chipsets" (at least as far as I can
ascertain), yet are both extremely popular languages that are at the
forefront of web site development.

In retrospect, JSP has also been encroaching into this realm over the
years, and I know of many companies that have moved away from PHP in
favour of JSP partly because it offers far better performance (PHP is an
interpreted scripting language embedded into HTML pages which requires
CPU-intensive parsing, where Java's compiled byte-codes don't require
nearly as much CPU power to run; Perl scripts are also CPU-intensive,
unless you're using mod_perl, or something similar, that dynamically
maintains compiled versions of scripts in RAM).

and will fade away just like that Pascal P machine idea,
people wasted millions on.

I question that statistic. I also don't consider such research
"wasteful;" if anything, it's a valuable contribution to the future of
software development in general, as is the JVM (which actually works and
has been gaining popularity in many corporate and government environments
that I know of locally).

Has anyone heard of P machine?

Well, it is EXACTLY the same idea as JVM,
for any and all practical purposes.

I believe you're not taking into consideration that the differences
between the computing environments of yesteryear and now. Back in the day
when Pascal was quite popular (when many people owns XT 8088 personal
computers), the need for cross-platform software wasn't an issue like it
is today, and mainstream consumer applications were typically written for
DOS (and in later years, Windows).

In the past decade I've noticed a gradually increasing trend from various
companies (mostly in the gaming industry) toward creating MacOS, Unix
(Linux specifically), and Windows versions, although not usually all
three. This shows marketplace awareness of demand for cross-platform
support for certain applications, and to me is an indication that this
trend will continue, hence the JVM has a very practical and relevant
purpose in today's computing environment.

What's going to happen in the future? It's difficult to predict
accurately, but I strongly suspect that Linux will continue to flourish,
MacOS will gain more popularity, and application developers will be faced
with either providing at least three versions of their software (to
support Unix, MacOS, and Windows), or provide on version written in Java
and include a copy of the JVM on the installation CD (which happens
already).

 

[Alex Hunsley]

That's your choice. But your needs undoubted differ from mine,
which could very well make your choice the right choice for what you
need to do; you didn't elaborate on your needs though (and you don't
need to), so I'm merely making an assumption.

In my view, the JVM has been a fantastic step in software progress,
especially with the "write once, run anywhere" aspect that makes it
possible for me, as a programmer, to not have to be bothered to learn
every Operating System that my compiled code will execute consistently on.

Hear hear.
Also, I'd like to add that the security benefits from a well made
virtual machine architecture are nice too - e.g. buffer overflows are
much less viable. The Java related buffer overflows I've occaisonally
heard of are down to native code libs (e.g. image processing) and didn't
happen in Java itself...

If you look around, you might notice millions of computers all over the
world living that dream. Think of all the web servers running Tomcat...
The portability and security benefits are obvious. People *could* be
hacking up old styley CGI bins, written in native code like C, but it
isn't happening that way anymore.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Thirdly, I do not see the very idea of JVM or ANY "vm"
for that matter as a viable approach.

Unless something becomes, applicable to ANY language
and ANY operating system, and ends up being wired
into your standard hardware chipset,
all it is to me is but a pipe dream
and will fade away just like that Pascal P machine idea,
people wasted millions on.

Has anyone heard of P machine?

Well, it is EXACTLY the same idea as JVM,
for any and all practical purposes.

Well if that was written in 1995 it would have been
a good hypothesis.

In 2007 it is just plain stupid, because languages
using VM's have succeeded.

Java, .NET and some of the dynamic types languages.

Arne

 

[=?ISO-8859-15?Q?Arne_Vajh=F8j?=]

Also, I'd like to add that the security benefits from a well made
virtual machine architecture are nice too - e.g. buffer overflows are
much less viable.

Buffer overflows is a big problem in C/C++.

But there are actual non VM languages that also
protects against it.

Like Ada.

Arne

 

[Alex Hunsley]

Buffer overflows is a big problem in C/C++.

But there are actual non VM languages that also
protects against it.

Good point, non-VM language architectures don't necessarily have to be
prone to such things... what examples come to your mind? You've made me
think of the C/C++ product called Boundschecker that helped to diagnose
such vulnerabilities, but you're probably thinking of something
completely different, as that isn't actually a language itself....

One of the arguments for the 'fallibility' of C code not being a bad
thing (in areas like memory management) is "C doesn't molly-coddle you,
it gives you all the power, if you mess up that's your fault" - but I
don't believe that's the whole story - I think protecting against
programmer error, to some extent, is useful.

 

[Lew]

One of the arguments for the 'fallibility' of C code not being a bad
thing (in areas like memory management) is "C doesn't molly-coddle you,
it gives you all the power, if you mess up that's your fault" - but I
don't believe that's the whole story - I think protecting against
programmer error, to some extent, is useful.

I know how to change my auto's oil, I could do it without error, but I choose
instead to bring it to a mechanic to change. It isn't to protect me, although
I do get more protection that way, but for the convenience. Both values exist;
one predominates in my decision.

- Lew

 

[Randolf Richardson]

Buffer overflows is a big problem in C/C++.

But there are actual non VM languages that also
protects against it.

Like Ada.

Perl comes to mind for me -- reading a socket into a string (strings can
be very large in Perl, as long as you have enough memory to store them;
run out of memory, and instead of over-writing some unknown data Perl will
just terminate with an error {this is obviously a much safer solution from
a security standpoint}).

 

[Randolf Richardson]

C doesn't give you all the power compared to Assembler, but it sure does
come close.

I know how to change my auto's oil, I could do it without error, but I
choose instead to bring it to a mechanic to change. It isn't to protect
me, although I do get more protection that way, but for the convenience.
Both values exist; one predominates in my decision.

I've not bothered to learn how to do this, although I suspect it's not
that difficult, but since I need to take my vehicle in for regular
(preventive) maintenance to my certified mechanic anyway, I figure I'm
better off having the experts take care of everything.

 

[=?ISO-8859-15?Q?Arne_Vajh=F8j?=]

Good point, non-VM language architectures don't necessarily have to be
prone to such things... what examples come to your mind?

I explicitly mentioned Ada in the the next line ...

One of the arguments for the 'fallibility' of C code not being a bad
thing (in areas like memory management) is "C doesn't molly-coddle you,
it gives you all the power, if you mess up that's your fault" - but I
don't believe that's the whole story - I think protecting against
programmer error, to some extent, is useful.

Protecting programmers against shooting themselves in the foot
is one of the major design principles in Java.

A wise one in my opinion. If you set 100 relative good
programmers to write code in a year, then the result will contain
several big programming mistakes. Even good programmers have bad
days. Errare humanum est.

Arne

 

[nukleus]

Good point, non-VM language architectures don't necessarily have to be
prone to such things... what examples come to your mind? You've made me
think of the C/C++ product called Boundschecker that helped to diagnose
such vulnerabilities, but you're probably thinking of something
completely different, as that isn't actually a language itself....

One of the arguments for the 'fallibility' of C code not being a bad
thing (in areas like memory management) is "C doesn't molly-coddle you,
it gives you all the power, if you mess up that's your fault" - but I
don't believe that's the whole story - I think protecting against
programmer error, to some extent, is useful.

Buffer overflow, array out of bounds are nothing
more than regular exceptions.
Just catch them, or at least let the higher levels
handle Exception and report unknown error.
Nothing needs to crach.