This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes regarding final as return type Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "regarding final as return type" Watch "regarding final as return type" New topic
Author

regarding final as return type

boopathy Gopalsamy
Greenhorn

Joined: Feb 07, 2005
Posts: 5
1.The following code compiles
static byte m()
{
final char c='\u0001';
return c;
}

2.But the following code doesn't compile
static byte m()
{
char a='\u0001';
final char c=a;
return c;
}

Explain me the difference?
challa
Greenhorn

Joined: Mar 28, 2005
Posts: 23
boopathy,
In the second code you made variable c as final but you are assigning to it a value which is not final. That is value in the variable is not final. If we change value in a it automatically changes value in 'c'.Hope you got it.
vidya sagar
Ranch Hand

Joined: Mar 02, 2005
Posts: 580
--------------------------------------------
In the second code you made variable c as final but you are assigning to it a value which is not final. That is value in the variable is not final. If we change value in a it automatically changes value in 'c'.
---------------------------------------------
hi purnima

how come if i change one variable it reflects in another

As per ur argument if i change argument from byte to int it should show error but not showing... why?

static int m()
{
char c= '\u0001';
final char a=c;
return a;
}

...............
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by boopathy Gopalsamy:
1.The following code compiles
static byte m()
{
final char c='\u0001';
return c;
}

2.But the following code doesn't compile
static byte m()
{
char a='\u0001';
final char c=a;
return c;
}

Explain me the difference?



In the first case , the compiler is sure that you are returning a char value that is in limit of byte .

And in second case , compiler is not sure , because a is not final ...

Hope it is clear .
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
c is a constant expression in the first example, while a is not.
A constant expression is not to be confused with a final.
http://qa.jtiger.org/GetQAndA.action?qids=13&showAnswers=true


Tony Morris
Java Q&A (FAQ, Trivia)
amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 810
hii
can any body pls pls explain me in details ... the above stuff..
i m not able to understand..

that..
1. how char is able to return with typecasting ?
2. why not char is not compiled when its final...and we declare and initialize it ..so there will be no problems..

pls explain me details both the cases what actually is happening and why compiler is giving error in one and not in other one..

would be gr8 full to him/her...
thanx in advance..


Thanks and Regards, Amit Taneja
James Larry Gaines II
Greenhorn

Joined: Apr 07, 2005
Posts: 3
I believe in the first part, because you are assigning the value of c in one line, the compiler knows that since this is a final variable, this value will never change. And since the value can actually be auto casted to byte, it will not throw an error. In the second case, since a is not a final variable, even if c is final, the compiler will know the value only on runtime. Try this two set of codes to understand it better :

static byte m()
{
final char c=1000;
return c;
}

static byte m()
{
final char c;
c='\u0001';
return c;
}

both will cause error. Just remember that in your first case, the compiler already know the value before it even compiles the code while the second, the compiler will not know the value until it runs the application.
amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 810
hi

is James Larry Gaines reply is correct ?
and he say in his reply that both will not compile..
why not 1st one ???
it must be as its similar to orginal 1st block of code which compiles ?

any further comment and explanations is welcome.... because he wrote in his reply "he thinks" i don't know if he is sure of his answer or not. ?

thanx
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Yes, neither will compile - notice the methods are declaring to return byte.
However, you are receiving a misleading response due to the confusion between a final and a constant. What you have is a constant in one expression and a variable in another (the JLS erroneously uses these terms interchangably at times).

So what you need to do is find out what a constant expression is. This is covered in JLS 15.28. You might also find out about type conversion rules, which is covered in Chapter 4 if I remember erectly and why a constant expression is a legitimate conversion in your provided case.

All references to a 'final' are potentially misleading. Do not confuse a final and a constant. The JLS is your definitive source (mind the errors).
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
The first case will compile because implicit narrowing conversion applies.
'\u0001' is a constant expression
therefore, c is a constant expression
therefore, the char c can be assigned to a byte because the compiler knows that '\u0001' will fit in a byte

In the second case a is not a constant expression
so c is not a constant expression
so implicit narrowing does not apply and a char cannot be assigned to a byte
so the method will not compile


Mike Gershman
SCJP 1.4, SCWCD in process
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
To clarify: Tony's last post is referring to the question Amit asked about Larry Gaines' reply. Mike's last post is referring to the first post in this thread. Thus when Tony says "neither will compile" and Mike says "the first case will compile", they are talking about two different posts. Just in case anyone else is as confused by this as I was when I first read Tony and Mike's posts next to each other.

[Tony]: What you have is a constant in one expression and a variable in another (the JLS erroneously uses these terms interchangably at times).

The JLS does not use the terms interchangebly at times. The JLS defines both terms, and uses both terms consistently and correctly for the way they've been defined. It so happens that both terms can and do overlap, in that a variable can be a constant, and vice versa (in JLS usage, obviously). However most variables are not constant, and many (probably most) constant expressions are not variables. Thus the terms are not interchangeable.
[ April 11, 2005: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
The JLS erroneously uses the terms interchangeably.
English says so.
Computer Science 101 (i.e. fundamentals of the science of computer programming) says so.
The JLS says otherwise (by implied contradiction).
The JLS has proven itself as erroneous in many respects.
The JLS is not a definitive source of the terms 'constant' and 'variable'.
The JLS is often erroneously referred to as some kind of authoritative source of definitions of terms that are well outside of its scope.
Why is this the case? I don't know. The truth prevails in any case.
Heck, it can't even get the concepts that *are* within its scope, correct.
I'd be keen to hear what a well-informed mathematician (which is the basis for computer science) has to say about a 'variable constant' and a 'constant variable', but I think I can speculate anyway.

OK, so Germany opposes war, and the world's most famous rap artist is caucasian. On the basis that the world is going mad, I may be willing to concede, but otherwise, the JLS does not change what has been the truth for decades - only madness could. A constant is not a variable in the same way that black is not white.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Tony]: The JLS erroneously uses the terms interchangeably.

If you've get a pertinent example from the JLS, please post it. As I requested last time (last post in that thread, currently). Well, the context was slightly different, but close enough for our purposes I think. I agree the JLS is not perfect, and that the definitions it uses here disagree with those used by most of the rest of the world. However I assert that the JLS usage of these two words is internally consistent, and they are absolutely not interchangeble within the JLS.

Other than that, I don't think there's anything new here to respond to.
Parameswaran Thangavel
Ranch Hand

Joined: Mar 01, 2005
Posts: 485
hi
sorry to ask silly question

diff btween char,short and byte

any one please
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: regarding final as return type