Seems like we can't/shouldn't fix this. We can at least make sure it is
documented.
Steve
On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it
would not be clear when there's e.g. a text property and text class if
we should set a property called text or create new text object and try
to assign it to the default property. The same problem with static
setters.
Is "hello.text.text" a fully qualified name of text class in or "text"
static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': "cSomeClass.java"
In the <?import ?> parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
&& i < n
&& Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
