On 2015-05-21 21:59, mark.reinh...@oracle.com wrote:
2015/5/21 12:01 -0700, jan.lah...@oracle.com:
This is a patch adding a new option, -platform, to javac.
Patch for the top-level repository is here:
http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/
Patch for the langtools
If you want a script/hack solution, you should be able to do something
like this:
make java.base-java-only JDK_FILTER=package/that/you/changed make
jimages-only
That's likely the best I can do. If you need a real image, it has to be
linked from scratch each time. If the exploded image is
The build change looks fine, thanks for fixing this!
/Erik
On 2015-05-22 02:42, Roger Riggs wrote:
Oops, got the wrong host:
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/
Issues:
8074818: Resolve disabled warnings for libjava
8080007: Stop ignoring
On 22/05/2015 01:42, Roger Riggs wrote:
Oops, got the wrong host:
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/
Issues:
8074818: Resolve disabled warnings for libjava
8080007: Stop ignoring warnings for libjava
Thanks, Roger
In JDK_GetVersionInfo0 then
On 22.5.2015 08:49, Erik Joelsson wrote:
On 2015-05-21 21:59, mark.reinh...@oracle.com wrote:
2015/5/21 12:01 -0700, jan.lah...@oracle.com:
This is a patch adding a new option, -platform, to javac.
Patch for the top-level repository is here:
On 2015-05-22 02:46, Mandy Chung wrote:
I’m including build-dev and we need to ask for Erik and Magnus advice what’s
the best way to work around this.
Erik, Magnus,
Security providers now become service providers. They are provided from 11
different modules, 3 of them are os-specific.
On 22/05/15 07:58, Erik Joelsson wrote:
On 2015-05-22 02:46, Mandy Chung wrote:
I’m including build-dev and we need to ask for Erik and Magnus advice
what’s the best way to work around this.
Erik, Magnus,
Security providers now become service providers. They are
provided from 11
Hi Alan,
The change to make the assert about the build numbers in getVersionInfo
should be a different issue.
Perhaps it makes sense to do that as part of the JEP 223: New
Version-String Scheme
that is specific to the Oracle JDK.
Thanks, Roger
On 5/22/2015 2:55 AM, Alan Bateman wrote:
On 22.5.2015 14:52, Maurizio Cimadamore wrote:
Excellent work.
I think the comment in CreateSymbols could be made clearer w.r.t. Probe
- i.e. that Probe should be ran on top of the JDK N - i.e.
JDK-8/bin/java Probe -- classes-8
JDK-7/bin/java Probe -- classes-7
JDK-6/bin/java Probe --
Hi,
I've uploaded a new iteration of the patch(es):
top-level repository:
http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/
langtools:
http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/
(besides full webrevs, there are also webrevs showing the differences
between
Excellent work.
I think the comment in CreateSymbols could be made clearer w.r.t. Probe
- i.e. that Probe should be ran on top of the JDK N - i.e.
JDK-8/bin/java Probe -- classes-8
JDK-7/bin/java Probe -- classes-7
JDK-6/bin/java Probe -- classes-7
etc.
Maurizio
On 22/05/15 13:38, Jan
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class names, not provider names, so the fallback
JDK-8027584 disabled ccache by default, I gather because it doesn't work in
Cygwin, and secondarily because of vague general problems with it.
The documentation (README-builds.html) still unambiguously endorses it,
although doesn't say anything about how to turn it on (configure with
On 05/22/2015 08:09 AM, Alan Bateman wrote:
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class
I plan to have review comments later today.
On Thu, May 21, 2015 at 2:09 PM, Roger Riggs roger.ri...@oracle.com wrote:
Please review these native code and build changes to clear compilation
warnings.
Most are due to mixing unsigned types with signed types or providing
the correct type to an
It's a good idea to order include statements by system dependencies, jdk
dependencies, implementation helpers, BUT order of include statements
should never ever matter. If it does, then we have a bug that should be
fixed. Every header file should be independently includable, and C files
should
On May 22, 10:54am, marti...@google.com (Martin Buchholz) wrote:
-- Subject: Re: RFR 9: 8074818: Resolve disabled warnings for libjava
| I agree it's a good idea to increase safety by replacing calls to *printf
| with calls to *nprintf, BUT when we do so we should also add debugging
| assertions
17 matches
Mail list logo
