> On Mar 5, 2015, at 11:25, Mandy Chung 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?
> https://bugs.openjdk.java.net/browse/JDK
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 hav
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 n
Build team,
Given the versatility of "make clean" and friends, I was surprised that
"make clean-docs" did not appear to be supported.
-- Jon
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
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 AM
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 \= {1,choi
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
invoca
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
invocations
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 li
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 effo
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
s
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 w
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
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 wrote:
> Hello Volker,
>
> We intended to switch to 5.1.1 and clang a long while back, but it never
> went throu
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 would
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 sp
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 jdk9/hs-
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 probl
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 Jav
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
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 hav
You are good to go.
/Erik
On 2015-03-03 19:28, Steven Loomis wrote:
OK, thanks.
Do I need a second or ready to commit?
On 3/3/2015 1:14 AM, Erik Joelsson wrote:
Still looks good.
(We usually skip the generated-configure in the review since it's
generated and quite large, at least if we rem
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 o
25 matches
Mail list logo
