Re: RFR [9] Modular Source Code

[Anthony Petrov]

Thanks!

--
best regards,
Anthony

On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:

On 2014-08-27 12:57, Anthony Petrov wrote:

Hi Magnus,

Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
opengl-related files) even though they're compiled into the awt native
libraries.


I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213,
JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After
some consideration, I choose to put them on the infrastructure/build
category, since I believe the build part (changes to the makefiles)
requires most of the work (compared to e.g. removing a file), and that
we are probably more keen on having them solved :), but they need to be
resolved in cooperation with the 2D team.

The issue regarding the medialib directories was already reported in
JDK-8055190.

/Magnus




--
best regards,
Anthony

On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:

On 2014-08-20 11:14, Magnus Ihse Bursie wrote:

On 2014-08-18 16:15, Anthony Petrov wrote:

So I'm not sure if the current set of AWT libraries could be
simplified any further.

Hope this helps.


Thank you for the clarification, it was very helpful!

While the set of AWT libraries probably cannot be simplified as you
say, my gut feeling is still that the current layout of files on disk
does not optimally match the actual libraries we build. Armed with the
help of your description, I'll look into them once again and see if I
can make that statement more concrete.


This is my suggestions based on what I found when trying to remove the
last unnecessary entanglement. Note that all paths are relative to the
java.desktop module, and  that I have at this stage only looked at
compiled sources (*.c), not header files.

* The following files are in the windows directory tree, but are
explicitly excluded on Windows. Thus they will never be built, and
should be removed instead:
   ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
   ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
   ./windows/native/libawt/sun/windows/WBufferStrategy.cpp

* The following file is in the share directory tree, but is only used on
Windows. It should be moved to the corresponding windows directory
instead:
   ./share/native/libawt/sun/java2d/ShaderList.c

* The following directory is in the unix directory tree, but is only
used on Solaris. It should be moved to the corresponding solaris
directory instead:
   ./unix/native/libawt/sun/java2d/loops

* The directory ./unix/native/common/sun/awt contains five more or less
unrelated .c files. Three of them are only used in libawt_xawt, and
should be moved there:
   ./unix/native/common/sun/awt/awt_Font.c
   ./unix/native/common/sun/awt/fontpath.c
   ./unix/native/common/sun/awt/X11Color.c
Of the remaining two CUPSfuncs.c seems correctly placed, since it is
shared between libawt_xawt and libawt_lwawt. However, I'm wondering
about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
when I checked some random functions, they are exported (via the
mapfile) for libawt only. So I believe it is a mistake to include it in
libawt_xawt, and that it should be moved to the libawt directory. This
will need verification from someone on the AWT team.

* The directory ./unix/native/libjawt is included in libawt_xawt (and in
libjawt, of course). This seems suspicious to me. There is just a single
file with a single function, JAWT_GetAWT(), which is exported in libjawt
(via a mapfile), but not in libawt_xawt. I believe it is a mistake to
include it in libawt_xawt. This will need verification from someone on
the AWT team.

* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
and just makes all paths extra long. I suggest that we remove that layer
and move everything up one step.

* The makefiles include too specific directories. Instead of including
e.g. ./*/native/common/sun/java2d/opengl and
./*/native/common/sun/java2d/x11, we should just include
./*/native/common/sun/java2d. This level corresponds to a logical
grouping of the source code, and not the directory structure in that
grouping.

* The file ./windows/native/common/awt_makecube.cpp is a bit strange. It
is not a shared file; instead it's a stand-alone binary with a main()
function. It is not compiled by any makefile targets. If this file is
actually used, I suggest moving it to a better location
(windows/native/launchers?), and starting to compile it with the build.
(Stuff that's not built regularly is doomed to bit rot.) It if is not
used, I suggest we remove it.

* And as I stated before, the medlialib directories are typically not
used by libawt and friends. It is used by libmlib_image and
libmlib_image_v, and should move away from the awt directory.

/Magnus

Re: RFR [9] Modular Source Code

[Anthony Petrov]

Hi Magnus,

Those look like reasonable suggestions. Could you please file separate 
bugs for each of these issues? Also, please note that most of them 
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and opengl-related 
files) even though they're compiled into the awt native libraries.


--
best regards,
Anthony

On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:

On 2014-08-20 11:14, Magnus Ihse Bursie wrote:

On 2014-08-18 16:15, Anthony Petrov wrote:

So I'm not sure if the current set of AWT libraries could be
simplified any further.

Hope this helps.


Thank you for the clarification, it was very helpful!

While the set of AWT libraries probably cannot be simplified as you
say, my gut feeling is still that the current layout of files on disk
does not optimally match the actual libraries we build. Armed with the
help of your description, I'll look into them once again and see if I
can make that statement more concrete.


This is my suggestions based on what I found when trying to remove the
last unnecessary entanglement. Note that all paths are relative to the
java.desktop module, and  that I have at this stage only looked at
compiled sources (*.c), not header files.

* The following files are in the windows directory tree, but are
explicitly excluded on Windows. Thus they will never be built, and
should be removed instead:
   ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
   ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
   ./windows/native/libawt/sun/windows/WBufferStrategy.cpp

* The following file is in the share directory tree, but is only used on
Windows. It should be moved to the corresponding windows directory instead:
   ./share/native/libawt/sun/java2d/ShaderList.c

* The following directory is in the unix directory tree, but is only
used on Solaris. It should be moved to the corresponding solaris
directory instead:
   ./unix/native/libawt/sun/java2d/loops

* The directory ./unix/native/common/sun/awt contains five more or less
unrelated .c files. Three of them are only used in libawt_xawt, and
should be moved there:
   ./unix/native/common/sun/awt/awt_Font.c
   ./unix/native/common/sun/awt/fontpath.c
   ./unix/native/common/sun/awt/X11Color.c
Of the remaining two CUPSfuncs.c seems correctly placed, since it is
shared between libawt_xawt and libawt_lwawt. However, I'm wondering
about initIDs.c. It is compiled in libawt as well as libawt_xawt, but
when I checked some random functions, they are exported (via the
mapfile) for libawt only. So I believe it is a mistake to include it in
libawt_xawt, and that it should be moved to the libawt directory. This
will need verification from someone on the AWT team.

* The directory ./unix/native/libjawt is included in libawt_xawt (and in
libjawt, of course). This seems suspicious to me. There is just a single
file with a single function, JAWT_GetAWT(), which is exported in libjawt
(via a mapfile), but not in libawt_xawt. I believe it is a mistake to
include it in libawt_xawt. This will need verification from someone on
the AWT team.

* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the "sun" directory. It is not needed anymore,
and just makes all paths extra long. I suggest that we remove that layer
and move everything up one step.

* The makefiles include too specific directories. Instead of including
e.g. ./*/native/common/sun/java2d/opengl and
./*/native/common/sun/java2d/x11, we should just include
./*/native/common/sun/java2d. This level corresponds to a logical
grouping of the source code, and not the directory structure in that
grouping.

* The file ./windows/native/common/awt_makecube.cpp is a bit strange. It
is not a shared file; instead it's a stand-alone binary with a main()
function. It is not compiled by any makefile targets. If this file is
actually used, I suggest moving it to a better location
(windows/native/launchers?), and starting to compile it with the build.
(Stuff that's not built regularly is doomed to bit rot.) It if is not
used, I suggest we remove it.

* And as I stated before, the medlialib directories are typically not
used by libawt and friends. It is used by libmlib_image and
libmlib_image_v, and should move away from the awt directory.

/Magnus

Re: RFR [9] Modular Source Code

[Anthony Petrov]

On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:

libawt et al:
   The relation between libawt, libawt_headless, libjawt, libawt_xawt
and libawt_lwawt are hairy enough to make my brain curl up. I believe
there are simplifications to be made but I gave up trying to figure them
out.


libawt contains code that is shared between all AWT lib implementations. 
Depending on what mode/toolkit is requested, it loads a specific variant 
of the awt native library, such as:


 - libawt_headless - headless AWT implementation.
 - libawt_xawt - XToolkit implementation (uses X11 for GUI)
 - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)

Historically, we were able to choose between lwawt and xawt on Mac in 
the past, but we no longer support or even build xawt on Mac. Also, in 
the past there was MToolkit (which used Motif for GUI). Again, we no 
longer support this toolkit. So, currently we always use xawt on 
Linux/Solaris and lwawt on Mac. But since we still need to choose 
between a real toolkit and a headless toolkit, we need the common libawt 
library.


libjawt is a helper library that implements JAWT API and is loaded by 
applications that use the JAWT interface which allows them to get direct 
access to the native AWT drawing surface and use native APIs (e.g. 
OpenGL) to draw on the surface. This library isn't needed for regular 
AWT/Swing applications.


So I'm not sure if the current set of AWT libraries could be simplified 
any further.


Hope this helps.

--
best regards,
Anthony

Re: [9] Review Request: 8047336 Read flavormap.properties as resource

[Anthony Petrov]

Thanks. Note that your email editor messed up the HTML part of the email 
(see below a text-only quote), so here's the correct link to the webrev:


http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/

The fix looks fine to me.

--
best regards,
Anthony

On 7/2/2014 3:10 PM, Petr Pchelko wrote:

Hello, Anthony, Alan.

Thank you for the review, the new version is located here:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/


I've changed the code to throw an InternalError if we cannot read
properties.
Once I get feedback from the build team - I'll push this fix.

With best regards. Petr.

On 02 июля 2014 г., at 13:52, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:


On 01/07/2014 09:35, Petr Pchelko wrote:

Hello,

The changes in the public API have been approved, so let me continue
the review process.

For your convenience:
The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/


Until now we've been discussing an abstract question of moving the
properties to a different location and agreed that it's possible.
Now it's time for an official code review. Could someone please make one?

Also some feedback from the build team is still required. Could
someone from the build team review this fix please?
(The question is that I've made a separate explicit rule for
flavormap.properties file. If I add it to COPY_PATTERNS than the
solaris version get's copied on Mac. Is that a bug in the build
system? Is my current solution good enough?)


I think this looks okay. I see Anthony's mail asking about the warning
message and whether it should the print stack trace. I just wonder if
it might be saner to just throw InternalError here. It throws
InternalError if flavormap.properties is missing and it might be
consistent to do the same when the file is corrupt or can't be parsed
as a properties file.

-Alan.

Re: [9] Review Request: 8047336 Read flavormap.properties as resource

[Anthony Petrov]

Hi Petr,

The fix looks fine to me. Only one question:

src/share/classes/java/awt/datatransfer/SystemFlavorMap.java

 234 } catch (IOException e) {
 235 System.err.println("Warning reading flavor mapping: " + 
e.getMessage());


Is there a reason to hide the stack trace of the exception? Why wouldn't 
a simple call to e.printStackTrace() work? Or why not to throw an 
InternalError(e) in this case? We already throw it at line 228 if the 
resource cannot be open.


--
best regards,
Anthony

On 7/1/2014 12:35 PM, Petr Pchelko wrote:

Hello,

The changes in the public API have been approved, so let me continue the
review process.

For your convenience:
The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/

Until now we've been discussing an abstract question of moving the
properties to a different location and agreed that it's possible.
Now it's time for an official code review. Could someone please make one?

Also some feedback from the build team is still required. Could someone
from the build team review this fix please?
(The question is that I've made a separate explicit rule for
flavormap.properties file. If I add it to COPY_PATTERNS than the solaris
version get's copied on Mac. Is that a bug in the build system? Is my
current solution good enough?)

Thank you.
With best regards. Petr.

On 20 июня 2014 г., at 15:50, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:


On 20/06/2014 12:41, Petr Pchelko wrote:

Hello, Anthony, Artem.


Do we officially declare that we drop support for this possibility?

This possibility will be dropped regardless of the current Petr's
fix, since there will be no single "jre" folder in jigsaw world.
Probably, some other mechanism to customize files like
flavormap.properties or logging.properties will be introduced.

And we can add a system property to set an alternative
flavormap.properties file later if someone would request such a feature.


BTW, the current fix is not about flavormap.properties on its own,
but about removing AWT.DnD.flavorMapFileURL toolkit property. I
would suggest to push this change as a separate bug fix, not as a
part of 8047336.

And also about changing flavormap.properties format) The current fix
is all the work in datatransfer modularization that needs a CCC. All
changes seem related, so I would prefer no to split it further,
because it would make it harder to track when all the peaces are
integrated to jake repository to continue the work. And it would need
more CCC requests which consume time.


The forum post looks like is from 2001. If there doesn't appear that
many developers have resorted to editing that file then I would
suggest just going with what you have. If it really becomes necessary
to support having configuration elsewhere (not in the JDK image) then
I don't think anything that you have now precludes that.

-Alan.

Re: [9] Review Request: 8047336 Read flavormap.properties as resource

[Anthony Petrov]

I see. OK then. But this looks like something that needs to be 
release-noted.


--
best regards,
Anthony

On 6/20/2014 3:41 PM, Petr Pchelko wrote:

Hello, Anthony, Artem.


Do we officially declare that we drop support for this possibility?

This possibility will be dropped regardless of the current Petr's fix, since there will 
be no single "jre" folder in jigsaw world. Probably, some other mechanism to 
customize files like flavormap.properties or logging.properties will be introduced.

And we can add a system property to set an alternative flavormap.properties 
file later if someone would request such a feature.


BTW, the current fix is not about flavormap.properties on its own, but about 
removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push 
this change as a separate bug fix, not as a part of 8047336.

And also about changing flavormap.properties format) The current fix is all the 
work in datatransfer modularization that needs a CCC. All changes seem related, 
so I would prefer no to split it further,
because it would make it harder to track when all the peaces are integrated to 
jake repository to continue the work. And it would need more CCC requests which 
consume time.

Thank you.
With best regards. Petr.

On 20 июня 2014 г., at 15:29, Artem Ananiev  wrote:



On 6/20/2014 3:19 PM, Anthony Petrov wrote:

Hi Petr,

I ran the following query:

https://www.google.com/#q=custom+flavormap.properties

and the search yielded the following forum thread:

https://community.oracle.com/thread/1293314?start=0&tstart=0

where developers seem to suggest they do edit the
$JDKHOME/jre/lib/flavormap.properties file sometimes.

Do we officially declare that we drop support for this possibility?


This possibility will be dropped regardless of the current Petr's fix, since there will 
be no single "jre" folder in jigsaw world. Probably, some other mechanism to 
customize files like flavormap.properties or logging.properties will be introduced.

BTW, the current fix is not about flavormap.properties on its own, but about 
removing AWT.DnD.flavorMapFileURL toolkit property. I would suggest to push 
this change as a separate bug fix, not as a part of 8047336.

Thanks,

Artem


--
best regards,
Anthony

On 6/19/2014 4:24 PM, Petr Pchelko wrote:

Hello, Alan.

Thank you for the review.


Do we know if anyone has been editing the file in ${java.home}/lib?

I couldn't find any examples on the internet although I've done a very
extensive search, so I we could add a property later if someone would
request it.

With best regards. Petr.

On 19 июня 2014 г., at 16:13, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:


On 19/06/2014 12:17, Petr Pchelko wrote:

Hello,

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8047336
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/

This is another step in datatransfer modularization work. This part
of the work needs a CCC, so I've moved it out to a separate fix. The
CCC will be filed once the fix is settled.

Multiple changes are happening here:
1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
public API. However one mention was forgotten and I'm removing it
now, see changes in Toolkit.java
2. For modules we need to move flavormap.properties out of the
jre/lib. I'm not sure about the new location. Can I add properties
to the java.awt.datatransfer package? Wouldn't they be considered
public in this case?
3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
the user and it's not used by us. So I'm removing it.
4. As flavormap.properties is not editable by the user any more, I'm
changing it's format to get significant simplification of the
parsing code.

There's no way left to change the default mappings now, but we have
public supported API to create new mappings in the Java code. System
property could be added to provide alternative properties location,
but I don't think it's required.


The dropping of the reference to flavormap.properties from
java.awt.Toolkit looks okay to me.

I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
(not a detailed review) and it looks okay. I cannot comment on the
changes to format as I don't know the history in this area to
understand the issues around duplicates.

On your question about introducing a system property to allow the
configuration be picked up from some other (non-JDK) location then it
doesn't sound like there is a strong case. Do we know if anyone has
been editing the file in ${java.home}/lib? I assume that if there is a
strong need then it could be possible to introducing it in the future
without conflicting with anything that you are doing here.

-Alan.

Re: [9] Review Request: 8047336 Read flavormap.properties as resource

[Anthony Petrov]

On 6/20/2014 3:29 PM, Artem Ananiev wrote:

On 6/20/2014 3:19 PM, Anthony Petrov wrote:

I ran the following query:

https://www.google.com/#q=custom+flavormap.properties

and the search yielded the following forum thread:

https://community.oracle.com/thread/1293314?start=0&tstart=0

where developers seem to suggest they do edit the
$JDKHOME/jre/lib/flavormap.properties file sometimes.

Do we officially declare that we drop support for this possibility?


This possibility will be dropped regardless of the current Petr's fix,
since there will be no single "jre" folder in jigsaw world. Probably,
some other mechanism to customize files like flavormap.properties or
logging.properties will be introduced.


Can we file an RFE for this feature now please?



BTW, the current fix is not about flavormap.properties on its own, but
about removing AWT.DnD.flavorMapFileURL toolkit property. I would
suggest to push this change as a separate bug fix, not as a part of
8047336.


+1

--
best regards,
Anthony



Thanks,

Artem


--
best regards,
Anthony

On 6/19/2014 4:24 PM, Petr Pchelko wrote:

Hello, Alan.

Thank you for the review.


Do we know if anyone has been editing the file in ${java.home}/lib?

I couldn't find any examples on the internet although I've done a very
extensive search, so I we could add a property later if someone would
request it.

With best regards. Petr.

On 19 июня 2014 г., at 16:13, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:


On 19/06/2014 12:17, Petr Pchelko wrote:

Hello,

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8047336
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/

This is another step in datatransfer modularization work. This part
of the work needs a CCC, so I've moved it out to a separate fix. The
CCC will be filed once the fix is settled.

Multiple changes are happening here:
1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties
and AWT.DnD.flavorMapFileURL Toolkit property was removed from the
public API. However one mention was forgotten and I'm removing it
now, see changes in Toolkit.java
2. For modules we need to move flavormap.properties out of the
jre/lib. I'm not sure about the new location. Can I add properties
to the java.awt.datatransfer package? Wouldn't they be considered
public in this case?
3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by
the user and it's not used by us. So I'm removing it.
4. As flavormap.properties is not editable by the user any more, I'm
changing it's format to get significant simplification of the
parsing code.

There's no way left to change the default mappings now, but we have
public supported API to create new mappings in the Java code. System
property could be added to provide alternative properties location,
but I don't think it's required.


The dropping of the reference to flavormap.properties from
java.awt.Toolkit looks okay to me.

I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
(not a detailed review) and it looks okay. I cannot comment on the
changes to format as I don't know the history in this area to
understand the issues around duplicates.

On your question about introducing a system property to allow the
configuration be picked up from some other (non-JDK) location then it
doesn't sound like there is a strong case. Do we know if anyone has
been editing the file in ${java.home}/lib? I assume that if there is a
strong need then it could be possible to introducing it in the future
without conflicting with anything that you are doing here.

-Alan.

Re: [9] Review Request: 8047336 Read flavormap.properties as resource

[Anthony Petrov]

Hi Petr,

I ran the following query:

https://www.google.com/#q=custom+flavormap.properties

and the search yielded the following forum thread:

https://community.oracle.com/thread/1293314?start=0&tstart=0

where developers seem to suggest they do edit the 
$JDKHOME/jre/lib/flavormap.properties file sometimes.



Do we officially declare that we drop support for this possibility?

--
best regards,
Anthony

On 6/19/2014 4:24 PM, Petr Pchelko wrote:

Hello, Alan.

Thank you for the review.


Do we know if anyone has been editing the file in ${java.home}/lib?

I couldn't find any examples on the internet although I've done a very
extensive search, so I we could add a property later if someone would
request it.

With best regards. Petr.

On 19 июня 2014 г., at 16:13, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:


On 19/06/2014 12:17, Petr Pchelko wrote:

Hello,

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8047336
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/

This is another step in datatransfer modularization work. This part of the work 
needs a CCC, so I've moved it out to a separate fix. The CCC will be filed once 
the fix is settled.

Multiple changes are happening here:
1. Afterhttp://ccc.us.oracle.com/8005250  the flavormap.properties and 
AWT.DnD.flavorMapFileURL Toolkit property was removed from the public API. 
However one mention was forgotten and I'm removing it now, see changes in 
Toolkit.java
2. For modules we need to move flavormap.properties out of the jre/lib. I'm not 
sure about the new location. Can I add properties to the java.awt.datatransfer 
package? Wouldn't they be considered public in this case?
3. The AWT.DnD.flavorMapFileURL Toolkit property cannot be set by the user and 
it's not used by us. So I'm removing it.
4. As flavormap.properties is not editable by the user any more, I'm changing 
it's format to get significant simplification of the parsing code.

There's no way left to change the default mappings now, but we have public 
supported API to create new mappings in the Java code. System property could be 
added to provide alternative properties location, but I don't think it's 
required.


The dropping of the reference to flavormap.properties from
java.awt.Toolkit looks okay to me.

