• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

In contrast to MS Windows, JVM ....

 
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...sorry, too angry, again... In contrast to ".exe files" or most applications, JVM...
is neither backward nor forward compatible. I.e certain version of JVM will run classes created only in a range of JDK versions.
What does impede backward compatibility compliance?
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wel,no - that is not a true statement.
All java code is backward compatable except for the (very few) specific exceptions in the 1.4 release that we have already talked about.
We have a huge application that was written in the 1.2 release that is running just fine in the 1.3 and 1.4 releases.
It is true that they are not forward compatable. Stuff written in 1.4 will probably NOT run in an earlier release.
You obviously are having problems of some sort and you are assuming that it is a compatability issue.
Exactly WHAT is the problem?
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cindy,
I do not go out with problems to public, at least with real ones. So, let's call it curiosity.
I have read this in, advised by you, book on JVM http://www.artima.com/insidejvm/ed2/
I shall give you exact link at 2002/12/03.
[ November 30, 2002: Message edited by: G Vanin ]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cindy,
I am sorry. I myself lost a lot of time searching in a wrong place, though I even remembered that it was Chapter 4, but from JVM specification.
Here it goes:

minor_version, major_version
The values of the minor_version and major_version items are the minor and major version numbers of this class file.Together, a major and a minor version number determine the version of the class file format. If a class file has major version number M and minor version number m, we denote the version of its class file format as M.m. Thus, class file format versions may be ordered lexicographically, for example, 1.5 < 2.0 < 2.1.
A Java virtual machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 v Mj.m. Only Sun can specify what range of versions a Java virtual machine implementation conforming to a certain release level of the Java platform may support.


And the endnote 1:

The Java virtual machine implementation of Sun's JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. Sun's JDK releases 1.1.X can support class file formats of versions in the range 45.0 through 45.65535 inclusive. Implementations of version 1.2 of the Java 2 platform can support class file formats of versions in the range 45.0 through 46.0 inclusive.


AFM (as for me), "range" means absence both forward and backward compatibility, and even more it is reserved by Sun and non-compliance is a crime and will be severely punished. Look at the agony of MS. Now we have 2 JVMs, ley me cite from
http://itwriting.co.uk/dotnet4.php#jvm


- The Java Virtual Machine is an object-oriented execution environment for any language so long as it’s Java
- The .NET Platform is an object-oriented execution environment for any language so long as it isn’t Java


For me they are too many. I am going to choose between.
[ December 03, 2002: Message edited by: G Vanin ]
 
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Java virtual machine implementation of Sun's JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. Sun's JDK releases 1.1.X can support class file formats of versions in the range 45.0 through 45.65535 inclusive. Implementations of version 1.2 of the Java 2 platform can support class file formats of versions in the range 45.0 through 46.0 inclusive.

There was a major change in Sun's JDK release 1.0.x and 1.1.x. However, from 1.1.x to present release 1.4, all JDKs are backward compatable (not including GUI stuff written in 1.0).

No company, especially Microsoft, writes things that are forward compatible. Have you ever tried to open a document saved in Word 6 format into Word 5? Or run a program written for Win9x in Win3.1? It won't work. Same reasoning why you can't always run a program written in JDK 1.4 in a JRE 1.1 environment.

Can you run a program written for Win3.1 on WinXP? Sometimes yes, sometimes no. Can you run a program written with JDK1.1 on JRE1.4? Yes.

The .NET platform encompases more languages and has some good things. However, you can only run the program you wrote with .NET on a computer that uses Windows.

If you compile a java class, you can run it on any OS as long as you install the current JRE. You can run it on Unix, Windows, or Apple (MacIntosh).

If you compile a .NET class, you can run it on a PC that uses MS Windows. That's all. Not unix, not linux, not Apple. However, if you are not interested in running your program on any other operating system other than MicroSoft Windows, it may be a good option for you.
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Marilyn,
thanks.
Yes I tried. First of all, I never use format .doc, but .rtf. It is from my experience with macros, i.e. viruses. You cannot catch it in RTF, RTF is vendor-independent and it is cross-platform. All the rest is there as in DOC.
It just warns that some featurtes are not available.
But forget about forward compatibility.

Can you run a program written with JDK1.1 on JRE1.4?


I don't know. I just would like to hear, because later will be late.

If you compile a .NET class, you can run it on a PC that uses MS Windows.


