Re: [ALL] Automated requirements (e.g. CheckStyle)?

[Gilles]

On Tue, 8 Aug 2017 18:49:44 -0700, Chas Honton wrote:

Since most of us work in an IDE, the "wasted" time of checkstyle for
every build is negligible.


It's not just the wasted time of running the tool (which might
well be negligible), it's the forcing of e.g. documenting a code
that might turn out to be transient on the path to a complete
fix.


At my day job, all code is automatically
reformatted as part of the build. It's just another step along with
PMD, CPD, findbugs, sonar, jacoco, junit, and a few other static
analyses. The more we automate, the less we need to remember and the
higher the quality of our code.


That's not always the case: I don't particularly like the "feature"
of IDEs that automatically inserts Javadoc templates:

/**
 *
 *
 * @param a
 * @param b
 * @return int
 */
public int doSomething(int a, int b) {
  // ...
}

Which then often remain useless as actual documentation. ;-)


Regards,
Gilles



Chas

On Aug 8, 2017, at 4:13 PM, Gilles  
wrote:


Hello.


On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
Hi,


Am 07.08.2017 um 15:09 schrieb Gilles:
Less work for the maintainers is good. :-)

By "taking time" I meant that validating should not be enforced 
when

calling "mvn compile" or "mvn test".
I wouldn't worry about the time consumption of the validation even 
if

it's run by every dev before very compilation since the sum of
conversation parts in patch/PR discussion in the form of "LGTM, 
except
for the indentation at line xy" - "OK, I fixed that now" - "Oh, no 
wait,
I forgot the trailing space at line yz" - ... - merged takes an 
infinite

more of time and energy.


I agree, but that is with respect to interaction with someone not 
used
to the coding style/rules; what I meant is that when doing one's 
"own"
work, one shouldn't have to wait for CheckStyle at every 
compilation,
when you know that you'll fix the missing doc _after_ fixing the 
code.



Regarding the phase where checkstyle should be run I have some
additional thoughts to my initial post:

 * If running checkstyle will be enforced the only phase that makes
sense is `validate` because you don't won't to build something 
that's
invalid because it's somehow unlogical and a waiste of time if you 
don't
fail the build as early as possible. In order to avoid annoyance 
for

users who aren't used to fix checkstyle errors before being able to
build I'd suggest a profile with deactivated checkstyle which 
allows

that rather an putting checkstyle in a separate profile.


IIUC, that would be fine (since it takes care of the above 
scenario).


 * Running checkstyle in the site or any other reporting phase is 
in
Maven speak afaik "show what might be wrong with my build given the 
fact
that I consider it passing after compilation, unit and integration 
tests
passed" or "show me some statistics about style issues - 150, wow 
that's

12 less than last build".


That's what we've done up to now; and the number of errors is 
supposed
to be zero before a release.  But I agree that the risk of a lot of 
work
for the RM would be reduced by enforcing checks at least before 
committing

to the "master" branch.

Is anyone objecting?

I think that the profile should be defined in the "parent" POM.
Can someone make the necessary additions?

Thanks,
Gilles





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Automated requirements (e.g. CheckStyle)?

[Chas Honton]

Since most of us work in an IDE, the "wasted" time of checkstyle for every 
build is negligible. At my day job, all code is automatically reformatted as 
part of the build. It's just another step along with PMD, CPD, findbugs, sonar, 
jacoco, junit, and a few other static analyses. The more we automate, the less 
we need to remember and the higher the quality of our code. 

Chas

