Need reviewer

[Kelly O'Hair]

6888701: Change all template java source files to a .java.template file suffix

http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/

-kto

[jonathan.gibbons]

Kelly O'Hair wrote:
>
> 6888701: Change all template java source files to a .java.template
> file suffix
>
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ 
>
>
> -kto
Looks good to me -- but I think you should get approval from the owners
of the src/* files as well.

-- Jon

[Mark Reinhold]

> Date: Sun, 11 Oct 2009 17:35:31 -0700
> From: kelly.ohair@...

> 6888701: Change all template java source files to a .java.template file suffix
>
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/

Most of the files you are renaming in this change are in NIO, and the
names of those files were carefully chosen so as to be invalid Java
class names -- they all contain at least one dash character.

This approach has the advantage that when you visit the files in an
editor or IDE they're treated as Java source files without any further
effort.  This is a feature, not a bug as claimed in 6888701.

I'd like to understand more about the complications in Makefile logic
claimed in 6888701.  If this is such a problem then why are we just
now getting around to fixing it?

- Mark

[jonathan.gibbons]

I doubt this is driving Kelly's work, but I note that with exotic identifiers added in JSR292, any JVMS name is a legal Java identifier.   Thus these files have potentially valid class names.

The interaction with an IDE can be inconvenient, since the IDE is likely to handle these files incorrectly.  langtools did this cleanup quite a while back for this reason.

-- Jon


Mark Reinhold wrote:

Date: Sun, 11 Oct 2009 17:35:31 -0700
From: kelly.ohair@...
    

6888701: Change all template java source files to a .java.template file suffix

http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/
    

Most of the files you are renaming in this change are in NIO, and the
names of those files were carefully chosen so as to be invalid Java
class names -- they all contain at least one dash character.

This approach has the advantage that when you visit the files in an
editor or IDE they're treated as Java source files without any further
effort.  This is a feature, not a bug as claimed in 6888701.

I'd like to understand more about the complications in Makefile logic
claimed in 6888701.  If this is such a problem then why are we just
now getting around to fixing it?

- Mark
  

[Kelly O'Hair]

Mark Reinhold wrote:

>> Date: Sun, 11 Oct 2009 17:35:31 -0700
>> From: kelly.ohair@...
>
>> 6888701: Change all template java source files to a .java.template file suffix
>>
>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/
>
> Most of the files you are renaming in this change are in NIO, and the
> names of those files were carefully chosen so as to be invalid Java
> class names -- they all contain at least one dash character.
>
> This approach has the advantage that when you visit the files in an
> editor or IDE they're treated as Java source files without any further
> effort.  This is a feature, not a bug as claimed in 6888701.
>
> I'd like to understand more about the complications in Makefile logic
> claimed in 6888701.  If this is such a problem then why are we just
> now getting around to fixing it?

I have been trying to change some of the Makefiles to use the GNU make
functions and everything is easier when knowing that a file ending in
.java is really input for javac. Filtering is easier.

We have at least 3 conventions being used for processing java source files:
*-template.java, *X-*.java, and *.java.template. By far the easiest one
to deal with in build scripts (make and ant) is the *.template convention.
I'm just trying to normalize this to one convention that is the easiest
to deal with in build scripts and for IDEs.

I know these files have been around for ages, and if IDE's treated them as
valid java sources files back then, I suspect the newer IDE's might have
figured out by now that they are not java source files.
NetBeans will let you open any file, and when I open these files with the
*.java suffix, I get hundreds of error indicators, but when opened as
*.java.template files, they appear as normal files with no error indications.
NetBeans doesn't know what these files really are anyway.

The complications in the Makefiles is that every time you want a list of
java sources from a directory to compile, you have to have a special exclude
list to remove all these files: X-*.java *-X-*.java *-template.java
It's a pain, in make files or in ant scripts.

-kto

>
> - Mark

[jonathan.gibbons]

NetBeans, and other IDEs that try to do "compilation on the fly", will
definitely have trouble with these files.

Lesser IDEs, like emacs, could presumably be taught to recognize
*.java.template as a Java file for Java mode.

-- Jon

Kelly O'Hair wrote:

>
> Mark Reinhold wrote:
>>> Date: Sun, 11 Oct 2009 17:35:31 -0700
>>> From: kelly.ohair@...
>>
>>> 6888701: Change all template java source files to a .java.template
>>> file suffix
>>>
>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ 
>>>
>>
>> Most of the files you are renaming in this change are in NIO, and the
>> names of those files were carefully chosen so as to be invalid Java
>> class names -- they all contain at least one dash character.
>>
>> This approach has the advantage that when you visit the files in an
>> editor or IDE they're treated as Java source files without any further
>> effort.  This is a feature, not a bug as claimed in 6888701.
>>
>> I'd like to understand more about the complications in Makefile logic
>> claimed in 6888701.  If this is such a problem then why are we just
>> now getting around to fixing it?
>
> I have been trying to change some of the Makefiles to use the GNU make
> functions and everything is easier when knowing that a file ending in
> .java is really input for javac. Filtering is easier.
>
> We have at least 3 conventions being used for processing java source
> files:
> *-template.java, *X-*.java, and *.java.template. By far the easiest one
> to deal with in build scripts (make and ant) is the *.template
> convention.
> I'm just trying to normalize this to one convention that is the easiest
> to deal with in build scripts and for IDEs.
>
> I know these files have been around for ages, and if IDE's treated
> them as
> valid java sources files back then, I suspect the newer IDE's might have
> figured out by now that they are not java source files.
> NetBeans will let you open any file, and when I open these files with the
> *.java suffix, I get hundreds of error indicators, but when opened as
> *.java.template files, they appear as normal files with no error
> indications.
> NetBeans doesn't know what these files really are anyway.
>
> The complications in the Makefiles is that every time you want a list of
> java sources from a directory to compile, you have to have a special
> exclude
> list to remove all these files: X-*.java *-X-*.java *-template.java
> It's a pain, in make files or in ant scripts.
>
> -kto
>
>>
>> - Mark

[Mark Reinhold]

Okay, I can live with this.

(At the risk of stating the obvious: Please be sure to use hg mv when
 you rename these files, otherwise the historical changeset trail will
 be broken.)

- Mark

[Kelly O'Hair]

Mark Reinhold wrote:
> Okay, I can live with this.
>

Thanks.

> (At the risk of stating the obvious: Please be sure to use hg mv when
>  you rename these files, otherwise the historical changeset trail will
>  be broken.)

Will do.

-kto

>
> - Mark

[Alan Bateman]

Kelly O'Hair wrote:

>
>
> Mark Reinhold wrote:
>> Okay, I can live with this.
>>
>
> Thanks.
>
>> (At the risk of stating the obvious: Please be sure to use hg mv when
>>  you rename these files, otherwise the historical changeset trail will
>>  be broken.)
>
> Will do.
>
> -kto

Sorry, I wasn't paying attention to this thread. Renaming these sources
to -template is okay with me (although I kinda liked the -X convention).

-Alan.