What's problematic about executables?
Certainly we want to avoid storing actual binary executables in repos.
I've also seen problems on other projects where Windows clients had stored
files (perhaps via Samba) on Unix systems and the files ended up getting their
execute bits set. I agree, this
We've run into this before; this is quite irritating. The bug is logged as
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6668018
Basically you can't do a jdk-subrepo-only build within a forest where you've
already done a full forest build. Attempting to do otherwise confuses the build
sys
Please review this change to add to the javac make rule some messages about the
number of files being compiled, the current working directory, and a new
message to demarcate the end of javac output.
This will help capture and analyze javac output, in particular, warning
messages.
Thanks.
s'm
On 11/28/11 7:00 PM, David Holmes wrote:
On 29/11/2011 10:42 AM, Stuart Marks wrote:
Please review this change to add to the javac make rule some messages
about the number of files being compiled, the current working directory,
and a new message to demarcate the end of javac output.
This
Thanks Kelly (and David).
Any objection if I were to push this into the TL forest? A test build on all
the platforms (including Windows) was successful.
s'marks
On 11/29/11 11:13 AM, Kelly O'Hair wrote:
Looks fine to me.
-kto
On Nov 28, 2011, at 8:00 PM, Stuart Marks wrote:
The webrev is here:
http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.0/
This defines the JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL variables in a
variety of Makefiles within the jdk repository. This essentially adds
-Xlint:all -Werror to the javac command lines, so that henceforth i
Yeah, that was me. I'll make sure this is fixed before the -Werror changes go
in.
s'marks
On 12/16/11 6:13 AM, Chris Hegarty wrote:
I filed CR 7122235 for this issue.
Forcing a compile time error of a JDK class by inserting some bad code is just
ignored and the build continues, and appears to
Here's a fix I'm working on. I'm still doing test builds but I wanted to get
this in front of people pretty quickly.
The initial diagnosis was correct; adding an "echo" (or some other command)
after the javac will prevent javac's failure code from reaching make and thus
not stopping the build
11 5:58 AM, Stuart Marks wrote:
Here's a fix I'm working on. I'm still doing test builds but I wanted to
get this in front of people pretty quickly.
The initial diagnosis was correct; adding an "echo" (or some other
command) after the javac will prevent javac's failure code
On 12/15/11 9:23 PM, David Holmes wrote:
On 16/12/2011 12:59 PM, Stuart Marks wrote:
http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.0/
Looks fine but ...
This defines the JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL variables
in a variety of Makefiles within the jdk repository
On 12/16/11 2:39 AM, Chris Hegarty wrote:
On 12/16/11 09:57 AM, Alan Bateman wrote:
Stuart - the changes look okay to me but it would be good to get
confirmation that you've done both full and partial builds with these
changes. Also I think we need confirmation that incremental builds in
each of
On 12/20/11 6:28 PM, Stuart Marks wrote:
On 12/16/11 2:39 AM, Chris Hegarty wrote:
On 12/16/11 09:57 AM, Alan Bateman wrote:
Stuart - the changes look okay to me but it would be good to get
confirmation that you've done both full and partial builds with these
changes. Also I think we
It's not enough to *set* ALT_BOOTDIR, it also needs to be *exported* to the
environment. If it's not exported, the variable is visible in your shell but
isn't visible to subprocesses such as make. It looks like that's what's going
on here.
How you export something to the environment depends on
On 12/22/11 3:52 AM, Alan Bateman wrote:
Just on terminology, when I use the term "partial" build then I meant building
a subset of the repositories with an import JDK providing the per-built bits
from the other repositories. I think this is what most folks working in the jdk
repository do, at
On 12/22/11 1:51 PM, Kelly O'Hair wrote:
On Dec 22, 2011, at 12:46 PM, Joe Darcy wrote:
As an aside, I've thought it was a bit of design error that implicit
compilation was the default.
Me too.
Since JDK 6 there has been a javac option that can be used to disable
implicit compilation, -impli
Hi all, here's any updated webrev for this fix:
http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.1/
Changes from the previous webrev:
* I've withdrawn the addition of -Werror from several Makefiles. There are two
reasons. First, some of these had a single warning, causing javac to
8/11 12:58 AM, chris hegarty wrote:
Looks fine to me.
Let's resync after this push and see if there is some low hanging fruit we can
pick, like the areas with 1 warning?
-Chris.
On 28/12/2011 01:57, Stuart Marks wrote:
Hi all, here's any updated webrev for this fix:
http://cr.op
Looks good to me too. I've updated the Mac build instructions on the wiki to
state that LANG should be set.
s'marks
On 3/15/12 9:30 AM, Kelly O'Hair wrote:
Looks fine to me.
-kto
On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote:
Can I get the following jdk8 change reviewed please?
It is
call /usr/libexec/java_home -v 1.7+ on
their own, and only balk if there is not sufficient OpenJDK installed.
Regards,
Mike Swingler
Apple Inc.
On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote:
Looks good to me too. I've updated the Mac build instructions on the wiki to
state that LANG sho
Hi Martijn!
One of my colleagues ran into this the other day. I don't know all the details
and the solution but I have a clue that might help you move forward.
In make/common/shared/Sanity.gmk there are the lines,
_ANT_VER:=$(shell $(ANT) -version 2>&1 )
ANT_VER:=$(call GetVersion,"$(_ANT_VE
Hi all,
The JDI tests have proven to be fairly unstable and are causing a lot of
spurious failures in our JPRT and nightly jobs. Instead of moving all the tests
into the problem list, we've decided to move the 'jdk_jdi' test target out of
the 'core' testset so they won't get run regularly unti
Thanks guys, pushed into tl and tl/jdk.
s'marks
On 11/29/12 1:18 AM, Chris Hegarty wrote:
Thanks Stuart, looks good.
-Chris.
On 11/29/2012 08:14 AM, Alan Bateman wrote:
On 29/11/2012 02:08, Stuart Marks wrote:
Hi all,
The JDI tests have proven to be fairly unstable and are causing
This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
This is a fairly straightforward removal of this component.
- Activation implementation classes removed
- Activation tests removed
- adjustments to various comments to remove references to Activation
- adjustments to s
On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote:
> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
>
> This is a fairly straightforward removal of this component.
> - Activation implementation classes removed
> - Activation tests removed
>
On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote:
> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
>
> This is a fairly straightforward removal of this component.
> - Activation implementation classes removed
> - Activation tests removed
>
Pretty much what it says. The new option controls a static member in
InstanceKlass that's consulted to determine whether the finalization machinery
is activated for instances when a class is loaded. A new native method is added
so that this state can be queried from Java. This is used to control
On Thu, 18 Nov 2021 04:13:21 GMT, Jaikiran Pai wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
ava. This is used to
> control whether a finalizer thread is created and to disable the `System` and
> `Runtime::runFinalization` methods. Includes tests for the above.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Inclu
Enable the security manager in rmiregistry's launcher arguments.
-
Commit messages:
- Add security manager property to rmiregistry launcher arguments.
Changes: https://git.openjdk.java.net/jdk18/pull/45/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=45&range=00
Iss
On Sat, 18 Dec 2021 00:40:05 GMT, David Holmes wrote:
> I think specifying "allow" would be the behaviour preserving change here.
This is strictly true. I did think about doing this. However, I don't think it
makes much of a practical difference. It's always been fully supported to
enable the
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote:
> Enable the security manager in rmiregistry's launcher arguments.
I think there's little to worry about with custom configurations of the
`rmiregistry` tool. What somebody might do is to enable a customized security
> Enable the security manager in rmiregistry's launcher arguments.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Change java.security.manager to "allow"; filter warning lines from
VersionCheck
-
On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks wrote:
>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change java.security.
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote:
> Enable the security manager in rmiregistry's launcher arguments.
This pull request has now been integrated.
Changeset: 04ee9211
Author: Stuart Marks
URL:
https://git.openjdk.java.net/jdk1
On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote:
>> Ok, sorry for the distraction.
>
> Our local Santuario maintainer says:
>
> In general, changes to Apache Santuario should also be made at Apache so we
> stay in sync.
Hi @doom369, I hope we didn't end up wasting too much of your tim
On Sat, 24 Oct 2020 22:22:56 GMT, Peter Levart wrote:
>> Reference instances should not be leaked and so I don't see very common that
>> caller of `Reference::get` does not know the referent's type. It also
>> depends on the `refersTo` check against `null` vs an object. Any known use
>> cas
On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A
t/~dtitov/8156960/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Thank you!
Best regards,
Daniil
-Original Message-
From: Mandy Chung
Sent: Wednesday, June 08, 2016 3:09 PM
To: Daniil Titov
Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev;
[email protected]
call.
Mandy
On Jun 10, 2016, at 9:58 AM, Stuart Marks wrote:
Hi, sorry I had missed this earlier.
It's surprising if forRemoval=true were to be added to this API when the rest
of the Applet API has forRemoval=false. Is it the intent, for example, to have
JSObject.getWindow() removed f
l in JDK N.
I’ll let Kevin and Dave to clear this up and make the final call.
Mandy
On Jun 10, 2016, at 9:58 AM, Stuart Marks wrote:
Hi, sorry I had missed this earlier.
It's surprising if forRemoval=true were to be added to this API when the rest
of the Applet API has forRemoval=false.
Hi all,
We had a problem in TL the other day [1] [2] that wasn't caught because a
developer was using a JDK 8 build as his boot JDK. Turns out the rule to use
JDK N-1 as the boot JDK for JDK N isn't specified clearly in
README-builds.html. Here's a diff to strengthen the wording in that file.
On 6/17/13 4:02 PM, Kelly O'Hair wrote:
Rule #1 Nobody reads the README
Rule #2 When things go wrong, blame the README
I of course have no objection to the change, however, I'm not convinced it will
help much the next time someone runs into this. :^(
Hi Kelly! You still read this stuff here? :
as the boot JDK not be
corrected? I'm assuming it is one of the more unusual parts of the
build where we mess with bootclasspath etc?
David
On 18/06/2013 10:21 AM, Stuart Marks wrote:
On 6/17/13 4:02 PM, Kelly O'Hair wrote:
Rule #1 Nobody reads the README
Rule #2 When things go wron
On 6/18/13 2:16 AM, Chris Hegarty wrote:
On 06/18/2013 10:02 AM, David Holmes wrote:
I don't think we should simply say
"Do not use a build of JDK 8 as the boot JDK for building JDK 8."
as that doesn't explain what the issue is. If I'm building the JDK for
my own use I can use JDK8. So how abo
On 6/18/13 2:25 AM, Alan Bateman wrote:
On 18/06/2013 08:42, Stuart Marks wrote:
4) Could jaxp, jaxws, and corba be built with the current JDK, not the boot
JDK? Sure, probably.[...]
My understanding is that the new build is just following the old build[...]
As least for the jaxws
On 6/19/13 1:01 AM, Erik Joelsson wrote:
Currently, configure checks that the found boot jdk is 7 or 8. Do we really
want to actively prevent using 8 all together? I could agree to printing a big
warning in the summary at the end of configure to discourage it, but I do
believe it necessary to hav
Hi Aleksej,
Thanks for the update. I took a look at the revised test, and there are still
some issues. (I didn't look at the build changes.)
1) System-specific resource limits.
I think the biggest issue is resource limits on the number of open files per
process that might vary from system to
aefimov/8021820/webrev.02/
<http://cr.openjdk.java.net/%7Eaefimov/8021820/webrev.02/>
-Aleksej
On 08/06/2013 05:14 AM, Stuart Marks wrote:
Hi Aleksej,
Thanks for the update. I took a look at the revised test, and there are still
some issues. (I didn't look at the build changes.)
1) Sy
On 8/7/13 6:44 PM, Jonathan Gibbons wrote:
On 08/07/2013 06:22 PM, Alan Bateman wrote:
It's good to see this logic going away. Also defaulting the output directory
to TEST_ROOT (= pwd) is an improvement.
Aaargh. If I read those words correctly, it's a horrible idea to set the
output dir to TE
On 8/8/13 1:54 AM, Chris Hegarty wrote:
On 08/08/2013 03:11 AM, Jonathan Gibbons wrote:
On 08/07/2013 07:10 PM, Stuart Marks wrote:
I'd suggest putting a comment at the top of the test class saying that
this test *must* be run in othervm mode, to ensure that files are
closed properly. Tha
03/>
Comments below.
Thanks,
Aleksej
On 08/08/2013 06:10 AM, Stuart Marks wrote:
Hi Aleksej,
Thanks for the update. The situation is a bit twisted.
I picked up a couple clues from David Holmes and Jon Gibbons. The
NoClassDefFoundError occurs when the JVM has hit its resource limit
for the numb
On 9/5/13 10:53 AM, Joe Darcy wrote:
On 9/5/2013 2:01 AM, Magnus Ihse Bursie wrote:
First of all, I think what you're doing is a great job, and I'm all in
favor of enabling more warnings!
Thanks; I'm all for more warnings too :-)
I think you meant, you're for *fewer* warnings. :-)
DISABL
[Adding build-dev to let them know others are seeing this. I'm not on jigsaw-dev
though so this might not make it there.]
Hi Peter,
I ran into this myself the other day and had a wrestling match with it. There's
a bug in the build system on this:
https://bugs.openjdk.java.net/browse/JDK-
On 12/10/14 3:30 AM, Erik Joelsson wrote:
Stuart: could you make sure this patch works since I can't repro the actual
failure?
Bug: https://bugs.openjdk.java.net/browse/JDK-8067060
Webrev: http://cr.openjdk.java.net/~erikj/8067060/webrev.jdk.01/
/Erik
Yup, build works for me with this patch a
Hi all,
Please review this change to hgforest.sh, to preserve argument quoting when
passing arguments with spaces through to the hg command.
Changeset (in the new sandbox repo):
http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070
Bug:
https://bugs.openjdk.java.net/browse/JDK-80
Hi Chris, thanks for the extra testing.
s'marks
On 12/16/14 9:58 AM, Chris Hegarty wrote:
Looks good to me Stuart.
I tried the patch on Mac and Linux, both with the OpenJDK set of repos and with
Oracle’s additional ones, and all seems ok.
-Chris.
On 16 Dec 2014, at 17:38, Stuart
56 matches
Mail list logo