I skimmed through the changes to java.awt.datatransfer.SystemFlavorMap
(not a detailed review) and it looks okay. I cannot comment on the
changes to format as I don't know the history in this area to
understand the issues around duplicates.

On your question about introducing a system property to allow the
configuration be picked up from some other (non-JDK) location then it
doesn't sound like there is a strong case. Do we know if anyone has
been editing the file in ${java.home}/lib? I assume that if there is a
strong need then it could be possible to introducing it in the future
without conflicting with anything that you are doing here.

-Alan.

Re: RFR: 8043805: Allow using a system-installed libjpeg

[Anthony Petrov]

Thanks, Omair.

--
best regards,
Anthony

On 5/23/2014 1:01 AM, Omair Majid wrote:

* Anthony Petrov  [2014-05-22 16:48]:

I think that it would be useful to have a bug id prior to sending a review
request, so that a review thread for the bug can be easily found in the
mailing archive. In the future, please do file a bug first and put its id in
the subject line of your review requests.


Apologies.

I have filed https://bugs.openjdk.java.net/browse/JDK-8043805 and
updated the subject of the thread.

Thanks,
Omair

Re: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg

[Anthony Petrov]

I think that it would be useful to have a bug id prior to sending a 
review request, so that a review thread for the bug can be easily found 
in the mailing archive. In the future, please do file a bug first and 
put its id in the subject line of your review requests.


--
best regards,
Anthony

On 5/23/2014 12:28 AM, Omair Majid wrote:

* Phil Race  [2014-05-22 16:02]:

BTW .. I just realised I haven't seen a bug ID in this thread.
Does one already exist ?


No. I was going to create one before I push.

Thanks,
Omair

Re: RFR: Allow using the system libjpeg

[Anthony Petrov]

Thanks for the update, Omair. The fix looks good to me now.

--
best regards,
Anthony

On 5/20/2014 9:11 PM, Omair Majid wrote:

Hi,

Updated webrevs:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/

* Anthony Petrov  [2014-05-19 14:42]:

make/lib/Awt2dLibraries.gmk

1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg


Since these are compiler flags, I suppose this should read "-I", not
just "".


Yes, it should. I wonder how my compiler accepted that.


Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg
files?


I did. I tested both combinations and made sure both the splash screen
and javax.swing.ImageIcon could display jpegs files with the first
webrev I posted.

Thanks,
Omair

Re: RFR: Allow using the system libjpeg

[Anthony Petrov]

Hi Omair,

common/autoconf/libraries.m4

 624   [use libjpeg from build system or OpenJDK source (system, bundled) 
@<:bundled@:>@])])


"@<:bundled@:>@" should read "@<:@bundled@:>@" - note the missing @.


make/lib/Awt2dLibraries.gmk

1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg


Since these are compiler flags, I suppose this should read "-I", 
not just "".


Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg 
files?


--
best regards,
Anthony

On 5/17/2014 4:45 AM, Omair Majid wrote:

Hi,

Webrevs are at:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk

This patch modifies OpenJDK to allow building and running using the
system copy of libjpeg. This follows my previous changes for lcms
and a lot of the decisions made on that patch apply here.

This is the last of my system-library patches :)

Thanks,
Omair

Re: RFR: Allow using a system installed libpng

[Anthony Petrov]

Hi Andrew,

"Client code" is basically anything in 2D, AWT, i18n, beans, a11y, 
ImageIO, Sound, or Swing. I.e., anything related to GUI/desktop.


In this particular case Omair is changing the SplashScreen code which 
belongs to AWT, hence the choice of the client repo for integration.


--
best regards,
Anthony

On 2/20/2014 7:30 PM, Andrew Hughes wrote:

- Original Message -

Hi Omair,


Should I be pushing this to jdk9/dev ? (Or to jdk9/client?)


If you change client code, then the fix should go to the client repo to
avoid merge conflicts and allow for more manual testing prior to
integrating the changes into the master repo.


Perhaps this would be an appropriate point to clarify what constitutes
'client code'?



--
best regards,
Anthony

On 2/19/2014 8:16 PM, Omair Majid wrote:

* Magnus Ihse Bursie  [2014-02-19 06:59]:

On 2014-02-17 10:16, Erik Joelsson wrote:

At least to me this looks good, but better let Magnus and Andrew
have their say too.


Looks good to me!


Thanks for the reviews, everyone!

I have filed https://bugs.openjdk.java.net/browse/JDK-8035341 to track
the issue. Can someone please point me some docs that explains what I
need to do to to this bug once I have pushed the fix?

Should I be pushing this to jdk9/dev ? (Or to jdk9/client?)

Thanks,
Omair





Thanks,

Re: RFR: Allow using a system installed libpng

[Anthony Petrov]

Hi Omair,


Should I be pushing this to jdk9/dev ? (Or to jdk9/client?)


If you change client code, then the fix should go to the client repo to 
avoid merge conflicts and allow for more manual testing prior to 
integrating the changes into the master repo.


--
best regards,
Anthony

On 2/19/2014 8:16 PM, Omair Majid wrote:

* Magnus Ihse Bursie  [2014-02-19 06:59]:

On 2014-02-17 10:16, Erik Joelsson wrote:

At least to me this looks good, but better let Magnus and Andrew
have their say too.


Looks good to me!


Thanks for the reviews, everyone!

I have filed https://bugs.openjdk.java.net/browse/JDK-8035341 to track
the issue. Can someone please point me some docs that explains what I
need to do to to this bug once I have pushed the fix?

Should I be pushing this to jdk9/dev ? (Or to jdk9/client?)

Thanks,
Omair

hg: jdk8/build/jdk: 8027912: [macosx] Provide means to force the headful mode on OS X when running via ssh

[anthony . petrov]

Changeset: 43168d403243
Author:anthony
Date:  2013-11-08 20:07 +0400
URL:   http://hg.openjdk.java.net/jdk8/build/jdk/rev/43168d403243

8027912: [macosx] Provide means to force the headful mode on OS X when running 
via ssh
Summary: Bypass AquaSession check if AWT_FORCE_HEADFUL env. variable is set to 
TRUE
Reviewed-by: anthony, art
Contributed-by: David Dehaven 

! src/solaris/native/java/lang/java_props_macosx.c

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

Hi David,

The fix looks fine to me. Thanks for all your hard work.

--
best regards,
Anthony

On 10/24/2013 03:52 AM, David DeHaven wrote:



Another option (I think would make everyone happy) would be to add a native 
method to LWCToolkit.{java,m} that implements isAquaSession and returns a 
boolean. Call this new method in the static initializer and use it's return 
value to set java.awt.headless before calling initIDs. This will still be done 
early enough that Toolkit.java will end up wrapping LWCToolkit in a 
HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks 
to see if it needs to be wrapped. Then all that code in java_props* and 
System.c could be removed.


I like this idea. But it needs testing.


Cool, I'll poke at it when I get a chance.


Doesn't work in LWCToolkit, GraphicsEnvironment gets initialized first which 
messes things up.

It sort of works in CGraphicsEnvironment. The problem there is 
GraphicsEnvironment.isHeadless() is called at least once prior to 
CGraphicsEnvironment being loaded which then caches the value (false) so just 
changing the system property doesn't do anything. I added a protected method to 
change headless and it works, but I'm not entirely happy with that approach and 
I'm not convinced there won't be other side effects. For one thing, what is 
calling isHeadless before CGE gets loaded and will it cope with the mode 
changing? I don't think we have time to chase down all the issues that might 
manifest from that change, when we know for certain the setting the property in 
System.c works fine.

I think the safest bet at this point is to move all the java_props.awt_headless 
field related code into #ifdef blocks so they only exist on Mac OS X. That will 
address the cross-platform concern and fix this issue. I just thought it would 
be useful for other platforms (especially embedded) to be able to poll their 
environment and set themselves up accordingly...


Updated (hopefully final...) webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/

Changes from last version:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.3/webrev.delta/index.html

(src/windows/native/java/lang/java_props_md.c only shows up because of the 
delta webrev, it gets reverted back to the way it was)


As a side note, SplashScreen calls isHeadless and dumps a nice ugly stack trace 
in a non-GUI session. It does this in the existing code so that's something 
that'll need to be addressed as a separate issue. Also, the message returned by 
GraphicsEnvironment.getHeadlessMessage() isn't correct for Mac, that should 
either be made more generic or let the platform impl class return that string 
(if it's even known or loaded at the time...).

-DrD-

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

On 10/23/2013 08:49 PM, David DeHaven wrote:

Not sure about this part. We already force this property to be set in
Embedded without needing any changes in the code you have modified and
I'm not sure if your changes will break what we already do. Why do you
need to do it?

I'm getting concerned about this change touching stuff outside of OSX.


I think I agree with David. E.g. I'm not sure I like changing
j/l/System.c for this fix.

Given the time constraints, perhaps going with HToolkit would be a good
enough solution for now?

Artem, what's your opinion?


I'm personally fine with the current version. The fix is now Mac OS X specific, 
as sprops.awt_headless is only set within #ifdef MACOSX, it won't have any 
impact on other platforms. At the same time it enables headless functionality 
on Mac OS X, while HToolkit doesn't.

Note that it can be improved further. As it stands now, the only purpose of 
getPreferredToolkit() is to check if Aqua session is active. The toolkit we use 
is always CToolkit, regardless of what this method returns, so the method can 
be removed, and isInAquaSession() can be called instead. Leaving this further 
cleanup up to David D., though.


The only reason I left it in there was for the AWT_TOOLKIT environment variable 
support. Right now if you set AWT_TOOLKIT to HToolkit it will start in headless 
mode regardless of what isAquaSession() returns. If we don't care about that 
then I'll happily remove it (I'm asking because I don't know if it's used or 
not).

For example:
$ AWT_TOOLKIT=HToolkit ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
-jar ~/Desktop/SwingSet2.jar
2013-10-23 09:26:21.726 java[23276:707] [JRSAppKitAWT markAppIsDaemon]: Process 
manager already initialized: can't fully enable headless mode.
Exception in thread "main" java.awt.HeadlessException
at 
sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77)
at SwingSet2.main(SwingSet2.java:224)

But it's *only* implemented on Mac OS X so it doesn't appear to be all that 
useful unless we want it implemented for other platforms, which would be a 
whole separate issue.


There's a documented way to choose a toolkit: it is the awt.toolkit 
system property.


We don't care about AWT_TOOLKIT anymore. It was only relevant at the 
time of 1.5 and 1.6 to allow users to switch between MToolkit and 
XToolkit. Now that MToolkit is gone, this environment variable isn't needed.



Another option (I think would make everyone happy) would be to add a native 
method to LWCToolkit.{java,m} that implements isAquaSession and returns a 
boolean. Call this new method in the static initializer and use it's return 
value to set java.awt.headless before calling initIDs. This will still be done 
early enough that Toolkit.java will end up wrapping LWCToolkit in a 
HeadlessToolkit, since it first initializes the wrapped toolkit *then* checks 
to see if it needs to be wrapped. Then all that code in java_props* and 
System.c could be removed.


I like this idea. But it needs testing.

--
best regards,
Anthony

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

On 10/23/2013 07:11 PM, Artem Ananiev wrote:


On 10/23/2013 4:34 PM, Anthony Petrov wrote:

On 10/23/2013 08:52 AM, David Holmes wrote:

On 23/10/2013 2:10 PM, David DeHaven wrote:


Updated webrev:

http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/

Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which
does not set the property)


Not sure about this part. We already force this property to be set in
Embedded without needing any changes in the code you have modified and
I'm not sure if your changes will break what we already do. Why do you
need to do it?

I'm getting concerned about this change touching stuff outside of OSX.


I think I agree with David. E.g. I'm not sure I like changing
j/l/System.c for this fix.

Given the time constraints, perhaps going with HToolkit would be a good
enough solution for now?

Artem, what's your opinion?


I'm personally fine with the current version. The fix is now Mac OS X
specific, as sprops.awt_headless is only set within #ifdef MACOSX, it


Well, we also need to make sure it's always initialized. I assume the 
whole sprops structure is zeroed out somewhere? If so, then everything 
looks fine.



won't have any impact on other platforms. At the same time it enables
headless functionality on Mac OS X, while HToolkit doesn't.

Note that it can be improved further. As it stands now, the only purpose
of getPreferredToolkit() is to check if Aqua session is active. The
toolkit we use is always CToolkit, regardless of what this method
returns, so the method can be removed, and isInAquaSession() can be
called instead. Leaving this further cleanup up to David D., though.


Thanks Artem. I'm OK with the current fix, too, then.

--
best regards,
Anthony



Thanks,

Artem


--
best regards,
Anthony



David


- Replaced the toolkit selection code in java_props_macosx.[ch]. I
could have just exposed isAquaSession but I wanted to preserve the
AWT_TOOLKIT environment variable support (no idea if it's actually
used or not...).
- Modified WrappedToolkitTest.sh to check that it's wrapping
LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless
jtreg tests pass.

No build system or hotspot changes since the last patch.

-DrD-

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

On 10/23/2013 08:52 AM, David Holmes wrote:

On 23/10/2013 2:10 PM, David DeHaven wrote:


Updated webrev:

http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/

Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which
does not set the property)


Not sure about this part. We already force this property to be set in
Embedded without needing any changes in the code you have modified and
I'm not sure if your changes will break what we already do. Why do you
need to do it?

I'm getting concerned about this change touching stuff outside of OSX.


I think I agree with David. E.g. I'm not sure I like changing 
j/l/System.c for this fix.


Given the time constraints, perhaps going with HToolkit would be a good 
enough solution for now?


Artem, what's your opinion?

--
best regards,
Anthony



David


- Replaced the toolkit selection code in java_props_macosx.[ch]. I
could have just exposed isAquaSession but I wanted to preserve the
AWT_TOOLKIT environment variable support (no idea if it's actually
used or not...).
- Modified WrappedToolkitTest.sh to check that it's wrapping
LWCToolkit in HeadlessToolkit and now all five awt/Toolkit/Headless
jtreg tests pass.

No build system or hotspot changes since the last patch.

-DrD-

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

We don't have to. IIRC, the choice of HToolkit on Mac was made by chance.

Since we must load the lwawt lib in headless on Mac anyway, we may as 
well use the CToolkit (properly wrapped in the HeadlessToolkit). But 
there's no need to continue to use the HToolkit on Mac.


--
best regards,
Anthony

On 10/22/2013 08:22 PM, Leonid Romanov wrote:

There was a discussion why we use HToolkit instead of HeadlessToolkit:
http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html

So we might want to continue using it.

Also, please be aware that there is HToolkit check in 
GraphicsToolkit.getHeadlessProperty()

On Oct 22, 2013, at 1:23 PM, Artem Ananiev  wrote:


Hi, David,

thanks for additional cleanup.

I have only one concern. Before the fix, we checked if there is an active Aqua 
session. When no session was found, we falled back to HToolkit. I think this 
logic should be preserved, but slightly corrected: fall back to HeadlessToolkit 
(with CToolkit wrapped in).

Otherwise the only way to run headless on Mac will be to force it with the 
system property. It works this way on Windows, but on Windows we're sure that 
WToolkit can run even without a UI session. Is it also true on Mac? Did you try 
to launch AWT without -Djava.awt.headless=true from remote console with no 
users logged in?

Thanks,

Artem

On 10/22/2013 7:34 AM, David DeHaven wrote:


Updated webrev for JDK (hotspot change is the same):
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/

Changes since last version:
- Moved to jdk8/build/jdk to save someone a merge headache, moved changes to 
CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk
- Removed HToolkit option and toolkit selection code from java_props_macosx.[ch]

-DrD-



I want to do one more iteration of this. Based on feedback it seems I can 
remove a bit more code from java_props_macosx.[ch] and make things a bit 
cleaner.

-DrD-


Thanks guys.

Anthony, can you sponsor this for me?

-DrD-


This fix looks fine to me as well.

--
best regards,
Anthony

On 10/20/2013 11:56 PM, David DeHaven wrote:


CCing: build-dev, macosx-port-dev, hotspot-dev

Request for review of JDK-8025673:
https://bugs.openjdk.java.net/browse/JDK-8025673

Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8025673/

This change disables building libawt_xawt.dylib and libawt_headless.dylib on 
Mac since they are not used and not supported. There are too many challenges 
(and not enough time) in removing all X11 code from the Mac build at this time, 
so we're deferring complete removal for later (will be covered by JDK-8003900).

A small change to hotspot is required as it was looking for libawt_xawt.dylib 
and if not found would set java.awt.headless to true. Since we don't build a 
headless only JRE on Mac I just have that method return false. I'm not sure how 
to handle changes to hotspot, can it be pushed along with the jdk changes? 
Without that change the Mac builds will be broken.

Significant build system changes, build-dev guys are encouraged to comment...

I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that 
broke JNI header generation on platforms still using X11 and I couldn't use the 
big list of excluded files on Mac as that resulted in Java compilation errors, 
so I just added some logic to exclude everything on Mac and left the list in 
place everywhere else.

The changes to CompileNativeLibraries.gmk will port to 
libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the 
jdk8/build workspace where the build cannot find symbols in JNI libs so that 
issue needs to be resolved first. I've not had time to investigate that problem.


Question for the AWT team, we still have this in java_props_md.c:
458 PreferredToolkit prefToolkit = getPreferredToolkit();
459 if (prefToolkit == CToolkit) {
460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit";
461 } else {
462 // TODO: do we still need this?
463 sprops.awt_toolkit = "sun.awt.HToolkit";
464 }

Is that necessary? Since we're now using libawt_lwawt in both headless and 
headful modes I would think we could remove the HToolkit option, but I'm not 
100% certain about that.


I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be 
working fine.

JPRT run for Mac is in progress, I will submit one for all other platforms when 
it finishes building.

-DrD-

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

Artem is correct. On Mac we can't start a GUI session via ssh, for 
example. Thus we choose the headless mode then. The isInAquaSession() is 
supposed to perform exactly this check. This logic needs to be preserved.


--
best regards,
Anthony

On 10/22/2013 01:23 PM, Artem Ananiev wrote:

Hi, David,

thanks for additional cleanup.

I have only one concern. Before the fix, we checked if there is an
active Aqua session. When no session was found, we falled back to
HToolkit. I think this logic should be preserved, but slightly
corrected: fall back to HeadlessToolkit (with CToolkit wrapped in).

Otherwise the only way to run headless on Mac will be to force it with
the system property. It works this way on Windows, but on Windows we're
sure that WToolkit can run even without a UI session. Is it also true on
Mac? Did you try to launch AWT without -Djava.awt.headless=true from
remote console with no users logged in?

Thanks,

Artem

On 10/22/2013 7:34 AM, David DeHaven wrote:


Updated webrev for JDK (hotspot change is the same):
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/

Changes since last version:
- Moved to jdk8/build/jdk to save someone a merge headache, moved
changes to CompileNativeLibs.gmk to libs/Awt2dLibraries.gmk
- Removed HToolkit option and toolkit selection code from
java_props_macosx.[ch]

-DrD-



I want to do one more iteration of this. Based on feedback it seems I
can remove a bit more code from java_props_macosx.[ch] and make
things a bit cleaner.

-DrD-


Thanks guys.

Anthony, can you sponsor this for me?

-DrD-


This fix looks fine to me as well.

--
best regards,
Anthony

On 10/20/2013 11:56 PM, David DeHaven wrote:


CCing: build-dev, macosx-port-dev, hotspot-dev

Request for review of JDK-8025673:
https://bugs.openjdk.java.net/browse/JDK-8025673

Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8025673/

This change disables building libawt_xawt.dylib and
libawt_headless.dylib on Mac since they are not used and not
supported. There are too many challenges (and not enough time) in
removing all X11 code from the Mac build at this time, so we're
deferring complete removal for later (will be covered by
JDK-8003900).

A small change to hotspot is required as it was looking for
libawt_xawt.dylib and if not found would set java.awt.headless to
true. Since we don't build a headless only JRE on Mac I just have
that method return false. I'm not sure how to handle changes to
hotspot, can it be pushed along with the jdk changes? Without that
change the Mac builds will be broken.

Significant build system changes, build-dev guys are encouraged to
comment...

I tried excluding all sun/awt/X11 classes in
CompileJavaClasses.gmk but that broke JNI header generation on
platforms still using X11 and I couldn't use the big list of
excluded files on Mac as that resulted in Java compilation errors,
so I just added some logic to exclude everything on Mac and left
the list in place everywhere else.

The changes to CompileNativeLibraries.gmk will port to
libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a
problem in the jdk8/build workspace where the build cannot find
symbols in JNI libs so that issue needs to be resolved first. I've
not had time to investigate that problem.


Question for the AWT team, we still have this in java_props_md.c:
458 PreferredToolkit prefToolkit = getPreferredToolkit();
459 if (prefToolkit == CToolkit) {
460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit";
461 } else {
462 // TODO: do we still need this?
463 sprops.awt_toolkit = "sun.awt.HToolkit";
464 }

Is that necessary? Since we're now using libawt_lwawt in both
headless and headful modes I would think we could remove the
HToolkit option, but I'm not 100% certain about that.


I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and
both seem to be working fine.

JPRT run for Mac is in progress, I will submit one for all other
platforms when it finishes building.

-DrD-

