Re: RFR: JDK-8152959: Build crashes in jdk9-hs-comp on Linux with gnumake 3.81

2016-03-29 Thread Chris Plummer

Hi Erik,

I can confirm that this fixes the issue I was seeing.

thanks,

Chris

On 3/29/16 6:14 AM, Erik Joelsson wrote:

Hello,

The VarHandles change introduced a new gensrc step that crashes when 
using gnumake 3.81. Newer versions of make seem to handle the 
construct in that file. I have found a way to express the makefile, 
which is a bit more correct, and doesn't crash.


The relevant part of the change is the extra dollars inside the eval. 
An eval inside a define that is expected to be called using eval, 
requires double escaping of dollars for correct handling. Most of the 
time it works without though. In this case adding it seems to stop the 
crashing.


The rest of the change is minor cleanups.

I intend to push this to hs-comp since that's where the varhandles 
patch currently sits.


Bug: https://bugs.openjdk.java.net/browse/JDK-8152959
Webrev: http://cr.openjdk.java.net/~erikj/8152959/webrev.jdk.01/

/Erik




Re: Provide zipped javadoc archive from make

2016-03-29 Thread Jiri Vanek

Hello Again!

Sorry for delay in reply.

There is webrev

https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v1/
https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v1/webrev.zip

with patch as was (moreover) agreed in this thread for *jdk8*

As I was studying the makefiles, I think I did not violated to much conditions 
by this hunk of code:)
I thought that 8 will be much more simple, but at the end it evolved to same "find all roots" as 
discussed for 9 and modules.


The only thing I don't like in this patch is unsuitability of zip to zip directories with stripped 
path.


I went by pushd/popd  but I had seen you like cd in  make files more.


Thanx for any feedback!

  J.

On 03/08/2016 03:50 PM, Erik Joelsson wrote:

I wouldn't go that far, but I won't have time to look into it for a while yet 
at least.

/Erik

On 2016-03-08 15:34, Jiri Vanek wrote:

Ping?

Or is this going to be considered closed-wont "fix"?

Thanx!

 J.
On 02/29/2016 04:24 PM, Jiri Vanek wrote:

On 02/26/2016 08:05 PM, Jonathan Gibbons wrote:

On 02/26/2016 03:49 AM, Jiri Vanek wrote:

On 02/25/2016 06:34 PM, Jonathan Gibbons wrote:

On 02/25/2016 09:23 AM, Jiri Vanek wrote:


I must be missing something. Dozens? Of varius runs of javadoc?

I thought that javadoc ending at the end in single drectory is one single 
javadoc for java. If
you are referring to javadoc generated by "per module" then one jjoined zip is 
enough for me.



Jiri,

If you accept the premise  that javadoc writes one stylesheet.css file per run 
of javadoc, take a
look at the following list:


Then my goal will be to crate a trget, which takes
   build/linux-x86_64-normal-server-release/images/docs/
and pack it to
 build/linux-x86_64-normal-server-release/images/javadoc.zip

It should contains also the "smaller api" you are mentioning below? If not, 
then those should
appear in this zip too.


$ find build/linux-x86_64-normal-server-release/images/docs/ -name 
stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css



build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css
build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css

build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css




The "main"/"Java SE" javadoc bundle that most are aware of is the shortest 
filename, in the
middle
of the list, but there are lots of other smaller APIs that get their own doc 
bundle.  You can
get at
most of them in released doc sets through the top-level "brick wall" page, or 
by using your
favorite
search engine.


Hmm.. Do you have some?  javadoc offline search is quite painful think. (Even 
with new search in
9, which seems to have some troubles on local filesystem). The best search 
engine I know is
(unluckily) https://github.com/judovana/JavadocOfflineSearch


The point of the preceding list was to say that each directory containing 
stylesheet.css is the
root
of a separate, distinct, javadoc bundle.  So the smaller APIs that get their 
own bundle are
precisely the ones given in the preceding list, other than the main javadoc 
bundle.

The point of the comment about the brick wall and search engines was to 
indicate how most people
will find these doc bundles in normal use, when they don't have a cheat sheet 
like the list above.


yes I got that. But Then this compressed shattered javadoc needs more thoughts.

What is expected format of distribution?
I can imagine: web accessible, unapcked "all docs" and "zipepd "all docs".
But never several 

Re: RFR: JDK-8152959: Build crashes in jdk9-hs-comp on Linux with gnumake 3.81

2016-03-29 Thread Tim Bell

Erik:

The VarHandles change introduced a new gensrc step that crashes when 
using gnumake 3.81. Newer versions of make seem to handle the 
construct in that file. I have found a way to express the makefile, 
which is a bit more correct, and doesn't crash.


The relevant part of the change is the extra dollars inside the eval. 
An eval inside a define that is expected to be called using eval, 
requires double escaping of dollars for correct handling. Most of the 
time it works without though. In this case adding it seems to stop the 
crashing.


The rest of the change is minor cleanups.

I intend to push this to hs-comp since that's where the varhandles 
patch currently sits.


Bug: https://bugs.openjdk.java.net/browse/JDK-8152959
Webrev: http://cr.openjdk.java.net/~erikj/8152959/webrev.jdk.01/


Looks good to me.

/Tim



RFR: JDK-8152959: Build crashes in jdk9-hs-comp on Linux with gnumake 3.81

2016-03-29 Thread Erik Joelsson

Hello,

The VarHandles change introduced a new gensrc step that crashes when 
using gnumake 3.81. Newer versions of make seem to handle the construct 
in that file. I have found a way to express the makefile, which is a bit 
more correct, and doesn't crash.


The relevant part of the change is the extra dollars inside the eval. An 
eval inside a define that is expected to be called using eval, requires 
double escaping of dollars for correct handling. Most of the time it 
works without though. In this case adding it seems to stop the crashing.


The rest of the change is minor cleanups.

I intend to push this to hs-comp since that's where the varhandles patch 
currently sits.


Bug: https://bugs.openjdk.java.net/browse/JDK-8152959
Webrev: http://cr.openjdk.java.net/~erikj/8152959/webrev.jdk.01/

/Erik


Re: [9] Review Request: 7179078 Remove @beaninfo processing from the makefiles

2016-03-29 Thread Erik Joelsson

Looks good, nice cleanup!

/Erik

On 2016-03-25 18:37, Sergey Bylokhov wrote:

Hello,
Please review the fix for jdk9.

Before the JEP 256 [1], we generated beanInfo classes + copied some 
other resources during the build. After the jep was integrated these 
files became obsolete and can be removed.

 - Utility classes were removed.(see [2] how they were used before)
 - The images were moved from the make folder to the src, so they will 
be copied using standard mechanism.


[1] https://bugs.openjdk.java.net/browse/JDK-8044826
[2] 
http://cr.openjdk.java.net/~serb/4763438/webrev.00/make/gensrc/GensrcSwing.gmk.sdiff.html


Bug: https://bugs.openjdk.java.net/browse/JDK-7179078
Webrevs can be found at:
http://cr.openjdk.java.net/~serb/7179078/jdk.00
http://cr.openjdk.java.net/~serb/7179078/root.00