Magnus, Jon,
As per your suggestions, I've split the ct.sym.txt into several files
approximately per (current) module. I've changed to format to a
baseline+change files as well. The biggest file is java.desktop baseline
(OpenJDK 7 content) which is 5MB, followed by java.base baseline whose
Magnus:
Looks good to me as well.
Tim
On 03/04/15 05:31, Erik Joelsson wrote:
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command
On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
I believe all warnings are important to check! Unfortunately, this has
not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of
warnings, it's just that we didn't keep up the
Hello,
JPRT builds on Solaris randomly fails. The failures look like the
typical problem of over allocating resources on Solaris. This time it
seems like it's too many instances of javadoc that overloads the machine.
My suggested fix is to use the JAVA_SMALL flags for all javadoc
Hello Erik:
JPRT builds on Solaris randomly fails. The failures look like the
typical problem of over allocating resources on Solaris. This time it
seems like it's too many instances of javadoc that overloads the machine.
My suggested fix is to use the JAVA_SMALL flags for all javadoc
I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
source libraries
and it may not always be possible to convince upstream to change their code.
-phil.
On 03/04/2015 08:30
I agree that configure should not mess with user's PATH and should
auto-find programs in /usr/ccs/bin only as a last resort.
It would be reasonable, when configure fails on Solaris, to notice that the
user does not have /usr/ccs/bin on PATH and suggest appending.
On Wed, Mar 4, 2015 at 12:31 AM,
The problem is that the makefiles do cleanup of the resource files,
accidentally deleting half of some strings. In this case
GC_INFO=Name = ''{0}'', Collections =
{1,choice,-1#Unavailable|0#{1,number,integer}}, Total time spent = {2}
becomes
GC_INFO=Name \= ''{0}'', Collections \=
I am about to introduce 2 APIs into jdk.dev so that people can call functions
of keytool and jarsigner directly. So what I am suggesting is
- Create jdk.security.util
- Move jarsigner, policytool to jdk.security.util
- Create the new APIs in this module
- Move keytool to jdk.security.util, it's
Build team,
Given the versatility of make clean and friends, I was surprised that
make clean-docs did not appear to be supported.
-- Jon
On Mar 5, 2015, at 11:25, Mandy Chung mandy.ch...@oracle.com wrote:
On 3/4/2015 6:55 PM, Wang Weijun wrote:
I am about to introduce 2 APIs into jdk.dev so that people can call
functions of keytool and jarsigner directly.
Are you referring to these 2 RFEs?
On 3/4/2015 6:55 PM, Wang Weijun wrote:
I am about to introduce 2 APIs into jdk.dev so that people can call functions
of keytool and jarsigner directly.
Are you referring to these 2 RFEs?
https://bugs.openjdk.java.net/browse/JDK-8056174
https://bugs.openjdk.java.net/browse/JDK-8058778
We
As listed in an open issue in JEP 200:
The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed or refactored.
Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in
the JDK that
Looks good to me.
/Erik
On 2015-03-03 14:45, Magnus Ihse Bursie wrote:
On 2015-03-03 13:01, Magnus Ihse Bursie wrote:
Open question: Should we do the same for toolchain-type=gcc? I'm not
quite sure what we're getting from calling the AC_PROG_OBJC macro,
except perhaps a loss of transparency
At least when we were building on Solaris 10 I think we needed to add
that to be sure to get the right tools. It might not be needed on
Solaris 11.
/Erik
On 2015-03-04 01:12, David Holmes wrote:
toolchain.m4 prepends /usr/ccs/bin to the PATH on Solaris, which is a
bad thing if you already
Hi,
recently a changed [1] was pushed to jdk9/hs-gc/hotspot which does not
compile neither with clang 5.1 nor with clang 4.0.
The OpenJDK Wiki [2] lists XCode / clang5.1.1 as the official compiler
tool chain for MacOS X so I wonder how this change could slip trough
JPRT without noticing the
On 2015-03-02 12:03, Erik Joelsson wrote:
Hello,
In JavaCompilation.gmk, between the definitions of SetupArchive and
add_file_to_copy, there is a partial block of code that looks like it
shouldn't be there. It seems to be part of the moved SetupZipArchive
and has most likely reappeared in
On 4/03/2015 6:24 PM, Erik Joelsson wrote:
At least when we were building on Solaris 10 I think we needed to add
that to be sure to get the right tools. It might not be needed on
Solaris 11.
It's not needed on Solaris 10 if you already have the right tools in
your path. :( Comment suggests it
Hello Volker,
We intended to switch to 5.1.1 and clang a long while back, but it never
went through. I don't know why the OpenJDK Wiki thinks it did. I'm
currently working on getting it done.
/Erik
On 2015-03-04 11:21, Volker Simonis wrote:
Hi,
recently a changed [1] was pushed to
When building the native code in the jdk repo, a lot of warnings are
generated. So many that it's hard to spot any new issues.
While the ultimate goal must be to address and fix these warnings
individually, this bug is about disabling these warnings where they
occur, so that it is easier to
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command line could be
copied to the shell for debugging in the future? Also, how hard
Hi Erik,
thanks for the info and good to see that there's at least one build
platform where we're ahead of the pack :)
Regards,
Volker
On Wed, Mar 4, 2015 at 11:37 AM, Erik Joelsson erik.joels...@oracle.com wrote:
Hello Volker,
We intended to switch to 5.1.1 and clang a long while back, but
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had warnings disabled. I expect the outcome of
On 2015-03-04 14:48, Alan Bateman wrote:
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had
24 matches
Mail list logo