> On Aug 8, 2017, at 4:13 PM, Gilles  wrote:
> 
> Hello.
> 
>> On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
>> Hi,
>> 
>>> Am 07.08.2017 um 15:09 schrieb Gilles:
>>> Less work for the maintainers is good. :-)
>>> 
>>> By "taking time" I meant that validating should not be enforced when
>>> calling "mvn compile" or "mvn test".
>> I wouldn't worry about the time consumption of the validation even if
>> it's run by every dev before very compilation since the sum of
>> conversation parts in patch/PR discussion in the form of "LGTM, except
>> for the indentation at line xy" - "OK, I fixed that now" - "Oh, no wait,
>> I forgot the trailing space at line yz" - ... - merged takes an infinite
>> more of time and energy.
> 
> I agree, but that is with respect to interaction with someone not used
> to the coding style/rules; what I meant is that when doing one's "own"
> work, one shouldn't have to wait for CheckStyle at every compilation,
> when you know that you'll fix the missing doc _after_ fixing the code.
> 
>> Regarding the phase where checkstyle should be run I have some
>> additional thoughts to my initial post:
>> 
>>  * If running checkstyle will be enforced the only phase that makes
>> sense is `validate` because you don't won't to build something that's
>> invalid because it's somehow unlogical and a waiste of time if you don't
>> fail the build as early as possible. In order to avoid annoyance for
>> users who aren't used to fix checkstyle errors before being able to
>> build I'd suggest a profile with deactivated checkstyle which allows
>> that rather an putting checkstyle in a separate profile.
> 
> IIUC, that would be fine (since it takes care of the above scenario).
> 
>>  * Running checkstyle in the site or any other reporting phase is in
>> Maven speak afaik "show what might be wrong with my build given the fact
>> that I consider it passing after compilation, unit and integration tests
>> passed" or "show me some statistics about style issues - 150, wow that's
>> 12 less than last build".
> 
> That's what we've done up to now; and the number of errors is supposed
> to be zero before a release.  But I agree that the risk of a lot of work
> for the RM would be reduced by enforcing checks at least before committing
> to the "master" branch.
> 
> Is anyone objecting?
> 
> I think that the profile should be defined in the "parent" POM.
> Can someone make the necessary additions?
> 
> Thanks,
> Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Automated requirements (e.g. CheckStyle)?

[Gilles]

Hello.

On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:

Hi,

Am 07.08.2017 um 15:09 schrieb Gilles:

Less work for the maintainers is good. :-)

By "taking time" I meant that validating should not be enforced when
calling "mvn compile" or "mvn test".

I wouldn't worry about the time consumption of the validation even if
it's run by every dev before very compilation since the sum of
conversation parts in patch/PR discussion in the form of "LGTM, 
except
for the indentation at line xy" - "OK, I fixed that now" - "Oh, no 
wait,
I forgot the trailing space at line yz" - ... - merged takes an 
infinite

more of time and energy.


I agree, but that is with respect to interaction with someone not used
to the coding style/rules; what I meant is that when doing one's "own"
work, one shouldn't have to wait for CheckStyle at every compilation,
when you know that you'll fix the missing doc _after_ fixing the code.


Regarding the phase where checkstyle should be run I have some
additional thoughts to my initial post:

  * If running checkstyle will be enforced the only phase that makes
sense is `validate` because you don't won't to build something that's
invalid because it's somehow unlogical and a waiste of time if you 
don't

fail the build as early as possible. In order to avoid annoyance for
users who aren't used to fix checkstyle errors before being able to
build I'd suggest a profile with deactivated checkstyle which allows
that rather an putting checkstyle in a separate profile.


IIUC, that would be fine (since it takes care of the above scenario).


  * Running checkstyle in the site or any other reporting phase is in
Maven speak afaik "show what might be wrong with my build given the 
fact
that I consider it passing after compilation, unit and integration 
tests
passed" or "show me some statistics about style issues - 150, wow 
that's

12 less than last build".


That's what we've done up to now; and the number of errors is supposed
to be zero before a release.  But I agree that the risk of a lot of 
work
for the RM would be reduced by enforcing checks at least before 
committing

to the "master" branch.

Is anyone objecting?

I think that the profile should be defined in the "parent" POM.
Can someone make the necessary additions?

Thanks,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Automated requirements (e.g. CheckStyle)? (Was: [MATH] Enforce run [...])

[Karl-Philipp Richter]

Hi,

Am 07.08.2017 um 15:09 schrieb Gilles:
> Less work for the maintainers is good. :-)
> 
> By "taking time" I meant that validating should not be enforced when
> calling "mvn compile" or "mvn test".
I wouldn't worry about the time consumption of the validation even if
it's run by every dev before very compilation since the sum of
conversation parts in patch/PR discussion in the form of "LGTM, except
for the indentation at line xy" - "OK, I fixed that now" - "Oh, no wait,
I forgot the trailing space at line yz" - ... - merged takes an infinite
more of time and energy.

Regarding the phase where checkstyle should be run I have some
additional thoughts to my initial post:

  * If running checkstyle will be enforced the only phase that makes
sense is `validate` because you don't won't to build something that's
invalid because it's somehow unlogical and a waiste of time if you don't
fail the build as early as possible. In order to avoid annoyance for
users who aren't used to fix checkstyle errors before being able to
build I'd suggest a profile with deactivated checkstyle which allows
that rather an putting checkstyle in a separate profile.
  * Running checkstyle in the site or any other reporting phase is in
