On 16/10/2013 21:22, Mike Duigou wrote:
Hello all;
With the imminent promotion of JTReg 4.1b07 it's possible to finally consider
completing this changeset!
http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/
This updated webrev includes handling of the shared library permissions.
On 16/10/2013 01:04, David Holmes wrote:
I think API restrictions already apply to the sun.tools packages - and
both language and API restrictions apply to other build tools that are
compiled using the boot JDK.
Yes for build tools but not sun.tools.** in general (the change to
On 15/10/2013 16:29, Volker Simonis wrote:
:
By the way, the main problem why the IBM J9 idlj and rmic didn't work
out of the box were some command line options which were only
supported by the Oracle implementation. It would therefore be very
nice if you could completely remove such options
On 15/10/2013 15:30, Erik Joelsson wrote:
Currently the RMI stubs in the jdk are built with the newly built rmic
binary at the end of the build. This patch changes that and instead
builds a bootstrap version of the rmic classes, much like bootstrap
javac in langtools, which runs on the
This is an update to the BuildMetaIndex tool, the tool used in the build
to generate the meta-index file.
The problem is that the tool assumes that there are at least two levels
of package in the name of each type. This causes a problem for
jdk.Exported, the annotation that was added as
Looks good. At some point it would be great to have a page somewhere
with the list of things that need to be updated when we move major
versions. There always seems to be something that only remember late in
the release.
-Alan
On 11/10/2013 11:50, Erik Joelsson wrote:
Please review this
On 10/10/2013 01:47, David Holmes wrote:
webrev:
http://cr.openjdk.java.net/~dholmes/8026232/webrev/
libnpt.so is used for debugging and profiling but was mistakenly
placed in profile compact1. It should be in compact3 along with the
hprof agent that uses it (other users are in full JRE).
On 10/10/2013 11:10, Michael McMahon wrote:
Can I get the following change for jdk 8 reviewed please?
It's a simple build change to enable compilation of the dummy
SCTP API layer on macosx, plus the dummy implementation
used on windows.
The existing jdk_sctp tests cover this.
I need a reviewer for a trivial change to add an additional package to
the API docs.
The background to this one is that JAXP has historically included the
API package org.w3c.dom.events but not org.w3c.dom.views. As
org.w3c.dom.events.UIEvent defines a method that returns a type in
On 01/10/2013 09:58, Mike Duigou wrote:
The change looks fine to me. I assume you are going to be pushing this through
TL?
Mike
Thanks Mike (and Tim). I'm going to push this through jdk8/tl.
-Alan.
On 06/09/2013 20:01, Naoto Sato wrote:
Hello,
Please review the fix for the following bug. At the moment, it's not
yet reflected in the bug database, but the symptom is that
sun.util.resources.en package is split between rt.jar and
localedata.jar, which would make it problematic in Jigsaw
On 09/09/2013 16:12, Kumar Srinivasan wrote:
Alan, are the nio changes acceptable? Let me know if you need more
time to go over all
the changes.
It looks fine (sorry I should have made that clearer). I skimmed over
the other tests too (the launcher tests in particular) and don't see any
On 06/09/2013 17:47, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove Solaris 32-bit binaries from JDK8
distros,
at this time the dual mode support in the launcher is being disabled.
Message regarding this:
On 16/08/2013 21:48, Mike Duigou wrote:
:
This could be corrected by changing the default to images. The current
default isn't really useful to anyone.
Maybe an informal survey is required but the normal way of working has
traditionally been to use the exploded classes (or jdk/classes as it
On 07/08/2013 14:44, Mike Duigou wrote:
Hello all;
This changesest simplifies how the the jdk/test/Makefile processes excluded
tests. Previously the test exclusions were pre-processed by scripts in the
Makefile before being passed to JTReg. JTReg will now the all the processing.
The change
On 07/08/2013 18:44, Jonathan Gibbons wrote:
:
Aaargh. If I read those words correctly, it's a horrible idea to set
the output dir to TEST_ROOT -- because on reruns jtreg will have to
scan the output files looking for new tests!
-- jon
Is that an existing problem as the output always goes
On 31/07/2013 05:18, Aleksej Efimov wrote:
Hi,
Can I have a review for the following problem:
The MACOSX JDK (more precisely - the java.net classes) uses the
select() system call to wait for different events on sockets fds. And
the default behaviour for select() on Darwin is to fail when fdset
On 26/07/2013 23:24, Phil Race wrote:
Flogging a dead horse here ..
it shouldn't really be necessary to do partial builds any more (it
was way too fragile in the past with the old build)
I whole heartedly disagree. I've said it before and I say it again.
I do not want to build hotspot or
On 26/07/2013 20:38, Mike Duigou wrote:
On Jul 26 2013, at 18:41 , Pete Brunet wrote:
Am doing my first jdk8 build. After reading through the build readme I
didn't see any info on building just jdk and using an import lib. I'm
guessing this is no longer possible but checking...
It's
On 10/07/2013 12:01, Omair Majid wrote:
On 07/09/2013 03:40 AM, Erik Joelsson wrote:
I would like to see a comment explaining why the option was needed. Is
this a bug in gcc or has the checking just become better?
-Werror is not a great default. It means all warnings are errors. The
set of
I need a reviewer for a small change to the profiles build so that JFR
is not included in compact3 builds (as it's not required there).
Thanks,
-Alan
diff --git a/makefiles/profile-includes.txt b/makefiles/profile-includes.txt
--- a/makefiles/profile-includes.txt
+++
On 20/06/2013 09:07, Erik Joelsson wrote:
Simple patch removing unnecessary check for existence of mercurial for
getting the hgtips for the release file. This check prevented the
backup solution of using the .hgtip files from working when building
from source bundles.
On 19/06/2013 09:01, Erik Joelsson wrote:
:
My preferred solution would be to fold in the repos that aren't
upstream projects into jdk and just have them compile with the rest
there. I much like the idea of reducing the number of repos. If that
isn't possible, we can just add those source
On 14/06/2013 17:21, Mike Duigou wrote:
I found -concurrency:auto generated too many jobs on the machines I use.
-concurrency:$(JOBS) is currently always smaller than -concurrency:auto.
$JOBS is currently approximately min(16, min($(CORES),$(MEMORY) / 1100M)))
If we find that $JOBS ends up
with 8014819 as the two issues
have been tested together. Thanks go to Amy Lu and Alan Bateman for their
feedback and experience reports with concurrent testing.
JPRT is not impacted by this change since it invokes the test/Makefile directly.
Mike
diff -r b40d24f793d2 common/makefiles/Main.gmk
On 05/06/2013 19:02, Phil Race wrote:
Yes, please support the old build system.
Is this really necessary? The old build is a tax and we really need it
to die. In this case, it's a new feature and I don't see any point in
anyone spending time adding this support to the old build.
-Alan
The new build has been the default for more than 4 months now (since b74
I think). For the period after the switch then we were careful to keep
the old build working but it's a tax and I'm wondering if we are past
that phase now. If we are past that phase then I wonder if there is a
plan to
On 04/06/2013 12:25, Erik Joelsson wrote:
On 2013-06-04 13:18, Alan Bateman wrote:
The new build has been the default for more than 4 months now (since
b74 I think). For the period after the switch then we were careful to
keep the old build working but it's a tax and I'm wondering if we
On 22/05/2013 05:20, David Holmes wrote:
On 21/05/2013 9:50 PM, Erik Joelsson wrote:
Looks good to me.
So has a bug been filed yet? :)
I think some further investigation is still needed because
gensrc_jobjc is being used in some places and not others and I'd want
to verify they are all
On 21/05/2013 06:00, David Holmes wrote:
Hi Alan,
That log looks correct to me. can you verify if the missing types are
indeed within:
/u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar
?
David
That's the boot JDK so it isn't going to have types that are new in
jdk8. So
On 21/05/2013 08:36, David Holmes wrote:
While that is probably true, it seems to me that the cause of the
problem here is that the javac source path includes
/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc -
and that seems wrong to me. It comes from
On 21/05/2013 10:53, Erik Joelsson wrote:
In the old build, JObjC.jar was built completely differently from all
other java classes, by an ant script. We kept the source/target 1.5
when converting to the new build to keep the builds equal. I very much
doubt there is a reason for it now though.
I've have an up-to-date clone of jdk8/tl + a patch to code in the jdk
repository that makes use of APIs that are new in jdk8. It builds/run
happily on all platforms except Mac where it needs to build JObjC.jar.
Attached is the tail of make LOG=trace where it looks like JObjC.jar
involves
On 14/05/2013 02:26, Jonathan Gibbons wrote:
On 05/13/2013 06:23 PM, Jonathan Gibbons wrote:
genstubs is a utility used to help javac through the bootstrap
process. It needs to be updated to strip the default modifier and
method body from default methods in interfaces.
I'm not sure if this
On 13/05/2013 13:14, A. Sundararajan wrote:
Incorporated changes as suggested. Uploaded webrev for historical
purpose:
http://cr.openjdk.java.net/~sundar/8012975/webrev.02/
PS. I am going ahead with push..
Thanks for fixing up refs.allowed, that one looks fine okay.
Did you decide to keep
No objection although it feels like we are going backwards rather than
forwards.
I submitted a few bugs on this topic recently as it seems to me that
there aren't too many override warnings to kill off. Daniel Fuchs has a
patch out for review today that fixes these warnings in the jaxp
On 13/05/2013 16:40, A. Sundararajan wrote:
I agree that it is better to remove com.sun.script.util package as
well. It is not used elsewhere and was never declared as supported
API. I've removed the same and re-generated webrev.
http://cr.openjdk.java.net/~sundar/8012975/webrev.03/
I ran
On 10/05/2013 10:26, A. Sundararajan wrote:
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8012975/webrev.01/
Thanks
-Sundar
PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed.
refs.allowed isn't quite right, the last line needs to be removed
On 10/05/2013 11:23, A. Sundararajan wrote:
com/sun/script/util is generic utility package for script engine
implementations. Only com/sun/script/javascript package is being
removed. Since we include javax/script for profile 3, should we also
include com/sun/script/util ?
Is
I'd like to propose adding javax.script to the compact1 builds (it has
been in compact3 to date). The rational is to provide a supported way
for applications running on the smallest profile make use of scripting
languages. The original goal of compact1 was to provide a migration
target for
On 03/05/2013 07:47, A. Sundararajan wrote:
Thanks. Looks like the first one has not been removed. But second one
was removed: hg stat shows
R make/sun/org/mozilla/javascript/Makefile
(also the webrev shows it as removed). Perhaps patch does not take
care of deleted files?? I am not sure.
On 02/05/2013 17:41, A. Sundararajan wrote:
Hi,
Oracle JDK includes Rhino based javax.script implementation (which
lives mostly in closed code). Rhino is being removed from Oracle JDK
builds and there are the changes to the jdk open repository as well
like com.sun.script.javascript package,
On 29/04/2013 09:51, Chris Hegarty wrote:
Thanks for the explanation, it makes reviewing much easier.
I can see the additional types in the changeset for 8005523, so it
looks good to me.
If possible, it would be nice if that anyone touching source that
effects jsse.jar could also check the
I need a reviewer for a small update to the refs.allowed file used by
the dependency checking tool in the profiles build.
To re-cap, the profiles build does not subset jsse.jar even though there
is JSSE code that references Kerberos classes that do not exist in
compact1 and compact2 builds.
On 21/03/2013 22:12, Brad Wetmore wrote:
:
The codereview is here:
http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/
I plan to push through the deploy gate, as they have an integration
next week. Thomas Ng will do the push for us.
Any objections, please speak now.
No objection
On 18/03/2013 19:59, David Holmes wrote:
Very simple fix/cleanup.
webrev: http://cr.openjdk.java.net/~dholmes/8009426/webrev/
nashorn.jar was being added to the set of JARS targets regardless of
what was being built, but nashorn is not a dependency for profiles
target. JARS is not used the
On 19/03/2013 16:19, Jen Dority wrote:
Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/.
This resolves JDK-8006818 which calls for adding the SunEC and
SunPKCS11 providers to the compact* profiles.
Thanks,
Jen
This looks okay to me although the SunPKCS11 provider isn't
On 14/03/2013 01:26, David Holmes wrote:
:
3. -Werror is set for the SCTP native code causing the build to fail:
Lots of stuff like:
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24:
error: unused parameter 'klass'
On 11/03/2013 01:24, David Holmes wrote:
I had overlooked the need to update the ct.sym creation tool to
recognize the new syntax in the profile spec file. That process also
uncovered a few bugs in the listing that needed correcting.
The javadoc generation of compact profile information is
On 05/03/2013 15:14, Erik Joelsson wrote:
:
Discovered some more problems with the bootcycle-images target that
needed to be fixed. A full bootcycle build is still not possible due
to errors like this:
On 28/02/2013 16:11, Martin Buchholz wrote:
On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman alan.bate...@oracle.com
mailto:alan.bate...@oracle.com 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 27/02/2013 23:16, Martin Buchholz wrote:
I have another iteration of this change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk8/hide-zlib/
that adds exciting new exception detail message for the InternalError
I was
On 26/02/2013 14:10, Chris Hegarty wrote:
On 02/26/2013 01:52 PM, Alan Bateman wrote:
While looking at the Nashorn build changes, I see that
top/make/nashorn-rules.gmk is included by the top-level Makefile but
was missed in the change-set.
Wow, a whole missing rules file! I'm surprised
Last week, David Holmes had to do a temporary addition to refs.allowed
(used by the dependency analyzer in the profiles build) in order to get
profiles over the line (a last minute glitch caused by closed code). The
temporary addition can now be removed so I'd like to get that done
before it
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 the image name is j2sdk-image or j2re-image so renaming will
be a
On 22/02/2013 22:03, Martin Buchholz wrote:
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
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 the old build system, but not
the new one.
I don't know if you consider this a bug with the new build system -
it's supposed to generate
On 20/02/2013 14:20, Erik Joelsson wrote:
Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the
target bootcycle-images. Also fixing an issue with bootcycle-images
target that prevented them from creating images.
http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/
/Erik
On 19/02/2013 09:20, David Holmes wrote:
On 19/02/2013 6:27 PM, Erik Joelsson wrote:
Looks good to me.
Thanks Erik. I guess I also need a jdk8 Reviewer ?
David
It looks fine to me too.
-Alan.
Changeset: 6f4615fd32da
Author:alanb
Date: 2013-02-19 11:08 +
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6f4615fd32da
8007097: (profiles) Build needs test to ensure that profile definitions are
updated
Reviewed-by: dholmes, erikj
-
As David mentioned in another mail, he is hoping to push the profiles
work to jdk8/build next week. One update that is needed to the
configuration is the changes to take account of ThreeTen (java.time.**).
This includes taking into account the ThreeTen updates for M7 that
remove the old time
On 29/01/2013 14:54, Erik Joelsson wrote:
Adding a chmod when copying msvcr100.dll into the jdk output dir. The
unix permissions shouldn't be needed on windows, but if the bundles
are unzipped on unix and accessed over nfs or samba, permissions matter.
On 24/01/2013 00:23, Martin Buchholz wrote:
:
Many years ago I filed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4904617
that remains unaddressed :-(
Perhaps as part of this change or set of changes, that bug could be dealt
with?
Perhaps even by deleting JVM_Read?
I believe there is
On 22/01/2013 19:09, Xueming Shen wrote:
Hi,
Webrev has been updated to address the build issue in the
new build infra. M
(1) added the java.time packages into
common/makefiles.javadoc/CORE_PKGS.gmk
to be included into ct.sym
http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/
(2) not
On 22/01/2013 22:19, David Holmes wrote:
All of the jar building was modified so that jars go into images/lib
not jdk/lib. So it should not be necessary (or desirable) to build
into jdk/lib and then copy over.
Sherman can confirm, but I believe the TzdbZoneRulesProvider requires it
in the lib
On 15/01/2013 11:13, Erik Joelsson wrote:
This fix adds the missing manifest to sunmscapi.jar. This should fix
javax/crypto/sanity/CheckManifestForRelease.java which is currently
failing for build-infra builds.
http://cr.openjdk.java.net/~erikj/8006296/webrev.jdk.01/
/Erik
This looks good
On 14/01/2013 13:24, Erik Joelsson wrote:
This didn't quite work as I expected. Found the issue in needing to
include SPEC before Jprt.gmk so that variables from SPEC would be
available in Jprt.gmk at parse time.
http://cr.openjdk.java.net/~erikj/8006100/webrev.root.02/
/Erik
Thanks Erik,
On 08/01/2013 14:07, Erik Joelsson wrote:
Five classes which in jigsaw will be located in the base module
currently have their native headers generated in a special way
(explicitly with javah). This was because the base module could not be
made dependent on the compiler module where the
I upgraded a Mac to 10.8.2 and Xcode 4.5.2 over the break, now I'm
trying to get the jdk7u/jdk7u-dev, jdk8/tl and jigsaw/jigsaw forests
building again. I installed XQuartz 2.7.2 so I have X11 and jdk8/tl
builds fine with the new build (except for the images target, there's
an issue with sed
On 07/01/2013 10:03, Joel Borggrén-Franck wrote:
On 7 jan 2013, at 10:43, Alan Batemanalan.bate...@oracle.com wrote:
I upgraded a Mac to 10.8.2 and Xcode 4.5.2 over the break, now I'm trying to get the
jdk7u/jdk7u-dev, jdk8/tl and jigsaw/jigsaw forests building again. I installed XQuartz
On 07/01/2013 13:57, Fredrik Öhrström wrote:
:
The makefile comments, comment on the fact that Java sources that
reside inside make/tools
are in fact part of the dt.jar (ie part of the jdk, not just a tool).
However this is not that easy to fix, since the actual tool that
generates the swing
On 04/01/2013 05:29, Frank Ding wrote:
Hi Kelly
I investigated how local specific characters get into generated
sources in corba module. Those classes are generated by following
command idlj
c:/openjdk/dep/jdk1.7.0_02/bin/idlj -J-XX:-PrintVMOptions
-J-XX:+UnlockDiagnosticVMOptions
On 21/12/2012 12:58, Fredrik Öhrström wrote:
:
The example Erik gave: make jdk-only JDK_FILTER=java/awt
Be aware that this workaround is of limited use, since it does not assist in
recompiling dependent packages, if the public api of java.awt was changed,
you need to know the 79 other packages
We're reviewing this one on core-libs-dev and the changes involve a
small build change to accommodate new locations in
src/share/classes/jdk/internal. As it's just pure java code then there
is no impact to the new build; for the old build we just need a
top-level Makefile, the
On 05/12/2012 11:23, Chris Hegarty wrote:
Looks fine me.
-Chris.
Thanks, I'd like to get someone from the build group to okay this too.
-Alan
On 30/11/2012 17:05, Kelly O'Hair wrote:
:
The overlay image has been one of these special cases that I would like to
avoid, but at the same time, building two rt.jar
files for the 32bit and 64bit images seems pretty silly too.
So for the sake of simplicity, I'm willing to take the build two
On 28/11/2012 19:45, Kumar Srinivasan wrote:
Hi,
Is it possible for the new infra, to produce a composite image of both
server and
client VMs on Solaris 32-bit
--with-jvm-variants=client,server --with-target-bits=32
For extra credits is it possible to build the 64 bit image as well and
On 30/10/2012 16:33, Naoto Sato wrote:
Hello,
I need someone to review my changes to the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231
The fix is to move locale data out of rt.jar into localedata.jar which
will be optional in the compact profile
On 29/10/2012 12:41, John Yeary wrote:
Thanks Ulf, that was my exact point Ulf. Although, you were much more
eloquent.
One of the most consistent things that Java has done is ensuring backwards
compatibility. The removal of something like the JDBC-ODBC bridge will
cause issues later. We tell
We're jettisoning the legacy JDBC-ODBC bridge from Oracle's jdk8 builds
and this means updating several make files. Here's the webrev:
http://cr.openjdk.java.net/~alanb/7176225/webrev/
I believe I got everything in the both builds. The only thing that isn't
clear is the old Def-solaris.gmk
On 26/10/2012 21:14, John Yeary wrote:
Hello All,
Out of curiosity what will replace it? I looked at the transitional
notification[1], but it leaves me feeling a little uneasy about it. At one
point, I worked on a number of simple applications which used MS Access
as the database for a Java
On 23/10/2012 19:47, Dan Xu wrote:
Thank you for all your good comments. After adding the
@GenerateNativeHeader annotation, I am able to build the jdk using the
new build.
But where can I check whether this class is part of the base module in
jigsaw? Or should I just use the annotation as
On 23/10/2012 09:16, Erik Joelsson wrote:
:
The first question then is whether a native header is still needed for
java_io_FileSystem? Are the constants used in native code? Do they
still belong in this class given that the method moved? I have no
idea, so I'm asking you.
Yes, with Dan's
On 17/10/2012 19:33, Mandy Chung wrote:
On 10/17/2012 11:29 AM, Kelly O'Hair wrote:
Looks ok to me. Did you plan on integrating it into jdk8/build?
I can do that. Thanks for reminding me - my local repo is a clone of
jdk8/tl.
It probably doesn't matter if this goes in via jdk8/tl.
-Alan.
On 17/10/2012 19:11, Mandy Chung wrote:
I need a reviewer to fix this build problem that only affects partial
build.
make/common/internal/Defs-jaxws.gmk maintains an explicit list of
JAXWS packages to import from a JDK for a partial JDK. However,
the list was not up-to-date and missing some
On 12/09/2012 19:49, Kelly O'Hair wrote:
Some stats on incremental builds. Not partial builds..
This is an older Solaris machine svc6.us.oracle.com, building the complete
openjdk forest from scratch
for 64bit including images took less than 14 minutes (parallel build setting
was 8) and images
On 11/09/2012 19:23, Fredrik Öhrström wrote:
Den tisdagen den 11:e september 2012 skrev Alan Bateman:
So far my experience is that touching native code and re-building
is super fast, it's on par to executing specific make files in the
old build (while wearing the appropriate amulet
I think this is a great topic to discuss.
At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say partial build then I
mean they build a subset of repositories, not all of them. So folks
working in the jdk repository tend to just
On 31/07/2012 00:24, Andrew Hughes wrote:
Ok for the build forest?
Once reviewed then I think jdk8/tl would be better as that's the route
that the changes to the zip code take.
-Alan.
On 04/06/2012 15:15, Erik Joelsson wrote:
I have created a (hopefully temporary) hack to run javah manually for
these 5 classes. This webrev is just against the build-infra repo.
Unless anybody objects to this temporary solution, I will publish a
new full webrev against the jdk8/build forest
On 04/06/2012 17:52, Kelly O'Hair wrote:
./share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java:@GenerateNativeHeader
./solaris/classes/sun/nio/ch/sctp/AssociationChange.java:@GenerateNativeHeader
./solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java:@GenerateNativeHeader
Kelly,
Can you hold off pushing this for a few days? While this is compile-time
only dependency I think the impact needs further study.
-Alan.
On 23/05/2012 02:14, Kelly O'Hair wrote:
7170969: Add @GenerateNativeHeader to classes whose fields need to be exported
for JNI
On 16/05/2012 13:32, Erik Joelsson wrote:
The build-infra project has been quite productive and would like to
push an update to the new build in jdk8.
All webrevs can be found here:
http://cr.openjdk.java.net/~erikj/build-infra-m1.1/
http://cr.openjdk.java.net/%7Eerikj/build-infra-m1.1/
On 02/05/2012 09:27, Jonathan Lu wrote:
Hi build-dev,
I've got a minor change to fix an invalid path from README.txt of
MemoryMonitor demo, could anybody please help to take a look?
http://cr.openjdk.java.net/~luchsh/7165722/
Best regards!
- Jonathan
7165722 was submitted as an incident
This isn't really an issue for the first push, more of a question as to
how this will all look once the remaining make files has been converted.
My question relates to jdk/makefiles/CompileJavaClasses.gmk and
CompileNativeLibraries.gmk and how they will be maintained more longer
term. Is the
On 26/03/2012 02:25, Weijun Wang wrote:
:
There is completely no harm in setting JDK 8 as BOOTDIR of JDK 8, but
I would suggest you using 7u4. If there is anything wrong, you can
send us a bug report.
I don't think we can guarantee that jdk8 will always be buildable using
another jdk8 build
On 26/03/2012 11:42, Jonathan Gibbons wrote:
Alan,
Really? I'm not sure I agree. If you have a complete and successful
build of JDK 8, then you should pretty much always be able to use that
as a bootstrap JDK.
No argument on that case as everything should match. The case I'm
concerned about
On 26/03/2012 12:34, Jonathan Gibbons wrote:
Right now, in the current build, we use a hybrid javadoc to build
the API documentation, where hybrid means: latest sources, running
on bootstrap JDK.
Looking to the future, at least for Jigsaw, and now maybe for JSR 308,
we may need to run
On 25/03/2012 13:01, Martijn Verburg wrote:
Hi Sean/Alan/Max,
Sean - Your solution did the trick, and I'll probably use this for now
as it means a smaller VM for the members to work with
Alan/Max - I did get the full build going, but then my VM ran out of
space.
I see Seán suggestion is to
On 22/03/2012 17:51, Martijn Verburg wrote:
Hi Andrew/Alan,
Thanks for responding! I suspect you are right, I'm only building the
tl project, which i guess is a partial build? I saw the patch that
Andrew mentioned but hadn't put 2 and 2 together that I'd need to
build the hotspot part
501 - 600 of 657 matches
Mail list logo
