Approved for jdk8u-dev.
regards,
Sean.
On 29/05/2018 15:42, Alexey Ivanov wrote:
I can fix it before pushing.
Regards,
Alexey
On 29/05/2018 15:13, Erik Joelsson wrote:
Looks good (except for my spelling error in the comment "siutations".
Not sure what the policy is for fixing such in backp
looks good. You'll need to run the new CryptoPolicyFallback.java
testcase in othervm mode.
Regards,
Sean.
On 02/12/16 23:50, Bradford Wetmore wrote:
Hi,
I need reviewers for these related bugs:
https://bugs.openjdk.java.net/browse/JDK-8170157
Enable unlimited cryptographic policy by default
=
300: Indention problem.
Looks ok otherwise.
Thanks,
Brad
On 11/4/2016 7:16 AM, Erik Joelsson wrote:
Build changes look ok to me.
/Erik
On 2016-11-04 14:42, Seán Coffey wrote:
Looking to push this enhancement to jdk8u. The change introduces the
new Security property which was brought i
Looking to push this enhancement to jdk8u. The change introduces the new
Security property which was brought into JDK 9 via JDK-8061842.
The code differs in that jar files continue to be used and backwards
compatibility is maintained. If the new security property is not defined
and the policy
Haven't forgotten about this one. Hope to get to it today.
Regards,
Sean.
On 05/08/2016 16:12, Andrew Hughes wrote:
- Original Message -
I'm seeing this patch fail across all platforms on internal builds.
Please hold off any push for now. Maybe other config changes are needed
on our b
One suggestion to future proof your fix might be to pattern match
against any CPU of M7 of greater perhaps. Something like SPARC-M[7+]
perhaps.
Regards,
Sean.
On 03/08/16 11:47, Erik Joelsson wrote:
Followup on this. I did a compare build on Solaris with 8GA and 8u20.
There is a slight differ
Andrew,
there are some non-OpenJDK related changes that I need to make at time
of this push. Is it OK if I push this patch to jdk8u-dev for you ?
Approved for jdk8u-dev.
Regards,
Sean.
On 02/08/2016 11:11, Seán Coffey wrote:
I'm seeing this patch fail across all platforms on int
I'm seeing this patch fail across all platforms on internal builds.
Please hold off any push for now. Maybe other config changes are needed
on our build systems.
e.g.
/opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC
\
-m64 -G -KPIC \
Hi Martin,
such packages are not in the scope of the OpenJDK project. I'll ping you
offline with some contacts.
Regards,
Sean.
On 28/07/2016 10:58, Martin Walsh wrote:
Hi,
I am currently building the JVM on Solaris 11.3. I am trying to
figure out how to build IPS packages from the SVR4 pa
Approved for jdk8u-dev once you have a peer code review.
Regards,
Sean.
On 12/02/2016 08:19, Alexey Ivanov wrote:
I forgot to add jdk8u-dev list...
On 11.02.2016 17:19, Alexey Ivanov wrote:
Hello,
Could you please review the fix for JDK-8147807 and approve push to
8u-dev?
JBS: https://bug
e 1:1. It's great to have system
library support - I'm just highlighting a possible risk. A fall back
option solves that but there's no appetite for such a solution. Let's
see how it goes.
regards,
Sean.
Sherman
On 02/10/2016 06:41 AM, Seán Coffey wrote:
On 10/02/16 14
On 10/02/16 14:29, Alan Bateman wrote:
On 10/02/2016 13:57, Seán Coffey wrote:
I'm all for allowing one to introduce a new version of zlib to their
JDK at runtime. I just don't think it's in the interests of
enterprises and stability to introduce a dependency to the JDK on the
On 08/02/16 09:55, Alan Bateman wrote:
On 08/02/2016 10:42, Seán Coffey wrote:
Is there an option to fall back to the older v.1.2.8 implementation
if necessary ? It would certainly alleviate issues for any
applications that might run into issues with the latest and greatest
zlib libraries
Is there an option to fall back to the older v.1.2.8 implementation if
necessary ? It would certainly alleviate issues for any applications
that might run into issues with the latest and greatest zlib libraries.
JDK-8133206 would be one such example.
Regards,
Sean.
On 05/02/2016 18:55, Xuemin
Approved but subject to review. Please add the noreg-build label. Add
the 9-na label if it's not applicable to JDK 9. If it is applicable to
JDK 9, create a backport record so that it doesn't get overlooked.
Regards,
Sean.
On 18/09/15 17:41, Erik Joelsson wrote:
Hello,
Please approve and rev
Great to see this model coming into sync with the JDK build versions.
Looks good.
Regards,
Sean.
On 21/07/2015 03:22, Alejandro E Murillo wrote:
On 7/20/2015 7:10 PM, David Holmes wrote:
Hi Alejandro,
On 21/07/2015 10:45 AM, Alejandro E Murillo wrote:
Please review the following change t
Looks fine to me Phil. Thanks for handling.
Approved. RDP2 for 8u66 [1] is approaching fast. We'll have to work out
if this makes the PIT snapshot.
[1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html
Regards,
Sean.
On 21/07/2015 20:11, Phil Race wrote:
Bug : https://bugs.openjdk.
Regards,
Sean.
On 16/06/2015 09:04, Andreas Lundblad wrote:
On Mon, Jun 15, 2015 at 02:30:41PM +0100, Seán Coffey wrote:
Hi,
I had a security library fix reviewed last week [1] and all was ok
with builds back then. Today, I found that my build is broken and I
think it's down to the ch
Hi,
I had a security library fix reviewed last week [1] and all was ok with
builds back then. Today, I found that my build is broken and I think
it's down to the changes introduced from the 8054717 fix.
The build error (snippet) is :
/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11
It might be good to edit the bug synopsis before pushing the change. I
don't think this issue is specific to java.net bundles. Might also be
useful to use the noreg-sqe label rather than noreg-build given that SQE
team do appear to have test code for this area.
Approved pending code review.
R
8u45 was a Critical Patch Update (CPU) release and such releases are not
worked via the OpenJDK forests. You won't be able to build the
equivalent of Oracle JDK from OpenJDK sources given that the Oracle JDK
contains extra features like plugin and installer bundles.
The Oracle JDK is built on
Pete,
http://openjdk.java.net/projects/jdk8u/groundrules.html
Rule 1. What are your plans for JDK 9 ? Is that family affected ? If not
- add '9-na' label to bug report.
Rule 4. Approval requests should be carried out on jdk8u-dev mailing list.
regards,
Sean.
On 08/04/2015 19:14, Pete Brunet
Hi Severin,
I'd missed your previous request. It was marked as a review request!
Consider this approved for jdk8u-dev. Can you add a 'noreg-build' label
to the bug report ?
Erik, would you be willing to push this changeset to the 8u-dev forest
? Looks like there's some closed code that needs
Hi Bhavesh,
Approved for jdk8u-dev. I'll help push this patch and the other 2 doc
related ones (8068491, 8068495) to jdk8u-dev. I'll also work with you on
getting these into 8u40.
regards,
Sean.
On 13/01/15 08:05, Erik Joelsson wrote:
Looks good to me.
/Erik
On 2015-01-13 00:40, Bhavesh P
Chris,
just a passing comment from me. I've been looking at the extension
directory changes. Looks like some code, locale resource files, man
pages and help menus still need updating to remove the ext dir
references. Is that tracked already ?
The rmic, javadoc and javac tools still have the
Approved but subject to a code review. Please add a noreg- label to the
bug report also.
regards,
Sean.
On 07/10/2014 09:33, Erik Joelsson wrote:
Hello,
Please review and approve this backport from jdk9 to jdk8u40. The
patch does not apply cleanly, but with a slight reduction it works
just
On 19/09/14 17:33, Alan Bateman wrote:
On 19/09/2014 17:22, Phil Race wrote:
Gosh that's going to be a pain to maintain .. here's an update to the
334 affected lines in that file ! Look ok ?
http://cr.openjdk.java.net/~prr/8056216.1
-phil
Ideally there should be just one line per directory,
Hi Phil,
you'll need to update the unshuffle script[1] also given your path
changes. A find/replace operation should work. It probably makes sense
to push all changes together.
Regards,
Sean.
[1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html
On 19/09/14 09:28, Magnus Ihse Bursi
Hurka wrote:
Hi Sean,
I guess that the “jdk7” text in following comment:
# When compiling code to be executed by the Boot JDK, force jdk7
compatibility.
should be changed to jdk8. It is on the line before
“BOOT_JDK_SOURCETARGET” change.
On 13 May 2014, at 00:22, Seán Coffey wrote:
While adding
While adding some lambda code to a CORBA class, I got a build time error
indicating that the build was running with -source 7.
Given that JDK 8 is now the official bootstrap JDK for JDK 9 building, I
think we can bump the -source and -target properties up to 8 (from 7)
bug ID : https://bugs.o
On 03/04/2014 11:17, David Holmes wrote:
Don't we also need to modify jprt properties?
Which properties need changing David ? We should list them.
The strange thing here is that JPRT is already using JDK 8 (b132) as
bootstrap. That's how the CORBA build failures passed by me.
regards,
Sean.
JDK 8 does continue to ship with tzdata info built into it. The
structure changed significantly with the introduction of JSR 310. The
lib/zi directory has been replaced with one lib/tzdb.dat file which
contains the tzdata rules in compiled format.
You can always add the latest tzdata to the jd
https://bugs.openjdk.java.net/browse/JDK-8029292 logged to capture this
enhancement request.
regards,
Sean.
On 27/11/13 16:36, Joe Darcy wrote:
+1.0!
-Joe
On 11/26/2013 3:01 PM, Mike Duigou wrote:
Yes please!
Mike
On Nov 26 2013, at 14:49 , mark.reinh...@oracle.com wrote:
Now that we've
Mikhail,
J4B is a private flag used in the closed install/deploy repos. It's not
suitable for discussion on OpenJDK.
I'll get back to you on this off mailing list.
regards,
Sean.
On 11/11/13 14:03, mikhail cherkasov wrote:
Hi all,
how to build J4B?
What flags should I pass to make or what e
o $OpenJDK prints the value while echo
$OPENJDK prints nothing!
Sorry for the noise and thanks for your attention on my problem
May be it would be interesting to add a check on the value of OPENJDK
somewhere to avoid such mistake.
Francis
Le 23/09/2013 19:46, Seán Coffey a écrit :
I don
Makefile:191: recipe for target `generic_build2' failed
make[1]: *** [generic_build2] Error 2
make[1] : on quitte le répertoire «
/cygdrive/z/DEV/OpenJDK7u/hotspot/make »
Makefile:151: recipe for target `jvmg' failed
make: *** [jvmg] Error 2
FrancisANDRE@idefix /cygdrive/z/DEV/OpenJD
Francis,
the OpenJDK 7 repository corresponds to the JDK 7 GA release made a few
years ago. The OpenJDK 7u repository is used to gather fixes for the JDK
7 update releases.
Isn't this patch already in the updates ? (7u2)
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2f27ed2a98fa
https:/
Approved.
regards,
Sean.
On 13/02/2013 22:35, Tim Bell wrote:
Requesting approval for these changes in make/common/Release.gmk
Adding a total of 8 lines in the open makefile. The OracleJDK pages
will be placed in a closed part of the forest.
Webrev:
http://cr.openjdk.java.net/~erikj/8007
Looks like you don't have the correct X11 header files on your build
system. X11/Intrinsic.h is required.
I'm seeing it under /usr/include on my system.
regards,
Sean.
On 29/12/2012 19:09, miten mehta wrote:
Hi,
I get following build error on debian for openjdk 7:
In file included from ../..
27;t
need the functionality and for the ones that do - they have the
FULL_DEBUG_SYMBOLS switch to flip..
JPRT and other internal build systems can activate such a switch easily
also.
my two cent.
regards,
Sean.
On 11/10/12 15:35, Daniel D. Daugherty wrote:
On 10/11/12 3:21 AM, Seán Co
Moving this off discuss mailing list to build-dev.
Why is ENABLE_FULL_DEBUG_SYMBOLS being set to 1 for many product builds
now ? It slows down the build and creates increased bundle size even
though the majority of users do not require this functionality.
Could we consider flipping the defaul
ghes wrote:
- Original Message -
On 21/08/2012 9:37 PM, Seán Coffey wrote:
Looks fine to me but best to get an official jdk8 reviewer.
Looks fine to me too.
Thanks David. Is there a preferred tree for me to push this to?
Not from me.
David
-
I presume the filter-out option
Looks fine to me but best to get an official jdk8 reviewer.
I presume the filter-out option on macosx becomes a no-op (on OpenJDK
builds) some lines later : (Images.gmk)
264 JDK_MAN_PAGES := $(filter-out jvisualvm.1, $(JDK_MAN_PAGES))
On the subject of dual Makefile maintenance, are there
I can't find the original jdk8 review thread either.
Good catch Andrew. I've created a bug ID for you : (should be live in
next 1-2 days)
7192804 : Build should not install jvisualvm man page for OpenJDK
Needs addressing in JDK8 and 7u. JDK8 will need addressing in the old
and new makefile sy
Similar to 7163470, the JDK has historically allowed builds without the
javax.crypto package src.
In such cases a jce.jar bootstrap should be used where necessary. One
remaining use case is during javadoc building process. Simple fix and
I've verified with a test build of docs.
bug report :
Martijn,
there's a pretty annoying build bug around the security build area that
I think you've hit. I haven't had time to look into it in detail yet.
I think Max's suggestion is to *move* the top level build directory to a
new name (not copy it). Basically a jdk8_tl/build/linux-amd64 and
jd
Martijn,
I ran into same issue a few weeks back. If you're only interested in
building the jdk repo, you can update your ALT_HOTSPOT_IMPORT_PATH
variable to point to a recent 7u4 build.
e.g export ALT_HOTSPOT_IMPORT_PATH=/export/home/jdk1.7.0_04
recent binaries at : http://jdk7.java.net/down
I ran into the same issue last week.
I'm hoping to push some RMI changes to 6-open shortly. Will push 7058133
in there also.
regards,
Sean.
On 14/11/11 16:34, Kelly O'Hair wrote:
After you apply the fix, you need to start from scratch, delete the
build/ directory and start again.
-kto
On
48 matches
Mail list logo
