You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Uwe Schindler <uw...@thetaphi.de> on 2019/04/15 09:52:02 UTC
Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Hi committers,
As discussed on https://issues.apache.org/jira/browse/LUCENE-8738, we are planning to switch master branch to use Java 11 tomorrow. The Apache and Policeman Jenkins servers are prepared to handle that change, but now it's your turn:
- Install a JDK 11 (remark: no Oracle JDK is needed, just use OpenJDK, e.g. from AdoptOpenJDK)
- If you are working on master, you have to use Java 11 also in your IDE (run ant eclipse, netbeans,...). We tested IDE integrations for the common cases. If there are bugs, just fix them if you stumble on them.
- If you are also maintaining Jenkins servers, update their configs!
- If your merge/cherry pick changes from master to 8.x, don't forget to run precommit with Java 8 (!) and adopt needed changes.
We will merge the branch with those changes tomorrow, 2019-04-16 afternoon UTC time, around 12 pm. As always, some hickups might happen, so ignore failing Jenkins jobs! I hope it settles by the time.
What's not working:
- The HTML linter based on HTML Tidy was disabled until we found a replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it might happen that bad javadocs are not detected in master but after merge to 8.x branch they might suddenly appear.
- OpenClover code coverage Jenkins Jobs were disabled (no support yet for Java 11)
TODOs:
- Use Java 11 features, e.g. replace many unmodifiable collections with Map.of/Set.of/List.of constructs
- Cleanup new warnings (we have to do this anyways, as javac is not even happy in Java 8)
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Erick Erickson <er...@gmail.com>.
Big THANKS to all who worked on this. I just took about 10 minutes to have everything up and running in IntelliJ, building from the command shell, etc. Most all of that just waiting for compilations to finish and tests to run….
That was about as painless as I could hope for.
Erick
> On Apr 16, 2019, at 5:13 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi,
>
> The master branch was updated to use Java 11 - all Jenkins Jobs are back online! Let's see if additional Jenkins failures occur.
>
> Go ahead and update your local dev environment:
>
>> As discussed on https://issues.apache.org/jira/browse/LUCENE-8738, we are
>> planning to switch master branch to use Java 11 tomorrow. The Apache and
>> Policeman Jenkins servers are prepared to handle that change, but now it's
>> your turn:
>>
>> - Install a JDK 11 (remark: no Oracle JDK is needed, just use OpenJDK, e.g.
>> from AdoptOpenJDK)
>> - If you are working on master, you have to use Java 11 also in your IDE (run
>> ant eclipse, netbeans,...). We tested IDE integrations for the common cases.
>> If there are bugs, just fix them if you stumble on them.
>> - If you are also maintaining Jenkins servers, update their configs!
>> - If your merge/cherry pick changes from master to 8.x, don't forget to run
>> precommit with Java 8 (!) and adopt needed changes.
>>
>> We will merge the branch with those changes tomorrow, 2019-04-16
>> afternoon UTC time, around 12 pm. As always, some hickups might happen,
>> so ignore failing Jenkins jobs! I hope it settles by the time.
>
> Here is the TODO list if you have an idea:
>
>> What's not working:
>>
>> - The HTML linter based on HTML Tidy was disabled until we found a
>> replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it
>> might happen that bad javadocs are not detected in master but after merge
>> to 8.x branch they might suddenly appear.
>
> Maybe we can use the infrastriucture using ASCIIdoctor of the Solr Ref guide here? It seems to also do link / HTML checks.
>
>> - OpenClover code coverage Jenkins Jobs were disabled (no support yet for
>> Java 11)
>>
>> TODOs:
>>
>> - Use Java 11 features, e.g. replace many unmodifiable collections with
>> Map.of/Set.of/List.of constructs
>> - Cleanup new warnings (we have to do this anyways, as javac is not even
>> happy in Java 8)
>
> Thanks, especially to Adrien for doing the initial work!
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Chris Hostetter <ho...@fucit.org>.
: > - The HTML linter based on HTML Tidy was disabled until we found a
: > replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it
: > might happen that bad javadocs are not detected in master but after merge
: > to 8.x branch they might suddenly appear.
:
: Maybe we can use the infrastriucture using ASCIIdoctor of the Solr Ref guide here? It seems to also do link / HTML checks.
The code in the ref-guide's CheckLinksAndAnchors.java is *very*
specialized around dealing with the specific problems that exist in
asciidoctor when building merged/monolithic docs (like our PDF) from
multiple source documents -- ie: only a small bit of it is about checking
links, most of it is about checking for duplicate anchors; and even the
link checking makes a lot of assumptions about the structure/conventions
of generated asciidoctor output.
If someone wanted to build a quick and dirty javadoc link checker, the
jsoup parsing code in CheckLinksAndAnchors.java might be a good starting
place, but it would probably be eaiser to build a new one then trying to
generalize what's there to work on arbitrary html.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Uwe Schindler <uw...@thetaphi.de>.
That groovy code is unfixable, it's a known issue. Warning existed since Java 9... We may try to update to later groovy, but it's a known issue and can be done later. One thing after the other! Just ignore it. For those who follow Jenkins jobs during the last years, it's well known.
Uwe
Am April 16, 2019 6:22:09 PM UTC schrieb Chris Hostetter <ho...@fucit.org>:
>
>: The master branch was updated to use Java 11 - all Jenkins Jobs are
>back online! Let's see if additional Jenkins failures occur.
>
>FYI: first oddity i noticed is coming from some groovy code that seems
>to run as part of "common.test" ?
>
>$ git clean -fx && cd solr/core/ && ant test
>-Dtestcase=TestCloudConsistency
>...
> [junit4] Tests summary: 1 suite, 2 tests
> [echo] 5 slowest tests:
>[junit4:tophints] 315.23s | org.apache.solr.cloud.ShardSplitTest
>[junit4:tophints] 260.44s | org.apache.solr.search.facet.TestJsonFacets
>[junit4:tophints] 208.15s | org.apache.solr.cloud.TestHossSanity
>[junit4:tophints] 186.80s |
>org.apache.solr.cloud.api.collections.ShardSplitTest
>[junit4:tophints] 125.64s | org.apache.solr.cloud.OnlyLeaderIndexesTest
>
>-check-totals:
>WARNING: An illegal reflective access operation has occurred
>WARNING: Illegal reflective access by
>org.codehaus.groovy.reflection.CachedClass
>(file:/home/hossman/.ivy2/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-2.4.15.jar)
>to method java.lang.Object.finalize()
>WARNING: Please consider reporting this to the maintainers of
>org.codehaus.groovy.reflection.CachedClass
>WARNING: Use --illegal-access=warn to enable warnings of further
>illegal reflective access operations
>WARNING: All illegal access operations will be denied in a future
>release
>
>common.test:
>
>BUILD SUCCESSFUL
>Total time: 1 minute 31 seconds
>
>I'm using...
>
>hossman@tray:~/lucene/dev/solr/core [master] $ java -version
>openjdk version "11.0.2" 2019-01-15
>OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
>OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
>
>...which i believe is the latest?
>
>-Hoss
>http://www.lucidworks.com/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@lucene.apache.org
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi again,
I was on my mobile only, so here is the "lengthy" explanation:
> FYI: first oddity i noticed is coming from some groovy code that seems
> to run as part of "common.test" ?
> -check-totals:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/home/hossman/.ivy2/cache/org.codehaus.groovy/groovy-
> all/jars/groovy-all-2.4.15.jar) to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
This is a warning that's triggered by the default behavior of Groovy to call "setAccessible" on all and every field/method of every class it sees. If it does this on a JDK one, the warning is printed. But for Groovy it's harmless, as a failing "setAccessible" is just ignored. The method is then just not available. As our Groovy code does not need to access private stuff, it does not matter is these are accessible or not.
Gradle is also full of those warnings, they are just hidden by the startup scripts that passes a special flag to the JVM. For Ant we can't do this, as it's not our startup script. If Java forbids in a later version that we access internal classes - who cares?! The whole thing is a stupidity in early Groovy versions when they decided that Groovy has access to everything by default. Stupid decision, but we have to live with it. Groovy is still arguing against the default in Java to print the warning, but there are no movements. As far as I know in Groovy 3 they may have removed that legacy behaviour, but I am not sure. Let's try it out.
For now, just ignore the warning, it's harmless! Asciidoctor has a similar problem BTW, but there it might be serious as a failure to make something accessible may block it from running.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Chris Hostetter <ho...@fucit.org>.
: The master branch was updated to use Java 11 - all Jenkins Jobs are back online! Let's see if additional Jenkins failures occur.
FYI: first oddity i noticed is coming from some groovy code that seems
to run as part of "common.test" ?
$ git clean -fx && cd solr/core/ && ant test -Dtestcase=TestCloudConsistency
...
[junit4] Tests summary: 1 suite, 2 tests
[echo] 5 slowest tests:
[junit4:tophints] 315.23s | org.apache.solr.cloud.ShardSplitTest
[junit4:tophints] 260.44s | org.apache.solr.search.facet.TestJsonFacets
[junit4:tophints] 208.15s | org.apache.solr.cloud.TestHossSanity
[junit4:tophints] 186.80s | org.apache.solr.cloud.api.collections.ShardSplitTest
[junit4:tophints] 125.64s | org.apache.solr.cloud.OnlyLeaderIndexesTest
-check-totals:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/hossman/.ivy2/cache/org.codehaus.groovy/groovy-all/jars/groovy-all-2.4.15.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
common.test:
BUILD SUCCESSFUL
Total time: 1 minute 31 seconds
I'm using...
hossman@tray:~/lucene/dev/solr/core [master] $ java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
...which i believe is the latest?
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
The master branch was updated to use Java 11 - all Jenkins Jobs are back online! Let's see if additional Jenkins failures occur.
Go ahead and update your local dev environment:
> As discussed on https://issues.apache.org/jira/browse/LUCENE-8738, we are
> planning to switch master branch to use Java 11 tomorrow. The Apache and
> Policeman Jenkins servers are prepared to handle that change, but now it's
> your turn:
>
> - Install a JDK 11 (remark: no Oracle JDK is needed, just use OpenJDK, e.g.
> from AdoptOpenJDK)
> - If you are working on master, you have to use Java 11 also in your IDE (run
> ant eclipse, netbeans,...). We tested IDE integrations for the common cases.
> If there are bugs, just fix them if you stumble on them.
> - If you are also maintaining Jenkins servers, update their configs!
> - If your merge/cherry pick changes from master to 8.x, don't forget to run
> precommit with Java 8 (!) and adopt needed changes.
>
> We will merge the branch with those changes tomorrow, 2019-04-16
> afternoon UTC time, around 12 pm. As always, some hickups might happen,
> so ignore failing Jenkins jobs! I hope it settles by the time.
Here is the TODO list if you have an idea:
> What's not working:
>
> - The HTML linter based on HTML Tidy was disabled until we found a
> replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it
> might happen that bad javadocs are not detected in master but after merge
> to 8.x branch they might suddenly appear.
Maybe we can use the infrastriucture using ASCIIdoctor of the Solr Ref guide here? It seems to also do link / HTML checks.
> - OpenClover code coverage Jenkins Jobs were disabled (no support yet for
> Java 11)
>
> TODOs:
>
> - Use Java 11 features, e.g. replace many unmodifiable collections with
> Map.of/Set.of/List.of constructs
> - Cleanup new warnings (we have to do this anyways, as javac is not even
> happy in Java 8)
Thanks, especially to Adrien for doing the initial work!
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org