× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Very well put Joe Sam. I always seem to learn something new from your posts.
Although I'm not the OP thanks!
--
James R. Perkins


On Fri, Mar 20, 2009 at 10:30, Joe Sam Shirah <joe_sam@xxxxxxxxxxxxx> wrote:


Well, it seems to me that with:

So, what will happen if the class, that compiled in the older version of
java complier, has a method that is fully deprecated in the new version
of JVM?

the question went from reasonable for a newbie, to magical. There is
no product that can guarantee that future versions will *always* run older
things. Feel free to argue, but someone can always come up with scenarios
(even if extreme) that wouldn't work.

So, the answer is that you can normally, reasonably expect previously
compiled classes to run in a later JVM. That's much more than most can
promise.

*Generally* deprecated is not a problem, but note that some of these say
"expected to be removed at some point." Now I'll give a real-life example:

Thread.destroy() was never a good idea and actually was never
implemented. At some point, it was changed to throw NoSuchMethodError. No
problem, right? No knowledgeable programmer would ever have used it
anyway.

Well, a sometime client of mine, who thinks they can save money by
paying four (and sometimes more) offshore programmers each a third of my
rate, assigned them to a project in which threads were a perfect fit. They
"delivered" a mess which depended on destroy() for cleanup. Now, it didn't
do anything anyway, but under 1.4, it just didn't do anything so the
program
ran (if you can call it that.) But try to run it under 1.5 and, you
guessed
it: NoSuchMethodError. BTW, the client routinely gets to pay me or others
to clean up after this group while the users suffer non-production quality
applications. But, "it's a corporate direction."

Another example was on another list yesterday. Someone wanted
performance gains in JSF, but couldn't go to JSF 1.2 because one (of an
extremely large number) of their dependencies was Apache Beehive, which
won't play nice with 1.2.

To repeat, the point is you can normally, reasonably expect previously
compiled classes to run in a later JVM, but there are always exceptional
conditions.


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message -----
From: "Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Friday, March 20, 2009 12:47 PM
Subject: Re: is class file backward compatible


Interesting. Thanks.

"James Perkins" <jrperkinsjr@xxxxxxxxx> wrote in message
news:<mailman.11055.1237566399.26163.java400-l@xxxxxxxxxxxx>...
Deprecated methods for more of a "please don't use me" rather than a
"you
can't use me". They really only show themselves at compile time as
warnings
(or you IDE).

So, you should be fine.
--
James R. Perkins


On Fri, Mar 20, 2009 at 09:13, Lim Hock-Chai
<Lim.Hock-Chai@xxxxxxxxxxxxxxx>wrote:

So, what will happen if the class, that compiled in the older
version of
java complier, has a method that is fully deprecated in the new
version
of JVM?

"David Gibbs" <david@xxxxxxxxxxxx> wrote in message
news:<mailman.11041.1237564455.26163.java400-l@xxxxxxxxxxxx>...
Lim Hock-Chai wrote:
can a class that created using a lower version of java compiler
run
on a
higher version of JVM?

Yes, this should be possible without a problem.

david



--
IBM i on Power - For when you can't afford to be out of business
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.