Re: RFR: JDK-8026966: Most native libs broken on mac in jdk8/build

[Anthony Petrov]

Hi Erik,

The fix looks good to me.

--
best regards,
Anthony

On 10/21/2013 07:08 PM, Erik Joelsson wrote:

"JDK-8025715: Split CompileNativeLibraries.gmk", caused (almost) all
libraries on macosx to be linked incorrectly. I propose we fix this by
removing an ugly hack for libJObjC.dylib, which was only put there to
make the new and old build be as similar as possible.

The result of this fix is that libObjC.dylib changes it's link line from:

-Xlinker -install_name -Xlinker /usr/local/lib/libJObjC.dylib

to:

-Xlinker -install_name -Xlinker @rpath/libJObjC.dylib

And the rest of the libraries get restored to their original link lines,
which look like the second line above.

Bug: https://bugs.openjdk.java.net/browse/JDK-8026966

Webrev: http://cr.openjdk.java.net/~erikj/8026966/webrev.jdk.01/

/Erik

Re: RFR: 8025673: Disable X11 AWT toolkit

[Anthony Petrov]

This fix looks fine to me as well.

--
best regards,
Anthony

On 10/20/2013 11:56 PM, David DeHaven wrote:


CCing: build-dev, macosx-port-dev, hotspot-dev

Request for review of JDK-8025673:
https://bugs.openjdk.java.net/browse/JDK-8025673

Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8025673/

This change disables building libawt_xawt.dylib and libawt_headless.dylib on 
Mac since they are not used and not supported. There are too many challenges 
(and not enough time) in removing all X11 code from the Mac build at this time, 
so we're deferring complete removal for later (will be covered by JDK-8003900).

A small change to hotspot is required as it was looking for libawt_xawt.dylib 
and if not found would set java.awt.headless to true. Since we don't build a 
headless only JRE on Mac I just have that method return false. I'm not sure how 
to handle changes to hotspot, can it be pushed along with the jdk changes? 
Without that change the Mac builds will be broken.

Significant build system changes, build-dev guys are encouraged to comment...

I tried excluding all sun/awt/X11 classes in CompileJavaClasses.gmk but that 
broke JNI header generation on platforms still using X11 and I couldn't use the 
big list of excluded files on Mac as that resulted in Java compilation errors, 
so I just added some logic to exclude everything on Mac and left the list in 
place everywhere else.

The changes to CompileNativeLibraries.gmk will port to 
libs/AwtJava2dLibraries.gmk in jdk8/build, however there is a problem in the 
jdk8/build workspace where the build cannot find symbols in JNI libs so that 
issue needs to be resolved first. I've not had time to investigate that problem.


Question for the AWT team, we still have this in java_props_md.c:
  458 PreferredToolkit prefToolkit = getPreferredToolkit();
  459 if (prefToolkit == CToolkit) {
  460 sprops.awt_toolkit = "sun.lwawt.macosx.LWCToolkit";
  461 } else {
  462 // TODO: do we still need this?
  463 sprops.awt_toolkit = "sun.awt.HToolkit";
  464 }

Is that necessary? Since we're now using libawt_lwawt in both headless and 
headful modes I would think we could remove the HToolkit option, but I'm not 
100% certain about that.


I've built and tested on Mac and a Linux VM (Ubuntu 12.04) and both seem to be 
working fine.

JPRT run for Mac is in progress, I will submit one for all other platforms when 
it finishes building.

-DrD-

Re: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated

[Anthony Petrov]

Hi David,

The fix looks fine to me.

--
best regards,
Anthony

On 10/20/2013 11:53 PM, David DeHaven wrote:


CCing: build-dev, macosx-port-dev

Request for review of JDK-8016096:
https://bugs.openjdk.java.net/browse/JDK-8016096

Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8016096/

Significant build system changes for this one so feedback from build-dev is 
appreciated. Actual functional changes are just ported from the JDK7 changes I 
made several months ago, less the X11 dependency in jawt_md.h. The autoconf 
changes also trigger an update of generated-configure.sh in jdk/make/closed, 
that will need to be pushed too.


Please note:
These patches will not work alone! You must also apply the patches for 8025673, 
which I'm also submitting for review.


Built and tested on Mac and Linux. I'm in the process of submitting JPRT runs.

-DrD-

Re: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

[Anthony Petrov]

The fix looks fine to me.

--
best regards,
Anthony

On 10/01/2013 09:39 AM, dmitry markov wrote:

Hello,

Could you review a back-port of 7129133 to JDK 7u, please? The back-port
and the main fix integrated into jdk8 are slightly different.

bug: http://bugs.sun.com/view_bug.do?bug_id=7129133
webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/
jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3
technical review for jdk8:
http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005450.html

Thanks,
Dmitry

Re: RFR: 8023216: Feedback on README-builds.html

[Anthony Petrov]

Hi Erik,

The fix looks fine to me.

--
best regards,
Anthony

On 08/19/13 16:43, Erik Joelsson wrote:

And again, here we go:

http://cr.openjdk.java.net/~erikj/8023216/webrev.root.01/

/Erik

On 2013-08-19 11:05, Erik Joelsson wrote:

Thanks for the feedback!

I took most of it and made into a change. Also removed some obsolete
parts that I stumbled over.

Warn is supposed to be quiet, but at least hotspot is still being
quite noisy.

/Erik

On 2013-08-06 01:18, Dan Smith wrote:

I'm building for the first time under the new infrastructure (late to
the party, I know). I appreciate the comprehensive readme page.
Here's a list of minor points of feedback:

"The set of repositories and what they contain": need to add nashorn

"warn — Default and very quiet": I presume this is still an
in-progress goal? I'm seeing almost 3000 lines of text in a fresh
build (including over 1000 from 'images')

---

Some copy editing:

"each repository is it's own independent repository": it's -> its

"Insure that GNU make": insure -> ensure

"rather thane excludes": thane -> than

"Other depends on pieces of code": other depends -> others depend

"for all classes that contains constants": contains -> contain

"we have missed to add support": missed -> neglected

Re: RFR: 8015759: hotspot changes needed to compile with Visual Studio 2012

[Anthony Petrov]

-servertest
windows_x64-product-c2-servertest
windows_i586-fastdebug-c2-internalvmtests
windows_x64-fastdebug-c2-internalvmtests
windows_i586-product-c2-wbapitest
windows_i586-fastdebug-c2-wbapitest
windows_x64-product-c2-wbapitest
windows_x64-fastdebug-c2-wbapitest
windows_i586-product-c1-wbapitest
windows_i586-fastdebug-c1-wbapitest


On 06/ 3/13 06:41 AM, Daniel D. Daugherty wrote:

On 6/1/13 11:02 AM, Tim Bell wrote:

8015759: hotspot changes needed to compile with Visual Studio 2012

The bug report will be visible in a few days here:
http://bugs.sun.com/view_bug.do?bug_id=8015759

Minor Makefile changes and one source file was touched to compile
with Visual Studio 2012. These changes also compile under
Visual Studio 2010 with no problem so we can upgrade gracefully.
Tested by building the forest with both compilers.

% hg status
M make/windows/makefiles/compile.make


same question about the STATIC_CPPLIB stuff as David H.



M make/windows/makefiles/sanity.make


No comments.



M make/windows/makefiles/vm.make


Same question about the new 'ifdef DEVELOP' change as David H.

Sanity check: The patch shows this change:

# Special case files not using precompiled header files.

-c1_RInfo_$(Platform_arch).obj:
$(WorkSpace)\src\cpu\$(Platform_arch)\vm\c1_RInfo_$(Platform_arch).cpp
+c1_RInfo_$(Platform_arch).obj:
$(WorkSpace)\src\cpu\$(Platform_arch)\vm\c1_RInfo_$(Platform_arch).cpp
$(CXX) $(CXX_FLAGS) $(CXX_DONT_USE_PCH) /c
$(WorkSpace)\src\cpu\$(Platform_arch)\vm\c1_RInfo_$(Platform_arch).cpp

But I don't see a change. And this diff doesn't show up in the
other views. Oh wait, there's a blank at the end of the '+'
line...


M src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp


No comments.

Dan




webrev and patch file are here:

http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/
http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/hotspot.patch


Thanks to Anthony Petrov who provided the initial set of patches for
this work.

I believe this should go in via the hotspot-rt forest (let me know if
that is not correct), in which case I will need a sponsor from that
team to push the change.

Thanks in advance-
Tim

Re: How to debug assert failure in awt.dll?

[Anthony Petrov]

On 07/10/2013 06:02 PM, Pete Brunet wrote:

On 7/10/13 8:57 AM, Pete Brunet wrote:

On 7/10/13 2:59 AM, Anthony Petrov wrote:

This is a known issue http://bugs.sun.com/view_bug.do?bug_id=8013849
Looks like it's unrelated to a11y and affects any apps with input boxes.

Thanks Anthony, You are right; it is not a11y related.  Is there a bug I
can edit?  I'll add more info:


Just open up the bug in JBS, and you'll be able to edit it. I don't post 
a JBS link here on the public mailing list because the JBS isn't public yet.




- it fails on 7udev
- it fails in SwingSet2 in the combo box demo when focus is on the
ComboBox Demo tab and the tab key is pressed to change focus into the
first non-edit combo box.

It turns out I get that failure whenever pressing the tab key.  I didn't
extensively test but I got it when tabbing to several different controls.

I'm not an expert in debugging with VS, but I suppose it wants the
.pdb file for the awt.dll. Try locating this file in the build/
directory and point the VS debugger to it. You should also point VS to
the sources directory (which is jdk/src/windows/native/sun/windows/).

I tried that (see below) with no luck.


Perhaps VS needs some more debugging files. Did you try to attach to the 
java.exe process from the VS debugger before you're hitting the breakpoint?


Anyway, I'm also CC'ing Alexey who could provide some more tips on 
debugging with VS.


--
best regards,
Anthony


--
best regards,
Anthony

On 07/10/2013 02:01 AM, Pete Brunet wrote:

Using code cloned from yesterday, I built the jdk portion of the 7u-dev
forest using the debug target and the 7u45 import and am getting an
assert failure in Hashtable.cpp when accessibility is enabled.  This is
a 32 bit build using a 32 bit import.

Letting the execution transition into the debugger stops pointing at
awt.dll.

How do I debug this?  Assuming having debug symbols would help, I set
the Visual Studio debugger symbols dialog to point at either of these
two directories but the debugger fails to find the symbols:
jdk7u-dev\jdk\build\windows-i586\tmp\sun\sun.awt\awt\obj_g or obj_gO.

Pete

Re: How to debug assert failure in awt.dll?

[Anthony Petrov]

This is a known issue http://bugs.sun.com/view_bug.do?bug_id=8013849
Looks like it's unrelated to a11y and affects any apps with input boxes.

I'm not an expert in debugging with VS, but I suppose it wants the .pdb 
file for the awt.dll. Try locating this file in the build/ directory and 
point the VS debugger to it. You should also point VS to the sources 
directory (which is jdk/src/windows/native/sun/windows/).


--
best regards,
Anthony

On 07/10/2013 02:01 AM, Pete Brunet wrote:

Using code cloned from yesterday, I built the jdk portion of the 7u-dev
forest using the debug target and the 7u45 import and am getting an
assert failure in Hashtable.cpp when accessibility is enabled.  This is
a 32 bit build using a 32 bit import.

Letting the execution transition into the debugger stops pointing at
awt.dll.

How do I debug this?  Assuming having debug symbols would help, I set
the Visual Studio debugger symbols dialog to point at either of these
two directories but the debugger fails to find the symbols:
jdk7u-dev\jdk\build\windows-i586\tmp\sun\sun.awt\awt\obj_g or obj_gO.

Pete

Re: RFR: 8015759: hotspot changes needed to compile with Visual Studio 2012

[Anthony Petrov]

Tim:
Thanks for fixing this! The changes look good to me. The only minor 
concern is with the following:


make/windows/makefiles/vm.make

 143 # VS2012 requires this object file to be listed:
 144 LD_FLAGS=$(LD_FLAGS) _build_pch_file.obj


I'm not sure if this is a VS2010- compatible change. There were some 
problems with this _build_pch_file.obj, but I can't recall the details. 
Can we make this conditional, like !if "$(MSC_VER)" >= "1700"?



David:
The _STATIC_CPPLIB not working means that the msvcp110.dll (C++ Runtime) 
needs to be redistributed along with the msvcr110.dll (C Runtime). Since 
both JDK and HotSpot (and FX, for that matter) use C++ libraries, it 
seems reasonable to redistribute this dll.


--
best regards,
Anthony

On 06/03/13 10:13, David Holmes wrote:

Hi Tim,

In compile.make:

Please update copyright end year to 2013 (hotspot-runtime process rule).

I'm wondering what the impact is of not being able to use
_STATIC_CPPLIB? Given it has been deprecated for a while was it actually
a no-op? We need to understand what impact this has, if any, on the
built bits.

---

In sanity.make:

Please update copyright end year to 2013

---

In vm.make this addition seems unrelated to a compiler change:

!ifdef RELEASE
+ !ifdef DEVELOP
+ CXX_FLAGS=$(CXX_FLAGS) /D "DEBUG"
+ !else
CXX_FLAGS=$(CXX_FLAGS) /D "PRODUCT"
+ !endif
!else
CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT"
!endif

What is a RELEASE+DEVELOP build? Further I would expect that any build
that sets DEBUG should also set ASSERT ??

---

In unwind_windows_x86.hpp

Please update copyright end year to 2013

---

I'd be happy to sponsor the push into hotspot-rt once this is finalized.
Just create the changeset and send me a link to it.

Thanks,
David

On 2/06/2013 3:02 AM, Tim Bell wrote:

8015759: hotspot changes needed to compile with Visual Studio 2012

The bug report will be visible in a few days here:
http://bugs.sun.com/view_bug.do?bug_id=8015759

Minor Makefile changes and one source file was touched to compile with
Visual Studio 2012. These changes also compile under
Visual Studio 2010 with no problem so we can upgrade gracefully. Tested
by building the forest with both compilers.

% hg status
M make/windows/makefiles/compile.make
M make/windows/makefiles/sanity.make
M make/windows/makefiles/vm.make
M src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp

webrev and patch file are here:

http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/
http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/hotspot.patch

Thanks to Anthony Petrov who provided the initial set of patches for
this work.

I believe this should go in via the hotspot-rt forest (let me know if
that is not correct), in which case I will need a sponsor from that team
to push the change.

Thanks in advance-
Tim

Re: Somewhat wonkier Windows problem

[Anthony Petrov]

[ adding 2d-dev@ ]

On 05/24/2013 11:23 AM, Erik Joelsson wrote:

On 2013-05-23 20:10, David Chase wrote:

One change to add (a by-hand "diff") to
common/autoconf/toolchain_windows.m4 :

   AC_MSG_CHECKING([for DirectX SDK lib dir])
   if test "x$with_dxsdk_lib" != x; then
 DXSDK_LIB_PATH="$with_dxsdk_lib"
   elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
 DXSDK_LIB_PATH="$dxsdk_path/Lib/x64"
+  elif test -d "$dxsdk_path/Lib/x86"; then
+DXSDK_LIB_PATH="$dxsdk_path/Lib/x86"
   else
 DXSDK_LIB_PATH="$dxsdk_path/Lib"
   fi

This allows 32-bit configure with DirectX SDK 2010.
This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't
seen it yet.


Yes, newer directx sdks have that subdir while the only one we support
doesn't. That's why I didn't add that check. The 2d team is quite
adamant about that being the only working directx sdk and any talk about
changing it should be with them, not the build team.


We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may (in 
theory) cause some differences in  rendering graphics. Note that in 
practice I don't recall if anyone has ever seen any actual differences. 
However, when fixing e.g. 2D bugs, it is important that developers use 
the proper version of DXSDK for their developer builds to make sure they 
reproduce the actual issue. In all other cases the version of DXSDK 
doesn't really matter.


I don't see how this translates to DXSDK 2004 "being the only working 
directx sdk". I believe that the changes proposed by David are 
reasonable and should be implemented to allow the OpenJDK community 
build with any version of DXSDK.




If we want to change directx sdk, we should first consider removing the
dependency completely since technically, everything that's needed is
installed with visual studio and/or the normal windows sdk.


I agree, this is a good idea. And this is exactly something that the 2D 
team should decide. However, I believe that the above patch could be 
applied to OpenJDK as an interim solution before the decision is made.


--
best regards,
Anthony



/Erik

It built, I ran an applet demo, so some minor success there, too.

I'm keeping notes on what works.

More later.

David

Re: Somewhat wonkier Windows problem

[Anthony Petrov]

Hi Volker,

I agree completely. As I wrote in my reply to David - fixes in this area 
are very much welcome. Adding additional and/or alternative instructions 
and tips to the BUILD-README file is also a fix, btw.


--
best regards,
Anthony

On 05/23/13 18:00, Volker Simonis wrote:

Hi Anthony,

I think what David is really objecting here is that the current build
requirements for building OpenJDK 8 on Windows as described in the
official build documentation can not be easily fulfilled by anybody
outside Oracle (because of age-old dependencies which simply aren't
publicly available anymore and which can not be easily provided by the
OpenJDK project itself because of licensing issues - e.g. "DirectX 9.0
SDK Update Summer 2004", Cygwin 1.7.16, etc...).

Of course it is possible to finally build with almost any combination of
tools and libraries given that you invest enough time and resources and
of course after you succeed in doing so you got wiser a little bit. But
that's not the point! Ideally, everybody should be able to get the
required build dependencies as easy as the JDK sources and after
installing them as described in the build documentation he should be
able to build. That's currently not the case - at least not on Windows!

The problem is that Oracle nails down the build requirements years
before a Java version is released and these requirements are carved into
stone in the official build documentation. That's perfectly fine for a
commercially released product which has to run on a variety of different
platforms and which has to be supported for a long period of time - but
not for an OpenSource project!

I've been criticized for my suggestion to put (at least a part of) the
build documentation into a Wiki in order to get a chance to update it
more dynamically. From a software engineering standpoint that criticism
was perfectly valid. From a pragmatic point of view perhaps not. Anyway
- if we want to keep the build instructions in the repository in a
central document (which is good!), than this document should really
reflect the current situation and not the the instructions how Oracle
once decided to build its derived, commercial product. I understand that
Oracle may not want to be responsible to provide such a kind of document
and that's perfectly fine. After all this is an open source project so
the community may have to be involved here - we just have to make this
fact clear to anybody.

Currently, unfortunately,  all these notable Windows build adventures
more than often lead to a dead-end (just browse the mailing lists!) or
at best in a blog entry which describes a special, working setup (been
there several time myself:)

Nevertheless David, you have my full moral support!

Regards,
Volker



On Thu, May 23, 2013 at 3:09 PM, Anthony Petrov
mailto:anthony.pet...@oracle.com>> wrote:

David,

I pretty much understand the problem you're trying to solve. I
recall myself in 2006-2007 when I was eagerly wanting to build
(then) JDK 6 with VS2005 while we officially used VS2003. It was
fun. :) Later on we ended up switching to VS2010 for JDK7, however
some results of my work still were useful and relevant, and they
made their way to the JDK repo (some make files changes,
command-line options for the compiler, minor code changes, etc.)

So if you come up with some useful fixes for our new build system
and/or sources to provide better support for newer
compilers/libraries - it's great!

FWIW, I did build JDK8 with VS2012 back in Oct/Nov last year. I've
run a few GUI demo apps (SwingSet2 and friends) and they all worked
just fine. Only some make files needed some minor updates in order
to learn to use the new compilers. Overall, switching from VS2010 to
VS2012 shouldn't be hard.

--
best regards,
Anthony


On 05/23/13 16:47, David Chase wrote:

I think you need to understand the problem I'm after --
currently, our public instructions for third-party OpenJDK (8)
builds don't work.
They don't build at all, so porting is completely out of the
question.  I'm trying to come up with instructions that will at
least build something that will run on the machine where it is
built.

Regarding the DirectX compatibility, that sounds like something
we should be repairing in the builds, so that we can cut our
dependence on a 9-year-old release of the DirectX SDK.

Note also that some of these newer DirectX SDKs (certainly April
2006) will mess up your %PATH% by inserting elements on it that
include quoted strings, and those you will need to remove
manually.  I will do the experiment to see if the 2010 release
does not do this, since "repair your path after installing
required software" is a good step not to have in

Re: Somewhat wonkier Windows problem

[Anthony Petrov]

David,

I pretty much understand the problem you're trying to solve. I recall 
myself in 2006-2007 when I was eagerly wanting to build (then) JDK 6 
with VS2005 while we officially used VS2003. It was fun. :) Later on we 
ended up switching to VS2010 for JDK7, however some results of my work 
still were useful and relevant, and they made their way to the JDK repo 
(some make files changes, command-line options for the compiler, minor 
code changes, etc.)


So if you come up with some useful fixes for our new build system and/or 
sources to provide better support for newer compilers/libraries - it's 
great!


FWIW, I did build JDK8 with VS2012 back in Oct/Nov last year. I've run a 
few GUI demo apps (SwingSet2 and friends) and they all worked just fine. 
Only some make files needed some minor updates in order to learn to use 
the new compilers. Overall, switching from VS2010 to VS2012 shouldn't be 
hard.


--
best regards,
Anthony