Maven speak afaik "show what might be wrong with my build given the fact
that I consider it passing after compilation, unit and integration tests
passed" or "show me some statistics about style issues - 150, wow that's
12 less than last build".



signature.asc
Description: OpenPGP digital signature

Re: Ready for JDK 9 ?

[Pascal Schumacher]

The same goes for commons-compress (as already mentioned by Simon Spero):

https://travis-ci.org/apache/commons-compress/jobs/258642081

Am 08.08.2017 um 22:48 schrieb Pascal Schumacher:

Hello everybody,

commons-lang and commons-text are build and tested with JDK 9 on 
traivs-ci, e.g.:


https://travis-ci.org/apache/commons-text/jobs/259838032
https://travis-ci.org/apache/commons-lang/jobs/258653445

so I guess these components are ready for JDK 9.

Cheers,
Pascal

Am 08.08.2017 um 12:09 schrieb Rory O'Donnell:


Hi Benedikt,

Thank you very much for all your testing of JDK 9 during its 
development! Such contributions have significantly helped shape and 
improve JDK 9.


Now that we have reached the JDK 9 Final Release Candidate phase [1] 
, I would like to ask if your project can be considered to be 'ready 
for JDK 9', or if there are any remaining show stopper issues which 
you've encountered when testing with the JDK 9 release candidate.


JDK 9  b181 is available at http://jdk.java.net/9/

If you have a public web page, mailing list post, or even a tweet 
announcing you project's readiness for JDK 9, I'd love to add the URL 
to the upcoming JDK 9 readiness page on the Quality Outreach wiki.



Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Ready for JDK 9 ?

[Pascal Schumacher]

Hello everybody,

commons-lang and commons-text are build and tested with JDK 9 on 
traivs-ci, e.g.:


https://travis-ci.org/apache/commons-text/jobs/259838032
https://travis-ci.org/apache/commons-lang/jobs/258653445

so I guess these components are ready for JDK 9.

Cheers,
Pascal

Am 08.08.2017 um 12:09 schrieb Rory O'Donnell:


Hi Benedikt,

Thank you very much for all your testing of JDK 9 during its 
development! Such contributions have significantly helped shape and 
improve JDK 9.


Now that we have reached the JDK 9 Final Release Candidate phase [1] , 
I would like to ask if your project can be considered to be 'ready for 
JDK 9', or if there are any remaining show stopper issues which you've 
encountered when testing with the JDK 9 release candidate.


JDK 9  b181 is available at http://jdk.java.net/9/

If you have a public web page, mailing list post, or even a tweet 
announcing you project's readiness for JDK 9, I'd love to add the URL 
to the upcoming JDK 9 readiness page on the Quality Outreach wiki.



Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Ready for JDK 9 ?

[Amey Jadiye]

Hmm, isn't that easy with just Travis ? We just have to add java9
option(not sure it have RC) and trigger build it will automatically check
build and tests. IIRC for few components we are having java9 Travis env
already set.

Regards,
Amey

On Tue, Aug 8, 2017, 8:38 PM Jörg Schaible 
wrote:

> Hi,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote:
> >> Hi Benedikt,
> >>
> >> Thank you very much for all your testing of JDK 9 during its
> >> development! Such contributions have significantly helped shape and
> >> improve JDK 9.
> >>
> >> Now that we have reached the JDK 9 Final Release Candidate phase [1]
> >> , I would like to ask if your project can be considered to be 'ready
> >> for JDK 9',
> >
> > Is there some simple thing to do in order to be able to answer
> > that question?
>
> IMHO no. Definitelly not in general for all components. Practically we
> would
> have to checkout the latest releases from source (or use the source
> tarballs) and run at least the unit tests with this Java 9 RC.
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Ready for JDK 9 ?

[Simon Spero]

Compress HEAD is tested against the equivalent of RC. The main issues were
with tests; some types of mocking (especially of concrete classes) don't
work. This might have been fixed by now.
I believe that the latest jacoco is 9 compatible.

