Mark, thanks for implementing my little feature request. Looks good to me.
Aside: we only support running configure under bash, but as a result the
configure script is now a strange mixture of bashisms and 1980-isms.
On Mon, Dec 18, 2017 at 2:41 PM, wrote:
> Bug: https://bugs.openjdk.java.net/
Yeah, tr is a stupid little utility that it would be nice to get away from.
It's possible that env LC_ALL=C tr will fix your ASCII character set
problem.
On Thu, Nov 30, 2017 at 1:45 PM, Tim Bell wrote:
> Magnus:
>
> Looks good.
>
> On well-behaving unix systems, tr -c '[a-z]' '_' would
>>
>>>
l with the overall goal of moving
> stuff
> into jtreg when it is practical to do so.
>
> -- Jon
>
>
> On 11/28/2017 02:03 PM, Martin Buchholz wrote:
>
>> Every jtreg run would like to have the most helpful failure handling
>> possible. Should some/all of this be push
t; On 2017-11-28 23:03, Martin Buchholz wrote:
>
> Every jtreg run would like to have the most helpful failure handling
> possible. Should some/all of this be pushed into jtreg itself instead of
> the makefiles?
>
> As I understand things, jtreg has a kind of plugin structure. Th
Every jtreg run would like to have the most helpful failure handling
possible. Should some/all of this be pushed into jtreg itself instead of
the makefiles?
On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> The jtreg failure handler needs to be used wh
Looks good.
On Fri, Nov 24, 2017 at 2:22 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> From the bug report:
> "According to research by Jonathan Gibbons , JTReg now supports 256 jobs,
> in contrast to the older limit of 50 jobs. This limit is enforced in the
> make files, and i
Should all phony targets be listed in a .PHONY line?
On Fri, Nov 24, 2017 at 2:45 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> With the new layout of make run-test, the test-results and test-support
> directories are not removed by "make clean-test", and not even "make clean".
Not a review, but ... a note that some of us have to live on slow
filesystems with deeply nested paths where canonicalizing paths becomes a
bottleneck.
On Wed, Oct 25, 2017 at 8:03 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> We are validating that the topdir we're using when
ng the build, causing race conditions.
>
> The bug analysis and patch is contributed by Martin Buchholz.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189376
> Patch inline:
> diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
> --- a/make/common/Modules.gmk
>
On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman
wrote:
> On 17/10/2017 17:53, Martin Buchholz wrote:
>
> I tried to figure out how this patch actually works. At first I thought
> we were "shading" (renaming all the packages in the source files) but now I
> think we'
Does $(INTERIM_LANGTOOLS_MODULES_COMMA) need to be repeated below? I would
think you could drop it from --limit-modules
+INTERIM_LANGTOOLS_ARGS := \
+--limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
+--add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
I tried to figure out how this patch actually works. At first I thought we
were "shading" (renaming all the packages in the source files) but now I
think we're merely renaming the modules by appending ".interim" to the
names. But that looks like cheating to me - we're not allowed to have
multiple
1.
The upgrade module path. This path contains compiled definitions of
modules that will be observed in preference to the compiled definitions of
any *upgradeable modules* that are present in (3) and (4). See the Java
SE Platform for the designation of which standard modules are upg
What's the canonical way to list all upgradeable modules?
There's a list in JEP 261, but naturally we can't consider it authoritative.
I was surprised that even java --describe-module doesn't tell me whether a
module is upgradeable.
I was surprised to see JEP 261 say that java.compiler is upgrade
oices.
On Mon, Oct 16, 2017 at 10:18 AM, Alan Bateman
wrote:
> On 16/10/2017 16:41, Martin Buchholz wrote:
>
>> The difficulties encountered trying to run langtools10 in a jdk9 suggests
>> that the jdk9 module model is too restrictive. I've long lobbied for
>> tr
The difficulties encountered trying to run langtools10 in a jdk9 suggests
that the jdk9 module model is too restrictive. I've long lobbied for
treating langtools as just another collection of ordinary programs that
happen to be written in java and should not need special support from the
host jdk.
It should be standard practice for whoever does systematic jtreg testing to
do it occasionally with the jdk sources mounted in a read-only file system,
and ensure all the tests still pass.
On Mon, Sep 25, 2017 at 4:54 AM, Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:
>
>
> On 25/09
Thanks!
On debian-based systems, it's useful to get dependencies using
sudo apt-get -y build-dep openjdk-8-jdk
even when building jdk9 or jdk10
ded test against libjava works as expected (or suggest how
> to make it work if it doesn't) then that'd be much appreciated.
>
> Thanks!
>
> /Claes
>
> On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>
>> I'm hoping Xueming will review as well.
&g
On Mon, Apr 24, 2017 at 5:06 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:
> There is also a very strong desire to move to HTML 5 for the JDK
> documentation to be able to make use of the accessibility features that are
> available.
>
OK, that's a good reason to do it sooner rather th
:
> Martin,
>
> Does this mean you oppose this change until all Javadoc compiles cleanly
> with doclint html5?
>
> /Magnus
>
> 22 apr. 2017 kl. 19:11 skrev Martin Buchholz :
>
> It seems our javadoc is using html constructs that are not valid html5.
> If so, we s
<
magnus.ihse.bur...@oracle.com> wrote:
> Jon,
>
> Can you please open a separate bug for this? Just adding --doclint-format
> html5 generates a lot of failures, as Martin points out, so it's not
> feasible to do as part of this fix.
>
> /Magnus
>
>
> On 2017-04-21
There would be a global cleanup involved for --doclint-format html5
A CSS expert can probably suggest replacements.
[javac] ... src/main/java/util/Deque.java:30: error: attribute border
for table only accepts "" or "1", use CSS instead: BORDER
[javac] *
On Thu, Apr 20, 2017 at 3:42 PM,
Does your jtreg have the latest javatest?
https://bugs.openjdk.java.net/browse/CODETOOLS-7183756
On Fri, Feb 3, 2017 at 4:59 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> There is a limitation in jtreg that causes it to fail if called with
> -concurrency:X where X is > 50. Thi
I noticed I couldn't use an exploded jdk tarball because some files were
not world readable.
tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz
...
-rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h
-rw-r--r-- java_re/java_re824 2017-01-18 17:59
jdk-9/include/linux/jni_md.h
-rw-r--r
On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis
wrote:
>
> I don't think this can be easily done with the current build system.
> Remember for example that even such a sensitive part like jni.h is
> still duplicated between the hotspot and the jdk repository:
>
> hotspot/src/share/vm/prims/jni.h
Currently the pendulum is swinging away from multiple applications
sharing common libraries towards every application being
self-contained, perhaps because disk space is dirt cheap and because
of the rise of "containers". It may be that much of the packaging of
jdks will be picked up by third part
I'm actually very happy that we've dropped private patches against libz.
And using the system libz seems like the right thing to do on Unix
systems, where libz should be ubiquitous.
On Wed, Feb 10, 2016 at 4:25 PM, Xueming Shen wrote:
>
> One of the benefits of moving to the system libz is actua
There's an endless debate about the pros and cons of "dynamic linking".
I think it would be best for the JDK to link to system libraries by
default, if possible.
For a particular JDK image, one can drop a patched libz into a
suitable lib directory to override the system one.
It should also be rel
On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie
wrote:
> On 2015-12-15 18:25, Martin Buchholz wrote:
>>
>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
>> affects interoperability between translation units. It would be good
>> to convert
We can fix both JDK-6515172 and JDK-8144312 by doing the autconf
detection of how to count the number of allowed processors, then
actually measuring what's available during the build, and also fixing
the hotspot implemementation of Runtime.availableProcessors.
On Wed, Dec 16, 2015 at 6:08 AM, Magnus Ihse Bursie
wrote:
> On 2015-12-15 19:38, Martin Buchholz wrote:
> Are you talking about JDK-6515172? I was thinking on how to implement a
> proper check in the configure script, where calling separate process are not
> so unorthodox after all.
Note that the semantics of stat and access may be subtly different,
and that there are many calls to stat in the JDK sources, and they may
all be broken on 32-bit systems.
I just wrote elsewhere:
_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
affects interoperability between t
_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
affects interoperability between translation units. It would be good
to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
that would be a big job. So traditionally the JDK has instead used
the functions made availabl
On 2015-12-15 04:27, Martin Buchholz wrote:
>>
>> My current mental model is
>> configured cpus >= online cpus >= allowed cpus
>> In a traditional system they are all the same.
>>
>> I experimented and saw that cpusets are indeed turned on in some
>>
_getaffinity nproc
> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
> 4
> +++ exited with 0 +++
>
> It would be nice if anyone with access to a system where the number of cpus
> is limited in a similar manner to a docker container could run the above
> command and see if it
> 1)
Not to say you shouldn't do this, but I worry that increasingly computing
is being done in "containers" where e.g. the number of cpus is doubling
every year but only a small number are available to actually be used by a
given process. if availableProcessors reports 1 million, what should we
do? (
n-alignment issue as you previously suggested.
> Suppressing it via the build configuration change is a procedural matter:
> work to find the root problem and a real solution continues nonetheless.
>
> On Nov 4, 2015, at 7:46 PM, Martin Buchholz wrote:
>
> OK, I looked a little
Array. Give those methods some javadoc!
Maybe the crash comes from type punning int* and float* ? We shouldn't
suppress the crash unless we can prove it's actually a compiler bug. Why do
these methods take Object instead of e.g. int[] as parameters?
On Wed, Nov 4, 2015 at 2:12 PM, Martin
At Google, we've also noticed crashes in Bits.c with recent gcc.
Adding nio-dev, since this is not really a build problem.
It appears that Bits.c is resorting to undefined behavior, even though
there is a long tradition of unaligned access on x86 being permitted by the
hardware.
My colleague Alexa
On Wed, Oct 28, 2015 at 2:32 AM, Andrew Haley wrote:
> On 27/10/15 20:36, Martin Buchholz wrote:
> > The world would be a better place if the current x86 32-bit ABI was
> > replaced by "x32"
> > https://en.wikipedia.org/wiki/X32_ABI
> > but it's loo
The world would be a better place if the current x86 32-bit ABI was
replaced by "x32"
https://en.wikipedia.org/wiki/X32_ABI
but it's looking unlikely that we will get there. For starters, all
compilers must be rewritten to target x32, and that includes the jdk jits.
And that's a big project, one f
I agree that configure should try to invoke "the compiler" without any
flags by default, but make it easy for users to supply them. If some
platform like SLES 10 on Linux/ppc64 wants to build 32-bit binaries, assume
that this is intended and let it go ahead! Don't just assume the distro
maintaine
[+build-dev]
On Mon, Oct 19, 2015 at 1:06 PM, Matthias Klose wrote:
> Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are
> configured to pass --as-needed to the linker by default, only linking with
> libraries when required. A common build failure triggered by this default
> is
On Tue, May 26, 2015 at 7:52 PM, Roger Riggs wrote:
> Hi,
>
> Sadly, but not entirely unexpectedly there is an anomaly in the include
> files:
> It seems that Windows does not define O_SYNC and O_DSYNC.
> To make up for the absence
> jdk/src/java.base/share/native/libjava/io_util.h
> conditional
The double assignment to i is stupid (a "dead store") - remove one of them.
63 size_t i = 0;
64 for (i = 1; i < len; i++) {
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 that the message fits into the buffer.
-sprintf(errmsg, format, errnum, detail);
+snprintf(errmsg, fmtsize, IOE_FORMAT, errnum, detail
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
I plan to have review comments later today.
On Thu, May 21, 2015 at 2:09 PM, Roger Riggs 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 invoked function.
>
I also think that backporting multiple toolchain support seems too risky
for jdk8u. At the same time, it may be very useful for others trying to
test or port the jdk8u code base (at google, we are motivated by running
asan via clang). It would be good if there was a way to share such a
backport w
[+distro-pkg-dev]
On Mon, Mar 23, 2015 at 11:47 AM, Styx, Aaron (US SSA) <
aaron.s...@baesystems.com> wrote:
> I'm working on porting Java 7 (using IcedTea 2.5.4) to a new OS. I've
> completed the build once, but when I install what was built to use as the
> bootstrap JDK and start a fresh build
> /usr/ccs/bin tool with user-supplied one.
>
> So both solutions above looks bad for me.
>
> And yes, this all is mostly about *nm*
>
> -Dmitry
>
>
> On 2015-03-09 20:03, Martin Buchholz wrote:
> > I support Magnus' strategy.
> >
> > Slightly unre
n /usr/ccs/bin instead of failing, is just like the rest of
> the processing configure does.
>
> /Magnus
>
> >
> > -Dmitry
> >
> >
> >
> >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote:
> >>> On 2015-03-04 22:03, Martin Buchholz wrote:
>
On Fri, Mar 6, 2015 at 6:50 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2015-03-04 22:03, Martin Buchholz wrote:
>
>> I agree that configure should not mess with user's PATH and should
>> "auto-find" programs in /usr/ccs/bin o
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
Source files should have exactly one trailing newline.
find -iregex '.*\.\(java\|txt\|c\|cc\|h\|hpp\|cpp\)$' | xargs perl -0777
-ne 'print "Must have exactly one trailing newline: $ARGV\n" unless
m~[^\n]\Z~s'
It's a mystery. My own successful config.log snippet with latest jdk8u is
below. Why didn't your config.log contain "checking for FREETYPE"? Maybe
a pkg-config problem? Are you doing something crazy like defining
LD_LIBRARY_PATH? Someone will need to debug configure, perhaps using bash
-x config
Others don't seem to have this problem - you can try looking at
config.log and elsewhere trying to figure out what went wrong.
On Fri, Dec 19, 2014 at 1:08 AM, Cédric Champeau
wrote:
> Hi everyone,
>
> Some of you may know that we try to test Groovy builds against the latest
> versions of the JDK
On Tue, Dec 2, 2014 at 2:48 PM, Jonathan Gibbons
wrote:
>> Do we really want more repositories?
>>
>
> Conversely, do we really want bigger repositories? :-)
Yes, we want bigger repositories, not more repositories.
Put the benchmarks into the existing repo test directories.
Name them all FooBen
Looks good to me too.
I appreciate the high bar for build correctness.
I would test with both make 3.81 and 4.x
On Wed, Nov 26, 2014 at 6:56 AM, Erik Joelsson wrote:
> Hello,
>
> Please review this build reliability fix. In JDK-8065138, we would have
> caught the error much faster if the build
Great!
On Fri, Nov 21, 2014 at 3:16 PM, Magnus Ihse Bursie
wrote:
>
> On 2014-11-21 22:40, Martin Buchholz wrote:
>>
>> A high-level followup ...
>>
>> Running most text-based OS tools, including sed and sort, is risky
>> because the user's encod
| $(SED) -e '/^#/d' -e '/^/d' \
>>> -e :a -e '/\\/N; s/\\\n//; ta' \
>>> -e 's/^[ ]*//;s/[ ]*//' \
>>> --e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
>>&g
Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but
the $(SED)s need it too!
On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz wrote:
> [+ build-dev]
>
> I think I see the problem. By default, a Unix pipeline sadly fails
> only when the last command fails. In b
[+ build-dev]
I think I see the problem. By default, a Unix pipeline sadly fails
only when the last command fails. In bash, you can change this to a
more sensible default via
set -o pipefail
but that's not portable enough for openjdk.
$(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\
Philosophically, there's more variation among unices than windows, but
windows OSes certainly have some variation over time. Especially if you
count the Win98 family, thankfully no longer supported.
On Wed, Sep 24, 2014 at 5:39 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
>
> A
I tried again today ( with jdk9/jdk9-dev ) and everything works now. I
believe the problem was fixed by the following, which replaced erroneous
references to SetupJava.gmk
# HG changeset patch
# User erikj
# Date 1408611935 -7200
# Thu Aug 21 11:05:35 2014 +0200
# Node ID b8f27b54cc51c17c7de
22, 2014 at 4:30 PM, Martin Buchholz
wrote:
> I've also just lost the ability to build jdk9.
> I also get uninformative
>
> make[1]: *** [main-wrapper] Error 2
>
> Trying to debug, I configure with --with-jobs=1 and run
> make LOG=debug
> and that gets me:
>
> m
I've also just lost the ability to build jdk9.
I also get uninformative
make[1]: *** [main-wrapper] Error 2
Trying to debug, I configure with --with-jobs=1 and run
make LOG=debug
and that gets me:
make[3]: Entering directory `...home/martinrb/ws/9up/jdk/make'
Tools.gmk:35: SetupJava.gmk: No suc
On Fri, Aug 22, 2014 at 3:10 AM, Erik Joelsson
wrote:
>
> On 2014-08-22 01:10, Martin Buchholz wrote:
>
> Serial execution is useful for both resource-constrained environments and
> for folks trying to profile the build itself. Serial build is also likely
> to be optimal if
Serial execution is useful for both resource-constrained environments and
for folks trying to profile the build itself. Serial build is also likely
to be optimal if you are optimizing for total energy used rather than total
wall clock time.
On Thu, Aug 21, 2014 at 8:39 AM, Erik Joelsson
wrote:
When I tried to get configure scripts to build things "my way" back in the
last millenium, I was successful with creating a bunch of shell scripts
that look like compilers, putting all the logic in there, and then just
getting the configure script to invoke my "compiler".
But now that we actually
On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes wrote:
> HotSpot is even more of a problem because not being able to commit directly
> risks people losing credit for the work they've done and, with an open
> source
> project, credit is the only reward.
>
It *is* possible with mercurial to create/i
x27;t have to ever worry about build failures getting through.
>>
>> In the meantime I don't think my request to work with others to ensure
>> broader test coverage of build changes is unreasonable.
>>
>> I can't force anyone's cooperation I can only request
On Mon, Apr 8, 2013 at 5:51 PM, David Holmes wrote:
> On 9/04/2013 2:59 AM, Andrew Hughes wrote:
>
>>
>> Well, if I push it, it will be, no?
>>
>
> Testing comes before pushing - thank you.
>
This issue keeps coming up.
Non-Oracle committers have no access to the Oracle automated testing
submiss
library was linked,
please!
On Tue, Mar 26, 2013 at 3:40 PM, Martin Buchholz wrote:
> I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and
> did "make images" but no actual compilation happened.
> (I guess I currently need to do a clean rebuild? Which is a serious bug?)
>
If I modify an ordinary JDK source file (like StringBuilder.java), then all
files are recompiled, even those that don't have any compile-time
dependency on StringBuilder.
## Starting jdk
Compiling 9412 files for BUILD_JDK
I'd like to see instead
Compiling 103 files for BUILD_JDK
I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and
did "make images" but no actual compilation happened.
(I guess I currently need to do a clean rebuild? Which is a serious bug?)
(As I've complained about recently)
Not all jdk commands (e.g. javap, and apparently sjavac) consistently
support either both or neither of '-cp' and '-classpath' as synonyms.
But that's being fixed.
On Fri, Mar 15, 2013 at 10:57 AM, Andrew Hughes wrote:
>
>
> - Original Message -
> > Th
While you're there, consider checking/modfying all of the jdk tools to
accept either both or neither of "-cp" and "-classpath". javap is the
command I'm thinking of.
Pushed to jdk8/tl/jdk.
I recommend this be backported to jdk7u.
On Tue, Mar 5, 2013 at 4:36 PM, David Holmes wrote:
>
>>> I disagree. The submitter should be responsible for the "right" amount
>> of
>> upfront testing.
>>
>
> Now you are confusing me :) You disagree but say the responsibility is on
> the submitter. Well I certainly agree with that! Our diffe
On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote:
> On 6/03/2013 9:17 AM, Martin Buchholz wrote:
>
>>
>> IMO the right approach is to improve processes so that bad commits don't
>> cause other developers to lose time. Once upon a time, I was actually
>>
On Tue, Mar 5, 2013 at 2:36 PM, David Holmes wrote:
>
> Sorry but that is completely unacceptable. If you are providing changes
> that obviously impact multiple platforms (ie there are platform specific
> changes) then they _must_ be tested on all platforms. If the external
> author/committer can
On Tue, Mar 5, 2013 at 1:53 PM, David Holmes wrote:
>
> You needed to have a jdk8 Reviewer listed for this change. Erik is a
> Committer not Reviewer.
>
>
That's not obvious. Isn't it jcheck's job to make sure any required
approvals are in?
I should have included more eyeball names on the Reviewe
Oh dear.
Please add in a fixup change if required.
On Tue, Mar 5, 2013 at 1:44 PM, David Holmes wrote:
> Martin, Erik,
>
> On 6/03/2013 7:19 AM, Martin Buchholz wrote:
>
>> Thanks.
>> Pushed to /hg/jdk8/tl.
>>
>
> There has to be a corresponding push
Thanks.
Pushed to /hg/jdk8/tl.
(only tested on Linux)
On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote:
> **
> On 2013-03-04 23:55, Martin Buchholz wrote:
>
>
>
> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote:
>
>> Thanks for the suggestion Martin!
>>
On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote:
> **
> Thanks for the suggestion Martin!
>
> I created 8009376 for this and will try to get it done.
>
There's already a bug for this:
8006988 : build-infra: Configure fails if 'cl' is in path on linux
I've refreshed my patch to implement the
On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer wrote:
> On 02/22/2013 11:03 PM, Martin Buchholz wrote:
>
> I've finally figured out why fastdebug jdk occasionally gives
>> InternalError
>> in the zip code.
>>
>
> In the distant past, I also saw this with pr
On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman wrote:
> The update to make/java/zip/Makefile looks good to me, we should have
> done it a long time ago. I assume you are pushing ahead on this because you
> want to push it to jdk7u-dev (as it's not interesting to jdk8 now because
> of the new buil
I have another iteration of this change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
that adds exciting new exception detail message for the InternalError I was
scratching my head about earlier.
-msg = strm->msg;
+msg = ((strm->msg != NULL) ? strm->msg :
+
;s better to use
> single one. and I would prefer to have quotes around xmacosx and
> xwindows just for consistency. i.e.
>
> if test "x$OPENJDK_TARGET_OS" = "xwindows";
>
> -Dmitry
>
>
> On 2013-02-24 00:05, Martin Buchholz wrote:
> > Hi Erik, Tim,
On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff <
dmitry.samers...@oracle.com> wrote:
>
> 2. Not all versions of test support == as equation. It's better to use
> single one. and I would prefer to have quotes around xmacosx and
> xwindows just for consistency. i.e.
>
> if test "x$OPENJDK_TARGET
13 at 9:18 AM, Kelly O'Hair wrote:
>
> On Feb 23, 2013, at 12:12 PM, Alan Bateman wrote:
>
> > On 23/02/2013 18:06, Martin Buchholz wrote:
> >> I am actually encountering this in openjdk7 with the old build system.
> >> I can repro the problem in openjdk8 with
Hi Erik, Tim, Kelly
Here's a proposed fix for you to review:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/
Martin
On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz wrote:
> I was trying out the shiny new build system.
>
> Problem: configure is not exe
On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman wrote:
> On 23/02/2013 10:29, David Holmes wrote:
>
>>
>> Just be aware there's a lot more involved in doing this than just
>> changing one a name in a makefile.
>>
>> You beat to me too! Yes, there are likely a lot of scripts and paths
> that assume
at com.sun.tools.javac.main.Main.compile(Main.java:356)
at com.sun.tools.javac.Main.compile(Main.java:76)
at com.sun.tools.javac.Main.main(Main.java:61)
On Sat, Feb 23, 2013 at 3:51 AM, Alan Bateman wrote:
> On 22/02/2013 22:03, Martin Buchholz wrote:
>
> Hi Alan, Xueming, build-ers,
I'm having fun with the shiny new build system.
It took me a while to discover that "make help" was exceptionally helpful.
However, I was interested in passing a configuration to CONF= and was
annoyed there was no clue what to provide. (I wasn't even sure exactly
what a "configuration" was)
Afte
"j2" is so 2001. Before freezing the shiny new build system, consider
taking the opportunity to rename
"j2sdk" => "jdk"
"j2re" => "jre"
globally in the new Makefiles.
On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen wrote:
> **
> Here is the bugid you will need.
>
> 8008759: Do not let internal JDK zlib symbols leak out of fastdebug
> libzip.so
>
>
Thanks! webrev updated.
Hi Alan, Xueming, build-ers,
I'd like you to do a code review.
I've finally figured out why fastdebug jdk occasionally gives InternalError
in the zip code.
Exception in thread "main" java.lang.InternalError
at java.util.zip.Inflater.init(Native Method)
at java.util.zip.Inflater.(Inflater.java:10
101 - 200 of 305 matches
Mail list logo
