Request for review: Rework cause-chaining in Exceptions was:JDK 8 code review request for 6380161 (reflect) Exception from newInstance() not chained to cause.
alexandre.boulgakov at oracle.com
Wed Aug 17 14:34:01 PDT 2011
On 8/17/2011 2:04 PM, Sebastian Sickelmann wrote:
> Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
>> Hello Sebastian.
>> On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
>>> Am 17.08.2011 13:45, schrieb Alan Bateman:
>>>> joe.darcy at oracle.com wrote:
>>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add
>>>>> conventional constructors to InternalError" for it.
>>>> Thanks Joe, and to help this along here's the webrev with
>>>> Sebastian's patches:
>>>> I haven't really looked but one thing I did notice is that the
>>>> multi-catch usages need to be checked as Sasha cleaned up a few of
>>>> these recently.
>>> Thanks for the webrev.
>>> I think it is very hard to start with the complete patch. Or is it
>>> better to review it all at once?
>>> I have created a webrev for my patches 0 and 1 and uploaded it here:
>>> After i have pulled from tl/jdk i got problems with building.
>>> I got warnings so that i must build with JAVAC_WARNINGS_FATAL=false,
>>> is this ok for tl-repo?
>> You should not set JAVAC_WARNINGS_FATAL manually, and you can ignore
>> any preexisting warnings (although you should not introduce any new
>> ones). The makefiles where it is safe to compile with
>> JAVAC_WARNINGS_FATAL will set it appropriately. There is an ongoing
>> effort to reduce javac warnings (including lint warnings, which are
>> not currently enabled in all parts of the code). If you build with
>> JAVAC_MAX_WARNINGS=true, you will notice that there are just over
>> 10,000 javac build warnings in tl/jdk...
> OK. Actually there aren't any warnings. The are all gone after i did a
> make clean & make all.
> Can that be? Is there an issue like : "make all doen't find all
> changes to rebuild all dependencies", or is this a quite normal behavior?
That doesn't sound right... Are you sure there aren't any warnings? They
can get lost among the other output. If you are redirecting output to a
file and then checking for warnings, you should make sure to redirect
both the standard output (&1) and the standard error (&2) streams since
the output gets split between those.
That said, you shouldn't have as many as 10 000 on a normal build, but
there should be some coming from different tools including javac, the C
compiler, the linker, and more.
>>> -- Sebastian
More information about the core-libs-dev