Re: [8u-dev] RFA for JDK-8079788: Fix broken CL version detection in configure for some Visual Studio configurations

2018-05-31 Thread Seán Coffey 

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 backports.)


/Erik

On 2018-05-29 05:27, Alexey Ivanov wrote:

Hi,

Could you please approve the following backport to 8u-dev?

JBS: https://bugs.openjdk.java.net/browse/JDK-8079788
jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145
Code review: 
http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html 



The patch applies cleanly to jdk8u-dev; generated-configure.sh is 
regenerated.

Webrev: http://cr.openjdk.java.net/~aivanov/8079788/jdk8/webrev.0/

I recently faced this issue, and configure for 8u cannot complete. 
It could be related to backporting of JDK-8042707.


Thank you in advance.

Regards,
Alexey

Re: RFR: 8170157/8169335: Unlimited Cryptography Policy Changes

2016-12-05 Thread Seán Coffey 
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 in OracleJDK

https://bugs.openjdk.java.net/browse/JDK-8169335
Add a crypto policy fallback in case Security Property
 'crypto.policy' does not exist

http://cr.openjdk.java.net/~wetmore/8170157

This change enables "unlimited" cryptographic policy by default in the 
OpenJDK/OracleJDK builds.


For those who still require the classic limited policy bundles, you 
will now need to use the following "configure" option:


--enable-unlimited-crypto

There are still distributions that require crypto policy, so simply 
removing that code is not an option, sorry!


Brad

Re: RFR: 8157561 :Ship the unlimited policy files in JDK Updates

2016-11-07 Thread Seán Coffey 
Thanks for review Brad. I've included an extra check in CryptoLevel to 
check for "limited/unlimited" input. Addressed the JceSecurity 
indentation issue also.


http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/

Regards,
Sean.

On 04/11/16 22:56, Bradford Wetmore wrote:
I didn't see anything majorly different in what I looked at earlier, I 
didn't check java.security or the test case.



CryptoLevel.java

49: Your usage mentions only unlimited|limited.  Do you want to 
include a check for that?


JceSecurity.java

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 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 jar files exist in the legacy locations, then
those jar files will continue to be honoured.

https://bugs.openjdk.java.net/browse/JDK-8157561
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/

RFR: 8157561 :Ship the unlimited policy files in JDK Updates

2016-11-04 Thread Seán Coffey 
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 jar files exist in the legacy locations, then those jar 
files will continue to be honoured.


https://bugs.openjdk.java.net/browse/JDK-8157561
webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/


--
Regards,
Sean.

Re: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6

2016-08-19 Thread Seán Coffey 

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 build systems.

e.g.


/opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC
\
  -m64 -G -KPIC \
   
-I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc
   \
   -I../generated   \
   -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include
   \
   
-I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris
   \
 \
   
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp
   \
   sadis.o  \
   -M
   
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile
   -mt -xnolib -norunpath
   \
   -o libsaproc.so
   \
   -ldl -ldemangle -lthread -lc
ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such
file or directory
ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or
directory
ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
ld: fatal: file processing errors. No output written to
libgenerateJvmOffsets.so
gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
gmake[6]: *** Waiting for unfinished jobs
gmake[6]: Leaving directory
`/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
gmake[5]: *** [the_vm] Error 2

It needs to be pushed by someone at Oracle anyway, so your internal
configure can be updated.

I think that might be the problem here. @CXXSTD_CXXFLAG@ and friends
should be substituted by configure with either the flag or the empty
string, so something is going wrong earlier with the configure stage.

Re: RFR: JDK-8162354: Unable to build JDK 9 on a Sparc T7-1 with default boot-jdk 8.0

2016-08-03 Thread Seán Coffey 
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 difference for these class files:


/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Errors.class 

/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Fragments.class 

/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Notes.class 

/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties$Warnings.class 


/jdk.compiler/com/sun/tools/javac/resources/CompilerProperties.class

The source file is generated and also differs. Without digging deeper, 
it looks like it's just ordering of methods, fields and/or inner 
classes, which is caused by the generator program not specifying the 
order, likely by using an unordered collection to store them during 
generation. While this is most likely fine, it's good practice to have 
the build more deterministic.


/Erik


On 2016-08-03 11:11, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8162354/webrev.02/

I found that the first working update was 8u20 and changed to use 
that instead for minimal impact.


/Erik

On 2016-08-03 09:08, Erik Joelsson wrote:



On 2016-08-03 04:20, David Holmes wrote:

Hi Erik,

On 3/08/2016 1:11 AM, Erik Joelsson wrote:

Hello,

The default bootjdk for 9 is JDK 8. Unfortunately JDK 8 does not 
work on

newer M7 sparc hardware. This has of course been fixed in an update.
This patch changes the Jib profile configuration to use 8u102 as 
bootjdk

on Solaris sparc if the cpu is of the M7 type.


Isn't 8u102 a bit too recent to use - shouldn't we use the oldest 
version that works on M7?


That is a good point. Either go with latest greatest when changing 
or try to find the minimum change. We had a similar problem in JDK 8 
where 7GA did not work on macosx. At that time we took the first 
working version. I will see if I can figure out which one it is at 
least.
Does this actually affect official builds (do they use M7) or does 
this simply enable use of M7 in the other build processes (JPRT etc)?


Unclear. The new hardware we received is M7, so without a change we 
can't use that hardware for any builds, which would be sad since the 
machine is very fast. I suspect that down the line we will want to 
use this class of hardware in all types of build scenarios. IMO, we 
get adequate testing that the 8GA as boot (which is the defined 
bootjdk) works on all the other platforms.


/Erik

Re: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6

2016-08-02 Thread Seán Coffey 

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 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 \
   
-I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc 
   \
   -I../generated   \
   -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include
  \
   
-I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris\
 \
   
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp
\
   sadis.o  \
   -M 
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt 
-xnolib -norunpath \
   -o libsaproc.so  
  \
   -ldl -ldemangle -lthread -lc
ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such 
file or directory
ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory
ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so
gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
gmake[6]: *** Waiting for unfinished jobs
gmake[6]: Leaving directory 
`/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
gmake[5]: *** [the_vm] Error 2


Regards,
Sean.
On 01/08/2016 12:34, Erik Joelsson wrote:

Looks good now, thanks!

Sorry for not answering earlier. I just got back from vacation.

/Erik

On 2016-07-15 17:22, Andrew Hughes wrote:

Ping?

- Original Message -

- Original Message -

Hello,

It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always 
returning
yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C 
and

C++ checks.


Ugh, merged a block in the wrong place by the looks of it.

Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/

configure:29739: checking if the C++ compiler supports "-std=gnu++98 "
configure:29755: /usr/bin/g++ -c  -std=gnu++98 conftest.cpp >&5
configure:29755: $? = 0
configure:29769: result: yes
configure:29815: checking if the C compiler supports
"-fno-delete-null-pointer-checks -Werror"
configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks 
-Werror

conftest.c >&5
configure:29832: $? = 0
configure:29846: result: yes
configure:29855: checking if the C++ compiler supports
"-fno-delete-null-pointer-checks -Werror"
configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks 
-Werror

conftest.cpp >&5
configure:29871: $? = 0
configure:29885: result: yes
configure:29894: checking if both compilers support
"-fno-delete-null-pointer-checks -Werror"
configure:29899: result: yes
configure:29911: checking if the C compiler supports 
"-fno-lifetime-dse

-Werror"
configure:29927: /usr/bin/gcc -c  -fno-lifetime-dse -Werror 
conftest.c >&5

configure:29927: $? = 0
configure:29941: result: yes
configure:29950: checking if the C++ compiler supports 
"-fno-lifetime-dse

-Werror"
configure:29966: /usr/bin/g++ -c  -fno-lifetime-dse -Werror 
conftest.cpp >&5

configure:29966: $? = 0
configure:29980: result: yes
configure:29989: checking if both compilers support "-fno-lifetime-dse
-Werror"
configure:29994: result: yes



/Erik

On 2016-07-07 22:21, Andrew Hughes wrote:

Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8151841

This is a backport of the original fix to support building OpenJDK
with GCC 6. It was necessary to cherry-pick parts of a number of
earlier fixes to make this work with the build system in 8:

8149647: Incremental enhancements from build-infra
8032045: Enable compiler and linker safety switches for debug builds

and so I'm requesting a review of the 8 version of the patch here 
as well

as approval for 8u.

