Pending Character-related work - Character-warnings

Fri Jul 2 00:33:14 UTC 2010

Am 02.07.2010 02:15, schrieb Jonathan Gibbons:
> Ulf,
>
> Have you tried it, and if so, what error do you get?

Sorry, no. It was Martin. I don't know the exact error message.
Building the whole JDK is outside my resources (Windows, labtop, etc.) :-( .
Anyway thanks for your time.

-Ulf

>    If you get an error, this may be a fault in the Makefiles for this 
> part of the system, using the wrong macro to get at javac.   That's 
> what I was trying to get at in my previous message.  However, I'm not 
> an expert on this part of the code, I'm just trying to explain 
> generalities here. There may be reasons I don't know about why this 
> needs to be compilable by the BOOT JDK.
>
> Separately, I know at some point, Joe was planning to have a concerted 
> effort to diamond-ize the JDK code base in areas where that is 
> technically reasonable (i.e. not javac etc.)
>
> -- Jon
>
>
> On 07/01/2010 04:51 PM, Ulf Zibis wrote:
>> Jonathan,
>>
>> much thanks.
>>
>> My question is not about the generated parts, it's about following lines
>>
>>  652         private static Map<String, UnicodeBlock>  map
>>  653             = new HashMap<String, UnicodeBlock>(256);
>>
>> in 
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Character-warnings/src/share/classes/java/lang/Character.java.sdiff.html 
>>
>> where JDK-7 compiler returns a warning: "redundant type arguments in 
>> new expression (use diamond operator instead).".
>>
>> If coded as:
>>
>>  652         private static Map<String, UnicodeBlock>  map  = new 
>> HashMap<>(256);
>>
>> Martin said, this doesn't work, because j.l.Character must be 
>> compilable by the bootstrap JDK which is JDK-6.
>> This I don't understand in reference to what you said: "... and all 
>> the code in the jdk/ repo can be built with the latest language 
>> features."
>>
>> -Ulf
>>
>>
>>
>> Am 02.07.2010 01:22, schrieb Jonathan Gibbons:
>>> Ulf,
>>>
>>> As complicated as the build is now, it used to be way more 
>>> complicated.  I suspect you're just seeing a bit of history leaking 
>>> into that part of the build.   Because some of the code in the 
>>> java.lang.Character area is automatically generated, it has its own 
>>> special Makefile rules, so I suspect it has slipped through the 
>>> cracks to make sure the files that get generated are compiled with 
>>> the latest compiler to -target 7 class files.
>>>
>>> -- Jon
>>>
>>>
>>> On 07/01/2010 04:11 PM, Ulf Zibis wrote:
>>>> Jonathan, Kelly,
>>>>
>>>> thanks for your short but excellent descriptive explanation.
>>>> It mainly reflects how I understood the build process in general.
>>>> Can you briefly answer my questions below?
>>>>
>>>> Am 01.07.2010 18:13, schrieb Kelly O'Hair:
>>>>>
>>>>> On Jul 1, 2010, at 7:56 AM, Jonathan Gibbons wrote:
>>>>>
>>>>>> On 07/01/2010 01:32 AM, Ulf Zibis wrote:
>>>>>>> Am 01.07.2010 09:38, schrieb Martin Buchholz:
>>>>>>>> On Wed, Jun 30, 2010 at 23:49, Ulf Zibis<Ulf.Zibis at gmx.de>  wrote:
>>>>>>>>> Am 30.06.2010 19:50, schrieb Martin Buchholz:
>>>>>>>>>> On Wed, Jun 30, 2010 at 01:22, Ulf Zibis<Ulf.Zibis at gmx.de>    
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Am 29.06.2010 02:29, schrieb Martin Buchholz:
>>>>>>>>>>>> I tried to do that, but Character.java is one of those classes
>>>>>>>>>>>> that needs to be compilable by the bootstrap JDK,
>>>>>>>>>>>> so this change ist leider nicht moeglich.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I think, there should be a note about this in the sources of 
>>>>>>>>>>> those
>>>>>>>>>>> classes.
>>>>>>>>>>>
>>>>>>>>>> Such a note is likely to become obsolete soon.
>>>>>>>>>>
>>>>>>>>> How do you mean that? Will the build procedure change soon. 
>>>>>>>>> Then it would be
>>>>>>>>> anyway appropriate to update to new "style".
>>>>>>>> In jdk8, the bootstrap jdk will be at least jdk7.
>>>>>>>
>>>>>>> It would make me wonder if there wont come new language extensions.
>>>>>>> I was thinking about a comment (in all bootstrap compiled 
>>>>>>> classes) which couldn't become obsolete like:
>>>>>>> "Don't use latest language extensions in this class. It's one of 
>>>>>>> those which must be compilable by the bootstrap JDK while 
>>>>>>> building this JDK. Add @suppressWarnings if appropriate."
>>>>>>>
>>>>>>> Anyway, couldn't we use the latest existing JDK-7 build for 
>>>>>>> bootstrap? Then we could update the sources 2 weeks later.
>>>>>>> ... or use 2 versions for bootstrap and library as said before.
>>>>>>>
>>>>>>> -Ulf
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Ulf,
>>>>>>
>>>>>> I suggest you go read blogs by Kelly (http://blogs.sun.com/kto/) 
>>>>>> and myself (http://blogs.sun.com/jjg/) on the process of building 
>>>>>> the JDK. The boot JDK is always the latest available FCS product 
>>>>>> (i.e JDK 6 for JDK 7), but the first thing done in the build is 
>>>>>> to build a hybrid javac that runs on the boot JDK and which 
>>>>>> understands the latest language.  Therefore, with the exception 
>>>>>> of javac and related tools that are used during the bootstrap 
>>>>>> (e.g. javah) most of the JDK, and all the code in the jdk/ repo 
>>>>>> can be built with the latest language features.
>>>>
>>>> I understand this, that all classes in jdk7/tl are compiled by 
>>>> source=7 level.
>>>> Is that correct?
>>>> In particular, why should j.l.Character then be compilable by 
>>>> source=6 level, as Martin said?
>>>> If so, is it thinkable to have 2 versions, one for the bootstrap 
>>>> and one for the final JDK7 library, so the latter would be "clean" 
>>>> for the source=7 level?
>>>>
>>>> -Ulf
>>>>
>>>>
>>>>>>
>>>>>> There may however be historical reasons why some classes still 
>>>>>> get special treatment; those would need to be examined on a case 
>>>>>> by case basis.
>>>>>>
>>>>>
>>>>> I think some of the source generation tools may require a 'dumbing 
>>>>> down' of the source, I forget the exact details.
>>>>>
>>>>> The jdk/make/tools/src tools are supposed to be built with the 
>>>>> BOOT jdk (jdk6), and in general are small utility tools
>>>>> that need to be run before the jdk7 image exists, but are not 
>>>>> technically part of the jdk7 image.
>>>>> So like langtools, they need to be BOOT jdk flavored sources, or 
>>>>> have a way to run with a BOOT jdk.
>>>>>
>>>>> -kto
>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>