What is the precedence of the 'new' and '.' operators?

From Boyarsky-Selikoff OCP17, (tb864585.JaSE17SG.c05.10)

6:       new Rope().swing();

I thought this would be a compiler error but looking at "TABLE 2.1
Order of operator precedence" I do not find either 'new' nor the '.'

In general, prefix operators have higher precedence than postfix operators.

I don't think I've ever seen a complete table of operators, regardless of the source. Even the Java tutorials don't list all available operators.

To be honest, using common sense here should just work. Meaning, new instance of a class gets created, and then method gets invoked.
Not sure how that translates to precedence definition, but I don't think I'd find it very useful even if I were sure.

public class Test {    public Test() {        System.out.println("Constructor");    }    void testMethod() {        System.out.println("Test Method");    }    public static void main(String[] args) {        new Test().testMethod();    } }
Prints:
Constructor Test Method
Which is what I would expect.

I saw a lot of questions about the precedences in the past, but I never myself found a need to consult operators precedence table, I find it actually confusing.

i.e. let's say we have this code (traditional question of this kind):
int a = 1; int b = 1; int result = a + b + ++a * b++; System.out.println(result);
Now, Oracle's documentation here says, that postfix (expr++) and unary (++expr) have highest precedence among all, while multiplicative (*) and additive (+) have lower precedence that those earlier.

So now one can think to no end what that means looking to that expression shown earlier.

