Strange behaviour when compiling java files with protected inner interface

[scabug]

=== What steps will reproduce the problem (please be specific and use wikiformatting)? ===
test/Foo.java

package test;

public abstract class Foo {
  protected interface Inner {
    public void hello();
  }
}

other/Bar.java

package other;

public class Bar extends test.Foo {
  void createMeSth(test.Foo.Inner aaa) {
    aaa.hello();
  }
}

ohmy/A.scala

package ohmy

class A extends other.Bar

=== What is the expected behavior? ===
Well, at least the error message seems misleading to me. Not sure if this should compile anyway, judging from the reply to bug #3934.
Java compiles fine.
Also not forcing the type by compiling only

scalac test/Foo.java  other/Bar.java

finishes successfully. So I would expect some consistency here.

=== What do you see instead? ===

other/Bar.java:4: error: trait Inner in object Foo cannot be accessed in object test.Foo
 Access to protected trait Inner not permitted because
 enclosing class class Bar in package other is not a subclass of 
 object Foo in package test where target is defined
  void createMeSth(test.Foo.Inner aaa) {
                            ^
one error found

btw java files like this are created through protobuf, therefore if possible it would be useful to fix something here.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-4402?orig=1
Reporter: @hubertp

[scabug]

@hubertp said:
I am ok to have a look at it as I already spent some time debugging the underlying issue. But I just need info whether this is an actual bug.

[scabug]

@odersky said:
Nested classes in Java interfaces are implictily static, and Scala does not understand what protected means for a static member -- it simply does not fit in its model.
Anything we could possibly do here would be a giant, ugly hack. Essentially, introduce a different concept for protected (difficult enough as it is!) just for Java. I would really like to avoid that. So unless we are convinced that the Java examples are absolute must works, I would leave the ticket as a wontfix.

[scabug]

@hubertp said:
Cannot we somehow ignore Java errors in those well known situations? (maybe silently make it public to ignore further false errors). Not fixing this bug will mean we ignore some peculiarities of Java interoperability and unfortunately classes like this are really available in important projects. I would really hate to say "life is hard, don't use that library" in this case.

[scabug]

@odersky said:
The problem is, if we ignore, we could get situations where we allow the access but
it should not be allowed. So bytecode verification would fail. What we could do is ignore the error if all participants come from Java. This would probably fix the problem above, not sure how many others. I'll give it a try.

[scabug]

@odersky said:
(In r24734) Closes #4402. Review by plocinic.

[scabug]

vector said:
Hi, I think this bug should be reopened, I�observed the same kind of problem with the following example but with static inner classes.

I am using the Scala Eclipse Plugin with tho following version:
org.scala-ide.scala.compiler_2.9.0.r24747-b20110413101932

So I think the previous fix is included.

Test1.scala

import test2.Test2;

class Test1 extends Test2 {

  new Test2.A()
  
}

test2/Test2.java

package test2;

public class Test2 {

	protected static final class A {
		public A() {
			
		}
	}
}

The error is:
class A in object Test2 cannot be accessed in object test2.Test2
Access to protected class A not permitted because enclosing class class Test1 is not a subclass of object Test2 in package test2 where target is defined

Thank you very much.

[scabug]

@odersky said:
No, this one is a different problem (and a known one). There's simply no way to make sense of protected static in Java. It's an ill-conceived notion - just google for protected static and observe the first entry you get. The 4402 ticket was that we simply ignore access errors if all participants come from Java (on the assumption that the java compiler will know best anyway). In your example, the error is raised in Scala code.