Hello Mandy,
Looks good. Just noticed another thing in CheckModules.gmk. You can
remove the explicit FIXPATH as the variable JAVA already contains it. In
general, only spec.gmk should need to worry about FIXPATH.
If there are no other changes, I don't need to see another round before
you pus
On 2014-08-28 18:24, Volker Simonis wrote:
This looks safe, but it's not clear why it needs to be done so it certainly
warrants a comment. Another approach on this would be to find a different
way of expressing FIND_DELETE on AIX that works better. Perhaps an xargs
construct? FIND_DELETE is de
From a build point of view, this looks fine.
/Erik
On 2014-08-28 20:34, Naoto Sato wrote:
Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
changes based on your suggestions as follows:
http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
Here are the changes since webrev
On 2014-08-28 21:40, Phil Race wrote:
On 8/28/2014 12:36 PM, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun
On 2014-08-28 21:36, Phil Race wrote:
>./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
Is a tool that is run manually when we need to re-generate the shaders.
It is co-located so that can be found easily. It certainly should not be
deleted, nor should it be moved anywhere obscure.
Oh,
Hi,
On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote:
>
> On 2014-08-28 18:24, Volker Simonis wrote:
>>
>>
>>> This looks safe, but it's not clear why it needs to be done so it
>>> certainly
>>> warrants a comment. Another approach on this would be to find a different
>>> way of expressing FI
On 2014-08-29 11:06, Volker Simonis wrote:
Hi,
On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote:
On 2014-08-28 18:24, Volker Simonis wrote:
This looks safe, but it's not clear why it needs to be done so it
certainly
warrants a comment. Another approach on this would be to find a differe
This is an old but trivial bug that I want to fix.
Dmitry Samersoff discovered that LOG=trace
only works if bash is in /bin. He also suggested this patch.
Bug: https://bugs.openjdk.java.net/browse/JDK-8027627
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8027627-dont-hardcode-bash/webrev.01
Looks good. I will push it for you.
/Erik
On 2014-08-29 11:06, Volker Simonis wrote:
Hi,
On Fri, Aug 29, 2014 at 9:22 AM, Erik Joelsson wrote:
On 2014-08-28 18:24, Volker Simonis wrote:
This looks safe, but it's not clear why it needs to be done so it
certainly
warrants a comment. Another
On 2014-08-22 16:20, Erik Joelsson wrote:
Thanks for looking into this. I took the liberty of tuning this some
more and finally arrived at this set of changes:
http://cr.openjdk.java.net/~erikj/8014510/webrev.root.01/
First of all I wanted to get rid of the big if-else construct, so I
changed
On 28/08/2014 19:34, Naoto Sato wrote:
Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
changes based on your suggestions as follows:
http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
Here are the changes since webrev.3
- CLDRLocaleProviderAdapter.java: modified to thr
Hello Magnus:
This is an old but trivial bug that I want to fix.
Dmitry Samersoff discovered that
LOG=trace only works if bash is in /bin. He also suggested this patch.
Bug: https://bugs.openjdk.java.net/browse/JDK-8027627
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8027627-dont-hardcode-
Since BASH is set by configure, it makes sense to use that value. OK
from me.
/Erik
On 2014-08-29 11:40, Magnus Ihse Bursie wrote:
This is an old but trivial bug that I want to fix.
Dmitry Samersoff discovered that
LOG=trace only works if bash is in /bin. He also suggested this patch.
Bug
On 8/28/14, 5:11 PM, Mandy Chung wrote:
Naoto,
This looks better. Thanks for the update.
The getSupportedLocaleString method in both EnLocaleDataMetaInfo and
NonEnLocaleDataMetaInfo has the javadoc that missing the description.
sun.util.locale.provider is a package in java.base and
NonEnLocal
On 8/29/14, 6:29 AM, Alan Bateman wrote:
I'm still not sure about CLDRLocaleProviderAdapter throwing UOE when
iterating over the installed LocaleDataMetaInfo implementations fail. It
almost feels like it should be an InternalError as it could only mean
something wrong with the JDK code or someth
I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev was to revert the hard-coding of the supported
locales list back to the one which dynamically generates the lists at
the build time. I initially thought static listing of locales would be
less complex as t
16 matches
Mail list logo
