On 26/08/2014 05:29, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service
On 26 Aug 2014, at 08:26, Alan Bateman wrote:
> On 26/08/2014 05:29, Mandy Chung wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
>>
>> This patch renames the class name of attach provider implementation class
>> to be the same for all platforms. This simplifies
Nice!
/Erik
On 2014-08-26 06:29, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generati
Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/
Some of the demos failed to compile because the javac_state file did not
contain any public api and this caused grep to exit with code 1, which
failed the build. I made exit code 1 for this grep line not fail the build.
On 2014-08-26 11:58, Erik Joelsson wrote:
Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/
Some of the demos failed to compile because the javac_state file did
not contain any public api and this caused grep to exit with code 1,
which failed the build. I made exit code
Hi Mandy,
I'm seeing some small differences in the various VirtualMachineImpl.java
files, but if I'm not mistaken, all the new AttachProviderImpl.java look
all the same. I wonder if the patch could be further simplified by
moving AttachProviderImpl.java to jdk.attach/share/classes (unless
there's
Hello,
Please review this proposed fix for the Hotspot build.
In the new jdk9 build, we utilize the gnu make job server, which
automatically makes sure the -j flag gets propagated and shared between
all recursive make calls. In the hotspot build, this gets overridden by
the HOTSPOT_BUILD_JOBS
There are some differences in the AttachProvideImpl files. Most notably the
windows version is very different. Linux, Bsd and Aix are the same. The Solaris
version has a minor difference in the “public String type()” implementation.
The Linux, Bsd, Aix and Solaris versions could probably be uni
Hi David,
The change was pushed on Friday so it included the change in the Makefile. I
filed JDK-8056056 to remove it.
Thanks!
/Jesper
David Holmes skrev 25/8/14 02:50:
Sorry I'm late but had a long weekend and was off last Friday.
On 22/08/2014 3:04 AM, Jesper Wilhelmsson wrote:
Thank you
On 8/26/14 12:59 PM, Staffan Larsen wrote:
There are some differences in the AttachProvideImpl files. Most notably the
windows version is very different. Linux, Bsd and Aix are the same. The Solaris
version has a minor difference in the “public String type()” implementation.
The Linux, Bsd, A
Hi Erik,
On 26/08/2014 8:53 PM, Erik Joelsson wrote:
Hello,
Please review this proposed fix for the Hotspot build.
In the new jdk9 build, we utilize the gnu make job server, which
automatically makes sure the -j flag gets propagated and shared between
all recursive make calls. In the hotspot b
Hello David,
I realize my description was not very clear and will try to make a
better one.
It used to be (before make 3.78), that recursive make calls and the -j
flag were tricky to use together. The Hotspot makefiles solved this by
asking people not to use -j, and instead set the variable
Hello,
Please review this small patch fixing a couple of issues that have been
raised on this list following the source code restructure.
* Fix spelling error in make help (build->built)
* Readd the jdk target as an alias for exploded-image as people are used
to the target and the error messa
Thanks for pointing this out. That is indeed a better and more portable
solution. I took the liberty of creating a new bug and creating a patch
reverting my earlier change and using this instead.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056064
Webrev: http://cr.openjdk.java.net/~erikj/805
On 26/08/2014 13:46, Erik Joelsson wrote:
Hello,
Please review this small patch fixing a couple of issues that have
been raised on this list following the source code restructure.
* Fix spelling error in make help (build->built)
* Readd the jdk target as an alias for exploded-image as people
On 26/08/2014 14:02, Erik Joelsson wrote:
Thanks for pointing this out. That is indeed a better and more
portable solution. I took the liberty of creating a new bug and
creating a patch reverting my earlier change and using this instead.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056064
We
Erik:
Please review this small patch fixing a couple of issues that have
been raised on this list following the source code restructure.
* Fix spelling error in make help (build->built)
* Readd the jdk target as an alias for exploded-image as people are
used to the target and the error messag
Hi Erik
On 08/26/14 07:30, Alan Bateman wrote:
On 26/08/2014 14:02, Erik Joelsson wrote:
Thanks for pointing this out. That is indeed a better and more
portable solution. I took the liberty of creating a new bug and
creating a patch reverting my earlier change and using this instead.
Bug: ht
On 2014-08-26 16:27, Alan Bateman wrote:
On 26/08/2014 13:46, Erik Joelsson wrote:
Hello,
Please review this small patch fixing a couple of issues that have
been raised on this list following the source code restructure.
* Fix spelling error in make help (build->built)
* Readd the jdk targe
On 8/26/2014 3:59 AM, Staffan Larsen wrote:
There are some differences in the AttachProvideImpl files. Most notably the
windows version is very different. Linux, Bsd and Aix are the same. The Solaris
version has a minor difference in the “public String type()” implementation.
The Linux, Bsd,
Hi
I am seeing some files with permission 0600 (-rw --- --- ) in my build. Is
there a way to influence the generated files' permission from the configure or
do I need to run a chmod(1) on them myself.
Note that I have selected owner=root , group=root, so the net effect is that
those files with
JDK-8055856: checkdeps build target doesn't work for cross-compilation builds
JDK-8056113: [build] tools.jar missing modules.xml
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856/
This patch fixes a few things about modules.xml
1. jdeps is invoked at build time to verify the
It seems like the development speed for sjavac needs to be increased
significantly, one JIRA bug, one 2 week review cycle, leads to one commit
is much too slow. I belive it would be good to have a separate repository
to do quicker development of sjavac, and test out all sorts of interesting
stuff,
23 matches
Mail list logo