It is not true. There is a mono project, Open Source projects. If you really do not know, tell me (or to Thomas Paul), I shall write you links later.
C#.NET is under standatization with intention to be left in public domain, Java is not. Though I do not know last news. Thomas Paul should know.
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok. I asked and here is the answer from Thomas Paul
https://coderanch.com/forums/
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me make it clear... C# is controlled by ECMA but .NET is not. There is a big difference between the two! A C# program compiled on windows to create an exe will not run in Linux. The source code will be theoretically compatible if you use no .NET classes specific to Windows. That means no ASP.NET and no ADO.NET (at least not yet).
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Paul:
That means no ASP.NET and no ADO.NET (at least not yet).


It is the same with between J2EE applications/technologies/application servers: application developed in one will not run in another one.
Don't you agree with this opinion:


JAVA's mantra needs to change or JAVA will become a niche language. Thus, "write once, run everywhere" must give way to "1.Write once. 2a. Test everywhere 2b. Compile to native (if speed is an issue) 3. Deploy bytecode or executable as neccessary" Why do i say that ? Look at http://www.excelsior-usa.com/home.html for some exciting options.


from http://www.sys-con.com/java/readmessage.cfm?id=1401&article=871
I do not see anything wrong with compiling on each platform. It is better to compile once (anyway JAVA requires installation on each client and compilation on each "new" JVM), than to torture multiple users with crawling, stampeding responsiveness. Though, stop... we are speaking about clients/desktops, aren't we?


The source code will be theoretically compatible if you use no .NET classes specific to Windows.


What exactly makes the source to "specific to Windows". "Compatible" with what?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MdQ: Can you run a program written with JDK1.1 on JRE1.4?
GV: I don't know. I just would like to hear, because later will be late.

Read Marilyn's original response again. She said "Yes" in answer to the question she posed. I don't know why you deleted this response and then asked the question again - seems pretty silly.
GV: (anyway JAVA requires installation on each client and compilation on each "new" JVM)
No, Java does not need to be recompiled on each new JVM. The JVM section you quoted earlier is misleading - it gives Sun the ability to declare that a new JDK version will not execute code compiled on older JDKs. This flexibility was important in JAva's early development (pre 1.1), as there were a number of changes made to class file format, and it would've been an excessive burden to require all JVMs to support antiquqted formats that no one would ever use. However ever since 1.1, Sun has consistently affirmed that each new JDK does indeed support all previous class file versions from 1.1 on. It's theoretically possible that they might change this policy in the future, but this would surely cause a lot of unhappy customers unless it were done for a very good reason, and I can't see how this would be in Sun's interest. Not worth worrying about, IMO.
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
you have problems with methaphors. I did not mean exactly version 1.1 and 1.4 since I even have never used them and do not plan using.


Only forum leaders or the person that posted this message may edit or delete the message of another member.


If you would like to know I did mean version 1.3.1 and, say 1.2. Just add 2 to version's minor number.
[ December 10, 2002: Message edited by: G Vanin ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you have problems with methaphors
Ummm... Ooooookay. So 1.1 is a "metaphor" for 1.2? And 1.4 for 1.3.1? Fine. The answer to the question is still "yes" - code compiled on 1.2 will run on 1.3.1. All statements in my previous posts still apply.
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
really sorry. I added in a hurry. It should be 1.6 and 1.3, though originally I have been thinking even about others...
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1.5 and 1.8, really
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, I see. As far as what might happen in the future, this previous comment applies:

It's theoretically possible that they might change this policy in the future, but this would surely cause a lot of unhappy customers unless it were done for a very good reason, and I can't see how this would be in Sun's interest. Not worth worrying about, IMO.


I think as long as Microsoft dominates the industry as it does, the other companies are forced to limit their use of destructive tactics against each other. Sun could use changes in Java to intentionally make Java-related products from other companies obsolete - but such tactics would do much more harm than good to Sun, IMO, and just drive more developers to C# and .NET . Which is why I don't think it would happen. If somehow the business situation were to change drastically, we might need to start worrying. E.g. if Microsoft were somehow crippled, or if Sun were acquired by Microsoft ! (or IBM - but in this case IBM would still be limited by Microsoft's power). Who knows what the future might bring? But I'm still pretty confident that future JDK releases will continue to be backwards compatible.
[ December 12, 2002: Message edited by: Jim Yingst ]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jim,
for insisting in clearing away my brains from any serious doubts about JAVA's future... I do not really have. I just look back at COBOL legacy example. Nothing has gone away eventually.
But the question was not: why? but rather what? I was just curious to get into internals...
 
reply
    Bookmark Topic Watch Topic
  • New Topic