Pending Character-related work - Character-warnings

Fri Jul 2 00:45:40 UTC 2010

I just tried to reproduce the failure ... and could not,
so it may have been either my fuzzy memory,
or perhaps some issue with the import JDK
not being sufficiently up to date.

Sorry for wasting bandwidth...

Standard response to

Q: Shouldn't we start using the diamond operator?
A: Yes.  Write a very clever script and convert the jdk sources.
Make sure the JDK can still be built from scratch using only jdk6.

Martin

On Thu, Jul 1, 2010 at 17:15, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Ulf,
>
> Have you tried it, and if so, what error do you get?   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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>