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

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

Re: about class dependancies

Show key headers only | View raw

On 17/12/15 02:27, Lew wrote:
> On Wednesday, December 2, 2015 at 4:49:41 PM UTC-8, regis wrote:
>> On 12/03/15 01:32, Lew wrote:
>>> On Wednesday, December 2, 2015 at 3:40:46 PM UTC-8, regis wrote:
>>>> let say we have some public class A
>>>> that depends on some public class B, e.g.:
>>>>
>>>> ====
>>>> // B.java
>>>> public class B {
>>>>      public int f(int n) { return 2*n; }
>>>> }
>>>> ====
>>>> // A.java
>>>> public class A {
>>>>      public static void main (String[] args) {
>>>>        B b= new B ();
>>>>        System.out.println (b.f(5));
>>>>      }
>>>> }
>>>> ====
>>>> $ javac A.java B.java
>>>> $ java A
>>>> 10
>>>> ====
>>>>
>>>> Then let say class B changes (with signature of f() unchanged), e.g.:
>>>>
>>>> ====
>>>> // B.java, changed
>>>> public class B {
>>>>      int lambda= 10;
>>>>      public int f(int n) { return lambda*n; }
>>>> }
>>>> ====
>>>>
>>>> Finally, we update file B.class, but not file A.class,
>>>>
>>>> ====
>>>> $ javac B.java        # but not A.java
>>>> $ java A
>>>> 50
>>>> ====
>>>>
>>>> It seems to work, but is it guaranteed ?
>>>> or should file A.class still be updated ?
>>
>>> The Java compiler "javac" is smart enough to resolve many dependencies, including the one you note here.
>>> However, this would not work if 'lambda' (*terrible* name for that variable!) were made 'final', and therefore a constant variable.
>>
>> It still seems to work if it is made final...
>>
>> // B.java, changed
>> public class B {
>>      final int multiplier= 1000;
>>      public int f(int n) { return multiplier*n; }
>> }
>> ====
>> $ javac B.java          # but not A.java
>> $ java A
>> 5000
> That isn't what I meant. I meant if you recompile 'A' but not 'B" then you don't pick up the change in 'B'. What you did was recompile 'B' and run 'A'. I had misread your example.

I don't get it.  A.java refers to B, so compiling A.java will also 
compile B.java as an implicit class, unless you have implicit 
compilation turned off.


-- 
ss at comp dot lancs dot ac dot uk

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next 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