[The biggest problem was caused by a bug in the zip code handling a
particular kind of timestamp; massive changes to the jdk implementation of
zip caused tests that had been passing (but shouldn't have) to fail
properly.]

NOTE:

Adding a Module name manifest header asserts that the code is tested
against Java 9. This is documented in the minutes of the armistice talks.

jigsaw modules are pretty useless for most of Commons (consumers pretty
much have to shade dependencies). [ subliminal whisper about benefits of
having correct OSGI headers]

Simon

On Aug 8, 2017 11:08 AM, "Jörg Schaible" 
wrote:

> Hi,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote:
> >> Hi Benedikt,
> >>
> >> Thank you very much for all your testing of JDK 9 during its
> >> development! Such contributions have significantly helped shape and
> >> improve JDK 9.
> >>
> >> Now that we have reached the JDK 9 Final Release Candidate phase [1]
> >> , I would like to ask if your project can be considered to be 'ready
> >> for JDK 9',
> >
> > Is there some simple thing to do in order to be able to answer
> > that question?
>
> IMHO no. Definitelly not in general for all components. Practically we
> would
> have to checkout the latest releases from source (or use the source
> tarballs) and run at least the unit tests with this Java 9 RC.
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Ready for JDK 9 ?

[Bernd Eckenfels]

Hello,

I am willing to do that for a few components. Maybe we can collect the Java9 
state for commons on a Wiki Page, like:

Component | Compiles with 9 since | Module aware? | Latest bin Release runs in 
9. | Comments

(Not sure how easy the modules check will be and what we define as module 
aware. But the compile checks should be easy to do.)

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Jörg Schaible 
Sent: Tuesday, August 8, 2017 5:07:54 PM
To: dev@commons.apache.org
Subject: Re: Ready for JDK 9 ?

Hi,

Gilles wrote:

> Hi.
>
> On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote:
>> Hi Benedikt,
>>
>> Thank you very much for all your testing of JDK 9 during its
>> development! Such contributions have significantly helped shape and
>> improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1]
>> , I would like to ask if your project can be considered to be 'ready
>> for JDK 9',
>
> Is there some simple thing to do in order to be able to answer
> that question?

IMHO no. Definitelly not in general for all components. Practically we would
have to checkout the latest releases from source (or use the source
tarballs) and run at least the unit tests with this Java 9 RC.

Cheers,
Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Ready for JDK 9 ?

[Jörg Schaible]

Hi,

Gilles wrote:

> Hi.
> 
> On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote:
>> Hi Benedikt,
>>
>> Thank you very much for all your testing of JDK 9 during its
>> development! Such contributions have significantly helped shape and
>> improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1]
>> , I would like to ask if your project can be considered to be 'ready
>> for JDK 9',
> 
> Is there some simple thing to do in order to be able to answer
> that question?

IMHO no. Definitelly not in general for all components. Practically we would 
have to checkout the latest releases from source (or use the source 
tarballs) and run at least the unit tests with this Java 9 RC.

Cheers,
Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-fileupload pull request #9: Msamery commons fileupload 1.3.2 patch 1

[MSAmery]

GitHub user MSAmery opened a pull request:

https://github.com/apache/commons-fileupload/pull/9

Msamery commons fileupload 1.3.2 patch 1



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSAmery/commons-fileupload 
MSAmery-commons-fileupload-1.3.2-patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-fileupload/pull/9.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #9


commit 459aaa93e02182fd7653d852fba4739529741182
Author: Mark Thomas 
Date:   2014-02-06T17:01:34Z

Tagging 1.3.1-RC1

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_1_RC1@1565352
 13f79535-47bb-0310-9956-ffa450edef68

commit e19f0d04ff9d28e5e0d7bc6a4e98b6f04cec6bf8
Author: Mark Thomas 
Date:   2014-02-07T15:07:48Z

FileUpload 1.3.1 RC1 release vote passed

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_1@1565671
 13f79535-47bb-0310-9956-ffa450edef68

commit b495a3408f0386156628be46e491afef2134ce79
Author: Jochen Wiedmann 
Date:   2016-01-28T09:11:39Z

Creating a 1.3 branch by copying the 1.3.1 release

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/FILEUPLOAD_1_3_1@1727283
 13f79535-47bb-0310-9956-ffa450edef68

commit 5d9ffbb277c538134f2cbf4a09d491fb933ba6fc
Author: Jochen Wiedmann 
Date:   2016-01-28T09:12:08Z

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1727284
 13f79535-47bb-0310-9956-ffa450edef68

commit bff2e09bbb065a60702150ccef28600e3bc5fd78
Author: Jochen Wiedmann 
Date:   2016-05-12T13:53:05Z

Preparing 1.3.2 release.


