FXMLLoader <?import?> checking code conventions too much?

[Stephen F Northover]

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.
>>
>