This question already has answers here:
Expression Versus Statement
(21 answers)
Closed 7 years ago.
What's the significant difference between Expressions vs Literals && Expressions vs Statements in Java? I'm aware that an expression represents a simple value or a set of operations that produces a value. However, literals can also be a simple value which makes it a little confusing to make difference between them. Could smb explain the differences? Thanks in advance!
A literal is a notation for representing a fixed value in source code. For example: 'a', "a", Object.class, and 1 are all literals. Their value is known at compile-time, and they are expressions, since they evaluate to a single value.
Statements are complete units of execution. Most statements terminate with a semicolon. For example: new Object(); is a statement, while new Object() is an expression that returns a reference to a newly created object. Examples of statements that don't terminate with a semicolon are blocks and control flow statements.
Related
This question already has answers here:
ternary operator not working
(3 answers)
Closed 4 years ago.
Hi below statement throws error . It says "Not a statement"
map.containsKey(1)? someObject.setFlag(true) : map.put(1,"hello");
Is it needed to store the returned value in some variable on the left hand side of the statement?
You are using the Ternary operator as a statement, not an assignment. In your case, you should use if else
if(map.containsKey(1)) {
someObject.setFlag(true)
}else{
map.put(1,"hello");
}
Here is the java docs of Ternary operator.
The ternary operator is an expression, not a statement. It is commonly used to set the value of a variable depending on some condition. In this case, you need to assign the result to a variable in order to make it into a statement:
String result = map.containsKey(1) ? someObject.setFlag(true) : map.put(1,"hello");
(Note: You should choose a better variable name.)
I think you will still have problems here because setFlag() probably doesn't return a String. Also, since you are creating side effects, you should replace this with an if statement.
This question already has answers here:
Difference Between dot operator and brackets in jsp el
(3 answers)
Closed 6 years ago.
In Jsp,what's the difference between ${param.name} and ${param[name]}?
I've tested that they can both get the parameter I set from a servlet,but I want to find out the difference between them.e.g,in what sittuaton,one can work while another one doesn't?
Thanks in advance.
All the following ways are evaluated same in standard JSP EL:
${param.myvar}
${param[name]} // here `name` is another EL variable with value `name = "myvar"`
${param["myvar"]}
${param['myvar']}
If you're referring to a variable, then you can use 2nd one. Otherwise if you're directly accessing through value, then you can use 3rd or 4th one.
According JSP specification:
The EL follows ECMAScript in unifying the treatment of the . and [] operators.
expr-a.identifier-b is equivalent to expr-a["identifier-b"]; that is, the identifier
identifier-b is used to construct a literal whose value is the identifier, and then the []
operator is used with that value.
This question already has answers here:
Is String s = "foobar" atomic?
(3 answers)
Closed 7 years ago.
This is related to Is String s = "foobar" atomic? . Im a bit confused by the answer there... Assignments are atomic, thats fine. But if we have
String s = "s";
Wouldn't the steps to execute this line be
1 - assign location of a new String instance to reference s (so its effectively not null, even though constructor for of a new String did not yet run)
2 - run constructor?
So, only time this assignment should happen atomically is if "s" is interned?
Isnt this exactly how reads of partially constructed objects happens?
Not a duplicate - my question is not whether assignment is atomic. My question is what if "s" is not yet interned (effectively does not exist at time of assignment) and if its possible.
Yes, it is an atomic operation.
Maybe this will help (JLS):
Compile-time constant expressions of type String are always "interned" so as to share unique instances, using the method String.intern.
Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (ยง15.28) - are "interned" so as to share unique instances, using the method String.intern.
So I am not sure the String constructor is called here.
This question already has answers here:
Interview : Java Equals
(7 answers)
Closed 8 years ago.
Is there a performance impact, assuming str is a java.lang.String, of using "String".equals(str) vs str.equals("String")? My gut says, "No, the JVM / compiler will optimize the literal string in either case", but I see the first style crop up enough in various codebases and it just looks so unnatural (at least to me), so I figured there must be a reason besides style.
The only reason for using "String".equals(str) (which I find ugly) is laziness, as it saves you the need to check that str != null prior to calling str.equals("String").
Performance-wise there shouldn't be any difference. You are comparing two String instances either way.
"String".equals(str)
Does not yield the same result as
str.equals("String")
if str == null.
In the first case, it returns false, in the second, it throws a NullPointerException.
"String".equals(str)
Is in fact equivalent to
str != null && str.equals("String")
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why boolean in Java takes only true or false? Why not 1 or 0 also?
I was wondering today why Java cannot test any other type than a boolean.
In C, C++ and many other languages (actually most programming languages), the following is possible and valid:
int a = 0;
if (a) // evaluates to false
; // do something nice
a = 6;
if (a) // evaluates to true
; // do something more
This also works almost everywhere for objects, arrays; anything that can have a value of 0x00000000 in the memory.
The question: why is this not possible in Java (you have to keep on testing for == 0 or == null)?
I would guess that the rationale why is because it simplifies things.
An if statement has to evaluate a value to one of two possible conditions. What Java does is require you to supply a statement itself that must evaluate to two possible conditions (boolean) rather than accept other values and arbitrarily decide if that evaluates to true or false.
Because James Gosling et al decided that Java wouldn't do that.