On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
>
> JimLaskey added 30 commits on Oct 9
> @Jim
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
This PR looks seriously messed up:
JimLaskey added 30
On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie wrote:
> With clang 10.0, the compiler now detects a new class of warnings. The
> `misleading-indentation` warning has previously been disabled on gcc for
> hotspot and libfdlibm. Now we need to disable it for clang as well.
On Tue, 3 Nov 2020 22:36:34 GMT, John Paul Adrian Glaubitz
wrote:
>> With clang 10.0, the compiler now detects a new class of warnings. The
>> `misleading-indentation` warning has previously been disabled on gcc for
>> hotspot and libfdlibm. Now we need to disable it for clang as well.
>
>
With clang 10.0, the compiler now detects a new class of warnings. The
`misleading-indentation` warning has previously been disabled on gcc for
hotspot and libfdlibm. Now we need to disable it for clang as well.
-
Commit messages:
- 8253892: Disable misleading-indentation on
The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
exist anymore.
-
Commit messages:
- 8255798: Remove dead headless code in CompileJavaModules.gmk
Changes: https://git.openjdk.java.net/jdk/pull/1031/files
Webrev:
On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview
>> APIs, and generally improve javac and javadoc behavior to more closely
>> adhere to JEP 12.
>>
>> The notable changes are:
>>
>> * adding support for Preview
On Fri, 23 Oct 2020 14:06:22 GMT, Maurizio Cimadamore
wrote:
>> Changes requested by ihse (Reviewer).
>
> @magicus the files you commented on are not part of this PR, but they are
> introduced as part of:
> https://git.openjdk.java.net/jdk/pull/548
> (you seemed to have approved the changes
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
On Mon, 19 Oct 2020 10:34:32 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> *
On Wed, 21 Oct 2020 20:05:31 GMT, Andy Herrick wrote:
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains five commits:
>
> - Merge branch master into
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
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.
>>
On Wed, 21 Oct 2020 02:55:49 GMT, David Holmes wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve wording in refersTo javadoc
>
> Update looks good. Need to reflect the change in the CSR.
>
> Thanks.
> David
On 2020-09-02 09:50, Kim Barrett wrote:
On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie
wrote:
On 2020-09-01 11:46, Kim Barrett wrote:
I really hate -Wstringop-truncation. It's been a constant source of churn
for us ever since it appeared. The changes being made to getIndex and
getFlags
On 2020-09-01 11:46, Kim Barrett wrote:
On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
Hi all,
Please review this simple change to fix some compile warnings.
The newer gcc (gcc-8 or higher) would warn for calls to bounded string
manipulation functions such as 'strncpy' that may either truncate
On 2020-09-01 13:41, Aleksei Voitylov wrote:
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the JEP to Proposed to Target:
On 2020-06-18 08:34, Kim Barrett wrote:
On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote:
On Jun 14, 2020, at 12:45 AM, Philip Race wrote:
Kim,
Until it says in "the JDK" and not "in HotSpot" you have not addressed my main
point.
Please rename the JEP.
After some off-list discussions I
On 2020-06-23 11:17, Peter Levart wrote:
Including build-dev since this patch is adding new issue 8248135:
https://bugs.openjdk.java.net/browse/JDK-8248135
So here's new webrev with a patch for building benchmarks with
--enable-preview included:
the classpath exception, I'd
prefer to keep JtregNativeLibTest.gmk in sync w/ the its siblings and
would leave it up to build team to decide how it's best to handle.
On Jun 15, 2020, at 8:12 AM, Magnus Ihse Bursie
<mailto:magnus.ihse.bur...@oracle.com>> wrote:
A few comments:
This seems li
A few comments:
This seems like code copied from elsewhere:
57 # This evaluation is expensive and should only be done if this target was
58 # explicitly called.
59 ifneq ($(filter build-test-libtest-jtreg-native, $(MAKECMDGOALS)), )
I don't agree that this is an expensive evaluation.
On 2020-06-05 09:52, Kim Barrett wrote:
[Changes are only to the build system, but since the changes have jdk-wide
effect I’ve cc’d what I think are the relevant dev lists.]
This change is part of JEP 347; the intent is to target JDK 16.
Please review this change to the building of C++ code in
On 2020-06-05 13:59, Jim Laskey wrote:
I know there was a discussion about this elsewhere but I would like to take the
opportunity to correct this now
make//autoconf/flags-cflags.m4:241
elif test "x$TOOLCHAIN_TYPE" = xclang; then
if test "x$OPENJDK_TARGET_OS" = xmacosx; then
#
On 2020-05-07 23:27, Mikael Vidstedt wrote:
On May 7, 2020, at 7:52 AM, Kumar Srinivasan wrote:
Hi Mikael,
I may have created solinux when the macosx port was merged and in an effort to
reduce the CPP conditionals.
solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has
On 2020-05-05 21:56, Jim Laskey wrote:
This fix addresses the inconsistent ordering by jimage content by jlink from
run to run. Bottom line, the implementer was using HashSet without defining
hashcode/equals for the Set entry classes.
webrev:
Hi Ioi,
On 2020-04-27 07:22, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8241071
http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
I can't really comment on the code changes, but I'd like to thank you
for the effort of getting a deterministic
This patch addresses the warnings deprecation and unchecked, which are
impossible to fully suppress.
With this patch, the test-image can be built fully without warnings.
The patch updates non-critical code to use modern solutions for
deprecated methods, where possible. Tested methods have
On 2020-04-15 17:56, sundararajan.athijegannat...@oracle.com wrote:
Please review.
Nashorn script engine modules (jdk.scripting.nashorn,
jdk.scripting.nashorn.shell) and jjs tool are removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8241749
JEP: https://openjdk.java.net/jeps/372
CSR:
From a build perspective this looks fine.
But it seems you are changing the interface for java.lang.System. Don't
you need a CSR for that? Or is your claim that the interface was indeed
changed by JDK-8197927, and it is a bug that the documentation was not
updated to match this?
/Magnus
On
On 2020-03-25 02:22, David Holmes wrote:
On 25/03/2020 3:49 am, Florian Weimer wrote:
* Magnus Ihse Bursie:
On 2020-03-24 09:59, Andrew Dinn wrote:
On 23/03/2020 18:38, Erik Joelsson wrote:
Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because
you're right. I'll move them as well.
I'll publish an updated webrev with these changes when there's agreement
on where in the source code tree to move the files.
/Magnus
Naoto
On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote:
The build tools (small java tools that are run during the build
On 2020-03-24 09:59, Andrew Dinn wrote:
On 23/03/2020 18:38, Erik Joelsson wrote:
Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a 1-liner :-).
For code in the build system, we do not have the Hotspot
The build tools (small java tools that are run during the build to
generate source code, or data, needed in the JDK) have historically been
placed in the "make" directory. This maybe made sense long time ago, but
does not do so anymore.
Instead, the build tools source code should move the the
);
Entry entry = (Entry)currentContainer;
...
/Magnus
/Erik
On 2020-03-19 09:53, Magnus Ihse Bursie wrote:
The buildtools (java tools needed to be run during the build) have
long been plagued by warnings, includuing deprecations and unchecked
warnings, which cannot be silenced during the build
http://cr.openjdk.java.net/~ihse/JDK-8241310-fix-warnings-in-buildtools/webrev.02
/Magnus
regards,
Rémi
- Mail original -
De: "Magnus Ihse Bursie"
À: "build-dev" , "core-libs-dev"
Envoyé: Jeudi 19 Mars 2020 17:53:09
Objet: RFR: JDK-8241310 Fix warning
The buildtools (java tools needed to be run during the build) have long
been plagued by warnings, includuing deprecations and unchecked
warnings, which cannot be silenced during the build.
This patch fixes all buildtool warnings. Most of the warnings are fixed
properly, but a few have had
this the whole way.
/Magnus
Thanks, Roger
On 3/18/20 9:01 AM, Magnus Ihse Bursie wrote:
On 2020-03-17 23:07, Roger Riggs wrote:
Hi Magnus, Erik,
Thanks for the pointers, I'm not familiar with those early build
intricacies.
Updated:
http://cr.openjdk.java.net/~rriggs/webrev-stubs-classes
he
generated stub .java class
and added it to the repo.
- The NetBeans Jmx build script had targets to build the stubs, they
have been removed.
Thanks, Roger
On 3/17/20 10:06 AM, Magnus Ihse Bursie wrote:
On 2020-03-17 14:17, Erik Joelsson wrote:
Hello,
That looks better, but th
On 2020-03-17 14:17, Erik Joelsson wrote:
Hello,
That looks better, but there are still some more things to remove.
This whole block:
# Targets for running rmic.
$(eval $(call DeclareRecipesForPhase, RMIC, \
On 2020-02-27 15:52, Bob Vandette wrote:
On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 22:01, Bob Vandette wrote:
Here’s an updated webrev that implementes the suggestion that allows JNIEXPORT
in jni.h to be overridden
and the build limits visibility for static
020, at 10:35 AM, Magnus Ihse Bursie
<mailto:magnus.ihse.bur...@oracle.com>> wrote:
On 2020-02-26 15:56, Bob Vandette wrote:
On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie
<mailto:magnus.ihse.bur...@oracle.com>> wrote:
On 2020-02-26 14:31, Bob Vandette wrote:
On Feb 26, 2
pted, I’ll update the CSR solution to match
this implementation.
I'm not even sure a CSR request is even warranted now.
Thanks,
David
http://cr.openjdk.java.net/~bobv/8239563/webrev.01
Bob.
On Feb 26, 2020, at 10:35 AM, Magnus Ihse Bursie
<mailto:magnus.ihse.bur...@oracle.com>>
On 2020-02-26 15:56, Bob Vandette wrote:
On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 14:31, Bob Vandette wrote:
On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing
On 2020-02-26 14:31, Bob Vandette wrote:
On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing that we were missing, David!
Sorry, I should have included you folks.
On 26/02/2020 6:37 am, Bob
Also, we've worked hard to get rid of the map files in the build system.
I'd be hesitant to say the least to re-introduce them.
/Magnus
On 2020-02-26 14:29, Bob Vandette wrote:
Thanks but I don’t like that idea for several reasons.
1. It’s too dramatic of a change for the immediate problem
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing that we were missing, David!
On 26/02/2020 6:37 am, Bob Vandette wrote:
Please review this RFE that alters the visibility of JNI entrypoints
to hidden when a shared library
is created using static JDK
On 2020-02-17 08:48, linzang(臧琳) wrote:
Hi,
May I ask help to review one tiny fix of build failure described at
https://bugs.openjdk.java.net/browse/JDK-8239139
Root cause is gcc version 8 prints warning for strncpy.
The fix simply replace strncpy with snprintf.
Thanks!
tend the
example to be verbatim correct for everyone (hence the "something
like" wording) but I see your point. Changed it.
/Erik
Thanks
Christoph
-Original Message-
From: Magnus Ihse Bursie
Sent: Mittwoch, 5. Februar 2020 10:54
To: Erik Joelsson ; core-libs-dev ; bu
On 2020-02-04 18:45, Erik Joelsson wrote:
Does anyone have an opinion on this?
The solution seems sound to me. I'm having a hard time figuring out if
the string manipulations in java_md_macosx.m are correct; as Christoph
is saying, they might not be. I realize you have copied an existing
On 2019-10-22 05:22, mark.reinh...@oracle.com wrote:
RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
Build changes look good.
/Magnus
This change implements jlink plugins, and
42, Magnus Ihse Bursie wrote:
I can’t see how the compilation is dependent on the copy being
finished. Since Erik contributed this it will probably be correct
:) but I’d appreciate an explanation on how this dependency is
guaranteed.
Or maybe I’m misunderstanding what this is supposed to do?
/
I can’t see how the compilation is dependent on the copy being finished. Since
Erik contributed this it will probably be correct :) but I’d appreciate an
explanation on how this dependency is guaranteed.
Or maybe I’m misunderstanding what this is supposed to do?
/Magnus
> 8 okt. 2019 kl.
files moved, instead of add/remove.
Thank you!
This looks good now from a build point of view, but you'll need a review from
core-libs as well.
/Magnus
>
> Thanks,
> Alexander
>
>> On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote:
>>
>>
>>> On 2019-02-1
On 2019-02-15 04:31, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Moved native code under platform specific folder.
- Removed most usage on #ifdefs for WINDOWS,
On 2019-02-01 14:43, naoto.s...@oracle.com wrote:
Hi Magnus,
I am assuming that the generated resource bundles are exactly the same
as before this fix, correct?
Yes. I have verified this using the COMPARE_BUILD functionality.
/Magnus
Naoto
On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote
JPACKAGELIB_SRC.
Old wmain() was in jpackage.cpp line 461.
Aha. :) I only knew about WinMain and main. You learn something every
day. Thanks.
/Magnus
Thanks,
Alexander
On 2/1/2019 3:39 AM, Magnus Ihse Bursie wrote:
Hi Alexander,
On 2019-02-01 05:22, Alexander Matveev wrote:
Please review
Hi Alexander,
On 2019-02-01 05:22, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- jpackage launcher will now build same as Linux and OS X using
SetupBuildLauncher.
-
The CLDR data is, since Jigsaw, used in two different modules --
java.base and jdk.localedata. Unfortunately, the split between these two
modules were not fully finished as part of the Jigsaw project.
This patch aims to resolving most of this. The CLDRConverter build tool
is now called from
Bug:https://bugs.openjdk.java.net/browse/JDK-8214533
>>>> >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/
>>>> >>
>>>> >> I added IBM29626C charset as standard way.
>>>> >> Please give any suggestion and quest
On 2019-01-18 15:18, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
The webrev includes all the jpackage Makefile Improvements listed in
[1], other than what is covered by [4],
, \
<-
LIBS := $(LIBCXX), \
LIBS_windows := user32.lib shell32.lib advapi32.lib, \
))
TARGETS += $(BUILD_JPACKAGE_APPLAUNCHERWEXE)
endif
/Andy
On 1/15/2019 8:09 AM, Magnus Ihse Bursie wrote:
Hi Andy,
This is looking really sweet from a build perspective!
Just a
Hi Andy,
This is looking really sweet from a build perspective!
Just a few minor nits:
* In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval
$(call SetupBuildLauncher, jpackage ") two spaces.
* In Lib-jdk.jpackage.gmk, I think there's still room to prune some more
On 2019-01-02 00:11, David Holmes wrote:
Hi Patrick,
On 13/12/2018 1:23 pm, Patrick Zhang wrote:
Ping...
Apply for a sponsor for this simple patch.
Seems no one wants to own this one :(
For what it's worth, it looks good to me. (But I'd like to see a core
library developer chime in as
t you mean by "linking behavior"?
/Magnus
Cheers,
David
-
On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote:
On 2018-12-11 23:47, David Holmes wrote:
On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote:
On 2018-12-11 00:23, David Holmes wrote:
Hi Magnus,
On 10/12/2018 11:19 pm
On 2018-12-12 16:34, Alexey Ivanov wrote:
On 12/12/2018 12:58, Magnus Ihse Bursie wrote:
On 2018-12-12 12:35, Alan Bateman wrote:
On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
:
I searched the code for "jdwpTransport_On" to see of there was any
corresponding OnUnload function
the undecorated
name, jdwpTransport_OnLoad.
Regards,
Alexey
[1]
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC
[2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017
On 12/12/2018 11:19, Magnus Ihse Bursie wrote:
On 2018-12-11 18:16
On 2018-12-12 12:35, Alan Bateman wrote:
On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
:
I searched the code for "jdwpTransport_On" to see of there was any
corresponding OnUnload function (or other), but could not find any.
That's right, an unload wasn't needed whe
ibraryEntry(handle, "jdwpTransport_OnLoad"); #endif
Thanks,
-Simon
Regards,
Alexey
https://bugs.openjdk.java.net/browse/JDK-8214122
On 10/12/2018 15:11, Magnus Ihse Bursie wrote:
Since removing JNICALL is not an option, there are only two options:
1. Add |/export| option to the Makefile or pragm
ad = (jdwpTransport_OnLoad_t)
dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif
Thanks,
-Simon
Regards,
Alexey
https://bugs.openjdk.java.net/browse/JDK-8214122
On 10/12/2018 15:11, Magnus Ihse Bursie wrote:
Since removing JNICALL is not an option, there are only two optio
On 2018-12-11 23:47, David Holmes wrote:
On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote:
On 2018-12-11 00:23, David Holmes wrote:
Hi Magnus,
On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote:
I propose that we introduce a new define, available to all JDK
native files (Hotspot included
On 2018-12-12 09:40, David Holmes wrote:
On 12/12/2018 5:44 pm, Volker Simonis wrote:
On Tue, Dec 11, 2018 at 11:47 PM David Holmes
wrote:
On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote:
On 2018-12-11 00:23, David Holmes wrote:
Hi Magnus,
On 10/12/2018 11:19 pm, Magnus Ihse Bursie
On 2018-12-11 00:23, David Holmes wrote:
Hi Magnus,
On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote:
I propose that we introduce a new define, available to all JDK native
files (Hotspot included), called JDK_EXPORT. The behavior of this
symbol will be very similar (as of now, in fact
On 2018-12-10 16:02, Alexey Ivanov wrote:
On 10/12/2018 10:41, Magnus Ihse Bursie wrote:
On 2018-12-07 22:18, Simon Tooke wrote:
Looking at the code, it seems (to me) the "correct" thing to do is to is
to create a Windows-specific version of dbgsysBuildFunName() in
linker_md.c
I propose that we introduce a new define, available to all JDK native
files (Hotspot included), called JDK_EXPORT. The behavior of this symbol
will be very similar (as of now, in fact identical) to JNIEXPORT;
however, the semantics will not.
Currently, we "mis-use" the JNIEXPORT define to
Hi Alexey,
On 2018-12-10 13:32, Alexey Ivanov wrote:
Hi,
Could you please review the following fix for jdk12?
bug: https://bugs.openjdk.java.net/browse/JDK-8215123
webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/
The fix looks good to me.
/Magnus
The problem is that calling
On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote:
Hi,
Any update on this one? Or do we want to give up on it until JDK-8165620
is implemented?
I think Alan reviewed it as OK with just a minor fix, and offered to
sponsor it for you.
Then the discussion started about some major
626C, x-IBM29626C, null, sun.nio.cs.ext, template false
$ find support/gensrc/ | grep 29626
$ find support/gensrc/ | grep Charsets
support/gensrc/java.base/sun/nio/cs/StandardCharsets.java
support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java
$ find support/gensrc/ | grep Charsets | xargs grep 29
On 2018-11-27 19:49, Andrew Luo wrote:
By the way, in hotspot we are generating a .def file dynamically while keeping
the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe
(just by looking through the code in
/windows/native/include/jni_md.h#L31 ? Wouldn’t
that be a more consistent move?
We can't do that.
Implementation of Java native methods must use __stdcall calling
convention.
Regards,
Ali
On 22 Nov 2018, at 17:29, Magnus Ihse Bursie
<mailto:magnus.ihse.bur...@oracle.com>> wrote:
I
On 2018-12-07 22:18, Simon Tooke wrote:
Looking at the code, it seems (to me) the "correct" thing to do is to is
to create a Windows-specific version of dbgsysBuildFunName() in
linker_md.c, and have it decorate the function name as appropriate for
32-bit windows. Note that in transport.c,
Looks good to me, too.
/Magnus
> 4 dec. 2018 kl. 20:34 skrev Mandy Chung :
>
> The revised webrev looks okay.
>
> Mandy
>
>> On 12/4/18 11:32 AM, Roger Riggs wrote:
>> Hi Mandy, Martin,
>>
>> The new test is unnecessary, the case is covered by
>> java/lang/System/Versions test
>> and uses
needed since there does not appear to be a change for 33722?
Regards, Roger
On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote:
On 2018-11-30 10:49, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8212794
Change: https://cr.open
arsetmapping/Main.java
make/jdk/src/classes/build/tools/charsetmapping/SRC.java
My build machine is not so fast, after test is done.
I'll post new code.
Thanks,
Ichiroh Takiguchi
On 2018-11-28 19:10, Magnus Ihse Bursie wrote:
On 2018-11-28 10:36, Alan Bateman wrote:
On 28/11/2018 09:28,
On 2018-11-28 23:49, Henry Jen wrote:
Since there is no header file in JDK provides the function prototypes, I don’t
think this is considered public(supported) APIs.
Anyway, in case a tools is build with launcher code, and shipped separately
from JDK, that would be impacted by this bug. So I
On 2018-11-28 10:36, Alan Bateman wrote:
On 28/11/2018 09:28, Magnus Ihse Bursie wrote:
I'm quite unsatisfied with the current handling of character sets in
the build in general. :-( I'd really like to modernize it. I have a,
slightly fuzzy, laundry list of things I want to fix from a build
On 2018-11-27 13:26, Ichiroh Takiguchi wrote:
Hello Volker.
Sorry for your confusion.
I want to keep visibility feature on AIX platform for future OpenJDK.
If I can apply workaround for AIX platform...
XLC++ 13.1 is confused destructor order for ~SimpleCriticalSectionLock()
on
> 26 nov. 2018 kl. 13:27 skrev Alan Bateman :
>
>> On 26/11/2018 09:08, Nick Gasson wrote:
>> Hi Alan,
>>
>> I've done this here:
>>
>> http://cr.openjdk.java.net/~njian/8214077/webrev.3/
> This looks good and I think means we no longer have any stat usages in
> libjava.
Do we have stat
On 2018-11-21 11:08, Nick Gasson wrote:
Hi Alan,
Have you looked at replacing the remaining usages of stat changed to
stat64 instead?
I've tried this just now and it also resolves the issue. I can
test on some more platforms and update the webrev if this is the
preferred solution?
I'd say
On 2018-11-20 18:50, Volker Simonis wrote:
On Tue, Nov 20, 2018 at 6:15 PM Thomas Stüfe wrote:
On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8 wrote:
Heya Tom,
"In JDK11 and JDK12, source files are compiled with -qvisibility=hidden
when using xlc version other than 12.1. That doesn't seem
On 2018-11-20 00:37, Roger Riggs wrote:
Hi,
Webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw
Build changes still look fine. But please, in the future, avoid updating
webrevs in place, but create new ones instead. It's hopeless to figure
out what has
On 2018-11-16 21:36, Erik Joelsson wrote:
Thanks, looks good to me now.
And to me.
Looks like a nice cleanup in general!
/Magnus
/Erik
On 2018-11-16 12:02, Roger Riggs wrote:
Hi Erik,
Yes, that is removed.
Webrev updated in place.
Thanks, Roger
I now noticed that this was only sent to build-dev. This is not really a build
question. Cc:ing core-libs-dev.
/Magnus
> 5 nov. 2018 kl. 15:21 skrev Magnus Ihse Bursie
> :
>
> Hi,
>
> Fix looks good, but maybe we should have a regression test of GetJREPath()?
>
> /
On 2018-10-24 19:18, Erik Joelsson wrote:
Hello,
Nice to see this finally happening!
Are we actually adding a new demo? I thought we were working towards
getting rid of the demos completely.
CompileJavaModules.gmk:
The jdk.packager_CLEAN_FILES could be replaced with a simple
> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg :
>
> Hi Kim,
>
> I like this initiative. I'm wondering if some of these rules can be easily
> codified or written into a jcheck style checker (ccheck?) so that Authors
> can adhere to the conventions and not rely on a Human review to pick out
>
> 25 sep. 2018 kl. 10:21 skrev Roman Kennke :
>
> Not sure this is the correct list. Please redirect as appropriate.
I believe core-libs is the appropriate place. Cc:d.
>
> Please review the following proposed change:
>
>
> There are 3 asserts in unpack.cpp which check only constants, and
The variable PACKAGE_PATH crept into the build when the macosx port was
integrated. It is not used, however, and should be removed. (This is a
BSD construct, and the macosx port was based on the BSD port.)
If/when the BSD port ever gets integrated upstream, we'll know better
then how to
On 2018-09-18 19:41, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209880
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
Looks good. Thank you for fixing this!
/Magnus
The
-Original Message-
From: Magnus Ihse Bursie
Sent: den 14 september 2018 09:22
To: Erik Joelsson ; Alan Bateman
; core-libs-dev@openjdk.java.net
Cc: build-dev
Subject: Re: Why static_jli for java/javaw on Windows?
On 2018-09-14 01:17, Erik Joelsson wrote:
I checked and the copying
14:07, Magnus Ihse Bursie wrote:
:
Apparently, someone was trying to get rid of dll dependencies from
java.exe. Why that would be desirable it does not say. Neither why
this should not apply to all other launchers. (Perhaps there were
not that many in these days?)
Do anyone think this still
dency, yes that's a separate
issue. Since it's obvious, I included the fix with this changeset (it
was actually described as a comment in the jira issue).
Naoto
On 9/12/18 9:08 AM, Erik Joelsson wrote:
On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hell
201 - 300 of 405 matches
Mail list logo