In brief, the patch makes OpenJDK build with GCC 6 by explicitly
specifying
the C++ standard to use (-std=gnu++98) and disabling two 
optimisations

with
-fno-lifetime-dse and -fno-delete-null-pointer-checks. Further
information
on the changes is available in the GCC 6 release notes [0]. GCC 6 
uses
a newer C

Re: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6

2016-08-02 Thread Seán Coffey 
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 \
   
-I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc 
   \
   -I../generated   \
   -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include
  \
   
-I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris\
 \
   
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp
\
   sadis.o  \
   -M 
/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt 
-xnolib -norunpath \
   -o libsaproc.so  
  \
   -ldl -ldemangle -lthread -lc
ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such 
file or directory
ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory
ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so
gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
gmake[6]: *** Waiting for unfinished jobs
gmake[6]: Leaving directory 
`/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
gmake[5]: *** [the_vm] Error 2


Regards,
Sean.

On 01/08/2016 12:34, Erik Joelsson wrote:

Looks good now, thanks!

Sorry for not answering earlier. I just got back from vacation.

/Erik

On 2016-07-15 17:22, Andrew Hughes wrote:

Ping?

- Original Message -

- Original Message -

Hello,

It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always 
returning

yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and
C++ checks.


Ugh, merged a block in the wrong place by the looks of it.

Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/

configure:29739: checking if the C++ compiler supports "-std=gnu++98 "
configure:29755: /usr/bin/g++ -c  -std=gnu++98   conftest.cpp >&5
configure:29755: $? = 0
configure:29769: result: yes
configure:29815: checking if the C compiler supports
"-fno-delete-null-pointer-checks -Werror"
configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks 
-Werror

conftest.c >&5
configure:29832: $? = 0
configure:29846: result: yes
configure:29855: checking if the C++ compiler supports
"-fno-delete-null-pointer-checks -Werror"
configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks 
-Werror

conftest.cpp >&5
configure:29871: $? = 0
configure:29885: result: yes
configure:29894: checking if both compilers support
"-fno-delete-null-pointer-checks -Werror"
configure:29899: result: yes
configure:29911: checking if the C compiler supports "-fno-lifetime-dse
-Werror"
configure:29927: /usr/bin/gcc -c  -fno-lifetime-dse -Werror 
conftest.c >&5

configure:29927: $? = 0
configure:29941: result: yes
configure:29950: checking if the C++ compiler supports 
"-fno-lifetime-dse

-Werror"
configure:29966: /usr/bin/g++ -c  -fno-lifetime-dse -Werror 
conftest.cpp >&5

configure:29966: $? = 0
configure:29980: result: yes
configure:29989: checking if both compilers support "-fno-lifetime-dse
-Werror"
configure:29994: result: yes



/Erik

On 2016-07-07 22:21, Andrew Hughes wrote:

Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8151841

This is a backport of the original fix to support building OpenJDK
with GCC 6. It was necessary to cherry-pick parts of a number of
earlier fixes to make this work with the build system in 8:

8149647: Incremental enhancements from build-infra
8032045: Enable compiler and linker safety switches for debug builds

and so I'm requesting a review of the 8 version of the patch here 
as well

as approval for 8u.

In brief, the patch makes OpenJDK build with GCC 6 by explicitly
specifying
the C++ standard to use (-std=gnu++98) and disabling two 
optimisations

with
-fno-lifetime-dse and -fno-delete-null-pointer-checks. Further
information
on the changes is available in the GCC 6 release notes [0]. GCC 6 
uses
a newer C++ standard, C++14, with which the OpenJDK codebase is 
not yet

compliant. The simplest way to fix this, especially for existing
releases,
is to explicitly request the previous default, gnu++98. The deletion
of null pointer checks and more aggressive lifetime dead store
elimination
in 6 lead to a crashing virtual machine being built, so we disable 
them

i

Re: Creating IPS packages on Solaris

2016-07-28 Thread Seán Coffey 

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 packages in my 
build directory.  Could anyone provide any insight in how to do this?


Thanks,

Martin

Re: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc

2016-02-12 Thread Seán Coffey 

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://bugs.openjdk.java.net/browse/JDK-8147807
Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/

The issue is not relevant to jdk 9.

The fix just removes kcms service leaving lcms as the only option 
which is the default in jdk8.



Thanks in advance,
Alexey

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

2016-02-11 Thread Seán Coffey 


On 11/02/2016 00:25, Xueming Shen wrote:


One of the benefits of moving to the system libz is actually for 
better/easy
maintenance. Just replacing the offending version of libz with an 
earlier/later
version that works, instead of waiting for a customized jdk/jre image 
with a
working/bundled libz, or the next update release. Especially given the 
fact
that we have decided not to touch the libz at source level. Having 
dependency

on the system libz is really not that bad. The experience suggests those
binaries are quite stable. And it should always be easier to replace the
system libz than a java runtime, in case of problem.


I think people overestimate people's ability to 'just replace' a zlib 
library. Adding a new system property is a struggle for some 
enterprises. We'll enjoy supporting a many to one matrix of zlib:JDK 
scenarios now rather than old style 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: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 underlying OS zlib libraries. Could we at least consider a 
runtime property to allow linking to the (currently bundled) zlib 
v.1.2.8 port in case issues arise ?
Don't the LD_* environment variables serve this need already? Once 
the JDK is using the system zlib then this is the simplest way to 
get it to use a different libz library at runtime.
No - I don't see that as a solution. You've still made the default 
JDK config become dependent on OS environment for all libzip 
operations. I don't think we even capture the zlib version that the 
JDK would be operating with in any diagnostics. An application 
wanting a tried/tested and stable libzip version has extra work to do 
now. Letting the default be system dependent has just increased risk 
for QA teams also. A system property just makes this all go away. In 
fact - I would say that for JDK9, the default should be the JDK 
bundled libzip library. For those looking for libzip experimenting 
and performance benefits, they could take the system property approach.


regards,
Sean.


-Alan



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. JDK-8133206 would be one such example.
Just at build time 
so - we introduce a runtime dependency on the underlying zlib 
libraries on the OS by default. I would be very concerned with this 
approach. We've run JDK 6 for 10+ years with zlib v1.1.3. It was 
consistent and reliable for the most part. When we moved JDK7/8 to 
zlib v1.2.5, we encountered an inflation issue[1]. When JDK was 
upgraded to zlib v1.2.8, we received reports of performance/OOM 
issues [2].
but if the zlib on the platform is broken then it impacts tools and 
probably lots of things. I would assume the OS would patch such 
issues quickly. In the case of JDK-8133206 then was the issue 
addressed in the libzip wrapper or in the zlib code? I thought it 
was the former.
The code change is proposed in the libzip wrapper but the issue was 
triggered by the zlib library update.


On a fallback or some way to configure at launch time then Sandhya 
Viswanathan (Intel) has a proposal here last year. I think we mostly 
agreed on that thread that switching the build to use the system 
zlib by default would be better.
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 
underlying OS zlib libraries. Could we at least consider a runtime 
property to allow linking to the (currently bundled) zlib v.1.2.8 
port in case issues arise ?


regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8044725
[2] https://bugs.openjdk.java.net/browse/JDK-8133206

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

2016-02-10 Thread Seán Coffey 


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 
underlying OS zlib libraries. Could we at least consider a runtime 
property to allow linking to the (currently bundled) zlib v.1.2.8 
port in case issues arise ?
Don't the LD_* environment variables serve this need already? Once the 
JDK is using the system zlib then this is the simplest way to get it 
to use a different libz library at runtime.
No - I don't see that as a solution. You've still made the default JDK 
config become dependent on OS environment for all libzip operations. I 
don't think we even capture the zlib version that the JDK would be 
operating with in any diagnostics. An application wanting a tried/tested 
and stable libzip version has extra work to do now. Letting the default 
be system dependent has just increased risk for QA teams also. A system 
property just makes this all go away. In fact - I would say that for 
JDK9, the default should be the JDK bundled libzip library. For those 
looking for libzip experimenting and performance benefits, they could 
take the system property approach.


regards,
Sean.


-Alan



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. JDK-8133206 would be one such example.
Just at build time 
so - we introduce a runtime dependency on the underlying zlib libraries 
on the OS by default. I would be very concerned with this approach. 
We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and 
reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we 
encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8, 
we received reports of performance/OOM issues [2].
but if the zlib on the platform is broken then it impacts tools and 
probably lots of things. I would assume the OS would patch such issues 
quickly. In the case of JDK-8133206 then was the issue addressed in 
the libzip wrapper or in the zlib code? I thought it was the former.
The code change is proposed in the libzip wrapper but the issue was 
triggered by the zlib library update.


On a fallback or some way to configure at launch time then Sandhya 
Viswanathan (Intel) has a proposal here last year. I think we mostly 
agreed on that thread that switching the build to use the system zlib 
by default would be better.
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 underlying OS zlib 
libraries. Could we at least consider a runtime property to allow 
linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ?


regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8044725
[2] https://bugs.openjdk.java.net/browse/JDK-8133206

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

2016-02-10 Thread Seán Coffey 

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. JDK-8133206 would be one such example.
Just at build time 
so - we introduce a runtime dependency on the underlying zlib libraries 
on the OS by default. I would be very concerned with this approach. 
We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and 
reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we 
encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8, 
we received reports of performance/OOM issues [2].
but if the zlib on the platform is broken then it impacts tools and 
probably lots of things. I would assume the OS would patch such issues 
quickly. In the case of JDK-8133206 then was the issue addressed in 
the libzip wrapper or in the zlib code? I thought it was the former.
The code change is proposed in the libzip wrapper but the issue was 
triggered by the zlib library update.


On a fallback or some way to configure at launch time then Sandhya 
Viswanathan (Intel) has a proposal here last year. I think we mostly 
agreed on that thread that switching the build to use the system zlib 
by default would be better.
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 underlying OS zlib 
libraries. Could we at least consider a runtime property to allow 
linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ?


regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8044725
[2] https://bugs.openjdk.java.net/browse/JDK-8133206

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

2016-02-08 Thread Seán Coffey 
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, Xueming Shen wrote:

Hi

Please help codereview the change to build the jdk9 runtime to use the 
system zlib on

Solaris and Linux platforms by default.

Issue: https://bugs.openjdk.java.net/browse/JDK-8031767
Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/

Background info:

Compression is heavily used in Java based big data/middle-ware 
applications.

There are many products in market today that help compression performance
either through software or hardware acceleration and most likely these 
products
support the zlib interface as API, for example Intel's IPP library has 
a faster
version of compression libraries. To configure the Java runtime to use 
the system
zlib would make these acceleration capabilities available to java 
users through
java.util.zip package directly. The jdk already has a build 
configuration option
to build the jdk to use the system zlib via "--with-zlib=system" and 
the OSX is
by default built to use the system zlib. This proposal is to propose 
to build
the jdk to use the system zlib library (the zlib bundled by the 
underlying Solaris/
Linuxplatforms), instead of the binary  built from source code jdk 
repository

(current 1.2.8 from the open source zlib.org)

Thanks,
Sherman


btw, attached is the similar change in the closed repo: 
autoconf/generated-configure.sh

-

# Do not change or remove the following line, it is needed for 
consistency checks:

-DATE_WHEN_GENERATED=1454436146
+DATE_WHEN_GENERATED=1454626552

 ### 


 #
 # Initialization / Boot-strapping
 #



@@ -58839,14 +58839,14 @@


   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for which zlib to 
use" >&5

 $as_echo_n "checking for which zlib to use... " >&6; }

- DEFAULT_ZLIB=bundled
- if test "x$OPENJDK_TARGET_OS" = xmacosx; then
- # On macosx default is system...on others default is bundled
 DEFAULT_ZLIB=system
+ if test "x$OPENJDK_TARGET_OS" = xwindows; then
+ # On windows default is bundled...on others default is system
+ DEFAULT_ZLIB=bundled
   fi

   if test "x${ZLIB_FOUND}" != "xyes"; then
 # If we don't find any system...set default to bundled
 DEFAULT_ZLIB=bundled

Re: [8u] Request for Approval and Review: JDK-8136691: 8u65/8u66 b14 Solaris builds failed on Linking libverify.so

2015-09-18 Thread Seán Coffey 
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 review this fix for 8u. There is a discrepancy 
between the Solaris and Linux makefiles for Hotspot, where a source 
file is excluded for a certain configuration on Linux but not on 
Solaris. This causes the build to fail on Solaris in that configuration.


Bug: https://bugs.openjdk.java.net/browse/JDK-8136691
Patch:
diff --git a/make/solaris/makefiles/trace.make 
b/make/solaris/makefiles/trace.make

--- a/make/solaris/makefiles/trace.make
+++ b/make/solaris/makefiles/trace.make
@@ -56,8 +56,12 @@
 ifeq ($(HAS_ALT_SRC), true)
 TraceGeneratedNames +=  \
traceRequestables.hpp \
-traceEventControl.hpp \
-traceProducer.cpp
+traceEventControl.hpp
+
+ifneq ($(INCLUDE_TRACE), false)
+  TraceGeneratedNames += traceProducer.cpp
+endif
+
 endif

 TraceGeneratedFiles = $(TraceGeneratedNames:%=$(TraceOutDir)/%)


/Erik

Re: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK

2015-07-21 Thread Seán Coffey 
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 that allows setting
the Hotspot minor version and build number to that
of the "--with-update-version" and "--with-build-number"
configure parameters when provided. 8u  builds only.

webrev:
http://cr.openjdk.java.net/~amurillo/8u66/8079410/


The logic seems fine. I would have put it in the hotspot_version file 
directly I think, but it's okay as is.

right, I could have put it there as well.


I presume we will still update the default update version at the 
start of each new release cycle.

Yes, but only  necessary for non milestone or jprt builds
Thanks
Alejandro


Thanks,
David


Background (since bug was originally filed as internal):

Currently, for 8u builds and earlier, the hotspot version looks like 
this

(remnant from the hotspot express days):

Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing)


By convention, minor version (66 above) always matches the JDK update
version
and hotspot build number is managed independently of the JDK build 
number.

Both values  are defined by default  in "hotspot/make/hotspot_version".
With this change they can now be setup using the corresponding JDK
configure parameters.

Consequences:

(1)  For promoted and other milestone builds, the hotspot minor version
will corresponds to the JDK update version and the hotspot build number
will match  the JDK build number.

(2) Hotspot snapshots will no longer need to change the hotspot build
number
as that will be set at promotion time (matching the JDK build number).
Since this is stored in the file mentioned above, a  repo push
(and the corresponding bug) was required to  change it.
That will no longer be necessary.

(3)  Since JPRT configures both the update and build numbers,
  when building via JPRT, the hotspot build number for those builds
will always be  'b00' (matching the JDK build number). The Hotspot
minor version will match the update version defined in
make/jprt.prtoperties:

java version "1.8.0_66-internal"
#   Java(TM) SE Runtime Environment (build
1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00)
#   Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing)

(4) Since the version string is not actually changing, I do not expect
this to have
any impact on external tools or apps, but let me know if so.

Thanks

Re: [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris

2015-07-21 Thread Seán Coffey 

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.java.net/browse/JDK-8130938

8071710 fixed the issue of libfontmanager and libt2k linking against 
X11 on JDK 9 for Solaris.
This was subsequently backported to JDK8u but one line was missed so 
incorrectly libt2k

still depends on X11 libraries on 8u.

This is a request for review and approval to push to 8u66.

The one line change is in-line below. jprt verified the build.

hg diff make/lib/Awt2dLibraries.gmk
diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -983,7 +983,7 @@
   $(call SET_SHARED_LIBRARY_ORIGIN), \
   LDFLAGS_windows := user32.lib 
$(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \
   LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager -ljava 
-ljvm -lc, \

-  LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \
+  LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \
   VERSIONINFO_RESOURCE := 
$(JDK_TOPDIR)/src/windows/resource/version.rc, \

   RC_FLAGS := $(RC_FLAGS) \
   -D "JDK_FNAME=t2k.dll" \

-phil.

Re: Question around the 8054717 fix

2015-06-16 Thread Seán Coffey 

Andreas,

thanks for getting back. Easiest way to reproduce this is probably by 
importing the jdk patch directly :


http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/
http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/jdk.patch

and then : gmake jdk.crypto.pkcs11

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 changes introduced from the 8054717 fix.

The build error (snippet) is :


/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:74:
 error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be 
accessed from outside package
 return new ECPublicKeyImpl(x509Spec.getEncoded());
^
/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77:
 error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied 
to given types;
 return new ECPublicKeyImpl(
^
   required: byte[]
   found: ECPoint,ECParameterSpec
   reason: actual and formal argument lists differ in length

I've confirmed that I do have the correct access type modifications
in the ECPublicKeyImpl constructor (moved to public)

The build system appears to be picking up the older ECPublicKeyImpl
class in the bootstrap JDK and not the newly built classes. 8054717
appears to have modified bootclasspath settings.

Is this an issue with my security fix or a build issue ? I've tried
the build on my local system and an JPRT.

This could very well be related to 8054717.

It's strange that it picks up ECPublicKeyImpl from the boostrap JDK though. We 
changed the build so that the bootclasspath is empty when compiling the JDK.

What's the easiest way for me to reproduce this? Could I get a JPRT id and 
download your files somehow? (Sorry, I'm still learning JPRT.)

-- Andreas

Question around the 8054717 fix

2015-06-15 Thread Seán Coffey 

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/share/classes/sun/security/pkcs11/P11ECUtil.java:74:
 error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be 
accessed from outside package
 return new ECPublicKeyImpl(x509Spec.getEncoded());
^
/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77:
 error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied 
to given types;
 return new ECPublicKeyImpl(
^
   required: byte[]
   found: ECPoint,ECParameterSpec
   reason: actual and formal argument lists differ in length
I've confirmed that I do have the correct access type modifications in 
the ECPublicKeyImpl constructor (moved to public)


The build system appears to be picking up the older ECPublicKeyImpl 
class in the bootstrap JDK and not the newly built classes. 8054717 
appears to have modified bootclasspath settings.


Is this an issue with my security fix or a build issue ? I've tried the 
build on my local system and an JPRT.


regards,
Sean.

[1] http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/

Re: [8u60] Request for review and approval: JDK-8074523: Java.net bundle has incorrect file version for jre/jdk

2015-05-20 Thread Seán Coffey 
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.

Regards,
Sean.

On 20/05/15 13:32, Erik Joelsson wrote:

Please review and approve this fix for 8u60.

On windows, native libraries and executables have version numbers 
embedded into them. These can be seen when right-clicking the binary 
in explorer, on the Details tab, as "Product version". Currently in 8 
update releases, these versions strings are inconsistent. An example:


in 8u45 b09 we have:

bin\client\jvm.dll: 8.0.0.9
bin\decora_sse.dll: 8.0.45.09
bin\deploy.dll: 8.0.450.9
bin\java.exe: 8.0.45.9

These differences fall into 4 different categories.

1. jvm.dll in hotspot is not picking up the update version at all. 
This is due to a bug in the build-infra makefile rewrite that wasn't 
discovered in JDK 8 because it didn't have an update version.


2. decora_sse.dll is part of javafx. Fixing their version scheme is 
out of scope of this fix. A separate bug for javafx would be needed.


3. deploy.dll is actually the correct one. Historically we have 
encoded the update version with an extra digit for a potential letter 
at the end of the string.


4. java.exe, and the rest of the binaries from the jdk repository lost 
their extra 0 in the build-infra makefile rewrite and it wasn't 
discovered in JDK 8.


Since we no longer use letters in update version strings, we could fix 
this by removing the extra 0. However, we have already released 8 
updates where some binaries have the extra 0. Removing it would mean 
releasing 8u60 with binaries having version numbers lower than 
previous updates. For this reason I propose fixing this by adding the 
0 for JDK and Hotspot binaries again, and of course by supplying the 
correct variable to the hotspot makefiles so that it even gets the 
update version in there. For clarity, with this patch, the above will 
log like this:


bin\client\jvm.dll: 8.0.450.9
bin\decora_sse.dll: 8.0.45.09
bin\deploy.dll: 8.0.450.9
bin\java.exe: 8.0.450.9

Note that in JDK 9, the version number scheme is being completely 
reworked so this will not be an issue.


Bug: https://bugs.openjdk.java.net/browse/JDK-8074523
Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html

/Erik

Re: Building OpenJDK that matches OracleJDK update

2015-05-18 Thread Seán Coffey 
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 top of the OpenJDK sources. The tags in each 
repo indicate the sources which they were built from. The best scenario 
for you might be to update your repos to the tag level corresponding to 
the Oracle JDK of which you wish to reach parity with. For 8u45, the GA 
build number was b14 - i.e. tag jdk8u45-b14


Regards,
Sean.

On 18/05/2015 17:48, Brian Toal wrote:

I'm trying to figure out how to build the OpenJDK so that it's at parity
with the OracleJDK version.

For example I want to build OpenJDK that is the equivalent of 8u45.
Appreciate if someone could point me into the correct direction to any
literature that explains how this is done.

I've see it's possible to clone 8u40, but not 8u45

hg clone http://hg.openjdk.java.net/jdk8u/jdk8u40 jdk8u40

as I get 404's when trying to clone.

Re: RfR JDK-8076552 nightly build break fix

2015-04-08 Thread Seán Coffey 

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 wrote:

resending - too many on To:/Cc:

On 4/8/15 1:08 PM, Pete Brunet wrote:

I confirmed the javadoc is gone, and make docs did not fail.

I have yet to submit the JPRT job.

Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
you approve the push?

Phil will have to do the push; my committer status is pending.

Pete

On 4/8/15 1:00 PM, Phil Race wrote:

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:

I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.

You can verify the result from make docs that there is no javadoc
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a
problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should
resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this
writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the
file
was planned to be removed.

Thanks, Pete

Re: [8u60] Request for approval to backport: 8067330: ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures

2015-03-02 Thread Seán Coffey 

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 updating also.


regards,
Sean.

On 02/03/15 16:06, Severin Gehwolf wrote:

Hi,

I've sent this email before[1], but would like for this backport to get
into 8u60 before it closes this month[2]. The patch in question only
touches Zero make variables and should be fairly safe to backport. The
patch is the same (modulo autogen.sh generation timestamp) as for JDK 9.
I'd also please need a sponsor who can push this change for me.

Thanks in advance!

Original 9 bug: https://bugs.openjdk.java.net/browse/JDK-8067330
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067330/webrev.jdk8.01/

JDK 9 review thread:
http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013895.html

Please let me know if there is anything else I need to do.

Cheers,
Severin

[1]
http://mail.openjdk.java.net/pipermail/build-dev/2015-February/014394.html
[2] http://openjdk.java.net/projects/jdk8u/releases/8u60.html

Re: [8u40] Request for review and approval: 8068485: Update references of download.oracle.com to docs.oracle.com in javadoc makefile

2015-01-14 Thread Seán Coffey 

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 Patel wrote:

Hi,
 In the javadoc makefile, there are references to 
http://download.oracle.com. This automatically gets redirected to 
http://docs.oracle.com. These references needs to be updated to point 
to https://docs.oracle.com.


JBS: https://bugs.openjdk.java.net/browse/JDK-8068485
Webrev: http://cr.openjdk.java.net/~bpatel/8068485/webrev.00/

 This fix is for 8u40. Can you please review it?

Thanks,
Bhavesh.

Re: RFR [JEP 220] Modular Run-Time Images

2014-11-21 Thread Seán Coffey 

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 concept of an extension 
directory.


e.g.
http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/jdk.rmic/share/classes/sun/rmi/rmic/newrmic/Main.java#l305
http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java#l70
http://hg.openjdk.java.net/jigsaw/m2/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java#l187
http://hg.openjdk.java.net/jigsaw/m2/jdk/file/tip/src/linux/doc/man/ja/javac.1

Hope that's expected.

regards,
Sean.

On 20/11/14 21:41, Chris Hegarty wrote:

From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: [8u40] Request for approval and review: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem?

2014-10-07 Thread Seán Coffey 
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 as well.


The Bug: https://bugs.openjdk.java.net/browse/JDK-8059135
The jdk9 review: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003568.html
The jdk8u-dev webrev: 
http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01.jdk8u/


/Erik

Re: RFR: 8056216 : Remove "sun" directory layer from libawt and common

2014-09-19 Thread Seán Coffey 


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, it should only 
list individual files for cases the files aren't all in the same 
directory in jdk8u-dev. It's hard to see from the webrev to know why 
there are individual source files listed. It would be great to 
collapse this down to 1 line if possible.

For the simpler packages, this was possible :
e.g. nashorn/src/jdk.scripting.nashorn/share/classes : nashorn/src

for the more complex packages where java src, native src and config 
files got split up and where backwards (9 -> 8) and forwards (8 -> 9) 
shuffling remained functional - then the picture is not as clear.


Thanks for the update Phil. Looks ok to me.

regards,
Sean.


-Alan

Re: RFR: 8056216 : Remove "sun" directory layer from libawt and common

2014-09-19 Thread Seán Coffey 

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 Bursie wrote:

On 2014-09-18 22:42, Phil Race wrote:

https://bugs.openjdk.java.net/browse/JDK-8056216
http://cr.openjdk.java.net/~prr/8056216/


Looks good to me. Thanks!

/Magnus



This is all just removing the sequence "sun/" from various pathnames.

Aside from the make file changes there are over 600 file moves which 
I don't think
its worth including in the webrev but they are the result of the 
following 'hg mv' commands


hg mv src/java.desktop/windows/native/libawt/sun/* 
src/java.desktop/windows/native/libawt/
hg mv src/java.desktop/windows/native/common/sun/awt 
src/java.desktop/windows/native/common
hg mv src/java.desktop/share/native/libawt/sun/* 
src/java.desktop/share/native/libawt
hg mv src/java.desktop/share/native/common/sun/* 
src/java.desktop/share/native/common
hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* 
src/java.desktop/macosx/native/libawt_lwawt
hg mv src/java.desktop/unix/native/libawt/sun/* 
src/java.desktop/unix/native/libawt
hg mv src/java.desktop/unix/native/common/sun/* 
src/java.desktop/unix/native/common
hg mv src/java.desktop/unix/native/libawt_headless/sun/awt 
src/java.desktop/unix/native/libawt_headless
hg mv src/java.desktop/unix/native/libawt_xawt/sun/* 
src/java.desktop/unix/native/libawt_xawt/


I have done full open+closed builds via JPRT on all platforms ...

-phil.

Re: RFR : 8042932: Bump up the -source version for JDK 9 builds

2014-05-13 Thread Seán Coffey 

Thanks all - will make that change and push.

regards,
Sean.

On 13/05/2014 08:55, Erik Joelsson wrote:

Hello Seán,

I agree with Tomas, please fix the comment too. Also don't forget to 
also push the closed generated-configure using the same bugid.


/Erik

On 2014-05-13 09:01, Tomas 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 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.openjdk.java.net/browse/JDK-8042932
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/

Thanks to Erik for identifying the offending file.

Bye,
--
Tomas Hurka   <mailto:tomas.hu...@oracle.com>
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

RFR : 8042932: Bump up the -source version for JDK 9 builds

2014-05-12 Thread Seán Coffey 
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.openjdk.java.net/browse/JDK-8042932
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/

Thanks to Erik for identifying the offending file.

regards,
Sean.

Re: When will JDK 9 builds move to requiring the boot JDK be JDK 8?

2014-04-03 Thread Seán Coffey 


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.



David

On 3/04/2014 8:12 PM, Chris Hegarty wrote:

FYI.

This is already reviewed ;-)
http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html

-Chris.

On 3 Apr 2014, at 11:04, Alan Bateman  wrote:


On 03/04/2014 09:53, Erik Joelsson wrote:
I don't see any reason not to make the switch. I filed this bug 
back in December:

https://bugs.openjdk.java.net/browse/JDK-8030794

Thanks, I can't think of any reason either.

So how do we make this happen? Would a mail to jdk9-dev be 
sufficient to alert folks about this change? Maybe the error from 
configure when there isn't a JDK 8 available is sufficient?


-Alan

Re: where is TimeZone bits

2014-03-03 Thread Seán Coffey 
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 jdk/make/data/tzdata/ 
directory and rebuild for latest rules.


regards,
Sean.

On 03/03/14 15:36, Martin Buchholz wrote:

A difference between IcedTea and Oracle JDK.  E.g.
http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches

use-system-tzdata Use timezone data from the system .

$ ./configure --help
   --with-tzdata-dir[=DIR] set the Java timezone data directory
   [DIR=/usr/share/javazi]



On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri wrote:


Hi,

Not sure if this is the correct forum
I have installed openJDK8 on a Debian linux. I was comparing my new JRE
with an older version (openjdk6) and I see that I don't have bunch of
timezone files.

Here is the old one

./jre/lib/zi/CST6CDT
./jre/lib/zi/SystemV/
./jre/lib/zi/SystemV/PST8PDT
./jre/lib/zi/SystemV/AST4
etc, etc

I read something about Sun no longer including tzupdator and timezone
fileswhat is OpenJDK's position on this issue? If openjdk8 does not
include TimeZone, how do I incorporate them into my JRE and JDK? Is there
another upstream maintainer of TZs?

thanks
Medi

Re: J2SE est mort, vive Java SE! (JDK-8029292)

2013-11-27 Thread Seán Coffey 
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 removed the old build system, can we please now
remove the last vestiges of Sun's pre-Java 5 naming scheme?

I refer in particular to these directories in a typical build:

  images/j2re-image
  images/j2sdk-image
  images/j2sdk-server-image

The "j2" nomenclature hasn't been used since 1.4.2.  These should
be named "jre-image", "jdk-image", and "jdk-server-image".

Thanks,
- Mark

Re: how to build J4B

2013-11-11 Thread Seán Coffey 

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 env variables should I define?

Thanks,
Mikhail.

Re: [SPAM]Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot

2013-09-24 Thread Seán Coffey 

Thanks for the updates Francis. Good to hear you solved the issue.

I don't know about JPRT and googled for it but did found anything 
relevant; Where is located JPRT?


JPRT is a build/test system used by Oracle. It's referenced every so 
often on OpenJDK mail threads :

https://weblogs.java.net/blog/kellyohair/archive/2006/09/jprt_buildtest.html

regards,
Sean.

On 24/09/2013 06:30, Francis ANDRE wrote:

Sean

OK, I found the problem: I had in the Windows environement variables a 
variable named OpenJDK, which under nmake/make gets translated into 
OPENJDK under cygwin, but echo $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't see the failure either. Ran an OpenJDK test job through 
JPRT.  I wonder if make version and/or shell env could have an impact 
? Can you share more details Francis ?


I see an OPENJDK condition expression in trace.make and wonder if 
that's being parsed incorrectly for this issue ?


http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/file/tip/make/windows/makefiles/trace.make

regards,
Sean.

On 23/09/13 17:54, Erik Joelsson wrote:
It's certainly not supposed to fail like that. I'm not able to 
reproduce this problem cloning from 
http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get 
your sources?


/Erik

On 2013-09-23 17:51, Francis ANDRE wrote:

Sean

The point is that OpenJDK7u is not open source while OpenJDK7 is... 
Following is a snippet of the make log joined...
That's the same story for the HSX project. Thus either the 
OpenJDK7u is an open source project and then the makefiles are 
wrong, either it is not and then I need the backport on the 
OpenJDK7 project.


Regards

Francis


mv  ad_x86_32.cpp  ad_x86_32.hpp ad_x86_32_clone.cpp 
ad_x86_32_expand.cpp  ad_x86_32_forma
t.cpp  ad_x86_32_gen.cpp  ad_x86_32_misc.cpp 
ad_x86_32_peephole.cpp  ad_x86_32_pipeline.cpp  adGlob

als_x86_32.hpp  dfa_x86_32.cpp adfiles/
"C:\Progra~1\Java\jdk1.6.0_35\bin\javac" -g -encoding ascii 
-source 6 -target 6 -d jvmtifile

s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java
Generating jvmtifiles/jvmtiEnv.hpp
Generating jvmtifiles/jvmtiEnter.cpp
Generating jvmtifiles/jvmtiEnterTrace.cpp
Generating jvmtifiles/jvmtiEnvRecommended.cpp
Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
Generating jvmtifiles/jvmti.h
*NMAKE : fatal error U1073: incapable d'obtenir 
'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t**

**raceEventClasses.xsl'*
Stop.
NMAKE : fatal error U1077: 'cd' : code retour '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio 10.0\VC\BIN\nmake.EXE"' : code

 retour '0x2'
Stop.
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/OpenJDK7u/hotspot/make
Le 22/09/2013 20:40, Seán Coffey a écrit :

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://bugs.openjdk.java.net/browse/JDK-2213981

regards,
Sean.

On 22/09/2013 09:37, Francis ANDRE wrote:

HI

the patch "JDK-7082220 : Visual Studio projects broken after 
change 7016797: Hotspot: securely/restrictive load dlls"  is 
missing in the 
OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. 
I applied it localy but some other OpenJDK developpers on 
WXP/VS2010 would benefit of this patch if it was applied to the 
OpenJDK7 forest. So I am wondering how to request a backport of 
this patch to the OpenJDK7/hotspot repository?


Regards

FA

Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot

2013-09-23 Thread Seán Coffey 
I don't see the failure either. Ran an OpenJDK test job through JPRT.  I 
wonder if make version and/or shell env could have an impact ? Can you 
share more details Francis ?


I see an OPENJDK condition expression in trace.make and wonder if that's 
being parsed incorrectly for this issue ?


http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/file/tip/make/windows/makefiles/trace.make

regards,
Sean.

On 23/09/13 17:54, Erik Joelsson wrote:
It's certainly not supposed to fail like that. I'm not able to 
reproduce this problem cloning from 
http://hg.openjdk.java.net/jdk7u/jdk7u-dev. From where did you get 
your sources?


/Erik

On 2013-09-23 17:51, Francis ANDRE wrote:

Sean

The point is that OpenJDK7u is not open source while OpenJDK7 is... 
Following is a snippet of the make log joined...
That's the same story for the HSX project. Thus either the OpenJDK7u 
is an open source project and then the makefiles are wrong, either it 
is not and then I need the backport on the OpenJDK7 project.


Regards

Francis


mv  ad_x86_32.cpp  ad_x86_32.hpp  ad_x86_32_clone.cpp 
ad_x86_32_expand.cpp  ad_x86_32_forma
t.cpp  ad_x86_32_gen.cpp  ad_x86_32_misc.cpp ad_x86_32_peephole.cpp  
ad_x86_32_pipeline.cpp  adGlob

als_x86_32.hpp  dfa_x86_32.cpp adfiles/
"C:\Progra~1\Java\jdk1.6.0_35\bin\javac" -g -encoding ascii 
-source 6 -target 6 -d jvmtifile

s Z:\DEV\OpenJDK7u\hotspot/src/share/vm/prims/jvmtiGen.java
Generating jvmtifiles/jvmtiEnv.hpp
Generating jvmtifiles/jvmtiEnter.cpp
Generating jvmtifiles/jvmtiEnterTrace.cpp
Generating jvmtifiles/jvmtiEnvRecommended.cpp
Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
Generating jvmtifiles/jvmti.h
*NMAKE : fatal error U1073: incapable d'obtenir 
'Z:\DEV\OpenJDK7u\hotspot/src/closed/share/vm/trace/t**

**raceEventClasses.xsl'*
Stop.
NMAKE : fatal error U1077: 'cd' : code retour '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
10.0\VC\BIN\nmake.EXE"' : code

 retour '0x2'
Stop.
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/OpenJDK7u/hotspot/make
Le 22/09/2013 20:40, Seán Coffey a écrit :

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://bugs.openjdk.java.net/browse/JDK-2213981

regards,
Sean.

On 22/09/2013 09:37, Francis ANDRE wrote:

HI

the patch "JDK-7082220 : Visual Studio projects broken after change 
7016797: Hotspot: securely/restrictive load dlls"  is missing in 
the 
OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. 
I applied it localy but some other OpenJDK developpers on 
WXP/VS2010 would benefit of this patch if it was applied to the 
OpenJDK7 forest. So I am wondering how to request a backport of 
this patch to the OpenJDK7/hotspot repository?


Regards

FA

Re: JDK-7082220 : Visual Studio projects broken after change: backport to OpenJDK7/hotspot

2013-09-22 Thread Seán Coffey 

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://bugs.openjdk.java.net/browse/JDK-2213981

regards,
Sean.

On 22/09/2013 09:37, Francis ANDRE wrote:

HI

the patch "JDK-7082220 : Visual Studio projects broken after change 
7016797: Hotspot: securely/restrictive load dlls"  is missing in the 
OpenJDK7/hotspot/src/share/tools/ProjectCreator/WinGammaPlatformVC10.java. 
I applied it localy but some other OpenJDK developpers on WXP/VS2010 
would benefit of this patch if it was applied to the OpenJDK7 forest. 
So I am wondering how to request a backport of this patch to the 
OpenJDK7/hotspot repository?


Regards

FA

Re: [7u] Request for approval for CR 8007450 - Add build support for different man pages for OpenJDK and OracleJDK

2013-02-14 Thread Seán Coffey 

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/8007450/webrev.jdk.02/

The review thread is here:
http://mail.openjdk.java.net/pipermail/build-dev/2013-February/007898.html 





Thanks-

Tim Bell

Re: build error on debian referring to solaris X11

2012-12-29 Thread Seán Coffey 
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 ../../../src/solaris/native/sun/awt/color.h:28,
  from ../../../src/solaris/native/sun/awt/img_util_md.h:26,
  from 
../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31:
../../../src/solaris/native/sun/awt/awt.h:38:27: error: X11/Intrinsic.h: No 
such file or directory
In file included from ../../../src/solaris/native/sun/awt/color.h:28,
  from ../../../src/solaris/native/sun/awt/img_util_md.h:26,
  from 
../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31:
../../../src/solaris/native/sun/awt/awt.h:162: error: expected '=', ',', ';', 
'asm' or '__attribute__' before '*' token
../../../src/solaris/native/sun/awt/awt.h:163: error: expected '=', ',', ';', 
'asm' or '__attribute__' before 'awt_ModLockIsShiftLock'
In file included from ../../../src/solaris/native/sun/awt/img_util_md.h:26,
  from 
../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31:
../../../src/solaris/native/sun/awt/color.h:34: error: expected 
specifier-qualifier-list before 'XPixmapFormatValues'
In file included from 
../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31:
../../../src/solaris/native/sun/awt/img_util_md.h:32: error: expected 
specifier-qualifier-list before 'XID'
make[5]: *** 
[/opt/openjdk/build/linux-i586/tmp/sun/sun.awt/awt/obj/BufImgSurfaceData.o] 
Error 1
make[5]: *** Waiting for unfinished jobs
make[5]: Leaving directory `/opt/openjdk/jdk/make/sun/awt'
make[4]: *** [library_parallel_compile] Error 2
make[4]: Leaving directory `/opt/openjdk/jdk/make/sun/awt'
make[3]: *** [all] Error 1
make[3]: Leaving directory `/opt/openjdk/jdk/make/sun'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/opt/openjdk/jdk/make'
make[1]: *** [jdk-build] Error 2
make[1]: Leaving directory `/opt/openjdk'
make: *** [build_product_image] Error 2
root@pinkydebian:/opt/openjdk#


Regards,

Miten.

Re: Fwd: Re: How to decrease size of j2sdk_image

2012-10-12 Thread Seán Coffey 

Dan,

thanks for the detailed reply. It makes sense to exercise such code 
where possible.


However, I'd also argue that Oracle JDK != OpenJDK.

why would openJDK developers get to build FDS by default? - it slows the 
build and makes bundles bigger. I would imagine most developers don'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 Coffey wrote:

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.


The Full Debug Symbols feature will eventually be enabled for all
OSes for which Oracle generates bits. I think MacOS X is the last
platform and that work is tracked by:

7165611 3/3 implement Full Debug Symbols on MacOS X

The default setting for ENABLE_FULL_DEBUG_SYMBOLS is "1" (enabled)
because the Full Debug Symbols feature is intentionally enabled in
all promoted bits for diagnosibility and debuggability. If FDS is
not enabled when the promoted bits are built, then the debug info
generated by a rebuild of *exactly the same source* with FDS enabled
cannot be (reliably) used with the promoted bits.

You might be saying:

That's fine for promoted bits, but what about the rest of us?

The answer there is actually simple. We want our developer private
builds and automated system builds, e.g., JPRT, to match what Release
Engineering builds. We don't want RE to be surprised by an integration
that builds fine when FDS is disabled only to blow up when FDS is
enabled.

Similarly, we also don't want SQE/SQA to be surprised by different
test results with bits built by RE versus bits built with FDS disabled,
e.g., JPRT. Enabling "debug info" in a build changes the compiler
optimizations and that changes the bits in the binary. Those changes
in the binary might mask a bug that only shows up after RE has built
with FDS enabled. Conversely, if you disable FDS in your private build,
you might end up chasing a bug that only reproduces in your private
build and doesn't reproduce in an FDS enabled build.


Could we consider flipping the default for ENABLE_FULL_DEBUG_SYMBOLS 
to 0 ? (like I've done for all my build scripts?)


For the reasons I stated above, no we won't change the default for
ENABLE_FULL_DEBUG_SYMBOLS to "0" (disabled) unless Oracle changes
the way that promoted bits are built.

You are welcome to disable the feature in your private builds which
is why I added the ENABLE_FULL_DEBUG_SYMBOLS flag. However, please
remember that any testing that you do with those bits won't necessarily
match testing done with the official promoted bits.

Dan




regards,
Sean.

 Original Message 
Subject:Re: How to decrease size of j2sdk_image
Date:   Thu, 11 Oct 2012 14:57:46 +0800
From:   Weijun Wang 
To: disc...@openjdk.java.net



You can try set ENABLE_FULL_DEBUG_SYMBOLS to 0.

-Max

On 10/11/2012 02:38 PM, matchew wrote:
>
> After successful openJDK7 build (Ubuntu 12.04) i have found that
> 'j2sdk-image' has 240MB. More than 100MB belongs to one directory:
> openjdk7/jre/lib/amd64
>
> Can anyone explain me why it is so big? For example in openJDK7 installed
> via package manager this folder has only 18MB
>
> Is there any way to decrease its size?
>
> Thanks in advance
> --
> Mateusz
>

Fwd: Re: How to decrease size of j2sdk_image

2012-10-11 Thread Seán Coffey 

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 default for ENABLE_FULL_DEBUG_SYMBOLS to 
0 ? (like I've done for all my build scripts?)


regards,
Sean.

 Original Message 
Subject:Re: How to decrease size of j2sdk_image
Date:   Thu, 11 Oct 2012 14:57:46 +0800
From:   Weijun Wang 
To: disc...@openjdk.java.net



You can try set ENABLE_FULL_DEBUG_SYMBOLS to 0.

-Max

On 10/11/2012 02:38 PM, matchew wrote:


After successful openJDK7 build (Ubuntu 12.04) i have found that
'j2sdk-image' has 240MB. More than 100MB belongs to one directory:
openjdk7/jre/lib/amd64

Can anyone explain me why it is so big? For example in openJDK7 installed
via package manager this folder has only 18MB

Is there any way to decrease its size?

Thanks in advance
--
Mateusz

Re: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries

2012-08-23 Thread Seán Coffey 

I haven't seen any complaints from build-dev members so I would also assume
that http://hg.openjdk.java.net/jdk8/build/jdk/ is a suitable repo.

I'll update bug status once I see your push.

regards,
Sean.

On 22/08/2012 10:29, David Holmes wrote:

On 22/08/2012 6:30 PM, Andrew Hughes 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 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))


Yes.


On the subject of dual Makefile maintenance, are there plans to
eventually remove
the older/legacy makefile structure on 8? I haven't been monitoring
that
topic too closely.


Yes. At some point "real soon now" we should make the switch to using
the new build system for our official builds. Some of the work for 8
is
only being done in the context of the new build system.



I need to look at moving our builds to using the new system.


David



regards,
Sean.

On 21/08/2012 12:13, Andrew Hughes wrote:

Ah good catch. I didn't realise this was duplicated in the new
build
system.

http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/

should deal with both cases.

If this is ok, is there a preferred forest to push to? I've been
testing against
build, but can easily push it somewhere else.

Re: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries

2012-08-21 Thread Seán Coffey 

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 plans to 
eventually remove
the older/legacy makefile structure on 8? I haven't been monitoring that 
topic too closely.


regards,
Sean.

On 21/08/2012 12:13, Andrew Hughes wrote:

Ah good catch.  I didn't realise this was duplicated in the new build system.

http://cr.openjdk.java.net/~andrew/jvisualvm/webrev.02/

should deal with both cases.

If this is ok, is there a preferred forest to push to?  I've been testing 
against
build, but can easily push it somewhere else.

Re: [7u6] Request for approval for CR 7157855: jvisualvm.1 not included in binaries

2012-08-20 Thread Seán Coffey 

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 systems.


regards,
Sean.

On 20/08/2012 18:57, Andrew Hughes wrote:

- Original Message -

This fix is also addressed in jdk8 at the same time.

Bug: http://bugs.sun.com/view_bug.do?bug_id=7157855
Webrev: http://cr.openjdk.java.net/~mfang/7157855/
Reviewers: katleman, thurka

thanks,

-michael


Do you have a link to where this was reviewed?  I don't see it in my inbox.

There is a flaw in this patch.  jvisualvm is not part of OpenJDK so the man
page should not be installed if building OpenJDK.

The same bug had to be rectified for javaws in 7021314: Build should not 
install javaws man page.

I'll post a webrev but basically it needs to be surrounded by an #ifndef 
OPENJDK.

RFR : 7185965 Build error in javadoc make stage for bundles not containing crypto package

2012-08-13 Thread Seán Coffey 
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 : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185965
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7185965.jdk8/ 



Regards,
Sean.

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

2012-05-15 Thread Seán Coffey 

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 
jdk8_tl/jdk/build/linux-amd64 structure don't co-exist well together.


regards,
Sean.

On 15/05/2012 14:11, Martijn Verburg wrote:

Hi all,


Cheers,
Martijn







The 2nd option would be the most up to date I guess but seems a bit
chicken and egg..

I normally use the latest jdk8 binary, but as I said above, sometimes it
still fails. In this case, do a full build and save the j2sdk-image
directory somewhere as later ALT_IMPORT_JDK_PATH. There is no chicken and
egg problem here, you use the full build output as IMPORT of a jdk-only
build, and full build does not need an IMPORT at all, and either a full
build or a jdk-only build depends on a previous veriosn of JDK as BOOTDIR.

Please note there is a bug in our build script that if you already have
tl/build/{platform} existing, a jdk/make build might fail (at some point in
smartcard or security, random). Please rename (or move) the
tl/build/{platform} directory before starting a jdk-only build.

I've been continuing the work to execute a full build followed by a
partial build. However, I think I'm still blocked by an  issue.

Full Build:

I set the following env vars

export LANG=C
export ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64

I execute a full build of the cloned code base from
http://hg.openjdk.java.net/jdk8/tl (after get_sources.sh is run) and
that all works fine

Partial Build:


# Create a backup of the full build (as per Weijun's recommendation)
cp -R /home/openjdk/projects/jdk8_tl/build/linux-amd64
/home/openjdk/projects/jdk8_tl/build/linux-amd64_backup

# Set the ALT_JDK_IMPORT_PATH to point to the j2sk-image backup of the
full build
export 
ALT_JDK_IMPORT_PATH=/home/openjdk/projects/jdk8_tl/build/linux-amd64_backup/j2sdk-image

# Run the warnings build
make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL=
OTHER_JAVACFLAGS="-Xmaxwarns 1"&>  build.log

It builds up to a point, but then has the problem where it's looking
for due to directory structure issues (it's looking too far back up
the directory tree basically).



/bin/mkdir -p ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned
rm -f ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
/usr/lib/jvm/java-7-openjdk-amd64/bin/jar cf
../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
  -C ../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes
sun/security/ec \
 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
-J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m
../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes/sun/security/ec
: no such file or directory
make[3]: *** 
[../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar]
Error 1
make[3]: Leaving directory
`/home/openjdk/projects/jdk8_tl/jdk/make/sun/security/ec'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/openjdk/projects/jdk8_tl/jdk/make/sun/security'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/openjdk/projects/jdk8_tl/jdk/make/sun'
make: *** [all] Error 1