git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743507
 13f79535-47bb-0310-9956-ffa450edef68

commit dba92f451d20f68ba17aa5b387739f40e74466af
Author: Jochen Wiedmann 
Date:   2016-05-13T08:55:25Z

[maven-release-plugin] prepare release commons-fileupload-1.3.2

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743624
 13f79535-47bb-0310-9956-ffa450edef68

commit d79a361a0f83ee6d2937b64996976430c1b4ad19
Author: Jochen Wiedmann 
Date:   2016-05-13T08:55:44Z

[maven-release-plugin] prepare for next development iteration

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743626
 13f79535-47bb-0310-9956-ffa450edef68

commit f262cfa6bad41bc136c3ab10099bc8f8051cee39
Author: Jochen Wiedmann 
Date:   2016-05-13T09:05:55Z

[maven-release-plugin] rollback the release of commons-fileupload-1.3.2

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743628
 13f79535-47bb-0310-9956-ffa450edef68

commit 11fa058829e5a46fd293fd71c169006979e295c0
Author: Jochen Wiedmann 
Date:   2016-05-13T09:08:04Z

Upgrading to latest parent POM, so that javadocs work as is.


git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743629
 13f79535-47bb-0310-9956-ffa450edef68

commit e6c6b206b4f8cbd032d1061c5534ef989398095d
Author: Jochen Wiedmann 
Date:   2016-05-13T09:20:45Z

Minor fixes, to make maven-javadoc-plugin happy.


git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743630
 13f79535-47bb-0310-9956-ffa450edef68

commit 72c89e5ccdce9a2a1c88fc1df7993f040ee20138
Author: Jochen Wiedmann 
Date:   2016-05-13T09:25:46Z

[maven-release-plugin] rollback the release of commons-fileupload-1.3.2

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743631
 13f79535-47bb-0310-9956-ffa450edef68

commit 3f8311c0eee9a5e4e423a521e7eb3f691a6fd03b
Author: Jochen Wiedmann 
Date:   2016-05-13T09:26:58Z

Fixing SCM Information: trunk => branches/b1_3


git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743632
 13f79535-47bb-0310-9956-ffa450edef68

commit 75af23d90a79bbbcd06da70a22f7bcd398071983
Author: Jochen Wiedmann 
Date:   2016-05-13T09:28:15Z

[maven-release-plugin] prepare release commons-fileupload-1.3.2

git-svn-id: 
https://svn.apache.org/repos/asf/commons/proper/fileupload/branches/b1_3@1743633
 13f79535-47bb-0310-9956-ffa450edef68

commit 0a7a2cd671e2f9662e4752d7b4fc769e22af29b5
Author: Jochen Wiedmann 
Date:   2016-05-13T09:28:39Z

[maven-release-plugin] prepare for next development iteration

git-svn-id: 

Re: Ready for JDK 9 ?

[Gilles]

Hi.

On Tue, 8 Aug 2017 11:09:01 +0100, Rory O'Donnell wrote:

Hi Benedikt,

Thank you very much for all your testing of JDK 9 during its
development! Such contributions have significantly helped shape and
improve JDK 9.

Now that we have reached the JDK 9 Final Release Candidate phase [1]
, I would like to ask if your project can be considered to be 'ready
for JDK 9',


Is there some simple thing to do in order to be able to answer
that question?

Regards,
Gilles


or if there are any remaining show stopper issues which
you've encountered when testing with the JDK 9 release candidate.

JDK 9  b181 is available at http://jdk.java.net/9/

If you have a public web page, mailing list post, or even a tweet
announcing you project's readiness for JDK 9, I'd love to add the URL
to the upcoming JDK 9 readiness page on the Quality Outreach wiki.


Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Ready for JDK 9 ?

[Rory O'Donnell]

Hi Benedikt,

Thank you very much for all your testing of JDK 9 during its 
development! Such contributions have significantly helped shape and 
improve JDK 9.


Now that we have reached the JDK 9 Final Release Candidate phase [1] , I 
would like to ask if your project can be considered to be 'ready for JDK 
9', or if there are any remaining show stopper issues which you've 
encountered when testing with the JDK 9 release candidate.


JDK 9  b181 is available at http://jdk.java.net/9/

If you have a public web page, mailing list post, or even a tweet 
announcing you project's readiness for JDK 9, I'd love to add the URL to 
the upcoming JDK 9 readiness page on the Quality Outreach wiki.



Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org