Java Forum / General / February 2007
Microsoft Java almost gone in Vista
Mickey Segal - 01 Feb 2007 18:46 GMT 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 - 02 Feb 2007 02:50 GMT > 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 [quoted text clipped - 10 lines] > 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.
 Signature Randolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/
Steven J. Sobol - 02 Feb 2007 04:16 GMT > 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.
 Signature Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Victorville, California PGP:0xE3AE35ED
It's all fun and games until someone starts a bonfire in the living room.
nukleus - 02 Feb 2007 11:50 GMT >> 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 [quoted text clipped - 10 lines] >> are running the Microsoft VM and it would be good to be able to test >> that environment without finding an XP computer. 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.
> 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 [quoted text clipped - 12 lines] > >the very beginning. Mickey Segal - 02 Feb 2007 13:14 GMT > Microsoft will continue developing their own > version of Java and the ace in their pocket is, first [quoted text clipped - 4 lines] > 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 - 03 Feb 2007 11:07 GMT >> Microsoft will continue developing their own >> version of Java and the ace in their pocket is, first [quoted text clipped - 11 lines] >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 - 03 Feb 2007 17:00 GMT [sNip]
> 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).
 Signature Randolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/
Alex Hunsley - 03 Feb 2007 20:48 GMT > [sNip] >> Thirdly, I do not see the very idea of JVM or ANY "vm" [quoted text clipped - 9 lines] > 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...
>> 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 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.
> That's not a logical assumption because Perl and PHP were never > "hardwired into any standard hardware chipsets" (at least as far as I [quoted text clipped - 50 lines] > The Lumber Cartel, local 42 (Canadian branch) > http://www.lumbercartel.ca/ Arne Vajhøj - 03 Feb 2007 23:44 GMT > 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 - 04 Feb 2007 01:03 GMT >> 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 [quoted text clipped - 4 lines] > 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 - 04 Feb 2007 01:18 GMT > 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 - 04 Feb 2007 02:44 GMT >> 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. 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.
 Signature Randolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/
Arne Vajhøj - 04 Feb 2007 04:25 GMT >> Buffer overflows is a big problem in C/C++. >> [quoted text clipped - 3 lines] > 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 - 04 Feb 2007 19:10 GMT >>> 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 [quoted text clipped - 16 lines] >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.
Randolf Richardson - 04 Feb 2007 02:40 GMT >> 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 [quoted text clipped - 6 lines] > > 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}).
 Signature Randolf Richardson - kingpin+nntp@lumbercartel.ca The Lumber Cartel, local 42 (Canadian branch) http://www.lumbercartel.ca/
Arne Vajhøj - 03 Feb 2007 23:42 GMT > Thirdly, I do not see the very idea of JVM or ANY "vm" > for that matter as a viable approach. [quoted text clipped - 10 lines] > 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
Mickey Segal - 02 Feb 2007 13:04 GMT > 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.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|