On 05/23/13 16:47, David Chase wrote:

I think you need to understand the problem I'm after -- currently, our public 
instructions for third-party OpenJDK (8) builds don't work.
They don't build at all, so porting is completely out of the question.  I'm 
trying to come up with instructions that will at least build something that 
will run on the machine where it is built.

Regarding the DirectX compatibility, that sounds like something we should be 
repairing in the builds, so that we can cut our dependence on a 9-year-old 
release of the DirectX SDK.

Note also that some of these newer DirectX SDKs (certainly April 2006) will mess up your 
%PATH% by inserting elements on it that include quoted strings, and those you will need 
to remove manually.  I will do the experiment to see if the 2010 release does not do 
this, since "repair your path after installing required software" is a good 
step not to have in any build process.

On 2013-05-23, at 8:08 AM, Anthony Petrov  wrote:


Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to make them 
compatible with XP.

Yes, we don't officially support JDK8 on Windows XP. However, there's a 
difference between _not supported_ and _just won't run_.

Hence, if we ever decide to switch to VS2012, we'll most likely want to use 
VS2012sp1+.

Re: Somewhat wonkier Windows problem

[Anthony Petrov]

David,

I have worked around the compatibility of latest DirectX SDK and 32-bit 
JDK builds by copying the contents of the \Program Files\Microsoft 
DirectX SDK\Lib\x86\* to the Lib\ directory itself. Works like a charm.


--
best regards,
Anthony

On 05/23/13 07:13, David Chase wrote:

I think that there is a 64-bit compiler in there, though it seems to not be the 
default.
I saw three different command-line choices, and one is 64-bit, which I am using.

The available copies of the DirectX SDK (later than 2004) were not recognized 
as 32-bit
by configure -- doesn't mean that they're not, it just decided that they were 
64-bit given
its current state, so I had to see if I could find a 64-bit compiler.

I can supply more details tomorrow, and check a little harder to ensure it 
really is 64-bit.

David

On 2013-05-22, at 8:44 PM, Tim Bell  wrote:


It has also been reported that the free VS2012 'Express' edition does not 
include the 64-bit compiler, so you will be able to build 32-bit only.   I have 
not verified that.

Re: Somewhat wonkier Windows problem

[Anthony Petrov]

Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to 
make them compatible with XP.


Yes, we don't officially support JDK8 on Windows XP. However, there's a 
difference between _not supported_ and _just won't run_.


Hence, if we ever decide to switch to VS2012, we'll most likely want to 
use VS2012sp1+.


--
best regards,
Anthony

On 05/23/13 03:54, Kelly O'Hair wrote:

If you accept the fact that the build may complete but not work, then fine.
But if you want the JDK you built to actually run, you will probably need to 
get the new msvcr*dll files placed in the jdk image area (in the bin dirs), 
manually or via the makefiles.

I also vaguely recall some silly thing with VS2012 that it was for Windows 8 
only and you needed VS2012sp1 to be able to build for Windows releases before 
Windows 8?  I'm not sure I remember that right. :^(

-kto

On May 22, 2013, at 4:27 PM, David Chase wrote:


I hope I'm trying to solve a simpler problem, which is just a build, as if I 
were someone outside Oracle playing with Openjdk.  I assume my problems are a 
subset of the release problem.

David

On 2013-05-22, at 6:53 PM, Kelly O'Hair  wrote:


Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, 
which we must deliver with the JDK, so the build process has to know what that 
DLL is named, where it is located, and copy it into various places.

DLLs created by a newer VS will not like the older VS runtime DLLs.

To make a long story short, changing VS compilers is a royal pain, and not 
trivial.
This is why we only recommend VS2010.

I'm not saying it cannot be done, I'm just saying you should have plenty of 
liquor available when you do it. :^(

-kto

Re: Found and solved a bug on Cursor Management on Windows platforms

[Anthony Petrov]

Hi Morvan,

build-dev@ is the wrong mailing list for this topic. It belongs to 
awt-...@openjdk.java.net only. Please re-post this message there.


--
best regards,
Anthony

On 04/17/2013 09:01 PM, Morvan Le Mescam wrote:

Dear all,

When developping a Swing client, I face the following problem :
When setting the hand cursor on Windows, I noticed that the default system
cursor was not used.

I analysed the problem and found the rrot cause.
I also made a correction and tested it on Windows 7.

This is my analyse :

When reading Java source code, it is obvious that on Windows, Java does not
use System resources.

In the code (from *jdk\src\windows\native\sun\windows\awt_Cursor.cpp* )
bellow :

AwtCursor * AwtCursor::*CreateSystemCursor*(jobject jCursor)

{

 JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);



 jint type = env->GetIntField(jCursor, AwtCursor::typeID);

 DASSERT(type != java_awt_Cursor_CUSTOM_CURSOR);



 LPCTSTR winCursor;

 switch (type) {

   case java_awt_Cursor_DEFAULT_CURSOR:

   default:

 winCursor = IDC_ARROW;

 break;

   case java_awt_Cursor_CROSSHAIR_CURSOR:

 winCursor = IDC_CROSS;

 break;

*[…]*

*  case java_awt_Cursor_HAND_CURSOR:*

*winCursor = TEXT("HAND_CURSOR");*

*break;*

   case java_awt_Cursor_MOVE_CURSOR:

 winCursor = IDC_SIZEALL;

 break;

 }

*HCURSOR hCursor = ::LoadCursor(NULL, winCursor);*

 if (*hCursor == NULL*) {

 /* Not a system cursor, check for resource. */

 *hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),
*

*   winCursor);*

 }

 if (hCursor == NULL) {

 hCursor = ::LoadCursor(NULL, IDC_ARROW);

 DASSERT(hCursor != NULL);

 }



 AwtCursor *awtCursor = new AwtCursor(env, hCursor, jCursor);

 setPData(jCursor, ptr_to_jlong(awtCursor));



 return awtCursor;

}



In the case of the HAND_CURSOR (*in red*),  Java will try to load the
cursor from the system (*in blue*).

If it fails (*hCursor == NULL*) then it will try to load the cursor from
its own resource (*in orange*) :

*hCursor = ::LoadCursor(AwtToolkit::GetInstance().GetModuleHandle(),*

*   winCursor);*



In our case, if we check in the AWTToolkit module resources, in *
jdk\src\windows\native\sun\windows\awr.rc*, we find the following content :

#include "windows.h"



// Need 2 defines so macro argument to XSTR will get expanded before
quoting.

#define XSTR(x) STR(x)

#define STR(x)  #x



LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL



*HAND_CURSOR  CURSOR  DISCARDABLE "hand.cur"*

AWT_ICON ICONDISCARDABLE "awt.ico"

CHECK_BITMAP BITMAP  DISCARDABLE "check.bmp"



And we find that java.exe embed its own hand cursor, in *
jdk\src\windows\native\sun\windows\hand.cur* : The “famous” hand that it is
displayed instead of our system cursor.


This is the correction :

, I made the correction into the JRE source code :

   case java_awt_Cursor_HAND_CURSOR:

 /* MLM change winCursor = TEXT("HAND_CURSOR"); */

 winCursor = IDC_HAND;

 break;

I could compile and regenerate a JRE with this change :

D:\Work\Current\openjdk\build\windows-amd64\bin>java -version

openjdk version "1.7.0-u6-unofficial"

OpenJDK Runtime Environment (build 1.7.0-u6-unofficial-b24)

OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)





And this works !

If I change the hand cursor at System level, Java takes it into account.
Last but not least question:

Why did a Sun developper, one day :  winCursor = TEXT("HAND_CURSOR");

This seems so not consistent with other part of the code... So there is
probably a good reason. Perhaps the hand cursor was not existant on Windows
platform when this was done ?


Regards


Morvan

Re: A couple of questions about the new build system

[Anthony Petrov]

You can't feed make with the /showInclude output. There's a dedicated 
tool in Cygwin (and on *NIX in general) - makedepend. It produces output 
that make can parse and understand directly.


--
best regards,
Anthony

On 4/8/2013 20:00, Kelly O'Hair wrote:

I think it's /showIncludes ???
http://msdn.microsoft.com/en-us/library/hdkef6tk%28v=vs.100%29.aspx

-kto


On 4/8/13 1:16 AM, "Erik Joelsson"  wrote:


I just realized you are probably running on windows and unfortunately
this currently doesn't work there. We use the -M flag for gcc which
outputs make dependency files. The visual studio compiler doesn't have
this feature. There are ways this can be worked around. I've created
8011687 to track this issue.

/Erik

On 2013-04-02 10:16, Erik Joelsson wrote:


On 2013-03-29 00:00, Phil Race wrote:

If you touch a header fie, the build is supposed to notice and "do

the right thing".

It did not do so. If I touched a C file, no problem, but not so for
the header file.
This was observed on Solaris 10 SPARC.


I just tried:
touch ../../jdk/src/share/native/sun/font/fontscalerdefs.h
make LOG=info

which resulted in the following:

...
## Starting jdk
Compiling AccelGlyphCache.c (for libawt_xawt.so)
Compiling OGLTextRenderer.c (for libawt_xawt.so)
Compiling X11FontScaler_md.c (for libawt_xawt.so)
Compiling XRBackendNative.c (for libawt_xawt.so)
Compiling DrawGlyphList.c (for libfontmanager.so)
Compiling FontInstanceAdapter.cpp (for libfontmanager.so)
Compiling SunLayoutEngine.cpp (for libfontmanager.so)
Compiling X11FontScaler.c (for libfontmanager.so)
Compiling sunFont.c (for libfontmanager.so)

/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/layo
ut/SunLayoutEngine.cpp:
In function ‘void Java_sun_font_SunLayoutEngine_nativeLayout(JNIEnv*,
_jclass*, _jobject*, _jobject*, _jfloatArray*, jint, jint,
_jcharArray*, jint, jint, jint, jint, jint, jint, jint, _jobject*,
_jobject*, jlong, jlong)’:

/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/layo
ut/SunLayoutEngine.cpp:190:
warning: comparison between signed and unsigned integer expressions
Compiling GeneralPath.cpp (for libt2k.so)
Compiling scalerMethods.c (for libt2k.so)
Compiling t2kScalerMethods.cpp (for libt2k.so)
Compiling AccelGlyphCache.c (for libawt_headless.so)

/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
ont.c: 
In function ‘Java_sun_font_StrikeCache_freeIntPointer’:


/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
ont.c:196: 
warning: cast to pointer from integer of different size


/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
ont.c: 
In function ‘Java_sun_font_StrikeCache_freeIntMemory’:


/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
ont.c:234: 
warning: cast to pointer from integer of different size

Compiling X11FontScaler_md.c (for libawt_headless.so)
Linking libawt_xawt.so
Linking libfontmanager.so
Linking libawt_headless.so
Linking libt2k.so
Linking libjawt.so
...

Note that the default verbosity doesn't print anything when compiling
native code. You need to increase it to "info" to see what gets
recompiled.

If this doesn't work for you, it's a bug that needs to be investigated.

/Erik


-phil.

On 3/28/2013 2:45 PM, Jonathan Gibbons wrote:

On 03/28/2013 02:29 PM, Phil Race wrote:

1. Why do we have both --with-cups and --with-cups-include ?
All we use is the header files so the latter is what matters and
I'm not sure which one the build system prefers if both are set.

2. In the old build I could do
cd make/sun/font
make clean
make all

Is there anything analagous to 'make clean' here,where I can have a
level of comfort
that all generated files related to building just a particular area
are removed.
This was useful after I touched a header file.
Now when I touch a header file, the new build system doesn't notice,
so I have to manually purge, but nor does it (as far as I can see)
give me
a target to purge that component. To do this I need to go hunt down
the directory with the object files and remove them.
Is there something better I can do ?

-phil.


If you touch a header fie, the build is supposed to notice and "do
the right thing".

-- Jon

Re: RFR: 8010465: Can't enable sjavac when building in jprt.

[Anthony Petrov]

Good to know this is unrelated to this fix. Thanks.

--
best regards,
Anthony

On 4/8/2013 17:21, Erik Joelsson wrote:



On 2013-04-08 15:17, Anthony Petrov wrote:

Thanks for clarifying that. Makes sense to me.

The fix looks good to me, btw, although I'm not a build expert.

Also, could you clarify why do Windows builds fail with sjavac? Is 
this a known bug in sjavac or the build system?



It looks to me like a bug in sjavac. I have seen it work previously.

/Erik

--
best regards,
Anthony

On 04/08/13 17:03, Erik Joelsson wrote:

Sjavac also enables parallel execution of java compilation, speeding up
full builds as well. But even if it didn't, being able to verify that
sjavac builds work in jprt will be a must if we are to enable it by
default.

/Erik

On 2013-04-08 14:56, Anthony Petrov wrote:

Just curious: sjavac is supposed to address the issue with slow
incremental builds. JPRT builds are full builds usually. What is the
benefit of using sjavac for full builds?

--
best regards,
Anthony

On 04/08/13 13:44, Erik Joelsson wrote:

Reminder that I would like this reviewed.

/Erik

On 2013-03-21 12:49, Erik Joelsson wrote:

This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command
line.

http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/

Doing this uncovered another bug. Adding the keyword "nofile" to the
LOG variable is done to disable logging build output to a file. JPRT
does this on all build runs since it already saves the build output.
The value of LOG is also sent to sjavac to help it filter its output,
but sjavac does not accept "nofile" as input. The logic to remove
"nofile" before sending it to sjavac didn't work and is also fixed in
this patch.

The sad news is that all the windows builds currently fail with 
sjavac

enabled, but having this feature will help us harden sjavac to the
point where we can make the switch.

/Erik

Re: RFR: 8010465: Can't enable sjavac when building in jprt.

[Anthony Petrov]

Thanks for clarifying that. Makes sense to me.

The fix looks good to me, btw, although I'm not a build expert.

Also, could you clarify why do Windows builds fail with sjavac? Is this 
a known bug in sjavac or the build system?


--
best regards,
Anthony

On 04/08/13 17:03, Erik Joelsson wrote:

Sjavac also enables parallel execution of java compilation, speeding up
full builds as well. But even if it didn't, being able to verify that
sjavac builds work in jprt will be a must if we are to enable it by
default.

/Erik

On 2013-04-08 14:56, Anthony Petrov wrote:

Just curious: sjavac is supposed to address the issue with slow
incremental builds. JPRT builds are full builds usually. What is the
benefit of using sjavac for full builds?

--
best regards,
Anthony

On 04/08/13 13:44, Erik Joelsson wrote:

Reminder that I would like this reviewed.

/Erik

On 2013-03-21 12:49, Erik Joelsson wrote:

This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command
line.

http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/

Doing this uncovered another bug. Adding the keyword "nofile" to the
LOG variable is done to disable logging build output to a file. JPRT
does this on all build runs since it already saves the build output.
The value of LOG is also sent to sjavac to help it filter its output,
but sjavac does not accept "nofile" as input. The logic to remove
"nofile" before sending it to sjavac didn't work and is also fixed in
this patch.

The sad news is that all the windows builds currently fail with sjavac
enabled, but having this feature will help us harden sjavac to the
point where we can make the switch.

/Erik

Re: RFR: 8010465: Can't enable sjavac when building in jprt.

[Anthony Petrov]

Just curious: sjavac is supposed to address the issue with slow 
incremental builds. JPRT builds are full builds usually. What is the 
benefit of using sjavac for full builds?


--
best regards,
Anthony

On 04/08/13 13:44, Erik Joelsson wrote:

Reminder that I would like this reviewed.

/Erik

On 2013-03-21 12:49, Erik Joelsson wrote:

This patch makes it possible to enable sjavac in jprt runs. This is
achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command line.

http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/

Doing this uncovered another bug. Adding the keyword "nofile" to the
LOG variable is done to disable logging build output to a file. JPRT
does this on all build runs since it already saves the build output.
The value of LOG is also sent to sjavac to help it filter its output,
but sjavac does not accept "nofile" as input. The logic to remove
"nofile" before sending it to sjavac didn't work and is also fixed in
this patch.

The sad news is that all the windows builds currently fail with sjavac
enabled, but having this feature will help us harden sjavac to the
point where we can make the switch.

/Erik

Re: recent problems with JFX ant script

[Anthony Petrov]

It's a known issue:

http://javafx-jira.kenai.com/browse/RT-27210

--
best regards,
Anthony

On 2/15/2013 0:32, Pete Brunet wrote:

I ran into two new problems building JFX on Win 7 this week:

1) I had to unset lowercase tmp and temp.  Apparently there is a new
problem with having duplicates, TMP/tmp and TEMP/temp.  This may be
related to http://www.cmake.org/Bug/print_bug_page.php?bug_id=13131

The failure appeared as:

launcher-win:
 [echo] STARTING: C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\devenv.com native/windows
 [echo] C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\devenv.com /build Release|Win32 IconSwap.vcxproj
 [exec]
 [exec] Microsoft (R) Visual Studio Version 10.0.30319.1.
 [exec] Copyright (coffee) Microsoft Corp. All rights reserved.
 [exec] 1>-- Build started: Project: IconSwap, Configuration:
Release Win32 --
 [exec] 1>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5):
error MSB6001: Invalid command line switch for "CL.exe". Item has
already been added. Key in dictionary: 'tmp'  Key being added: 'TMP'
 [exec] == Build: 0 succeeded, 1 failed, 0 up-to-date, 0
skipped ===

2) DEVENVDIR somehow gets unset.  I had to rerun vsvars.sh to fix it. 


This failure appeared as:

needs-devenv:
 [echo] Using
C:\Users\Pete\JavaFX\controls-RT-26343\jfx\rt-closed\glass\glass-mat-lib-windows\${windows.vs.DEVENVCMD}.

BUILD FAILED

Both of these showed up when building on Windows 7 which I haven't done
in a while.  I was just rerunning the ant script over and over after
source code changes.  I use ant -Dhudson.jfx.job.name=8.0-controls-scrum
sdk-no-docs

Since the problem is intermittent I supposed these could be related to
the combination of cygwin/Norton360.  I'll disable Norton auto-protect
for a while to see if that helps, but wanted to let others know of this
in case it's helpful.

Pete

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

[Anthony Petrov]

CC'ing awt-dev@, Yuri, and Artem.

--
best regards,
Anthony

On 11/29/12 18:27, Fredrik Öhrström wrote:

The GensrcX11Wrapper.gmk makefile creates a new sizes.32 or sizes.64 by
running a generated C program
that performs many sizeof calculations on X11 structures. This is cross
compileable.

Fortunately the sizes.32 and sizes.64 offset files are very stable. Thus
we can commit them to the
source code repository. When not cross compiling we perform a
verification step that
regenerates the offset file for the build platforms bits, and checks
that it is the same
as the committed version.

Patch is here:
http://cr.openjdk.java.net/~ohrstrom/webrev-8004151-gensrcX11wrapper/
(do not read the diff of the makefile, read the new makefile, too many
changes.)

Question: by always supplying both sizes.32 and sizes.64 to the
generator tool, it
seems like it is encoding both offsets into the java classes. This might
not always
have been done before. Good or bad?

//Fredrik

Re: [8] Review request for 8001764: vsvars.sh should support VS2012

[Anthony Petrov]

Tim, Kelly: thanks for your review. I'll push the fix via the awt forest 
tomorrow.


On 10/29/2012 8:29 PM, Tim Bell wrote:
We're not yet switching JDK builds to VS2012. However, the vsvars.sh 
script is useful for other applications in order to set up the build 
environment, so I think the proposed changes should be useful. Once we 
start using VS2012 (or VS2014, or whatever it will be) for JDK, the 
vsvars.sh will already support that.


Changing compilers needs to come down from the release team.  I hope you 
realize that.  If they do not make a decision soon, VS2012 or later will 
wait until JDK9.


That's correct. Currently we don't have any plans to change compilers 
for JDK 8. It will be discussed with the release team when need arises.


--
best regards,
Anthony

[8] Review request for 8001764: vsvars.sh should support VS2012

[Anthony Petrov]

Hello,

Please review a fix for 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001764 at:


http://cr.openjdk.java.net/~anthony/8-46-full-vs2012.0/

We're not yet switching JDK builds to VS2012. However, the vsvars.sh 
script is useful for other applications in order to set up the build 
environment, so I think the proposed changes should be useful. Once we 
start using VS2012 (or VS2014, or whatever it will be) for JDK, the 
vsvars.sh will already support that.


--
best regards,
Anthony

Re: Need reviewer for fix to Mac jdk partial builds

[Anthony Petrov]

Hi Kelly,

The JDK 8 partial repository (only the jdk itself) builds fine on my Mac 
with your changes. The fix looks good to me, although I don't have deep 
knowledge of the components being modified.


Thanks for fixing this issue!

--
best regards,
Anthony

On 9/20/2012 5:19 AM, Kelly O'Hair wrote:

7191703: jprt cannot build jdk on MacOSX.
http://cr.openjdk.java.net/~ohair/openjdk8/jobjc-fix/webrev/

Fixes a partial build issue with the jdk repo on the Mac.
If LANGTOOLS_DIST is defined, nothing changes and the ant script should find 
langtools/dist/classes.jar.
Otherwise, by running ant with the import jdk, it should build ok.

I very much dislike this logic but don't feel it is worth doing more than the 
minimum here.

-kto

Re: The future of partial builds