--

Apart from ALT_JDK_IMPORT_PATH are there any other env vars I need to
set in order to have a partial build run (using the full build as a
base)?

Cheers,
Martijn

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

2012-03-23 Thread Seán Coffey 

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/download.html

HTH,
Sean.

On 23/03/2012 09:46, Martijn Verburg wrote:

Hi Alan/Max,

You're both right, I've actually been working from 
http://hg.openjdk.java.net/jdk8/tl/jdk as opposed to 
http://hg.openjdk.java.net/jdk8/tl - thanks for catching that with the 
limited info I posted.


Will start from scratch from http://hg.openjdk.java.net/jdk8/tl and 
see where the yellow brick road takes me :-)


Cheers,
Martijn

On 23 March 2012 06:16, Weijun Wang > wrote:


A partial build is you go inside tl/jdk/make/ and run make there,
it only builds the tl/jdk part, and the output goes to
tl/jdk/build/linux-i586. A full build is you go inside tl/ and run
make there, it builds all repos, and output goes to
tl/build/linux-i586.

I suspect you're doing a partial build because these 2 options
appear in the error:

   -I../../../build/linux-i586/tmp/java/java.lang/java/CClassHeaders
   -I../../../src/solaris/javavm/export

This means "src" and "build" are at the same directory levels.
Therefore the "build" is inside tl/jdk.

