- This topic has 27 replies, 5 voices, and was last updated 21 years, 3 months ago by
.
-
Posts
-
Hmm… Michael where does this leave things? Will ME make this change now or should we send BEA hatemail?
Hate mail to BEA will probably be ineffective, or at least painfully slow. Instead, I’ve added an enhancement request to allow the user to specifically select to relax spec compliance and have our validator allow either $ or . as the inner class seperator.
–Scott
MyEclipse SupportFrom skkunkk’s prior post:
I have tested the application you sent and I saw the same issue. After going through the issue notes, I found out that BEA recommends that users always use the $ sign with inner classes and not the . sign. This is what our jsp developer has to say about this issue :
—————————————————————————————————————————————————————————————————-
“So we must recommend to customers to always use ‘$’ for an inner class within jsp:useBean and internally change the $ to a . for generating types. e.g
given foo.Bar$Inner
generated code should look like
foo.Bar.Inner test = (foo.Bar.Inner) Beans.instantiate(classloader,”foo.Bar$Inner”);
The fix would be simple and would have to be made in JspLexer i think.
(Aside: even sun’s urlclassloader doesnt support ‘.’ notation for classloading i.e class.forName(“foo.Bar.Inner”) in the above case will give you a ClassNotFoundException)”
—————————————————————————————————————————————————————————————————-In another case, one person raised a question as to why the javap command allows “.” with innerclass while the jsp container does not. According to the developer :
—————————————————————————————————————————————————————————————————-
“This is due to a variation in the way javap and java class loaders search for class files. I don’t know why this variation exists, but the difference is lower level than WLS. We could probably modify our class finders to use a similar algorithm as javap, but I don’t think we should because then we would have different behavior depending on whether the class was in the webapp or the system classpath. Since the system classes are still loaded with a java classloader, we don’t have control over the search algorithm.”
—————————————————————————————————————————————————————————————————-Thus, it seems that WebLogic will only support $ and not . with nested classes.
It not only appears that ‘$’ works, it also says that using ‘.’ will not. Skkunkk, will you please verify that this is what you’re seeing?
–Scott
MyEclipse SupportAn example what can happen by using the ‘$’:
< ... type="foo.X$$$$$Y" ...>could be interpreted as:
foo.X$$$$$Y - a class named X$$$$$Y in package foo foo.X.$$$$Y - an inner class $$$$Y of class X in package foo foo.X$.$$$Y - an inner class $$$Y of class X$ in package foo foo.X$$.$$Y - an inner class $$Y of class X$$ in package foo foo.X$$$.$Y - an inner class $Y of class X$$$ in package foo foo.X$$$$.Y - an inner class Y of class X$$$$ in package foo foo.X.$.$$Y - an inner class $$Y of an inner class $ of class X in package foo foo.X.$$.$Y - an inner class $Y of an inner class $$ of class X in package foo foo.X.$$$.Y - an inner class Y of an inner class $$$ of class X in package foo foo.X$.$.$Y - an inner class $Y of an inner class $ of class X$ in package foo foo.X$.$$.Y - an inner class Y of an inner class $$ of class X$ in package foo foo.X$$.$.Y - an inner class Y of an inner class $ of class X$$ in package foo foo.X.$.$.Y - an inner class Y of an inner class $ of an inner class $ of class X in package fooNOP
While NOP is technically correct, and obviously has read both the JLS and the JSP specs, interpreting the $ as he noted would be perfectly acceptable, provided the user loosened up the proposed compliance setting. It makes perfect sense. If they choose to compile with full compliance, then the offending line will be marked as an error as the spec states. But the user still gets to choose, and if he chooses to loosen spec compliance he also looses the ability to create top level classes with $ in there name. Of course, I’ve never seen anyone actually do this, since only those of us who’ve really read the specs would even know you could. 😉
–Scott
MyEclipse Support… well, I use a lot of generated code, and I like it to distinguish generated code from user code by having the ‘$’.
So changing this behaviour might open a new bug like
“cannot use classes containg a ‘$’ in its name with jsp:useBean”… I am not BEA, so I am the weaker one.
NOP
I like the foo example. I have asked for a bit more clarification from BEA. Fingers crossed they will recognise it as a bug (I am not holding my breath). I hope that they can fix the problem but in the mean time thanks to MyEclipse for the idea of a code compliance switch. This should allow me to get the go ahead to purchase licenses for our dev team.
It seems from all the input will actually satisfy everyone. NOP can leave the validator in a fully compliant configuration so that he won’t have problems with generated code, and the BEA users can “soften it” a bit so that MyEclipse will accept the BEA-specific non-compliant format.
–Scott
MyEclipse SupportThere is a sun bug 4628117 (from Jan 24, 2002) that addresses this problem and suggests a change to the jls wording for inner class representation from “fully qualified name” to “binary name”. See the following links
http://developer.java.sun.com/developer/bugParade/bugs/4628117.html
http://developer.java.sun.com/developer/bugParade/bugs/4378381.html
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44909Funny to read the thread 4378381: Closed, will not be fixed.
So they missed the chance to do a general clarification.
Simplest solution:
– disallow ‘$’ in names => $ clearly marks an inner class
e.g.
class f$o$o // is invalid then
– require ‘$’ in types => clearly specifiy inner classes
e.g.
A.B b1; // class B in package A
A$B b2; // inner class B of class ABut there is one even simpler solution:
Kick the butt, if someone makes inner classes public available.
HNY 2004
NOP