[Anthony Petrov]

The build times for incremental builds look awesome. Now I'm really 
looking forward to the new build system! Thanks!


Regarding partial builds: as long as the other components don't add 
dependencies that we didn't use to have before (when working on the jdk 
repo only), I guess it's all right, too.


--
best regards,
Anthony

On 09/13/12 00:32, Kelly O'Hair wrote:

Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the 
machine used (hardware vs. VM),
how many CPUs etc. But it's a bit erratic, depends on lots of things. We are 
still working around some CYGWIN issues.
The incremental builds should be similar. I don't have any numbers right now.

We hope we can get MinGW/MSYS working which might reduce the overall time by 
20% or more (a big guess)
(Remember MKS will not work with the new build-infra Makefiles).

Windows XP 32bit builds take a bit longer maybe 35mins?, but the XP systems 
have limited RAM and cpu capacity.
Solaris, Linux, and Mac builds are pretty consistent, but Windows is another 
story. :^(

What we have noticed is that a beefy PC running Windows XP can easily do 20min 
builds, but building in
an area that is immune from On-Access AntiVirus scanning or turning On-Access 
scanning off.

-kto

On Sep 12, 2012, at 11:52 AM, Igor Nekrestyanov wrote:


What about windows?

-igor

On 9/12/12 11:49 AM, Kelly O'Hair wrote:

Some stats on incremental builds. Not partial builds..

This is an older Solaris machine svc6.us.oracle.com, building the complete 
openjdk forest from scratch
for 64bit including images took less than 14 minutes (parallel build setting 
was 8) and images took 2mins of this 14mins:

-- Build times --
Target
Start 2012-09-12 10:56:17
End   2012-09-12 11:09:55
00:00:30 corba
00:04:51 hotspot
00:00:23 jaxp
00:00:33 jaxws
00:04:43 jdk
00:01:59 jdk-images
00:00:39 langtools
00:13:38 TOTAL
-

A repeated 'gmake images" with no changes took 31 seconds:

-- Build times --
Target
Start 2012-09-12 11:13:30
End   2012-09-12 11:14:01
00:00:02 corba
00:00:07 hotspot
00:00:02 jaxp
00:00:04 jaxws
00:00:08 jdk
00:00:07 jdk-images
00:00:01 langtools
00:00:31 TOTAL
-

I touched a few awt java sources  (touch jdk/src/share/classes/java/awt/*.java) 
and did just a 'gmake all' (no images)
and it took 2 minutes (this will improve significantly with smartjavac):

-- Build times --
Target
Start 2012-09-12 11:17:34
End   2012-09-12 11:19:32
00:00:00 corba
00:00:00 hotspot
00:00:00 jaxp
00:00:01 jaxws
00:01:56 jdk
00:00:01 langtools
00:01:58 TOTAL
-

I touched a few awt native sources (touch jdk/src/share/native/sun/awt/*/*.c) 
and did the 'gmake all' (no images)
and it took 37 seconds):

-- Build times --
Target
Start 2012-09-12 11:22:24
End   2012-09-12 11:23:01
00:00:00 corba
00:00:00 hotspot
00:00:00 jaxp
00:00:01 jaxws
00:00:35 jdk
00:00:01 langtools
00:00:37 TOTAL
-

So as far as incremental builds go, I think this is a vast improvement. And the 
incremental build should be accurate.

I'm not taking a position on partial builds here, just providing some hard data 
on full openjdk builds with the
new build-infra makefiles.

The above builds are complete openjdk builds, with no import jdk needed, and no 
concerns about
sync issues between jdk components (hotspot<->jdk).

-kto


On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote:


Magnus,

You've only explained how incremental builds could work for Java classes in the 
new build-infra. What about incremental builds of native code? E.g. in AWT we 
often do the following:

$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make

And this re-builds both AWT classes and AWT native code (and some 2D stuff too, 
btw). What has build-infra got to offer for incremental builds of native code?

Also, how fast are those incremental solutions (both the temporary, and the 
expected final one) in build-infra? Performing the above commands with the 
current build system takes literally just a few seconds on any platform (given 
you've built the JDK repo once before, and it might took like 10-30 minutes for 
the first build).

--
best regards,
Anthony

On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote:

On 2012-09-10 14:13, Alan Bateman wrote:

When you say "sub-directory builds" then I think you mean incremental builds, or "poor-man 
increment builds" as I call it. I think the majority of people working in the jdk repository, at least 
in Oracle, do this because they know the area and know which make files that re-build the files that they 
have changed. Incremental builds are generally not very reliable but seem to be "good enough" for 
most people needs, at least those that aren't doing significant refactoring. The main motive of course is to 
be able to re-build in a few seconds an

Re: The future of partial builds

[Anthony Petrov]

On 9/12/2012 1:54 PM, Alan Bateman wrote:

On 12/09/2012 06:46, Fredrik Öhrström wrote:

:
Excellent. I hope you realize how valuable it is that the build system 
recompiled the proper source files, then proceed to generate the the 
jni headers output
because of native methods in those classes that were recompiled, then 
proceed to recompile only the shared libraries that implement these 
jni interfaces.


Later we will make sure that if the recompile of the java source file 
does not change the jni header, it will not be updated/touched.


Have you tried making an actual change in a Java source file that 
changes the public api? To see how the build system recompiles all 
packages

that import from that changed package?
I am aware of how clever the new build is, too clever sometimes!! So 
when I removed the -Xprefer:source then it immediately detected my 
attempt at subterfuge:


  Dropping old javac_state since a new command line is used

In terms of timings then it reduced that specific incremental build case 
from 33 to 22s, which I think it getting into the right ball park.


That sounds promising. Thanks for testing this.

--
best regards,
Anthony

Re: The future of partial builds

[Anthony Petrov]

Magnus,

You've only explained how incremental builds could work for Java classes 
in the new build-infra. What about incremental builds of native code? 
E.g. in AWT we often do the following:


$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make

And this re-builds both AWT classes and AWT native code (and some 2D 
stuff too, btw). What has build-infra got to offer for incremental 
builds of native code?


Also, how fast are those incremental solutions (both the temporary, and 
the expected final one) in build-infra? Performing the above commands 
with the current build system takes literally just a few seconds on any 
platform (given you've built the JDK repo once before, and it might took 
like 10-30 minutes for the first build).


--
best regards,
Anthony

On 9/10/2012 6:00 PM, Magnus Ihse Bursie wrote:

On 2012-09-10 14:13, Alan Bateman wrote:
When you say "sub-directory builds" then I think you mean incremental 
builds, or "poor-man increment builds" as I call it. I think the 
majority of people working in the jdk repository, at least in Oracle, 
do this because they know the area and know which make files that 
re-build the files that they have changed. Incremental builds are 
generally not very reliable but seem to be "good enough" for most 
people needs, at least those that aren't doing significant 
refactoring. The main motive of course is to be able to re-build in a 
few seconds and the #1 goal of any new build system has to be fast 
incremental builds.


In the new build system, fast incremental builds of Java code is 
dependent on the new "smart javac", which unfortunately has still not 
proven stable enough to be enabled by default, even in the experimental 
build-infra forest. It is still our hope that it will turn out to be 
good enough to be used as default, but I don't want to trust hope alone.


As an interim solution, I have just created the following two shortcuts. 
Both of these bypass the proper dependency detection. This means that 
make will cut to the chase and recompile faster, but it also means that 
you need to take over the responsibility of making sure dependencies are 
correct. This is very similar to the "*-only" (e.g. hotspot-only) 
targets that are current available in the new build system.


First shortcut is to skip parts of the JDK makefile. By typing e.g. 
"make jdk JDK_TARGET=classes", the JDK build will stop after building 
the "classes" target (which compiles the majority of the JDK java 
files). An even faster, but less safe, version is "make jdk-only 
JDK_TARGET=classes-only", which will jump directly to the JDK Makefile, 
and only execute the "classes" target. In this way, absolutely no time 
is spent before starting to compile Java classes.


Second shortcut is to limit the classes that are recompiled by the JDK 
"classes" target. Currently, *all* (more or less) Java classes in the 
JDK is recompiled at once. While this speeds up things considerably at a 
first time compilation, it makes all subsequent builds take the same 
time. By specifying e.g. JDK_FILTER=java/nio, only files in the java/nio 
package will get compiled. This is, I think, similar (but not strictly 
not identical) to the effect of "sub-directory builds". It is possible 
to use an even more fine-grained filter, separated by comma, e.g. 
JDK_FILTER=java/nio/channels,java/nio/charset -- the smaller number of 
Java files your filter includes, the faster the build will go (more or 
less).


These two can of course be combined.

I would like to point out that this is hopefully a temporary solution -- 
if proper dependency checking and incremental builds get fast enough, 
this kind of trickery should not be needed. If this happens, we will 
remove the support for these shortcuts since they do carry a risk of 
improper builds.


/Magnus

Re: The future of partial builds

[Anthony Petrov]

+1

--
best regards,
Anthony