-Max


On 03/23/2012 01:51 AM, 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 separately first.

I'll try that next, my next post will likely be a q about
building the
hotspot part or providing the extra info Andrew requested.

Cheers,
Martijn




On Thursday, 22 March 2012, Alan Bateman
mailto:alan.bate...@oracle.com>
>> wrote:
> On 22/03/2012 15:19, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> I'm back from holiday and am building the latest
(http://hg.openjdk.java.net/jdk8/tl/jdk) project for our 3rd
Java User
Group OpenJDK hack day. I've run across an error that I
haven't been
able to resolve.
>>
>> ..
>> ..
>>

../../../build/linux-i586/tmp/java/java.lang/java/obj/Thread.o:(.data.rel+0xbc):
undefined reference to `JVM_SetNativeThreadName'
>> collect2: ld returned 1 exit status
>> make[2]: ***
[../../../build/linux-i586/lib/i386/libjava.so] Error 1
>> make[2]: Leaving directory
`/home/openjdk/sources/jdk/make/java/java'
>> make[1]: *** [all] Error 1
>> make[1]: Leaving directory
`/home/openjdk/sources/jdk/make/java'
>> make: *** [all] Error 1
>>
>> I've posted a more verbose version of the error at
http://pastebin.com/9exQpFkq
>>
>> I got a bit lost in the C++ spelunking, so Ben Evans gave
me a hand
and we think we've tracked it down to the fact that the
reference to
JVM_SetNativeThreadName is not in java_lang_Thread.h (a generated
header).  Looking at java_lang_Thread.h, the reference that is the
closest is Java_SetNativeThreadName, which we think has been
incorrectly
generated.
>>
>> I'll confess I haven't caught up with the last couple of months
archives, so I'm not sure if I missed a javah issue or
something else
obvious.
>>
>> Cheers,
>> Martijn
>
> Martijn - is this a partial build by any chance? I can
imagine the
above failure if doing a partial build and the import JDK is
not in sync.
>
> -Alan
>
>
>

Re: problem when building openjdk6 - CR 7058133

2011-11-14 Thread Seán Coffey 

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 Nov 13, 2011, at 7:10 PM, Li Li wrote:


hi all
I tried to build a debug version of openjdk6. I follows these 
articles:

http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html
http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html
I've got the latest codes and an error occured:
2045 /usr/bin/gcc  -O2-fno-strict-aliasing -fPIC -W -Wall 
 -Wno-unused -Wno-parentheses -fno-omit-fra me-pointer 
-D_LITTLE_ENDIAN   -DARCH='"i586"' -Di586 -DLINUX 
-DRELEASE='"1.6.0-internal"' -D_LARGEFI LE64_SOURCE -D_GNU_SOURCE 
-D_REENTRANT -I. 
-I/media/d/openjdk6/build/linux-i586/tmp/sun/sun.security 
.pkcs11/j2pkcs11/CClassHeaders 
-I../../../../src/solaris/javavm/export -I../../../../src/share/javav 
m/export -I../../../../src/share/javavm/include 
-I../../../../src/solaris/javavm/include -I../../../ 
../src/share/native/sun/security/pkcs11/wrapper 
-I../../../../src/solaris/native/sun/security/pkcs11 /wrapper 
-I../../../../src/share/native/common 
-I../../../../src/solaris/native/common -I../../../.. 
/src/share/native/sun/security/pkcs11 
-I../../../../src/solaris/native/sun/security/pkcs11-c -o 
 /media/d/openjdk6/build/linux-i586/tmp/sun/sun.security.pkcs11/j2pkcs11/obj/p11_convert.o 
 ../../../ 
../src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
2046 
../../../../src/share/native/sun/security/pkcs11/j2secmod.c:76:27: 
error: conflicting types for 'Jav 
a_sun_security_pkcs11_Secmod_nssGetModuleList'
2047 
/media/d/openjdk6/build/linux-i586/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/sun_security_p 
kcs11_Secmod.h:49:27: note: previous declaration of 
'Java_sun_security_pkcs11_Secmod_nssGetModuleLis t' was here
2048 make[6]: *** 
[/media/d/openjdk6/build/linux-i586/tmp/sun/sun.security.pkcs11/j2pkcs11/obj/j2secmod.o 
] Error 1

I searched a bug in sun's bug database:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058133
in my make/sun/security/pkcs11/Makefile
There is not any JAVAHFLAGS += -classpath $(CLASSDESTDIR)
So I tried to add this line. But it still failed.

The result of make sanity:
make[1]: Entering directory `/media/d/openjdk6/jdk/make'
make[2]: Entering directory 
`/media/d/openjdk6/jdk/make/tools/freetypecheck'

make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/media/d/openjdk6/jdk/make/tools/freetypecheck'

make[1]: Leaving directory `/media/d/openjdk6/jdk/make'

Build Machine Information:
   build machine = lili-desktop

Build Directory Structure:
   CWD = /media/d/openjdk6
   TOPDIR = .
   LANGTOOLS_TOPDIR = ./langtools
   JAXP_TOPDIR = ./jaxp
   JAXWS_TOPDIR = ./jaxws
   CORBA_TOPDIR = ./corba
   HOTSPOT_TOPDIR = ./hotspot
   JDK_TOPDIR = ./jdk

Build Directives:
   BUILD_LANGTOOLS = true
   BUILD_JAXP = true
   BUILD_JAXWS = true
   BUILD_CORBA = true
   BUILD_HOTSPOT = true
   BUILD_JDK= true
   DEBUG_CLASSFILES =
   DEBUG_BINARIES =

Hotspot Settings:
  HOTSPOT_BUILD_JOBS  =
  HOTSPOT_OUTPUTDIR   = 
/media/d/openjdk6/build/linux-i586/hotspot/outputdir
  HOTSPOT_EXPORT_PATH = 
/media/d/openjdk6/build/linux-i586/hotspot/import




Bootstrap Settings:
  BOOTDIR = /home/lili/java/jdk1.6.0_26/
ALT_BOOTDIR = /home/lili/java/jdk1.6.0_26/
  BOOT_VER = 1.6 [requires at least 1.6]
  OUTPUTDIR = /media/d/openjdk6/build/linux-i586
ALT_OUTPUTDIR = /media/d/openjdk6/build/linux-i586
  ABS_OUTPUTDIR = /media/d/openjdk6/build/linux-i586
Build Tool Settings:
  SLASH_JAVA = /NOT-SET
ALT_SLASH_JAVA =
  VARIANT = OPT
  JDK_DEVTOOLS_DIR = /NOT-SET/devtools
ALT_JDK_DEVTOOLS_DIR =
  ANT_HOME =
  UNIXCOMMAND_PATH = /bin/
ALT_UNIXCOMMAND_PATH =
  COMPILER_PATH = /usr/bin/
ALT_COMPILER_PATH =
  DEVTOOLS_PATH = /usr/bin/
ALT_DEVTOOLS_PATH =
  UNIXCCS_PATH = /usr/ccs/bin/
ALT_UNIXCCS_PATH =
  USRBIN_PATH = /usr/bin/
ALT_USRBIN_PATH =
  MOTIF_DIR = /usr
ALT_MOTIF_DIR =
  MOTIF_REQUIRED = false
  COMPILER_NAME = GCC
  COMPILER_VERSION =
  CC_VER = 4.5 [requires at least 3.2]
  ZIP_VER = 3.0 [requires at least 2.2]
  UNZIP_VER = 6.00 [requires at least 5.12]
  ANT_VER = 1.8 [requires at least 1.6.3]
  TEMPDIR = /media/d/openjdk6/build/linux-i586/tmp
Build Directives:
  OPENJDK = true
  USE_HOTSPOT_INTERPRETER_MODE =
  PEDANTIC =
  DEV_ONLY =
  NO_DOCS =
  NO_IMAGES =
  TOOLS_ONLY =
  INSANE =
  COMPILE_APPROACH = parallel
  PARALLEL_COMPILE_JOBS = 2
ALT_PARALLEL_COMPILE_JOBS =
  FASTDEBUG =
  COMPILER_WARNINGS_FATAL = false
  COMPILER_WARNING_LEVEL =
  INCREMENTAL_BUILD = false
  CC_HIGHEST_OPT = -O3
  CC_HIGHER_OPT = -O3
  CC_LOWER_OPT = -O2
  CXXFLAGS =  -O2  -fPIC -DCC_NOEX -W -Wall  -Wno-unused 
-Wno-pare