• 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
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Devaka Cooray
  • Ron McLeod
  • paul wheaton
Saloon Keepers:
  • Tim Moores
  • Piet Souris
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Frits Walraven
  • Scott Selikoff

Doubt in compile time constants

 
Ranch Hand
Posts: 173
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

In the following code , compile time constants work well as return types but
compiler generates error if they are passed as arguments ...



Can anyone explain this??
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the compiler error?

I think its because method1 has declared its parameter as Non final. So there would be a possibility of change in value in the method. This may not be of concern for primitives, but surely will affect when references are passed.

And in case of return types- As the variable goes out of scope after the method return- It doesnt matter if its declared as Final.
 
Hareendra Reddy
Ranch Hand
Posts: 173
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Test.java:7: method(byte) in Box cannot be applied to (int)
method(i);
^
1 error

Compiler error is usual ...


I think its because method1 has declared its parameter as Non final. So there would be a possibility of change in value in the method.


Why does we need to declare it final , change in its value doesn't affect it either ..

Here b value may be altered even and it doesnt generate compiler errors...
 
Mohamed Sanaulla
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I did mention that the parameters can be object references

Ok. This is pretty confusing. Am not going too much into this

Update: Too late in the night to give my mind some dose of thinking
 
Hareendra Reddy
Ranch Hand
Posts: 173
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Then we should expect more comments from experts about it....
 
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java is "call by value" strictly. So it doesn't matter at all if parameters or variables are final for actual and formal parameters to be compatible.

What matters is the type. You can't put (i.e. actual parameter) a big thing (int, 4 bytes) in a small box (formal parameter, byte, size: 1 byte).

Unless you tell the compiler that you are aware of the problem and take the consequences of throwing away three bytes (i.e. downcasting).
 
Hareendra Reddy
Ranch Hand
Posts: 173
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


What matters is the type. You can't put (i.e. actual parameter) a big thing (int, 4 bytes) in a small box (formal parameter, byte, size: 1 byte).


That's where compile time constants come into picture , here compiler knows for certain that a value of 4 can be put into a byte (If it can't it
generates a compiler error)...

So compile time constants do not work when we pass it as arguments to method..
then how we can use them in returning from a method it also should not work...
 
author
Posts: 23928
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hareendra Reddy wrote:
That's where compile time constants come into picture , here compiler knows for certain that a value of 4 can be put into a byte (If it can't it
generates a compiler error)...

So compile time constants do not work when we pass it as arguments to method..
then how we can use them in returning from a method it also should not work...




I think that it is really safe to say that this isn't on the SCJP test.


But to answer your question... if you follow the JLS for the "return" statement, in section 14.17, you'll notice that the return type must be assignable under the rules of section 5.2. And this section allows for the "compile time constant rule" that you mentioned.

Method parameters conversions are under section 5.3 of the JLS; And this section doesn't have a "compile time constant rule".

Henry
 
Hareendra Reddy
Ranch Hand
Posts: 173
Firefox Browser Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Henry...
It cleared my confusion
 
Create symphonies in seed and soil. For this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic