Request for Review: Java SE 8 Compact Profiles (original) (raw)

Kelly O'Hair kelly.ohair at oracle.com
Sat Dec 22 01:53:38 UTC 2012

On Dec 21, 2012, at 5:01 PM, David Holmes wrote:

On 22/12/2012 10:11 AM, Kelly O'Hair wrote:

On Dec 21, 2012, at 3:27 PM, David Holmes wrote:

On JarReorder.java, it seems like you have just deleted a warning that someone explicitly asked for a class to be included, and also explicitly asked for that class to be excluded. If we are changing the tool so that exclusion just silently trumps any inclusion request, seems like we should just do that and delete this message. I'm fine with that, but the if(false) seems a bit terse.

Yes ideally this change will trigger a closer look at jarreorder and how it is used. AFAIK those listings have been decaying. But the warning message was far too noisy for the profiles builds. I did not want to go down a path of trying to define per-profile reorder lists given that we haven't maintained this for the full JRE anyway. Can we add a comment as to that being the reason for the if(false)? Maybe file a separate Issue to fix it someday, or maybe toss the whole ball of JarReorder wax someday. ;^) Okay I'll add a comment and comment out the line and see if there is an existing CR to revisit jarreorder.

OK.

Why are some of the makefiles named with a ".txt" suffix? Like makefiles/profile-includes.txt? Because they aren't makefiles ;-) They are txt files that define named lists that happen to be compatible with makefile variable declarations. But they aren't plain text files, right? What is a plain text file ??? They look like make variable declarations, they also look like property definitions. I liken these files to the version.numbers file that happen to contain stuff that looks like makefile variable declarations - should they be .gmk files too?

I guess what I'm saying is that they have a particular syntax, it's not arbitrary text. Leave them as is, we can deal with it later.

These lists also get used by other tools eg javac and javadoc. Do we have any convention for the file suffix on these yet? Or is the long term plan to just use .txt? Right now it is the .txt. If we want/need to change this then now is the time as I'll have to sync this with the langtools changes. Not a huge deal to change later I suppose. But I'm not sure there is any obviously better choice.

I'd have to think about it more. I'm fine with leaving them as .txt files for now.

Unfortunately, everybody on build-infra will be busy for a few weeks trying to get the cutover done. :^(

Not to mention the Xmas/NewYear break. :( Yeah, might be a limited vacation for some of us. Limited vacation, limited weekends, ... ;-)

Yup. :^(

-kto

David

-kto

Thanks, David

-kto

More information about the core-libs-dev mailing list