Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #33289

Re: about class dependancies

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>

Show all headers | View raw


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


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