Bug 39602 - problem when compiling/referencing static inner class
Summary: problem when compiling/referencing static inner class
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.0 M2   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-03 10:34 EDT by Luciano Mollea CLA
Modified: 2003-07-08 08:18 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luciano Mollea CLA 2003-07-03 10:34:25 EDT
Hi all.
sorry if this bug is a duplicate, but i can't find an easy description for this
problem in the database.

I have a class like this one:
---
public class StringRepository {
  public static final String MSG_1 = "...";
  public static final String MSG_2 = "...";

  public static class Keys extends StringRepository {
    public static final String KEY_1 = "...";
    public static final String KEY_2 = "...";
  }
  public static class Labels extends StringRepository {
    public static final String LBL_1 = "...";
    public static final String LBL_2 = "...";
  }
}
---
Pratically, this class is a container for Strings used here and there (and
everywhere) in the program (this strings are not to be localized and we'd prefer
not to use an hashtable as it's slower). Strings have been grouped in a
hierarchical manner.
Eclipse compiles this source perfectly.
Somewhere in the code a class creates an instance of a StringRepository like
this one:

private static StringRepository.Keys k = new StringRepository.Keys();

and then uses it like this:

Line 1: String f = ... + k.MSG_1;
Line 2: String g = ... + k.Labels.LBL_1;

/* 
please, don't comment on HOW PERVERT this thing is. It's not my fault and I
found it done this damned way (and this is not the only mind-twisting thing in
the code). If I only had time, I'd change all this thing from the ground up.
Problem is the damn thing works and no-one dares in any way touch it
*/

Problem is: Sun's javac compiles correctlym while Eclipse gives out these messages:
line 1: WARNING: f should be accessed in a static way
line 2: ERROR f.Labels cannot be resolved or is not a field

As I said, Sun's javac correctly compiles the classes and execution is OK
(correct values are inserted where expected).
As I said, Eclipse's compiler fails. I tried to look in the Java Language
Specification if I could find a hole into the static field definition, but it's
a matter for the language lawyers and I'm not one.

Sorry if things are not crystal clear, feel free to ask me if anything is not clear.

Thanks in advance.
Comment 1 Philipe Mulet CLA 2003-07-03 12:42:17 EDT
Accessing a type through variables is forbidden. Which version of javac does 
accept it ? I remember they wanted to support it, but backed out this idea 
fairly quickly.

Comment 2 Philipe Mulet CLA 2003-07-03 18:31:37 EDT
FYI, both javac 1.4.1 and jikes 1.18 agree with us:

X.java--------------------------------------
public class X {
	public static void main(String[] args) {
		X x = new X();
		System.println(x.XMember.S);
	}
	public static class XMember {
		public static final String S = "hello"; //$NON-NLS-1$
	}
}

>javac X.java
X.java:4: unexpected type
required: class, package
found   : variable
                System.out.println(x.XMember.S);
                                   ^
1 error

>jikes X.java -cp \jdk1.4.1\jre\lib\rt.jar

Found 1 semantic error compiling "X.java":

     4.                 System.out.println(x.XMember.S);
                                             ^-----^
*** Semantic Error: A type "XMember" was found where a field name or method call
 was expected. Did you mean to write "XMember.xxx", or "new XMember()", or ... ?



Ok to close ?
Comment 3 Philipe Mulet CLA 2003-07-03 18:38:04 EDT
Closing, please reopen if you disagree.
Comment 4 Luciano Mollea CLA 2003-07-08 08:18:42 EDT
True. Checked also myself with 1.4.0.
Although javac included in Sun JDK 1.3.1 compiles...
Thanks.