For me, all those precedences do not matter much (and I don't know them well), but I still can calculate easily what the result will be.

It is as simple as that, evaluating expression from left to right.

We start with:
a = 1
b = 1
a + b + ++a * b++

1. Initial value of a is 1, so we place its current value to expression and so we have:
1 + b + ++a * b++
2. b is 1, so we place its current value to expression and so we have:
1 + 1 + ++a * b++
3. ++a means increment its current value and then place it to expression and so we have:
1 + 1 + 2 * b++
4. b++ means place its current value to expression and then increment and so we have:
1 + 1 + 2 * 1
5. Now we have basic mathematics, multiplication first, then addition:
1 + 1 + 2 which turns to 2 + 2 and then to 4, because evaluating left to right

Now, I don't know, maybe that indeed is what those precedences imply from technical language standpoint, but I just simply never think about them and use some other means (which I just showed) to figure out

Liutauras Vilda wrote: To be honest, using common sense here should just work. Meaning, new instance of a class gets created, and then method gets invoked.

Thank you for your reply. I disagree with the "common sense" part.
Common sense to the person may not be Common sense to the compiler or specification.

I expected

(new Rope()).swing();

to be the correct way since neither 'new' nor '.' are in the precedence table.
Furthermore some operators are R to L while others are L to R.

Anil Philip wrote:I expected

(new Rope()).swing();
to be the correct way.

And it is. That's just common sense.

(The specification is required to go into all of that detail so that compiler writers know exactly what to do.  Like Liutauras I don't exactly know what operators take precedence over what operators, except for what you learn in elementary school math. If I'm unsure then I insert parentheses so that the correct answer is produced. And it's very rare that I write code to do arithmetic.)

And, even without a precedence-table, new (Rope().swing()) wouldn't make much sense. But we can have a static innerclass, then the dot takes precedence:
new Outerclass.Innerclass();

I agree with Anil that "common sense" doesn't mean the same thing to different people, and as such it isn't that useful in explanations, unfortunately.  

Trying to forget what I already know from years of Java programming...I sympathize that when I look at
new Rope().swing();
the spacing alone encourages me to see it as
new (Rope().swing());
So yeah, there's an argument for common sense to lead you in that direction.  However, what happens then?  What would "Rope().swing()" even mean?  If Rope() is a constructor (which it is), then there is no legal Java syntax for invoking that constructor without "new".  That's just the way Java was conceived - they chose to highlight object creation with the new keyword, and require it when using constructors.  Other languages like Kotlin may not require this.  But we're in Java, and Rope() by itself doesn't mean anything - so that means this way of parsing the line can't work.

As for tables of precedence for operators... one issue here is that Java's definition of "operator" may be more limited that what you may expect.  Java doesn't define new and "." as operators.  Other languages like C++ may, but not Java.  So if you see a list of precedence of all Java operators, it can still leave off other things that would be useful to know about.  The most complete list I know of is actually the Java Language Specification, specifically the JVM Chapter 15 table of contents.  It's not stated directly, but the order of the sections in that chapter is actually the order of precedence, from highest to lowest. To make that more rigorous, you need to carefully look through all the grammar definitions in this section; it's a pain.  See an example in the last post in this ancient thread.  But the upshot is, the JLS section on expressions defines higher-precedence expressions before lower-precedence expressions, in order to be able to use the higher-precedence definitions within the definitions of the lower-precedence definitions.

Specifically for the question in this thread: "new" in that code is used in a class instance creation expression, section 15.9.  The "." is part of a method invocation expression, section 15.12, which is lower precedence than the "new", therefore coming later in the chapter.  After that come things like postfix expressions, unary operators, binary operators, assignment expressions, and lambda expressions, which are even lower precedence.

Mike Simmons wrote:Trying to forget what I already know from years of Java programming...I sympathize that when I look at
new Rope().swing();

Well, but this one, isn't much different from:
Rope rope = new Rope(); rope.swing();
What I meant, that by the time one takes Oracle Certified Professional Java Programmer cert, very likely they have at least some (or they could) of experience creating an instance of some class. So deduct that from such an experience is possible without trying to trick yourself much into thinking about precedences. It is of those questions where don't need to overthink in my opinion.

Those exams are by no means easy, but there are questions that require a creative stab at them rather than try to infer and apply all the rules compiler has.

Perhaps no need to say, but I'll say anyway, @OP, don't think I'm trying to diminish your common sense. No  Just trying to help to look at some of those questions from a different angle.

Note that there are languages where new (Rope().swing()) makes absolute sense. JavaScript is one such language.

Rope() would call a function that is available in the current scope. It could return an object that contains a swing() method. The call to the swing() method could then return a constructor, which you can apply the new operator to.

For people who have experience with languages where functions and constructors are first class citizens, explicitly stating the precedence of the new and . operators isn't pointless.

Since new is not an operator, the question of operator precedence does not arise. There is no need for applying precedence rules here.

As soon as you hit the new keyword, you get into the "UnqualifiedClassInstantiationCreationException" production rule, which is ( as per JLS 17 section 15.9):
UnqualifiedClassInstanceCreationExpression:     new [TypeArguments]         ClassOrInterfaceTypeToInstantiate ( [ArgumentList] ) [ClassBody] ClassOrInterfaceTypeToInstantiate:    {Annotation} Identifier {. {Annotation} Identifier}         [TypeArgumentsOrDiamond]     TypeArgumentsOrDiamond: TypeArguments <>

The ClassOrInterfaceTypeToInstantiate cannot extend beyond the dot after parenthesis.

This means, new Rope().swing() can only be interpreted as (new Rope()).swing();

Paul Anilprem wrote:Since new is not an operator, the question of operator precedence does not arise. There is no need for applying precedence rules here.

Hmmm, I'm much more in agreement with Stephan and others that the question isn't pointless.  If you're looking at grammar production rules, you don't the concept of precedence at all (it's all implicit in the structure of the rules) - but it's a useful shortcut to gain understanding.  Whether or not it's called operator precedence is an artifact of how the JLS defines "operator", which is different from some other languages like C/C++.  I brought up the point that "new" and "." aren't operators in order to explain why they aren't included in the operator precedence table - but that doesn't mean it's a bad question.  Regardless of the definition of operator, Java programmers need to understand how expressions like this are parsed.  A more complete table of precedence for operator-ish things would actually be a useful learning tool, I think.   Unfortunately, the closest I've seen is the JLS chapter 15 table of contents.  There's probably some resource out there somewhere that does it though...

It is indeed a good question.

i have a feeling that "new Rope().swing();" would violate some coding best practices / style guide.
it irks me to even look at it.

I do it to start my Swing applications all the time:
SwingUtilities.invokeLater(() -> new MainWindow().show());

ok you got me, i do that too, but i think its the only time i do it.

S Fox wrote:but i think its the only time i do it.

Maybe you, not necessarily others. Here is another common usage.

Before the advent of Executors, this was also a common occurrence:
new Thread(task).start();
(It might still be common, but it's not supposed to)