On 9/10/2012 6:52 PM, Weijun Wang wrote:
Sorry I was not clear, by "clone the repo(s)", I mean either only the 
jdk repo, or plus the jdk/*/closed ones. I almost never clone other 
repos (langtools, hotspot, ...).


-Max

On 09/10/2012 10:48 PM, Weijun Wang wrote:

It's not uncommon that I just clone the repo(s), do a quick build, run
several tests and abandon it, for example, if I want to try my code
changes on a different platform (from my daily work machine). Therefore
I find the jdk-only build very useful.

-Max

On 09/10/2012 10:20 PM, Magnus Ihse Bursie wrote:

On 2012-09-10 14:13, Alan Bateman wrote:


I think this is a great topic to discuss.

At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say "partial build" then I
mean they build a subset of repositories, not all of them. So folks
working in the jdk repository tend to just build that repository with
everything else coming from whatever import JDK they are using.
Partial builds are of course very fragile and frequently people have
problems because they aren't using a matching import JDK. Also
periodically we have flag days, say changes that impact langtools+jdk
or hotspot+jdk and these usually cause a bit of disruption until the
changes get into a promoted build and into the import JDK that people
use.  As to why people do partial builds then it's probably a mix of
issues including disk space, time to do the first build, and of course
it's just the way that we've always done it.



In build-infra, there is currently a "somewhat partial  build" feature
that is implemented like this:
1) You check out a "master forest", containing all repos. You only need
to do this checkout once, and you are not required to pull/update it
(unless you want to keep up with changes -- like on a flag day).

2) For subsequent work, you can clone just a single repo (let's call it
"my_hotspot"), and doing some configure magic (currently a bit
complicated, but that can be rewritten to be simpler) which will point
to the "master forest" but replace the hotspot repo in the master forest
with "my_hotspot"..

3) The first time you build "my_hotspot", it will rebuild the whole
forest (but with hotspot replaced with my_hotspot). However, if you
never pull/update the master forest, this will be a one-time event.
Subsequent builds will see that nothing has changed in the master
forest, and only changes in my_hotspot will be recompiled.

The pros with this solution is:
1) help with flag days -- just pull/update the master forest and 
rebuild.

2) you can always build the complete product.
3) you save some disk space by only cloning the complete forest once.

However:
1) you will still need disk space for build output for the complete
forest, for every single repo.
2) you will still need to recompile the whole forest for each new single
repo you clone.

Do you think this will make the solution not good enough?

I think it is possible and not too hard to change this solution
slightly, so you would only need to compile the master forest once, and
then new single repos can use that build output as well as using the
source code from the master forest. Though proper dependency checking
might be harder, and there will be semantic issues about the meaning of
things like "make clean" that can be surprising. Is this something you
think is worth pursuing?

To completely eliminate compiling the whole product at least once seems
much harder. I can't really see a good way of using "import JDKs" the
way they've been used in the old build system. I imagine one possibility
is to prepare a tar ball, including a complete cloned forest (for a
certain point in time) and a build directory with build artifacts
corresponding to that source code and your platform(s) of choice, and
have people download that as starting point. It seems like a lot of
work, though. Do you think that is needed to get the new build system
accepted?

/Magnus

Re: jdk builds on the mac

[Anthony Petrov]

This patch won't work for me. I use the following "workaround" patch 
instead:



diff -r 8a2bc6e82d81 make/java/Makefile
--- a/make/java/Makefile
+++ b/make/java/Makefile
@@ -58,7 +58,7 @@
 endif # PLATFORM

 ifeq ($(PLATFORM), macosx)
-  SUBDIRS += jobjc
+#  SUBDIRS += jobjc
 endif # PLATFORM

 include $(BUILDDIR)/common/Subdirs.gmk



which is way far from ideal...

Is anyone working on 7191703 to resolve this issue?

--
best regards,
Anthony

On 8/15/2012 10:30 PM, Joel Borggrén-Franck wrote:

Well that didn't work, patch inline:

diff -r 38263aa28324 src/macosx/native/jobjc/build.xml
--- a/src/macosx/native/jobjc/build.xml Mon Jul 30 22:32:59 2012 +0100
+++ b/src/macosx/native/jobjc/build.xml Wed Aug 15 20:09:08 2012 +0200
@@ -73,6 +73,10 @@
 
   
 
+  

+
+  
+
   
 
   

@@ -115,7 +119,7 @@
 
   
 
-  

+  
 
   

 
@@ -140,15 +144,11 @@
 
 
-  
-
-  
+   includeantruntime="false"
+   classpath="${classes}">
 
-
-  
-
-  
+
 
 
 


On 15 aug 2012, at 20:17, Joel Borggrén-Franck  wrote:


I would't say I'm working on it.

But from the department of "works for me (™)" here is a patch that sort of 
works for me. It might be breaking other stuff (like full forest builds), and it might 
not be what we want to do ...

cheers
/Joel



On 10 aug 2012, at 07:39, Erik Joelsson  wrote:


It does and I believe Joel, in the langtools team, is looking at this issue.

/Erik

On 2012-08-10 03:00, Kelly O'Hair wrote:

I think we need to make sure that the only thing that gets built with the 
bootjdk javac is the langtools
bootstrap javac.jar, all other javac compilations needs to be done by the 
bootstrap javac.
Does that fix this issue?

-kto

On Aug 6, 2012, at 2:33 AM, Erik Joelsson wrote:


The classpath reference was added on my request for build-infra. The reason was 
to get javax.annotation.GenerateNativeHeader on the classpath. The javac used 
in that ant script is the bootjdk javac, which usually doesn't provide the 
annotation. I suppose the correct fix would be to change the ant script to use 
the bootstrap javac instead.

/Erik

On 2012-07-28 00:06, Kumar Srinivasan wrote:

On 7/25/2012 2:23 PM, Kelly O'Hair wrote:

Naoto has noticed this build failure on the Mac (just the Mac) when building 
just the jdk repository.

From what I can tell, the Mac build of the jdk repository now depends on the 
langtools repository also
being built, which means that partial builds of just the jdk repository will no 
longer work on the Mac?
There is an ant script at jdk/src/macosx/native/jobjc/build.xml that has a 
baked in classpath reference to
../../langtools/dist/lib/classes.jar

Has anyone seen this, or have any additional information on it?

This is preventing me to test certain things I can only run from a jdk build 
under
jprt on the macosx machine.

Kumar


-kto

--
build-core:
   [mkdir] Created dir: 
/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core
   [javac] com/apple/jobjc/PrimitiveCoder.java added as 
com/apple/jobjc/PrimitiveCoder.class doesn't exist.
   [javac] Compiling 1 source file to 
/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core
   [javac] Using modern compiler
dropping 
/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/langtools/dist/lib/classes.jar
 from path as it doesn't exist
   [javac] Compilation arguments:
   [javac] '-d'
   [javac] 
'/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core'
   [javac] '-classpath'
   [javac] 
'/private/tmp/jprt/P1/174541.nsato/s/build/macosx-x86_64/JObjC.build/bin/core'
   [javac] '-sourcepath'
   [javac] 
'/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java'
   [javac] '-target'
   [javac] '1.5'
   [javac] '-g'
   [javac] '-source'
   [javac] '1.5'
   [javac]
   [javac] The ' characters around the executable and arguments are
   [javac] not part of the command.
   [javac] File to be compiled:
   [javac] 
/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java
   [javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.5
   [javac] 
/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java:32:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
   [javac] import sun.misc.Unsafe;
   [javac]^

.

  [javac] @GenerateNativeHeader
  [javac]  ^
  [javac]   symbol: class GenerateNativeHeader
  [javac] Note: Some input files use unchecked or unsafe operations.
  [javac] Note: Recompile with -Xlint:unchecked for details.
  [javac] 61 errors
  [javac] 7 warnings

BUILD FAILED
/private/tmp/jprt/P1/174541.nsato/s/src/macosx/native/jobjc/build.xml:143: 
Compile failed; see the compiler error output for details.
  a

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

I see your point. As I told you we'll be open-sourcing a JAWT-specific 
test under 7190587. This test already provides support for Linux, 
Solaris, and Windows platforms, and even does a little more than just 
loads the jawt library.


So it looks there's still some value in Kumar's test as well. Yes, it 
will need to be rewritten should we replace the RPATH mechanism with 
something else in the future. It's up to Kumar to decide whether he 
wants such test to be present in the repo. Personally, I don't mind.


--
best regards,
Anthony

On 8/13/2012 7:04 PM, Omair Majid wrote:

On 08/13/2012 10:39 AM, Anthony Petrov wrote:

The test looks great, and I like that it doesn't depend on the JAWT
machinery, but tests the actual problematic RPATH entry only.


I generally go for tests that verify behaviour (that jawt-linked
programs are working) rather than implementation details (which changed,
for example, when we switched from LD_LIBRARY_PATH to RPATHS).


+1 from me.


Yes, good to have something that guards us from changing something
unintentionally. Looks fine to me too.

Cheers,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

The test looks great, and I like that it doesn't depend on the JAWT 
machinery, but tests the actual problematic RPATH entry only.


+1 from me.

--
best regards,
Anthony

On 08/13/12 18:22, Kumar Srinivasan wrote:

Hi Anthony, Omair.

Here is the patch for the test, this will live in test/tools/launcher,
also I don't have access
to a MacOS system, appreciate if you can add this otherwise I will file
a bug and add
the macosx case later on.

Thanks

Kumar


Hi Omair and Kumar,

As to me, the fix and the test look good. A few suggestions:

1. Mac is also a supported platform now, so you need to add the
"Darwin" option to the "SunOS | Windows_* )" case in the .sh file.

2. If gcc is not present, this should be considered that the test is
passed. Systems used for running tests may lack compilers, and this is
perfectly OK.

Having said that, let's wait and see what test Kumar has to offer.

--
best regards,
Anthony

On 08/11/12 00:56, Omair Majid wrote:

Hi Anthony,

On 08/10/2012 08:29 AM, Anthony Petrov wrote:

Actually, if Omair has a good automatic jtreg test, we would be
happy to
get it checked in with this fix. Could we see a webrev for the test
please?


I have uploaded a new webrev that includes a test case too:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/

The bug number in the jtreg test is entirely made up. Any thoughts for a
better description or alternate locations for the test code?

I can only run the test case on Linux, so that's what it's for. It needs
gcc to build the native bits. The webrev is against jdk8/awt forest, if
it matters.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

Hi Omair and Kumar,

As to me, the fix and the test look good. A few suggestions:

1. Mac is also a supported platform now, so you need to add the "Darwin" 
option to the "SunOS | Windows_* )" case in the .sh file.


2. If gcc is not present, this should be considered that the test is 
passed. Systems used for running tests may lack compilers, and this is 
perfectly OK.


Having said that, let's wait and see what test Kumar has to offer.

--
best regards,
Anthony

On 08/11/12 00:56, Omair Majid wrote:

Hi Anthony,

On 08/10/2012 08:29 AM, Anthony Petrov wrote:

Actually, if Omair has a good automatic jtreg test, we would be happy to
get it checked in with this fix. Could we see a webrev for the test please?


I have uploaded a new webrev that includes a test case too:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/01/

The bug number in the jtreg test is entirely made up. Any thoughts for a
better description or alternate locations for the test code?

I can only run the test case on Linux, so that's what it's for. It needs
gcc to build the native bits. The webrev is against jdk8/awt forest, if
it matters.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

On 8/10/2012 4:59 PM, Andrew Hughes wrote:


- Original Message -

On 8/10/2012 4:24 PM, Andrew Hughes wrote:

- Original Message -

Hi Anthony,

a. although this is a build change, I have requested Omair to
provide
a
regression
 test, IMO if we had a regression test to begin with, this
 would
 not
have been removed
 during the RPATH work. We may have to check in a ".so" for
 linux
and solaris
 variants. So my question to you. Where should such a test be
parked, in awt regression
test hierarchy ?

b. this should be pushed via awt integration repo,  thus allowing
all
awt PITs to be run.


Please don't check binaries into the repositories.  Omair's test
works fine
with just source code.  I replicated the issue using it.

+1 regarding binaries in repos.

Actually, if Omair has a good automatic jtreg test, we would be happy
to
get it checked in with this fix. Could we see a webrev for the test
please?



A webrev of the patch and a separate test case are both linked in this e-mail:

http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006555.html

The test case would need converting to use jtreg obviously, but I'm pretty sure
there are similar tests already (certainly in HotSpot).


Yes, I've seen those links. I would like to review the full webrev, 
including a jtreg-compatible test.


--
best regards,
Anthony






--
best regards,
Anthony


Thanks

Kumar


Hi Omair,

The fix looks good to me. I think Kumar needs to take a look at
it,
too, before the fix can be pushed to a repo.

Thanks for finding and fixing this issue.

--
best regards,
Anthony

On 8/10/2012 1:48 AM, Omair Majid wrote:

On 08/09/2012 07:15 AM, Andrew Hughes wrote:

- Original Message -

Hi Kumar,

On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:

My suggestion is to see if System.loadLibrary can be used,
this
will
bode well for the modularization effort.

I discussed this with the folks at awt-dev and they would
prefer
to
avoid loading as much as possible. They are strongly against
always
preloading libjawt.so.


For my 2c, I'm against it too.  It doesn't seem the right fix.

I can see your point, but both the solutions feel wrong to me. I
can't
make up my mind which is the less bad.


I don't see an attachment :-(

I guess the mailing list software stripped it out. I did attach
it.


Shouldn't it be a webrev anyway?

Old habits :)

Webrev is at:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/

I have also put up a test case at:
http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz

The test case is the exact same as that on
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html,

except it automates the building and running. You will have to
edit the
makefile to set the value of JDK_HOME. It should point to a
j2sdk-image
directory.

Then do:
$ make
$ make run

Without the fix it should print an UnsatisfiedLinkError. With
the
fix,
it should show a window.


I built jdk8/build successfully just last week.  What issues
are
you
seeing?

Errors building hotspot, I seem to recall. But I cant reproduce
it
anymore after pulling today. I can now confirm that the fix
works
for me
with jdk8 too.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

On 8/10/2012 4:24 PM, Andrew Hughes wrote:

- Original Message -

Hi Anthony,

a. although this is a build change, I have requested Omair to provide
a
regression
 test, IMO if we had a regression test to begin with, this would
 not
have been removed
 during the RPATH work. We may have to check in a ".so" for linux
and solaris
 variants. So my question to you. Where should such a test be
parked, in awt regression
test hierarchy ?

b. this should be pushed via awt integration repo,  thus allowing all
awt PITs to be run.



Please don't check binaries into the repositories.  Omair's test works fine
with just source code.  I replicated the issue using it.


+1 regarding binaries in repos.

Actually, if Omair has a good automatic jtreg test, we would be happy to 
get it checked in with this fix. Could we see a webrev for the test please?


--
best regards,
Anthony




Thanks

Kumar


Hi Omair,

The fix looks good to me. I think Kumar needs to take a look at it,
too, before the fix can be pushed to a repo.

Thanks for finding and fixing this issue.

--
best regards,
Anthony

On 8/10/2012 1:48 AM, Omair Majid wrote:

On 08/09/2012 07:15 AM, Andrew Hughes wrote:

- Original Message -

Hi Kumar,

On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:

My suggestion is to see if System.loadLibrary can be used, this
will
bode well for the modularization effort.

I discussed this with the folks at awt-dev and they would prefer
to
avoid loading as much as possible. They are strongly against
always
preloading libjawt.so.


For my 2c, I'm against it too.  It doesn't seem the right fix.

I can see your point, but both the solutions feel wrong to me. I
can't
make up my mind which is the less bad.


I don't see an attachment :-(

I guess the mailing list software stripped it out. I did attach
it.


Shouldn't it be a webrev anyway?

Old habits :)

Webrev is at:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/

I have also put up a test case at:
http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz

The test case is the exact same as that on
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html,

except it automates the building and running. You will have to
edit the
makefile to set the value of JDK_HOME. It should point to a
j2sdk-image
directory.

Then do:
$ make
$ make run

Without the fix it should print an UnsatisfiedLinkError. With the
fix,
it should show a window.


I built jdk8/build successfully just last week.  What issues are
you
seeing?

Errors building hotspot, I seem to recall. But I cant reproduce it
anymore after pulling today. I can now confirm that the fix works
for me
with jdk8 too.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

Well, it's complicated. There's problems with JAWT on the Mac currently, 
which makes it hard or even impossible to use it on that platform.


We'll add support for the Mac to a test open-sourced with 7190587 once 
JAWT is working fine on the Mac in general.


--
best regards,
Anthony

On 8/10/2012 2:42 PM, Kumar Srinivasan wrote:

Hi Anthony, Omair,

Shouldn't there be a case for MacOSX as well ?

Kumar


Hi Anthony,

a. although this is a build change, I have requested Omair to provide 
a regression
test, IMO if we had a regression test to begin with, this would 
not have been removed
during the RPATH work. We may have to check in a ".so" for linux 
and solaris
variants. So my question to you. Where should such a test be 
parked, in awt regression

   test hierarchy ?

b. this should be pushed via awt integration repo,  thus allowing all 
awt PITs to be run.


Thanks

Kumar


Hi Omair,

The fix looks good to me. I think Kumar needs to take a look at it, 
too, before the fix can be pushed to a repo.


Thanks for finding and fixing this issue.

--
best regards,
Anthony

On 8/10/2012 1:48 AM, Omair Majid wrote:

On 08/09/2012 07:15 AM, Andrew Hughes wrote:

- Original Message -

Hi Kumar,

On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:

My suggestion is to see if System.loadLibrary can be used, this
will
bode well for the modularization effort.

I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are strongly against always
preloading libjawt.so.


For my 2c, I'm against it too.  It doesn't seem the right fix.


I can see your point, but both the solutions feel wrong to me. I can't
make up my mind which is the less bad.


I don't see an attachment :-(


I guess the mailing list software stripped it out. I did attach it.


Shouldn't it be a webrev anyway?


Old habits :)

Webrev is at:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/

I have also put up a test case at:
http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz

The test case is the exact same as that on
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, 


except it automates the building and running. You will have to edit the
makefile to set the value of JDK_HOME. It should point to a j2sdk-image
directory.

Then do:
$ make
$ make run

Without the fix it should print an UnsatisfiedLinkError. With the fix,
it should show a window.

I built jdk8/build successfully just last week.  What issues are 
you seeing?


Errors building hotspot, I seem to recall. But I cant reproduce it
anymore after pulling today. I can now confirm that the fix works 
for me

with jdk8 too.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

Hi Kumar, Omair,

[ adding awt-dev@ in the loop ]

On 8/10/2012 2:30 PM, Kumar Srinivasan wrote:
a. although this is a build change, I have requested Omair to provide a 
regression
test, IMO if we had a regression test to begin with, this would not 
have been removed
during the RPATH work. We may have to check in a ".so" for linux and 
solaris
variants. So my question to you. Where should such a test be parked, 
in awt regression

   test hierarchy ?


We have a test for this already, actually, although it is closed and 
doesn't use jtreg. I filed 7190587 to fix this. For now Omair may 
proceed w/o a regression test.


b. this should be pushed via awt integration repo,  thus allowing all 
awt PITs to be run.


I don't mind that.

--
best regards,
Anthony



Thanks

Kumar


Hi Omair,

The fix looks good to me. I think Kumar needs to take a look at it, 
too, before the fix can be pushed to a repo.


Thanks for finding and fixing this issue.

--
best regards,
Anthony

On 8/10/2012 1:48 AM, Omair Majid wrote:

On 08/09/2012 07:15 AM, Andrew Hughes wrote:

- Original Message -

Hi Kumar,

On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:

My suggestion is to see if System.loadLibrary can be used, this
will
bode well for the modularization effort.

I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are strongly against always
preloading libjawt.so.


For my 2c, I'm against it too.  It doesn't seem the right fix.


I can see your point, but both the solutions feel wrong to me. I can't
make up my mind which is the less bad.


I don't see an attachment :-(


I guess the mailing list software stripped it out. I did attach it.


Shouldn't it be a webrev anyway?


Old habits :)

Webrev is at:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/

I have also put up a test case at:
http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz

The test case is the exact same as that on
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, 


except it automates the building and running. You will have to edit the
makefile to set the value of JDK_HOME. It should point to a j2sdk-image
directory.

Then do:
$ make
$ make run

Without the fix it should print an UnsatisfiedLinkError. With the fix,
it should show a window.

I built jdk8/build successfully just last week.  What issues are you 
seeing?


Errors building hotspot, I seem to recall. But I cant reproduce it
anymore after pulling today. I can now confirm that the fix works for me
with jdk8 too.

Thanks,
Omair

Re: [PATCH] Update RPATH to make loading libjawt possible

[Anthony Petrov]

Hi Omair,

The fix looks good to me. I think Kumar needs to take a look at it, too, 
before the fix can be pushed to a repo.


Thanks for finding and fixing this issue.

--
best regards,
Anthony

On 8/10/2012 1:48 AM, Omair Majid wrote:

On 08/09/2012 07:15 AM, Andrew Hughes wrote:

- Original Message -

Hi Kumar,

On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:

My suggestion is to see if System.loadLibrary can be used, this
will
bode well for the modularization effort.

I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are strongly against always
preloading libjawt.so.


For my 2c, I'm against it too.  It doesn't seem the right fix.


I can see your point, but both the solutions feel wrong to me. I can't
make up my mind which is the less bad.


I don't see an attachment :-(


I guess the mailing list software stripped it out. I did attach it.


Shouldn't it be a webrev anyway?


Old habits :)

Webrev is at:
http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/

I have also put up a test case at:
http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz

The test case is the exact same as that on
http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html,
except it automates the building and running. You will have to edit the
makefile to set the value of JDK_HOME. It should point to a j2sdk-image
directory.

Then do:
$ make
$ make run

Without the fix it should print an UnsatisfiedLinkError. With the fix,
it should show a window.


I built jdk8/build successfully just last week.  What issues are you seeing?


Errors building hotspot, I seem to recall. But I cant reproduce it
anymore after pulling today. I can now confirm that the fix works for me
with jdk8 too.

Thanks,
Omair

Re: Review: Removing GenerateNativeHeader where not needed

[Anthony Petrov]

Looks good to me. Although most of the changes are in Java2D code, so 
I'm also CC'ing 2d-dev@ to take a look.


--
best regards,
Anthony

On 7/3/2012 10:23 PM, Erik Joelsson wrote:
The build infra project added the use of the annotation 
GenerateNativeHeader. It was addded to java classes without native 
methods that were listed in the old makefiles as needing headers 
generated for them. It was noted then that some of those classes didn't 
actually need native headers. To clean things up, we have tried to 
identify the empty headers and removed the annotation for those classes.


http://cr.openjdk.java.net/~erikj/build-infra-m1.2/webrev-jdk-awt/ 

Re: RFR: 7171653 32-bit cross-compile on 64-bit build host generates 64-bit data for awt/X11 leading to crash

[Anthony Petrov]

Hi David,

The fix looks fine to me. Is the empty line 281 OK in Makefiles? I'd 
remove it just in case. Besides it would make it more clearer that the 
SIZERS_CC commands are related to the SIZERS target.


--
best regards,
Anthony

On 5/25/2012 10:20 AM, David Holmes wrote:
This is a tweak to the cross-compilation rules in sun/xawt/Makefile to 
force correct compilation of the sizers utility.


http://cr.openjdk.java.net/~dholmes/7171653/webrev/

webrev is against tl/jdk but I can use a different repo if you prefer.

Now that we use CFLAGS_32/64 in the cross compilation case we no longer 
need different cc commands, other than the actual choice of compiler.


Longer term 7153072 will make this fix obsolete but for now we need this 
for our new build servers, and I wanted to make sure this only affected 
cross-compilation.


Same change will need to go to the 7u train as well.

Thanks,
David

Re: Request for Review: Remove import of empty JNI header files

[Anthony Petrov]

On 4/25/2012 6:15 PM, Magnus Ihse Bursie wrote:
However, this problem may occur again because most developers use the 
old build system, and as such won't notice the issue. Is there a plan 
to remove the old build system and switch over to the new one?


Yes, there is such a plan. The exact details have not been decided yet, 
but since Jigsaw is dependent on the new build system, it will replace 
the old build system no later than the first push from Jigsaw to 
mainline -- but hopefully earlier.


Thanks for clarifying that.

--
best regards,
Anthony

Re: Request for Review: Remove import of empty JNI header files

[Anthony Petrov]

Hi Magnus,

The fix looks fine to me.

However, this problem may occur again because most developers use the 
old build system, and as such won't notice the issue. Is there a plan to 
remove the old build system and switch over to the new one?


--
best regards,
Anthony

On 4/25/2012 5:44 PM, Magnus Ihse Bursie wrote:
There are a few files native files in AWT and Java2d, which include 
generated JNI header files, but the corresponding header files are 
empty, since the class contains neither native methods nor constants.


All of them have probably been useful at one point in time, but then the 
Java code changed and the include became irrelevant, but nobody noticed. 
(Some of them contains JDK1.0-style, pre-JNI native access...)


The trouble is, in the new build system, we only generate JNI header 
files when they actually contains something useful! So these files don't 
get generated. But then the compiler complains when building the native 
library, since the #include statements points to non-existent files.


Webrev:
http://cr.openjdk.java.net/~ihse/remove-empty-imports/webrev.00/

/Magnus

Re: requirements for building on Mac?

[Anthony Petrov]

Hi Ray,

JDK is buildable on 10.6. Please run Apple Software Update to install 
all the latest patches on your Snow Leopard system. This should update 
the FreeType lib as well.


--
best regards,
Anthony

On 04/22/12 02:36, Ray Kiddy wrote:


I am seeing differing statements about what is needed to build jdk7u-dev. Which 
is correct?

The page at http://code.google.com/p/openjdk-osx-build/ says "Packages built on 
SnowLeopard (10.6) and tested on SnowLeopard (10.6) and Lion (10.7)."

The page at https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port says 
"Prerequisites to build... Mac OS X 10.7.3."

And when I actually try to build on 10.6.8 (using the instructions on 
https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port), I get:

ERROR: FreeType version  2.3.0  or higher is required.
 /bin/mkdir -p 
/Users/ray/Projects/openjdk/jdk7u-dev/build/macosx-amd64/btbins

rm -f 
/Users/ray/Projects/openjdk/jdk7u-dev/build/macosx-amd64/btbins/freetype_versioncheck
Failed to build freetypecheck.

Exiting because of the above error(s).

make: *** [post-sanity] Error 1

So, should I try to get around this error, or is building on 10.6 just not 
going to work? And if it should work, should this be stated on the 
wikis.oracle.com page?

I had been able to build a couple of months ago. But perhaps the landscape is 
changing?

thanx - ray

Re: RFR: 7155585: Fix ifeq errors in makefiles [macosx]

[Anthony Petrov]

Hi Michael,

Changes to awt/font makefiles look fine to me.

--
best regards,
Anthony

On 03/21/12 19:03, Michael McMahon wrote:

Could I get the following change reviewed please for jdk 8?

It is to fix a number of minor build warnings caused by the macosx changes.

http://cr.openjdk.java.net/~michaelm/7155585/webrev.1/

Thanks
Michael

Re: BUILD_HEADLESS_ONLY

[Anthony Petrov]

Hi Martin,

On 3/6/2012 6:17 PM, martin burtscher wrote:
if I use BUILD_HEADLESS=true the awt packages are included and useable. 
So either I understand BUILD_HEADLESS wrong or it doesnt do what its 
supposed to do.


AWT can work w/o a display, e.g. for in-memory image manipulation, or 
printing support. So there's nothing wrong with having AWT packages 
built when the BUILD_HEADLESS is true.



Second point is: Why do i need ALT_OPENWIN_HOME? I wanna build it 
headless, so there's no use of X11. I removed the CROSS_COMPILE options 
to test the headless build. (Just try to use the cross compile to be 
sure its working before i use a different compiler...) btw: changing 
ALT_OPENWIN_HOME doesnt change anything with the errors (Xrender.h 
missing) i'll get when im using crosscompile.


AFAIK, currently there's no an officially supported way to build an 
AWT-less OpenJDK.


--
best regards,
Anthony

Re: Request for review: 7030063 AWT support for SE-Embedded integration

[Anthony Petrov]

Hi David,

The fix looks good to me.

--
best regards,
Anthony

On 3/23/2011 4:25 AM, David Holmes wrote:

(build-dev cc'ed as there are some makefile changes (Hi Kelly! :) ) )

webrev:

http://cr.openjdk.java.net/~dholmes/7030063/webrev/

This CR integrates support for SE-Embedded into the AWT. The main
changes are:

- forward-port from JDK6 the replacement of hard-wired X11 paths to use
OPENWIN_HOME-based paths
- cross-compilation support
- Support for BUILD_HEADLESS_ONLY, which is a specialized build for
environments where there are no X11 libraries available at build-time.
X11 headers are still needed due to various dependencies in the native
code.
- Customize the tray-icon timeout for slow devices
- Add new HToolkit for headless environments without any xawt support
(used for SE-Embedded reduced-headless builds for which the VM
automatically sets -Djava.awt.headless=true)
- Update logic for default toolkit selection on Solaris/Linux (AWT team
request)
- SE-Embedded specific customizations (conditional on defining
JAVASE_EMBEDDED in the build variables)
- New AWT event polling algorithm with changed defaults for SE-Embedded
(SE behaviour remains the same)

Thanks,
David Holmes
Java SE VM Embedded Team

Re: JDK8 Preliminary Repository Layout

[Anthony Petrov]

Hi Andrew,

On 3/10/2011 3:48 AM, Dr Andrew John Hughes wrote:

   * Separating out the client (awt/swing/etc) code from the jdk repo into a 
separate repo


Why would we want to do this?  IME, there are lots of interdependencies with 
the other code and
this would make the build a nightmare.


Not at all. AWT/Swing/2D have a lot of inter-dependencies with each 
other, but no deep dependencies with other parts of JDK. I believe the 
Sound libraries are very similar in this regard as well. Separating them 
out makes a lot of sense to speed up the build time for those primarily 
working on bugs and enhancements in these areas only.


What particular problems do you anticipate with their separation?



Hey, I'd just make it all one repository as they all interdepend on each other


One huge "all-in-all" repository is great for integrators, porters, or 
maintainers, but it isn't that convenient for developers working on 
specific areas of JDK. Primarily because of the unnecessarily increased 
build time.


Since it's always possible to make a clone of the whole 'forest', and 
hence get all the repos virtually at once, I don't really see any 
problems with making some parts of the class (and native) libraries 
separate repositories.


--
best regards,
Anthony

Re: 6839999: Cumulative fix for 6762511 and 6838003

[Anthony Petrov]

On 6/17/2009 10:13 PM Andrew John Hughes wrote:

Please update the README-builds.html file also as Kelly suggests. Thanks!


Ok here's an updated version with Xrender mentioned in README-builds:

http://fuseyism.com/6851515/webrev.03/

Ok?

Perfect! Approved. Feel free to push to the AWT gate.

--
best regards,
Anthony

Re: 6839999: Cumulative fix for 6762511 and 6838003

[Anthony Petrov]

Andrew,

Please update the README-builds.html file also as Kelly suggests. Thanks!

--
best regards,
Anthony

On 6/17/2009 9:00 PM Anthony Petrov wrote:

On 6/17/2009 8:44 PM Andrew John Hughes wrote:

So should I push the original webrev
http://fuseyism.com/xrender/webrev.01/ (which uses the standard header
instead) to the awt gate?
Given Kelly's point, I'm approving the fix. Please use the CR number 
6851515 for your commit message. Thanks for the patch.


--
best regards,
Anthony

Re: 6839999: Cumulative fix for 6762511 and 6838003

[Anthony Petrov]

On 6/17/2009 8:44 PM Andrew John Hughes wrote:

So should I push the original webrev
http://fuseyism.com/xrender/webrev.01/ (which uses the standard header
instead) to the awt gate?
Given Kelly's point, I'm approving the fix. Please use the CR number 
6851515 for your commit message. Thanks for the patch.


--
best regards,
Anthony

Re: 6839999: Cumulative fix for 6762511 and 6838003

[Anthony Petrov]

So, build-dev,

Any opinions? Can we make sure the header is always present on Sol10u2? 
Perhaps we could add it to the requirements list for building OpenJDK?


--
best regards,
Anthony


On 06/16/2009 07:25 PM, Anthony Petrov wrote:

On 06/16/2009 07:21 PM, Andrew John Hughes wrote:

Is it really necessary to include a chunk of the header file rather
than just doing a #include?  If so, may I suggest that the block is
dependent on _XRENDER_H_ not being defined?
The header may be absent on Solaris 10 U2 which is now a supported 
platform
for building JDK. This was the primary reason to cut'n'paste the 
chunk of
code from the xrender header. I think the best solution would be to 
wrap the
"imported" chunk of code with the proper #ifdef statement for now. 
Can you

make a patch please?



I did:

http://fuseyism.com/xrender/webrev.02/

Unfortunately, it isn't sufficient.  gcc seems to include awt_p.h
first, so that when the XRender header is included, it again redefines
the structures.
I tried also defining _XRENDER_H_ in awt_p.h, but of course because
this is not the whole of the header, the XRender pipeline code then
fails to compile:

In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:34,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/MaskBuffer.h:45: error:
expected specifier-qualifier-list before 'Picture'
../../../src/solaris/native/sun/java2d/x11/MaskBuffer.h:87: error:
expected declaration specifiers or '...' before 'Picture'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:35,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:46: error:
expected specifier-qualifier-list before 'Picture'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:64: error:
expected '=', ',', ';', 'asm' or '__attribute__' before 'color_black'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:67: error:
expected ')' before 'mask'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:35,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:73: error:
expected declaration specifiers or '...' before 'XRenderColor'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:76: error:
expected declaration specifiers or '...' before 'XRenderColor'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:118:
error: expected specifier-qualifier-list before 'Picture'
make[6]: *** 
[/mnt/builder/icedtea/openjdk-ecj/build/linux-amd64/tmp/sun/sun.awt.X11/xawt/obj64/X11TextRenderer_md.o] 


Error 1

As the XRender pipeline will be a feature of JDK7
(http://openjdk.java.net/projects/jdk7/features/), I think support for
UNIX platforms without it, such as Solaris 10 U2, will have to be
dropped for 7.

This is a question to discuss on the build-dev mailing list (CC'ed).
Any tips?

--
best regards,
Anthony





--
best regards,
Anthony


Here's a webrev that fixes it by just using the xrender header:

http://fuseyism.com/xrender/webrev.01/

It does mean the header has to be available at build time, but dlsym
is still used to make it optional at runtime.
Given the XRender project is going to be merged at some point anyway,
this hardly seems like a huge sacrifice.

Ok to commit?

Re: 6839999: Cumulative fix for 6762511 and 6838003

[Anthony Petrov]

On 06/16/2009 07:21 PM, Andrew John Hughes wrote:

Is it really necessary to include a chunk of the header file rather
than just doing a #include?  If so, may I suggest that the block is
dependent on _XRENDER_H_ not being defined?

The header may be absent on Solaris 10 U2 which is now a supported platform
for building JDK. This was the primary reason to cut'n'paste the chunk of
code from the xrender header. I think the best solution would be to wrap the
"imported" chunk of code with the proper #ifdef statement for now. Can you
make a patch please?



I did:

http://fuseyism.com/xrender/webrev.02/

Unfortunately, it isn't sufficient.  gcc seems to include awt_p.h
first, so that when the XRender header is included, it again redefines
the structures.
I tried also defining _XRENDER_H_ in awt_p.h, but of course because
this is not the whole of the header, the XRender pipeline code then
fails to compile:

In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:34,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/MaskBuffer.h:45: error:
expected specifier-qualifier-list before 'Picture'
../../../src/solaris/native/sun/java2d/x11/MaskBuffer.h:87: error:
expected declaration specifiers or '...' before 'Picture'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:35,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:46: error:
expected specifier-qualifier-list before 'Picture'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:64: error:
expected '=', ',', ';', 'asm' or '__attribute__' before 'color_black'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:67: error:
expected ')' before 'mask'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:35,
 from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:73: error:
expected declaration specifiers or '...' before 'XRenderColor'
../../../src/solaris/native/sun/java2d/x11/XRSurfaceData.h:76: error:
expected declaration specifiers or '...' before 'XRenderColor'
In file included from
../../../src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c:31:
../../../src/solaris/native/sun/java2d/x11/X11SurfaceData.h:118:
error: expected specifier-qualifier-list before 'Picture'
make[6]: *** 
[/mnt/builder/icedtea/openjdk-ecj/build/linux-amd64/tmp/sun/sun.awt.X11/xawt/obj64/X11TextRenderer_md.o]
Error 1

As the XRender pipeline will be a feature of JDK7
(http://openjdk.java.net/projects/jdk7/features/), I think support for
UNIX platforms without it, such as Solaris 10 U2, will have to be
dropped for 7.

This is a question to discuss on the build-dev mailing list (CC'ed).
Any tips?

--
best regards,
Anthony





--
best regards,
Anthony


Here's a webrev that fixes it by just using the xrender header:

http://fuseyism.com/xrender/webrev.01/

It does mean the header has to be available at build time, but dlsym
is still used to make it optional at runtime.
Given the XRender project is going to be merged at some point anyway,
this hardly seems like a huge sacrifice.

Ok to commit?

Re: hgext.fetch

[Anthony Petrov]

On 6/2/2009 7:28 PM Kelly O'Hair wrote:

And also add ffetch variations too. ;^)
In the [defaults] section only. The ffetch command itself is available 
anyway if you have both fetch and forest extensions enabled.


--
best regards,
Anthony


If you want to use ffetch...

-kto

Andrew Haley wrote:

Anthony Petrov wrote:

Do the following instead:

[extensions]
hgext.fetch =

[defaults]
fetch = -m Merge


OK, ta.

Andrew.

Re: hgext.fetch

[Anthony Petrov]

Do the following instead:

[extensions]
hgext.fetch =

[defaults]
fetch = -m Merge

--
best regards,
Anthony

On 06/02/2009 06:43 PM, Andrew Haley wrote:

I can't get the fetch extension to work properly.

I was told that I need to add

[extensions]
hgext.fetch = -m Merge

but that doesn't work:

*** failed to import extension hgext.fetch from -m Merge: [Errno 2] No such 
file or directory
fetch extension - no help text available

It seems that the RHS of the = is supposed to be the path of the extension,
not the options, and I can't find any information in the Mercurial manuals.

Thanks,
Andrew.

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

[Anthony Petrov]

On 5/15/2009 5:48 PM Jonathan Gibbons wrote:

The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and
(a) the Mercurial package does not completely install correctly
(b) even if it did, it is version 1.1.2.something, and OpenJDK requires
0.9.5.
I don't experience any problems using a newer version of Mercurial with 
OpenJDK. AFAIK this is a minimum version requirement, not an exact one.


--
best regards,
Anthony

Re: Request for review: 6833444 version 2

[Anthony Petrov]

On 4/27/2009 7:56 PM Dmitri Trembovetski wrote:
On pretty much any system you can tell if a drive is local or not, 
albeit in a system specific way.
That would be cool. However I don't see much justification around 
verifying for sure if a path is on the network. After all it's just a 
warning message, not a error.


  It's very easy to check on windows (in shell, adjust appropriately for 
makefile):

   net use j: > /dev/null 2>&1
   if [ $? -ne 0 ]; then
 # local drive
   else
 # remote drive
   fi

   If you want to be fancy you could grep the output of net use for 
"Remote Resource" or something..
Thanks Dmitri. That's totally correct. But still I don't consider it as 
a requirement. If we were to prohibit using a network-located BOOTDIR, 
then this would be a must. Currently this just seems like an overkill 
for such a tiny fix.


--
best regards,
Anthony

Request for review: 6833444 version 2

[Anthony Petrov]

Jon, Kelly, Xiomara,

Thank you very much for your feedback. I decided to revise the fix to:
1. Leave the current c:\jdk default path for those who still uses it.
2. Issue a warning message on MS Windows platform if the BOOTDIR is 
located on the J: drive (that is assumed to be mapped over network).


Here's the updated webrev:

http://cr.openjdk.java.net/~anthony/webrev-6833444.1/

Please review.

Some comments:

On 04/23/2009 11:53 PM, Jonathan Gibbons wrote:

On pretty much any system you can tell if a drive is local or not, albeit in a 
system specific way.
That would be cool. However I don't see much justification around 
verifying for sure if a path is on the network. After all it's just a 
warning message, not a error.


--
best regards,
Anthony

Re: _BOOTDIR1 on MS Windows platform

[Anthony Petrov]

Jon, Kelly,

Then what about the default builds on Linux/Solaris that do use the 
/java share and do not issue any warning message? I agree that these 
builds are generally much faster than on Windows, but still. Besides, as 
I mentioned before, on my local systems the /java directory and the J: 
disk are local  directories that just get occasionally synced. So the 
warning would be meaningless for such configurations...


--
best regards,
Anthony

On 4/23/2009 10:54 PM Kelly O'Hair wrote:

Adding a sanity check warning about J:/ usage would be a nice addition
to this change.

-kto

Jonathan Gibbons wrote:

Kelly,

Perhaps "make sanity" on Windows could give a warning about the use
of network paths, if such is detected.

-- Jon


Kelly O'Hair wrote:

Sorry I'm so slow in responding to this...

The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.

Bottom line, builds are always faster and more reliable when all 
components

are stored on local disk, and this is particularly true on Windows.

Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
(and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
by this change, but I bet quite a few people rely on this c:/jdk1.6.0
default. With enough warning you might be able to change this.

---

I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{

-kto


Anthony Petrov wrote:

Hello,

Back in 2007 we already discussed this issue with Kelly, but 
transitioning to Mercurial just stopped the work. So, I would like 
to revive this now.


Here's a part of the output generated by `grep -r BOOTDIR make/*`:

make/common/shared/Defs-solaris.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 

make/common/shared/Defs-solaris.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR1  
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 

make/common/shared/Defs-linux.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)


One can notice that the _BOOTDIR1 is defined differently on MS 
Windows platform. I would like to propose a change so that its value 
would be the same as on other platforms. The SLASH_JAVA on MS 
Windows equals to the J: drive. So one could setup the same 
directory tree as on Linux/Solaris, use the subst command to make 
the directory the J: drive, and be able to build the jdk w/o 
specifying the ALT_BOOTDIR variable manually.


Is there any objection to removing the 
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?


--
best regards,
Anthony

Re: _BOOTDIR1 on MS Windows platform

[Anthony Petrov]

On 4/23/2009 10:15 PM Kelly O'Hair wrote:

The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have gotten over the years, and it's really depends on the Windows
machine, the network, etc.

Bottom line, builds are always faster and more reliable when all components
are stored on local disk, and this is particularly true on Windows.
I totally agree with that. That's why my J: disk is NOT a network share, 
but a local directory that is mapped on the J: drive using the 'subst' 
command. This directory, however, gets synced with the real /java 
network share from time to time. So not setting the ALT_BOOTDIR does not 
slows down my builds in any way. What's more, it enables me to build by 
just issuing the make command, w/o setting ANY ALT_ variables in most cases.



Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
(and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
by this change, but I bet quite a few people rely on this c:/jdk1.6.0
default. With enough warning you might be able to change this.
I believe most people that might possibly be affected by this change 
reside on this mailing list. Who isn't - they probably either use the 
ALT_BOOTDIR, or, in the worst case, will be able to easily identify the 
problem since the reported error will include the /NO_BOOTDIR/ path to 
the javac compiler.


--
best regards,
Anthony




---

I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only 24hrs
in a day. :^{

-kto


Anthony Petrov wrote:

Hello,

Back in 2007 we already discussed this issue with Kelly, but 
transitioning to Mercurial just stopped the work. So, I would like to 
revive this now.


Here's a part of the output generated by `grep -r BOOTDIR make/*`:

make/common/shared/Defs-solaris.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 

make/common/shared/Defs-solaris.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR1  
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH) 

make/common/shared/Defs-linux.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)


One can notice that the _BOOTDIR1 is defined differently on MS Windows 
platform. I would like to propose a change so that its value would be 
the same as on other platforms. The SLASH_JAVA on MS Windows equals to 
the J: drive. So one could setup the same directory tree as on 
Linux/Solaris, use the subst command to make the directory the J: 
drive, and be able to build the jdk w/o specifying the ALT_BOOTDIR 
variable manually.


Is there any objection to removing the 
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?


--
best regards,
Anthony

Re: Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)

[Anthony Petrov]

On 4/23/2009 10:40 PM Kelly O'Hair wrote:

As I emailed earlier, I'd be ok with this change but only if RE (Xiomara)
was ok with it, and we made sure everyone was warned well in advance.

Thanks!


Also, the change is incomplete because the README-builds.html file probably
would need to change too.
I verified this file already and found no remarks about the default 
BOOTDIR locations on Windows. There's only a remark about Solaris/Linux 
regarding the possibility of using the /usr/java/ by default - but I 
don't change this. So there's no need to update any readme's.


--
best regards,
Anthony



-kto


Anthony Petrov wrote:

Please review the fix for the CR mentioned in the subject. The webrev:

http://cr.openjdk.java.net/~anthony/webrev-6833444.0/

I verified the fix on MS Windows platform, and it works pretty well.

--
best regards,
Anthony

Re: Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)

[Anthony Petrov]

On 4/23/2009 10:31 PM xiomara.jayas...@sun.com wrote:

We do set ALT_BOOTDIR all the time.

 From Kelly:

Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
(and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
by this change, but I bet quite a few people rely on this c:/jdk1.6.0
default. With enough warning you might be able to change this. 


It's OK with me, if you remove c:/jdk ...

Great to hear that! Thanks!

--
best regards,
Anthony



Thanks,
-Xiomara


On 04/23/09 09:31, Anthony Petrov wrote:

Hi Xiomara,

Thank you for the comments!

On 4/23/2009 6:27 PM Xiomara Jayasena wrote:
Release Engineering uses c:\jdk ... when building on windows.  We 
will still need that.
Ups. I'm sorry about that, I really didn't know you use this path. 
This was the reason I initiated the discussion on the build-dev@ 
yesterday. Since I didn't receive any feedback, I assumed nobody cares 
about c:\jdk.



I am understanding that, that is being removed?

-  _BOOTDIR1  =$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
+  _BOOTDIR1  =$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archiv

Yes, this is correct.
Well, then perhaps I'll go and add the _BOOTDIR3 then. So, on Windows 
we will have three options: c:\jdk, c:\program files\java, and finally 
the standard j: approach introduced with the fix. Does it sound good?



RE tries to localized all the software we use in the local build system.
So do I on my local Windows build machine. And it seems that 
maintaining a local copy of the standard directory tree (/java --> j:) 
is *way* simpler than inventing something new. I just sync my local 
directory with the /java network share, and use the 'subst' command to 
make the J: disk out of the directory. With this configuration all the 
default options in the makefiles make sense, and I don't need to 
define any additional environment variables prior to running make 
(well, excluding the vsvars32.bat, of course, but that's another story).


PS. I moved the discussion to the build-dev@, since it is basically 
the fix reviewing.


--
best regards,
Anthony

Re: Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)

[Anthony Petrov]

Hi Xiomara,

Thank you for the comments!

On 4/23/2009 6:27 PM Xiomara Jayasena wrote:
Release Engineering uses c:\jdk ... when building on windows.  We will 
still need that.
Ups. I'm sorry about that, I really didn't know you use this path. This 
was the reason I initiated the discussion on the build-dev@ yesterday. 
Since I didn't receive any feedback, I assumed nobody cares about c:\jdk.



I am understanding that, that is being removed?

-  _BOOTDIR1  =$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
+  _BOOTDIR1  =$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archiv

Yes, this is correct.
Well, then perhaps I'll go and add the _BOOTDIR3 then. So, on Windows we 
will have three options: c:\jdk, c:\program files\java, and finally the 
standard j: approach introduced with the fix. Does it sound good?



RE tries to localized all the software we use in the local build system.
So do I on my local Windows build machine. And it seems that maintaining 
a local copy of the standard directory tree (/java --> j:) is *way* 
simpler than inventing something new. I just sync my local directory 
with the /java network share, and use the 'subst' command to make the J: 
disk out of the directory. With this configuration all the default 
options in the makefiles make sense, and I don't need to define any 
additional environment variables prior to running make (well, excluding 
the vsvars32.bat, of course, but that's another story).


PS. I moved the discussion to the build-dev@, since it is basically the 
fix reviewing.


--
best regards,
Anthony

Review request: 6833444 (_BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms)

[Anthony Petrov]

Please review the fix for the CR mentioned in the subject. The webrev:

http://cr.openjdk.java.net/~anthony/webrev-6833444.0/

I verified the fix on MS Windows platform, and it works pretty well.

--
best regards,
Anthony

_BOOTDIR1 on MS Windows platform

[Anthony Petrov]

Hello,

Back in 2007 we already discussed this issue with Kelly, but 
transitioning to Mercurial just stopped the work. So, I would like to 
revive this now.


Here's a part of the output generated by `grep -r BOOTDIR make/*`:


make/common/shared/Defs-solaris.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-solaris.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR1  
=$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-windows.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)
make/common/shared/Defs-linux.gmk:  _BOOTDIR1  
=$(SLASH_JAVA)/re/jdk/$(PREVIOUS_JDK_VERSION)/archive/fcs/binaries/$(PLATFORM)-$(ARCH)
make/common/shared/Defs-linux.gmk:  _BOOTDIR2  
=$(USRJDKINSTANCES_PATH)/jdk$(PREVIOUS_JDK_VERSION)


One can notice that the _BOOTDIR1 is defined differently on MS Windows 
platform. I would like to propose a change so that its value would be 
the same as on other platforms. The SLASH_JAVA on MS Windows equals to 
the J: drive. So one could setup the same directory tree as on 
Linux/Solaris, use the subst command to make the directory the J: drive, 
and be able to build the jdk w/o specifying the ALT_BOOTDIR variable 
manually.


Is there any objection to removing the 
$(_system_drive)/jdk$(PREVIOUS_JDK_VERSION) default path?


--
best regards,
Anthony

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hi Mark,

On 08/28/2008 09:35 PM Mark Wielaard wrote:

On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote:
1. The patch cuts off the embedded versions of these libraries from 
OpenJDK source code. In fact, there may exist systems where these 
libraries are not installed. And currently OpenJDK runs perfectly on 
these systems since it have the libraries compiled in.

Yes it does remove the upstream sources. But I admit to be slightly
confused about this practice of embedding upstream source code into your
own code repository. If we want to support static linking of libraries
wouldn't it be enough to configure and detect the static library .a
versions and link against those?
This seems to be a very neat idea. I personally like it. But what about 
MS Windows builds?


--
best regards,
Anthony

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

On 08/28/2008 08:33 PM Martin Buchholz wrote:

I'm thinking:
- the MMX support is in pnggccrd.c,
- but that file is never compiled in OpenJDK

Why? There's the following line in the make/sun/splashscreen/Makefile:

vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng

that effectively includes all *.c files in the libpng sources directory 
(src/share/native/sun/awt/libpng/) in the compilation process. Honestly, 
to me this seems to be a problem with the #ifdef's/#define's logic in 
libpng, rather than the strong necessity to disable MMX support at all. 
At least the correct working of this code on MS Windows and 32-bit Linux 
systems (if compiling using the recommended build environment) somewhat 
proves this point of view.


--
best regards,
Anthony


- so... how could png ever work when PNG_NO_MMX_CODE is not defined,
  on any platform?

I am suspicious that png splashscreens are actually broken
without my proposed patch.  Has this actually been tested?

I googled a little and have a theory.
"-z defs" is supposed to be ignored for shared libs
(but why are we using it to build libsplashscreen.so?)
but very recent gcc toolchains don't ignore it the way they
perhaps should.

E.g. Here's a debian bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142
On hppa -Wl,-z,defs is not ignored for shared libraries

But using "-z defs" is actually good engineering practice,
since it catches problems at link time instead of run time.
Whether or not it's a bug in my toolchain, my toolchain
detects the unsatisfied symbols in the link.
There's a good chance that my change will be necessary
to build OpenJDK on future stock Linux systems.

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hi Martin,

The AWT folks think we need to guard this CPPFLAGS setting with the 
following condition:


ifneq ($(PLATFORM), windows)
...
endif

We don't use gcc on Windows, and everything works just fine with MS VS. 
Please feel free to submit the patch with this change, and please add 
OpenJDK user 'art' to the reviewers list. Given this modification 
applied, I'm approving the fix. The push is going to be performed by 
Artem (CC'ed). Thanks in advance!


--
best regards,
Anthony


On 08/29/2008 01:58 AM Martin Buchholz wrote:

Hi Anthony,

I investigated yet a bit more, and finally am sure about the underlying cause:
Standard gcc does not define __MMX__, but ours does,
perhaps because it has been configured to make MMX support the default.

$ gcc -E -dM main.c | grep __MMX__
$ /usr/local/google/fauxJDKCompiler/gcc -E -dM main.c | grep __MMX__
#define __MMX__ 1

By default, pngconf.h uses mmx instructions if __MMX__ is defined.
But this can be disabled by -DPNG_NO_MMX_CODE.

Since the existing code in OpenJDK depends on MMX not being used
(since pnggccrd.c is never compiled) -DPNG_NO_MMX_CODE should
be added to CPPFLAGS in the splashscreen makefile unconditionally.

Requesting permission to push...

You could file a new bug, or we could reuse 6613927, at your option.

Martin

# HG changeset patch
# User martin
# Date 1219960566 25200
# Node ID 198b5e82cd0fa4b42cafabce3e763e2a2cb3888c
# Parent  1267605489211c6c162bb246f653759e933bd06e
6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit)
Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
Reviewed-by: anthony

diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile
+++ b/make/sun/splashscreen/Makefile
@@ -85,13 +85,6 @@
 CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
-I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
 CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
-I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3

-ifeq ($(PLATFORM), linux)
-  ifeq ($(ARCH_DATA_MODEL), 64)
-# 64-bit gcc has problems compiling MMX instructions.
-# Google it for more details. Possibly the newer versions of
-# the PNG-library and/or the new compiler will not need this
-# option in the future.
-CPPFLAGS += -DPNG_NO_MMX_CODE
-  endif
-endif
-
+# Shun the less than portable MMX assembly code in pnggccrd.c,
+# and use alternative implementations in C.
+CPPFLAGS += -DPNG_NO_MMX_CODE

On Thu, Aug 28, 2008 at 9:33 AM, Martin Buchholz <[EMAIL PROTECTED]> wrote:

I'm thinking:
- the MMX support is in pnggccrd.c,
- but that file is never compiled in OpenJDK
- so... how could png ever work when PNG_NO_MMX_CODE is not defined,
 on any platform?

I am suspicious that png splashscreens are actually broken
without my proposed patch.  Has this actually been tested?

I googled a little and have a theory.
"-z defs" is supposed to be ignored for shared libs
(but why are we using it to build libsplashscreen.so?)
but very recent gcc toolchains don't ignore it the way they
perhaps should.

E.g. Here's a debian bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142
On hppa -Wl,-z,defs is not ignored for shared libraries

But using "-z defs" is actually good engineering practice,
since it catches problems at link time instead of run time.
Whether or not it's a bug in my toolchain, my toolchain
detects the unsatisfied symbols in the link.
There's a good chance that my change will be necessary
to build OpenJDK on future stock Linux systems.

Martin


On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:

Hello Martin,

Thank you for the patch. Though there's a little concern: how does the bare
libpng deal with this issue when compiled using the toolchain you use? I
mean, the problem is not reproducible when compiling on a "regular" 32-bit
system, so it might be important to identify the root cause of this issue.
Could you please take a look at the libpng source (the version that was
forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your
tools (by the way, what are they?)? If this is the problem with this
particular version of libpng, and newer versions do not experience this
problem, then this might be probably a justification for updating our
version of libpng rather than disabling the usage of MMX for all platforms.
What do you think?

--
best regards,
Anthony


On 08/28/2008 02:23 AM Martin Buchholz wrote:

Anthony,

Thanks for your patience; you were entirely right,
it was indeed necessary to define PNG_NO_MMX_CODE.
Since pnggccrd.c is never compiled, and it contains the MMX code,
the only correct thing appears to be to define this macro unconditionally.
The obvious patch follows (tested on 32-bit Ubuntu Linux with
very recent gcc toolchain)

(Has anyone actually tested png splashscreen ima

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hi Mark,

Thanks for pointing this. Actually, the patch existing in the IcedTea 
seems to have two potential issues that we at Sun are worried about:


1. The patch cuts off the embedded versions of these libraries from 
OpenJDK source code. In fact, there may exist systems where these 
libraries are not installed. And currently OpenJDK runs perfectly on 
these systems since it have the libraries compiled in.


2. The system libraries may contain issues/errors/bugs/whatever which 
our code cannot deal with (I think Java2D folks may collaborate on 
this). Throwing the libraries away from the OpenJDK code may reveal some 
of the issues, but we obviously can't fix the libraries as fast as our 
code. And also, we do guarantee some behavior (like understanding file 
format versions or whatever) that we wouldn't be able to guarantee if we 
can't ship our copies of the libraries.


So, it seems that a better patch would allow choosing whether the user 
wants to build the OpenJDK using the embedded versions of the libraries 
(with which the OpenJDK is guaranteed to behave as it should), or the 
user is brave enough to dynamically link to the system copies and the 
user is not going to redistribute the OpenJDK to systems that do not 
have these libraries installed.


That actually was the main idea of the patch for 
http://bugs.sun.com/view_bug.do?bug_id=6565114. Could the IcedTea 
maintainers do some similar stuff and provide us with the patch? Thanks 
in advance!


--
best regards,
Anthony


On 08/28/2008 12:51 PM Mark Wielaard wrote:

Hi,

On Wed, 2008-08-27 at 15:34 -0700, Martin Buchholz wrote:

Adding options to use the system versions of these graphics libraries
is integrated into IcedTea already.  IcedTea and Sun AWT engineers
should work together to put such changes into OpenJDK7.


Yes, this would be great so we don't have to maintain so many extra
external patches. The patch to do this in icedtea6 is at:
http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-libraries.patch
That makes sure the system versions of the png, jpeg and zlib libraries
are used.

Cheers,

Mark

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hello Martin,

Thank you for the patch. Though there's a little concern: how does the 
bare libpng deal with this issue when compiled using the toolchain you 
use? I mean, the problem is not reproducible when compiling on a 
"regular" 32-bit system, so it might be important to identify the root 
cause of this issue. Could you please take a look at the libpng source 
(the version that was forked for the purposes of OpenJDK is 1.2.18) and 
try compiling it with your tools (by the way, what are they?)? If this 
is the problem with this particular version of libpng, and newer 
versions do not experience this problem, then this might be probably a 
justification for updating our version of libpng rather than disabling 
the usage of MMX for all platforms. What do you think?


--
best regards,
Anthony


On 08/28/2008 02:23 AM Martin Buchholz wrote:

Anthony,

Thanks for your patience; you were entirely right,
it was indeed necessary to define PNG_NO_MMX_CODE.
Since pnggccrd.c is never compiled, and it contains the MMX code,
the only correct thing appears to be to define this macro unconditionally.
The obvious patch follows (tested on 32-bit Ubuntu Linux with
very recent gcc toolchain)

(Has anyone actually tested png splashscreen images on 32 or 64-bit Linux?)

# HG changeset patch
# User martin
# Date 1219875308 25200
# Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c
# Parent  1267605489211c6c162bb246f653759e933bd06e
6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit)
Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
Reviewed-by: anthony

diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile
+++ b/make/sun/splashscreen/Makefile
@@ -85,13 +85,6 @@
 CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
-I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
 CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
-I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3

-ifeq ($(PLATFORM), linux)
-  ifeq ($(ARCH_DATA_MODEL), 64)
-# 64-bit gcc has problems compiling MMX instructions.
-# Google it for more details. Possibly the newer versions of
-# the PNG-library and/or the new compiler will not need this
-# option in the future.
-CPPFLAGS += -DPNG_NO_MMX_CODE
-  endif
-endif
-
+# Shun the less than portable MMX assembly code in pnggccrd.c.
+# Newer versions of the PNG-library may not need this option.
+CPPFLAGS += -DPNG_NO_MMX_CODE

Martin

On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:

Hi Martin,

On 08/25/2008 08:17 PM Martin Buchholz wrote:

Thanks for the link, but...
- The fix for 6613927 is applied in my workspace

And it gets activated when building on a 64-bit system only. Could you
please take a look at the make/sun/splashscreen/Makefile file and make sure
it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really
very interesting if this will resolve the issue. Thank you in advance.

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hi Martin,

On 08/25/2008 08:17 PM Martin Buchholz wrote:

Thanks for the link, but...
- The fix for 6613927 is applied in my workspace
And it gets activated when building on a 64-bit system only. Could you 
please take a look at the make/sun/splashscreen/Makefile file and make 
sure it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is 
really very interesting if this will resolve the issue. Thank you in 
advance.


This is not an ideal solution. Updating to a new libpng version would be 
fine, however these should be some clean sources (i.e. vanilla libpng 
source tarball, w/o any static <-> const swaps, etc.), and secondly it 
requires some Sun-internal bureaucratic process to put these sources to 
the OpenJDK source tree.


Currently I don't see the suggested change is justified since using the 
standard build environment does not reproduce the problem. However, you 
might probably be interested in fixing the following CR: 
http://bugs.sun.com/view_bug.do?bug_id=6565114
This would eliminate this problem at once and forever. Diego 'Flameeyes' 
Pettenò didn't provide us with a working patch (please see the archives 
of the awt-dev mailing list), hence the CR has been suspended.


--
best regards,
Anthony

Re: splashscreen.so is missing pnggccrd.c

[Anthony Petrov]

Hi Martin,

On 08/24/2008 04:44 AM Martin Buchholz wrote:

../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In
function `png_init_mmx_flags':
png.c:(.text+0xbb): undefined reference to `png_mmx_support'

It looks like another reincarnation of
http://bugs.sun.com/view_bug.do?bug_id=6613927
It seems strange the problem arises on a 32-bit system though...

Could you please try using the workaround from this bug to see if it 
solves the issue?


--
best regards,
Anthony

Re: Building on Win 2008

[Anthony Petrov]

Hi Kelly,

On 07/31/2008 10:58 PM Kelly O'Hair wrote:

So no plugin code, no installation bundle code, etc.

Right. But all the currently opensourced code was buildable at that time.

 From this point it was clean: VS2005ExpressSP1 + Platform SDK for 
Win2003R2 + DirectX SDK June 2007 + cygwin. Nothing else.

That sounds right then. (I assume you also dealt with the manifest issue?)
Yes, I manually created the *.exe.manifest files (see 6523947 for the 
workaround).



Sounds right. But be careful doing any plug and play with a jvm.dll.
One needs to build the hotspot first, and then use the 
ALT_HOTSPOT_IMPORT_PATH to point the j2se makefiles to the correct jvm.


Until they get opensourced, the community doesn't need to worry about 
their compatibility with Express, does it?

Remains to be seen. We have no control over this compiler and
cannot predict what happens with each Express compiler release.
Frankly, we don't have much control over the Professional compiler as 
well. So I don't see any significant difference between the free and 
commercial editions of VS from this point.


--
best regards,
Anthony

Re: Building on Win 2008

[Anthony Petrov]

On 7/31/2008 7:14 PM Kelly O'Hair wrote:

Define "complete Hotspot and J2SE code".
Just OpenJDK?
Was this the JRL or full Sun JDK sources?
Just hotspot and j2se (or now called "jdk") directories?

These were old-good j2se and hotspot workspaces back in June 2007.


Just installing an Express compiler and using it doesn't mean that
during the build the Professional files installed on the machine
are not used. To know it works, you have to start with a clean
install of the OS and Express.
The system did not have the Professional version installed for sure. 
From this point it was clean: VS2005ExpressSP1 + Platform SDK for 
Win2003R2 + DirectX SDK June 2007 + cygwin. Nothing else.
...Oh yeah, there were also a couple of unicows-related files (MSLU), 
but this dependency is going to die (if not already).



Hotspot certainly could be built with the Express compiler, and
I suspect much of the OpenJDK if not all of it right now can be
built with the Express compiler.
But there are parts of the Sun JDK sources that use ATL and cannot be
built with the Express compiler.
It's not clear if and when those sources might end up in the OpenJDK.
Exactly. So from the community point of view it is important to be able 
to build the code that is available now using the free compilers. And if 
it builds with Express, this is great. For Sun JDK we can continue using 
Professional versions for the parts that are not buildable otherwise. 
Until they get opensourced, the community doesn't need to worry about 
their compatibility with Express, does it?


--
best regards,
Anthony



If you can use the Express compiler for your OpenJDK work, that's great,
just make sure that's indeed what you are using. ;^)

-kto

Anthony Petrov wrote:
About a year ago I did build the complete Hotspot and J2SE code using 
VS2005 Express + MS Platform SDK + DirectX SDK - all downloaded for 
free from the Microsoft web-site. During building I identified some 
bugs (to name a few: 6486546, 6488751, 6523947). Some of them 
belonging to the J2SE code I've fixed myself, some were fixed by the 
Hotspot team. AFAIR, apart from the problem with the manifest files 
(see 6523947) I don't recall any unresolved issues... Are there any?


--
best regards,
Anthony


On 07/30/2008 08:23 PM Kelly O'Hair wrote:

We are focusing on the Professional edition first because the free
Express edition does not include the ATL include or lib files.

I'm not an ATL expert, but JDK builds have a dependence on it and it's
probably not going away for quite some time I'm told.

It's quite possible that much of the OpenJDK is very buildable with the
free Express edition, and once we are building with the Professional
edition, someone can see how much is buildable with the Express edition.

-kto

Anthony Petrov wrote:

On 07/29/2008 11:03 PM Erik Trimble wrote:
I certainly can't speak for Sun on this.  But, I don't think there 
is any immediate plans to use GCC on Windows. It would probably be 
OK if someone wanted to try, but I can't imagine it being even 
remotely easy.  There's just so much stuff dependent on the various 
Visual Studio or MS SDK header files, that I'm almost positive you 
have to install them to do the build, so why bother with GCC?  
(even from a Free Software point of view, if you can't get away 
from the proprietary MS SDK/VisStudio, then compiling with GCC 
rather than the MS-provided one isn't going to be really any win at 
all).
Indeed. But we should make it possible to use the free versions of 
the MS Visual Studio at least.


--
best regards,
Anthony

Re: Building on Win 2008

[Anthony Petrov]

On 07/30/2008 07:56 PM Erik Trimble wrote:
would make it very nice.  Unfortunately, the free version of VS is 
actually _very_ different than the Professional version, and not just 
the compiler itself (which, has a whole 'nother set of bugs unique to 
it...).
AFAIK, that was true for the free version of VS2003. Starting from 
VS2005 Express they provide exactly the same compiler that comes with 
the Professional VS (I don't say for the bit-to-bit equality of the 
executable files, but it is the same compiler anyway).


--
best regards,
Anthony

Re: Building on Win 2008

[Anthony Petrov]

About a year ago I did build the complete Hotspot and J2SE code using 
VS2005 Express + MS Platform SDK + DirectX SDK - all downloaded for free 
from the Microsoft web-site. During building I identified some bugs (to 
name a few: 6486546, 6488751, 6523947). Some of them belonging to the 
J2SE code I've fixed myself, some were fixed by the Hotspot team. AFAIR, 
apart from the problem with the manifest files (see 6523947) I don't 
recall any unresolved issues... Are there any?


--
best regards,
Anthony


On 07/30/2008 08:23 PM Kelly O'Hair wrote:

We are focusing on the Professional edition first because the free
Express edition does not include the ATL include or lib files.

I'm not an ATL expert, but JDK builds have a dependence on it and it's
probably not going away for quite some time I'm told.

It's quite possible that much of the OpenJDK is very buildable with the
free Express edition, and once we are building with the Professional
edition, someone can see how much is buildable with the Express edition.

-kto

Anthony Petrov wrote:

On 07/29/2008 11:03 PM Erik Trimble wrote:
I certainly can't speak for Sun on this.  But, I don't think there is 
any immediate plans to use GCC on Windows. It would probably be OK if 
someone wanted to try, but I can't imagine it being even remotely 
easy.  There's just so much stuff dependent on the various Visual 
Studio or MS SDK header files, that I'm almost positive you have to 
install them to do the build, so why bother with GCC?  (even from a 
Free Software point of view, if you can't get away from the 
proprietary MS SDK/VisStudio, then compiling with GCC rather than the 
MS-provided one isn't going to be really any win at all).
Indeed. But we should make it possible to use the free versions of the 
MS Visual Studio at least.


--
best regards,
Anthony

Re: Building on Win 2008

[Anthony Petrov]

On 07/29/2008 11:03 PM Erik Trimble wrote:
I certainly can't speak for Sun on this.  But, I don't think there is 
any immediate plans to use GCC on Windows. It would probably be OK if 
someone wanted to try, but I can't imagine it being even remotely easy.  
There's just so much stuff dependent on the various Visual Studio or MS 
SDK header files, that I'm almost positive you have to install them to 
do the build, so why bother with GCC?  (even from a Free Software point 
of view, if you can't get away from the proprietary MS SDK/VisStudio, 
then compiling with GCC rather than the MS-provided one isn't going to 
be really any win at all).
Indeed. But we should make it possible to use the free versions of the 
MS Visual Studio at least.


--
best regards,
Anthony

Re: Patch for libpng unresolved methods on x86_64 with MMX

[Anthony Petrov]

This is a known issue. Anyway, thanks for reporting it! Please refer to 
the following bug to track the status of the problem:


http://bugs.sun.com/view_bug.do?bug_id=6613927

Currently the bug is being fixed.

Concerning the possibility of using an external libpng library, we've 
got the following bug report:


http://bugs.sun.com/view_bug.do?bug_id=6565114

However, we're postponing the fix because the submitter of the patch 
haven't prepared a clean patch yet. The main reason to use a slightly 
more comprehensive patch is to be able to use both the internal version 
of the library and the external one (if the developer defines the 
EXTERNAL_LIBPNG macro when building OpenJDK). It would be very helpful 
if someone could provide a clean patch for the latter bug.


--
best regards,
Anthony


On 10/12/2007 05:14 AM Frederic Simon wrote:

I tried to build b21 on my Ubuntu 7.04 and got:
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/png.o: 
In function `png_init_mmx_flags':

png.c:(.text+0xbc): undefined reference to `png_mmx_support'
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: 
In function `png_push_process_row':

pngpread.c:(.text+0x86e): undefined reference to `png_read_filter_row'
pngpread.c:(.text+0x934): undefined reference to `png_do_read_interlace'
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: 
In function `png_progressive_combine_row':

pngpread.c:(.text+0x141): undefined reference to `png_combine_row'
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/pngread.o: 
In function `png_read_row':

pngread.c: (.text+0xa7d): undefined reference to `png_combine_row'
pngread.c:(.text+0xbd8): undefined reference to `png_combine_row'
pngread.c:(.text+0xbfc): undefined reference to `png_combine_row'
pngread.c:(.text+0xc98): undefined reference to `png_combine_row'
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/pngread.o:pngread.c:(.text+0xcb4): 
more undefined references to `png_combine_row' follow
/work/java.net/openjdk.trunk/control/build/linux-amd64/tmp/sun/sun.awt/splashscreen/obj64/pngread.o: 
In function `png_read_row':

pngread.c:(.text+0xce5): undefined reference to `png_read_filter_row'
pngread.c:(.text+0xd0d): undefined reference to `png_do_read_interlace'
collect2: ld returned 1 exit status
make[3]: *** 
[/work/java.net/openjdk.trunk/control/build/linux-amd64/lib/amd64/libsplashscreen.so] 
Error 1
make[3]: Leaving directory 
`/work/java.net/openjdk.trunk/j2se/make/sun/splashscreen'


I found this thread talking about it:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-August/000192.html

So, I tried to modified the makefile to use the system png. It's very 
roughly removing the integrated libpng and linking with png12.
Here is the patch: 
https://www.jfrog.org/svn-jfrog/openjdk/patch/SplashScreen_libpng12.patch


Hope it helps.

--
http://freddy33.bglogspot.com/
http://www.jfrog.org/

Re: Success :) building openjdk for windows

[Anthony Petrov]

Yes. I used Visual C++ Express 2005 SP1.

--
best regards,
Anthony

On 8/19/2007 5:36 AM Ted Neward wrote:

You did this with Visual C++ Express 2005? (The term "VS2005 Express" throws
me, as there is no "Visual Studio Express" SKU from Microsoft that I'm aware
of.)

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 


-Original Message-
From: [EMAIL PROTECTED] [mailto:build-dev-
[EMAIL PROTECTED] On Behalf Of Anthony Petrov
Sent: Friday, August 17, 2007 12:21 AM
To: Rishi Khare
Cc: build-dev@openjdk.java.net; [EMAIL PROTECTED]; Igor
Nekrestyanov
Subject: Re: Success :) building openjdk for windows

I took some part in testing the VS2005 Express to build the JDK. So far
there's no any major problem present except the following:
http://bugs.sun.com/view_bug.do?bug_id=6523947
However, this RFE has a very simple workaround provided. Please try it
and tell us about the results.

--
best regards,
Anthony


On 08/17/2007 10:36 AM Igor Nekrestyanov wrote:

The biggest pain is to use Visual Studio.net <http://Studio.net>

2003

and not Visual Studio.2005 Express edition or GCC for windows or

MingW

or some other free Compiler for windows.The idea of buying any
software to work on open source development is not very encouraging.


I agree it will be nice to build with freely available tools only.
I have vague recollection that usage of free MS compiler was

evaluated n

the past and there were some complications.
Anyway, this sounds like interesting project to explore (adapting

build

procedure to use free tools only) even without access to mercurial.

-igor

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.12.0/957 - Release Date:
8/16/2007 1:46 PM



No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.484 / Virus Database: 269.12.0/960 - Release Date: 8/18/2007

3:48 PM
 

Re: Success :) building openjdk for windows

[Anthony Petrov]

I took some part in testing the VS2005 Express to build the JDK. So far 
there's no any major problem present except the following: 
http://bugs.sun.com/view_bug.do?bug_id=6523947
However, this RFE has a very simple workaround provided. Please try it 
and tell us about the results.


--
best regards,
Anthony


On 08/17/2007 10:36 AM Igor Nekrestyanov wrote:


The biggest pain is to use Visual Studio.net  2003 
and not Visual Studio.2005 Express edition or GCC for windows or MingW 
or some other free Compiler for windows.The idea of buying any 
software to work on open source development is not very encouraging.



I agree it will be nice to build with freely available tools only.
I have vague recollection that usage of free MS compiler was evaluated n 
the past and there were some complications.
Anyway, this sounds like interesting project to explore (adapting build 
procedure to use free tools only) even without access to mercurial.


-igor

Re: encumbrances update

[Anthony Petrov]

Hmm...

On 08/01/2007 10:58 PM Dan Fabulich wrote:

It is believed to build and work on all platform combinations : windows,
linux, solaris, 32 and 64 bit, but testing has focused on the 32 bit
versions.
"believed to build"?  Has anyone yet tried doing the standard OpenJDK 
build on Windows, following the directions described in the documentation?
There's still no reason to believe these build scripts work until 
somebody (anybody) says: "Yes, I did the build, just like any other 
non-Sun employee would.  The build works for me."
I'm afraid that until someone tells us exactly: "I've got the following 
problems with builds on Windows: this, this, and this", we can't help 
you at all, can we?..


--
best regards,
Anthony