Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #33289
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: about class dependancies |
| Date | 2015-12-03 08:06 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <n3pel2$rs8$1@dont-email.me> (permalink) |
| References | <565f816b$0$3054$426a74cc@news.free.fr> <symbol-table-20151203011146@ram.dialup.fu-berlin.de> <565f95e3$0$4574$426a74cc@news.free.fr> |
On 12/2/2015 8:07 PM, regis wrote:
> On 12/03/15 01:12, Stefan Ram wrote:
>> regis <regis.barbanchon@free.fr> writes:
>>> public class B {
>>
>> The Byte Code contains symbols that AFAIK refer to the
>> class and the methods /by name/. There is no other magical
>> link or internal versioning. So it should be legal as long
>> as the interface is the same.
>>
>> With
>>
>> javap -verbose A
>>
>> , you can see the symbol table of class A.
>>
>
> so as long as f() signature is untouched,
> no amount of change in B will make a non-updated A.class to break ?
> including:
> - adding/removing members, static member, final members
> - changing a final member's values,
> - adding/removing methods other than f(),
> - changing f()'s body.
None of these will change the way A refers to B's f(). If you
saved the old A.class and recompiled A to make a fresh one, the byte
code would be unchanged. (Some non-executable metadata like date
stamps might be, but all of A's fields, methods, and so on would
be the same as before.)
Some of the changes you mention would invalidate A.class if A
made other kinds of references to B. For example, if A also calls
B's g() method and you remove g() or make it private, A.class won't
work any more.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
about class dependancies regis <regis.barbanchon@free.fr> - 2015-12-03 00:40 +0100
Re: about class dependancies Lew <lewbloch@gmail.com> - 2015-12-02 16:32 -0800
Re: about class dependancies regis <regis.barbanchon@free.fr> - 2015-12-03 01:49 +0100
Re: about class dependancies regis <regis.barbanchon@free.fr> - 2015-12-03 02:26 +0100
Re: about class dependancies Arne Vajhøj <arne@vajhoej.dk> - 2015-12-02 21:55 -0500
Re: about class dependancies Arne Vajhøj <arne@vajhoej.dk> - 2015-12-02 21:58 -0500
Re: about class dependancies Steven Simpson <ss@my.domain.invalid> - 2015-12-03 15:15 +0000
Re: about class dependancies Arne Vajhøj <arne@vajhoej.dk> - 2015-12-03 19:49 -0500
Re: about class dependancies Lew <lewbloch@gmail.com> - 2015-12-16 18:27 -0800
Re: about class dependancies Steven Simpson <ss@my.domain.invalid> - 2015-12-17 08:39 +0000
Re: about class dependancies Lew <lewbloch@gmail.com> - 2015-12-17 13:36 -0800
Re: about class dependancies Mike Amling <mamling@chaff.us> - 2015-12-21 08:29 -0600
Re: about class dependancies regis <regis.barbanchon@free.fr> - 2015-12-03 02:07 +0100
Re: about class dependancies Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-03 08:06 -0500
csiph-web