Re: [pool] close(). Closeable, and AutoCloseable
On 31 October 2017 at 04:42, Mark Thomas wrote: > > If we implement Closeable then we get AutoCloseable for free. > With an IOException as its throwable instead of a more generic Exception, though of course, that can be overridden. -- Matt Sicker
Re: [dbcp] update to pool 2.4.3.
On 31 October 2017 at 04:21, Mark Thomas wrote: > > If the methods are required then that makes 2.4.3 broken in my view. In > which case we should wait for 2.4.4 before updating the version DBCP > depends on. I don't think we should adapt the test. The test is telling > us something is broken. We should fix the root cause not change the test. > Regarding this, if the method names were expected in the output, then a unit test should have existed to verify that. The existing test was only checking for class names, so I'm assuming that's why I made the change a while back to optimize it for that use case. I think I asked on the mailing lists first, but that was a while ago. > - fix pool > - release pool 2.4.4 > - update DBCP to pool 2.4.4 > - release DBCP > Sounds good to me. This can be done by just removing the SecurityManager version since a StackWalker version of CallStack could be implemented for Java 9, so it would be pointless to fully revert the change. -- Matt Sicker
Re: [dbcp] update to pool 2.4.3.
Yes, I can look into this over the next couple days. I'd imagine this should be configurable whether you want just the class or if you need more info for leakage detection. On 30 October 2017 at 10:31, Gary Gregory wrote: > Hi Matt, > > Can you provide a patch to add an option to restore the behavior from we > had in 2.4.2? > > Gary > > On Sun, Oct 29, 2017 at 2:32 PM, Matt Sicker wrote: > > > It's been a while since I looked at that, but from what I can tell, if > the > > method name needs to be tracked as well as the class name, then the > > SecurityManager solution isn't practical at all. Pre Java 9 would need to > > use a Throwable no matter what, while Java 9+ can use StackWalker. > > > > On 29 October 2017 at 10:51, Gary Gregory > wrote: > > > > > On Oct 29, 2017 02:21, "Pascal Schumacher" > > > wrote: > > > > > > Am 29.10.2017 um 09:09 schrieb Mark Thomas: > > > > > > > On 29 October 2017 03:54:40 GMT+00:00, "Bruno P. Kinoshita" < > > > > brunodepau...@yahoo.com.br.INVALID> wrote: > > > > > > > >> Hi Gary, > > > >> > > > >> Started the tests in Maven command line, found which tests failed. > > > >> Executed the tests in Eclipse, found which class was related to the > > > >> failure. Then did a diff between both tags. > > > >> > > > >> git diff POOL_2_4_2 POOL_2.4.3-RC1 -- > > > >> ./src/main/java/org/apache/commons/pool2/impl/ > > DefaultPooledObject.java > > > >> > > > >> The short diff indicates that the failures started possibly due to > the > > > >> replacement of Exceptions in the DefaultPooledObject by a CallStack. > > > >> Looks like the CallStack does not keep track of all the methods > called > > > >> (due to a security context manager from what I could tell?). Only > > > >> classes. > > > >> > > > >> The following pull request updates pool to 2.4.3, and changes the > unit > > > >> tests to, instead of looking for method names in the log writer > > output, > > > >> to look for the test class name. > > > >> > > > >> https://github.com/apache/commons-dbcp/pull/8 > > > >> > > > >> > > > >> Feel free to review and merge if you agree it's a good solution. > > > >> > > > > I'm not sure it is a good solution. I need to look at what is going > on > > in > > > > more detail but if the method information has been lost then that > will > > > make > > > > tracking down the root cause of a pool leak much, much harder. > > > > > > > > > > I guess this was caused by: > > > > > > [POOL-320]: Use more efficient stack walking mechanisms for usage > > tracking > > > > > > https://github.com/apache/commons-pool/commit/3994baf0f3ce59 > > > b73bd36e869320275d757d1884 > > > > > > > > > Matt, > > > > > > Any thoughts on the missing method names? > > > > > > Gary > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: [dbcp] update to pool 2.4.3.
It's been a while since I looked at that, but from what I can tell, if the method name needs to be tracked as well as the class name, then the SecurityManager solution isn't practical at all. Pre Java 9 would need to use a Throwable no matter what, while Java 9+ can use StackWalker. On 29 October 2017 at 10:51, Gary Gregory wrote: > On Oct 29, 2017 02:21, "Pascal Schumacher" > wrote: > > Am 29.10.2017 um 09:09 schrieb Mark Thomas: > > > On 29 October 2017 03:54:40 GMT+00:00, "Bruno P. Kinoshita" < > > brunodepau...@yahoo.com.br.INVALID> wrote: > > > >> Hi Gary, > >> > >> Started the tests in Maven command line, found which tests failed. > >> Executed the tests in Eclipse, found which class was related to the > >> failure. Then did a diff between both tags. > >> > >> git diff POOL_2_4_2 POOL_2.4.3-RC1 -- > >> ./src/main/java/org/apache/commons/pool2/impl/DefaultPooledObject.java > >> > >> The short diff indicates that the failures started possibly due to the > >> replacement of Exceptions in the DefaultPooledObject by a CallStack. > >> Looks like the CallStack does not keep track of all the methods called > >> (due to a security context manager from what I could tell?). Only > >> classes. > >> > >> The following pull request updates pool to 2.4.3, and changes the unit > >> tests to, instead of looking for method names in the log writer output, > >> to look for the test class name. > >> > >> https://github.com/apache/commons-dbcp/pull/8 > >> > >> > >> Feel free to review and merge if you agree it's a good solution. > >> > > I'm not sure it is a good solution. I need to look at what is going on in > > more detail but if the method information has been lost then that will > make > > tracking down the root cause of a pool leak much, much harder. > > > > I guess this was caused by: > > [POOL-320]: Use more efficient stack walking mechanisms for usage tracking > > https://github.com/apache/commons-pool/commit/3994baf0f3ce59 > b73bd36e869320275d757d1884 > > > Matt, > > Any thoughts on the missing method names? > > Gary > -- Matt Sicker
Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)
On 22 October 2017 at 16:17, Romain Manni-Bucau wrote: > So i just copy the mvn release tag? Sounds quite useless since the tag is > done no? > A release candidate is supposed to match the eventual release at some point; that's why it's a "candidate". Making a copy of an RC tag to make the final release tag makes perfect sense in that context. -- Matt Sicker
Re: [pool] Java 7 and release
On 24 October 2017 at 06:44, Mark Thomas wrote: > On 24/10/17 05:56, Matt Sicker wrote: > > Go for it! Though perhaps some quick feedback from Tomcat would be good > > since they're the primary Apache project that uses the library. > > I assume we are talking about Pool 2.x. > Yes. > Pool 2.x is used by Tomcat 8 onwards and Tomcat 8 has a requirement of > Java 7 or later so updating Pool 2.x to Java 7 would not present a > problem for the Tomcat community. > Great! That means DBCP 2.x should be able to upgrade to Java 7 as well if it hasn't already. -- Matt Sicker
Re: [pool] Java 7 and release
Go for it! Though perhaps some quick feedback from Tomcat would be good since they're the primary Apache project that uses the library. On 23 October 2017 at 17:30, Gary Gregory wrote: > Or the other way around. Release and update to Java 7... > > Gary > > On Mon, Oct 23, 2017 at 4:25 PM, Gary Gregory > wrote: > > > Wow, 2 years since the last release of [pool]. I plan on updating to Java > > 7 and push out a release. > > > > Gary > > > -- Matt Sicker
Re: [text] always use static imports for assertion methods
Assertion classes are just containers for static methods. Using "import static" is the only way in Java to import the individual methods as if the class itself were a package. Also, doing this is pretty common when using the Assert class as all its methods are prefixed with "assert" anyways. On 15 October 2017 at 13:44, Gilles wrote: > On Sun, 15 Oct 2017 12:22:13 +0200, Pascal Schumacher wrote: > >> Just for consistency. >> > > Consistency is fine. ;-) > > All almost all tests already used static >> imports, so I adjusted the few that did not. >> > > It's the use of "import static" which I was questioning. > > Gilles > > > >> -Pascal >> >> Am 15.10.2017 um 11:44 schrieb Gilles: >> >>> On Sun, 15 Oct 2017 09:34:04 + (UTC), pascalschumac...@apache.org >>> wrote: >>> >>>> Repository: commons-text >>>> Updated Branches: >>>> refs/heads/master 51645b4f0 -> 8f7d0494d >>>> >>>> >>>> always use static imports for assertion methods >>>> >>>> >>> Why? >>> >>> Gilles >>> >>> >>>> [...] >>>> >>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [LANG] Add module-info.java?
Which is mainly because the version of Java in Android is intentionally lacking about half of the standard library. Perhaps this will improve in the future now that they're adopting OpenJDK, though. On 14 October 2017 at 17:04, Ralph Goers wrote: > I need to point out that even after removing that there would be a lot of > stuff in log4j-core that doesn’t work in Android. > > Ralph > > > On Oct 14, 2017, at 12:02 PM, Gary Gregory > wrote: > > > > I am wondering if this is a little too early. A lot of tooling our there > > does not play well with Java 9 class files. > > > > The last time I tried to use Log4j 2 (which contains Java 9 classes files > > in the right multi-jar spot) with an Android app, the Android tooling > threw > > up all over itself because it was incorrectly trying to do something with > > these Java 9 class file :-( > > > > Gary > > > > On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne < > scolebou...@joda.org> > > wrote: > > > >> On 14 October 2017 at 14:05, Rob Tompkins wrote: > >>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter > >> wrote: > >>> Feels like a change that would warrant a major version change, but that > >> would have us maintaining another major version branch. > >> > >> No need for a major version change. Its just one more .class file in > >> the jar file. The jar file is still usable on Java 7 and 8, its just > >> that the *build* is Java 9 specific. > >> > >> As Pascal says, really we want all the maven plugins to be ready for > >> this, but we don't control those timescales. > >> > >> Options to fix the site plugin problem: > >> > >> 1) Alter the PR so that releases have to be in two stages - jar file > >> build/deploy on Java 9 and site on Java 8. The risk is that someone > >> forgets to do the release using Java 9. > >> > >> 2) Compile the module-info.java file on Java 9 and check it in (as a > >> binary module-info.class file). Then the build could stay on Java 7/8. > >> The problem however is that whenever a new package is added, the > >> module-info.class file would have to be recreated and re-checked in, > >> an error-prone process. > >> > >> Stephen > >> > >> --------- > >> 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 > > -- Matt Sicker
Re: commons-collections git commit: MapUtilsTest: fix order of expected and actual parameter in assertions (closes #32)
ot;key", 0), 0);
> >>>> +assertEquals(0, MapUtils.getInteger(in,"noKey", 0), 0);
> >>>>
> >>>> final Map inStr = new HashMap<>();
> >>>> inStr.put("str1", "2");
> >>>> @@ -1028,12 +1028,12 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> final short val = 10;
> >>>> in.put("key", val);
> >>>>
> >>>> -assertEquals(MapUtils.getShortValue(in,"key", val), val, 0);
> >>>> -assertEquals(MapUtils.getShortValue(in,"key"), val, 0);
> >>>> -assertEquals(MapUtils.getShortValue(in,"noKey", val), val,
> 0);
> >>>> -assertEquals(MapUtils.getShortValue(in,"noKey"), 0, 0);
> >>>> -assertEquals(MapUtils.getShort(in,"key", val), val, 0);
> >>>> -assertEquals(MapUtils.getShort(in,"noKey", val), val, 0);
> >>>> +assertEquals(val, MapUtils.getShortValue(in,"key", val), 0);
> >>>> +assertEquals(val, MapUtils.getShortValue(in,"key"), 0);
> >>>> +assertEquals(val, MapUtils.getShortValue(in,"noKey", val),
> 0);
> >>>> +assertEquals(0, MapUtils.getShortValue(in,"noKey"), 0);
> >>>> +assertEquals(val, MapUtils.getShort(in,"key", val), 0);
> >>>> +assertEquals(val,MapUtils.getShort(in,"noKey", val), 0);
> >>>>
> >>>> final Map inStr = new HashMap<>();
> >>>> inStr.put("str1", "10");
> >>>> @@ -1047,12 +1047,12 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> final byte val = 100;
> >>>> in.put("key", val);
> >>>>
> >>>> -assertEquals(MapUtils.getByteValue(in,"key", val), val, 0);
> >>>> -assertEquals(MapUtils.getByteValue(in,"key"), val, 0);
> >>>> -assertEquals(MapUtils.getByteValue(in,"noKey", val), val,
> 0);
> >>>> -assertEquals(MapUtils.getByteValue(in,"noKey"), 0, 0);
> >>>> -assertEquals(MapUtils.getByte(in,"key", val), val, 0);
> >>>> -assertEquals(MapUtils.getByte(in,"noKey", val), val, 0);
> >>>> +assertEquals(val, MapUtils.getByteValue(in,"key", val), 0);
> >>>> +assertEquals(val, MapUtils.getByteValue(in,"key"), 0);
> >>>> +assertEquals(val, MapUtils.getByteValue(in,"noKey", val),
> 0);
> >>>> +assertEquals(0, MapUtils.getByteValue(in,"noKey"), 0);
> >>>> +assertEquals(val, MapUtils.getByte(in,"key", val), 0);
> >>>> +assertEquals(val, MapUtils.getByte(in,"noKey", val), 0);
> >>>>
> >>>>
> >>>> final Map inStr = new HashMap<>();
> >>>> @@ -1067,8 +1067,8 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> final Number val = 1000;
> >>>> in.put("key", val);
> >>>>
> >>>> -assertEquals(MapUtils.getNumber(in,"key", val).intValue(),
> >>>> val.intValue(), 0);
> >>>> -assertEquals(MapUtils.getNumber(in,"noKey", val).intValue(),
> >>>> val.intValue(), 0);
> >>>> +assertEquals(val.intValue(), MapUtils.getNumber(in,"key",
> >>>> val).intValue(), 0);
> >>>> +assertEquals(val.intValue(), MapUtils.getNumber(in,"noKey",
> >>>> val).intValue(), 0);
> >>>>
> >>>> }
> >>>>
> >>>> @@ -1077,11 +1077,11 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> final Map in = new HashMap<>();
> >>>> in.put("key", "str");
> >>>>
> >>>> -assertEquals(MapUtils.getString(in,"key", "defualt"),
> "str");
> >>>> -assertEquals(MapUtils.getString(in,"key"), "str");
> >>>> -assertEquals(MapUtils.getString(null,"key"), null);
> >>>> -assertEquals(MapUtils.getString(in,"noKey", "default"),
> >>>> "default");
> >>>> -assertEquals(MapUtils.getString(null,"noKey", "default"),
> >>>> "default");
> >>>> +assertEquals("str", MapUtils.getString(in,"key", "defualt"));
> >>>> +assertEquals("str", MapUtils.getString(in,"key"));
> >>>> +assertEquals(null, MapUtils.getString(null,"key"));
> >>>> +assertEquals("default", MapUtils.getString(in,"noKey",
> >>>> "default"));
> >>>> +assertEquals("default", MapUtils.getString(null,"noKey",
> >>>> "default"));
> >>>>
> >>>> }
> >>>>
> >>>> @@ -1090,11 +1090,11 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> final Map in = new HashMap<>();
> >>>> in.put("key", "str");
> >>>>
> >>>> -assertEquals(MapUtils.getObject(in,"key", "defualt"),
> "str");
> >>>> -assertEquals(MapUtils.getObject(in,"key"), "str");
> >>>> -assertEquals(MapUtils.getObject(null,"key"), null);
> >>>> -assertEquals(MapUtils.getObject(in,"noKey", "default"),
> >>>> "default");
> >>>> -assertEquals(MapUtils.getObject(null,"noKey", "default"),
> >>>> "default");
> >>>> +assertEquals("str", MapUtils.getObject(in,"key", "defualt"));
> >>>> +assertEquals("str", MapUtils.getObject(in,"key"));
> >>>> +assertEquals(null, MapUtils.getObject(null,"key"));
> >>>> +assertEquals("default", MapUtils.getObject(in,"noKey",
> >>>> "default"));
> >>>> +assertEquals("default", MapUtils.getObject(null,"noKey",
> >>>> "default"));
> >>>>
> >>>> }
> >>>>
> >>>> @@ -1109,7 +1109,7 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> assertTrue(!MapUtils.getBooleanValue(in,"noKey"));
> >>>> assertTrue(MapUtils.getBoolean(in,"key", true));
> >>>> assertTrue(MapUtils.getBoolean(in,"noKey", true));
> >>>> -assertEquals(MapUtils.getBoolean(null,"noKey"),null);
> >>>> +assertEquals(null, MapUtils.getBoolean(null,"noKey"));
> >>>>
> >>>>
> >>>>
> >>>> @@ -1130,10 +1130,10 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>> in.put("key1", valMap);
> >>>> final Map outValue = MapUtils.getMap(in,"key1",
> null);
> >>>>
> >>>> -assertEquals( outValue.get("key1"), "value1");
> >>>> -assertEquals( outValue.get("key2"), null);
> >>>> -assertEquals( MapUtils.getMap(in,"key2", null), null);
> >>>> -assertEquals( MapUtils.getMap(null,"key2", null), null);
> >>>> +assertEquals("value1", outValue.get("key1"));
> >>>> +assertEquals(null, outValue.get("key2"));
> >>>> +assertEquals(null, MapUtils.getMap(in,"key2", null));
> >>>> +assertEquals(null, MapUtils.getMap(null,"key2", null));
> >>>> }
> >>>>
> >>>> @Test
> >>>> @@ -1143,8 +1143,8 @@ public class MapUtilsTest extends
> >>>> AbstractAvailableLocalesTest {
> >>>>
> >>>> MapUtils.safeAddToMap(inMap,"key1", "value1");
> >>>> MapUtils.safeAddToMap(inMap,"key2", null);
> >>>> -assertEquals( inMap.get("key1"), "value1");
> >>>> -assertEquals( inMap.get("key2"), "");
> >>>> +assertEquals("value1", inMap.get("key1"));
> >>>> +assertEquals("", inMap.get("key2"));
> >>>> }
> >>>>
> >>>> @Test
> >>>>
> >>>>
> >>>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
--
Matt Sicker
Re: [IO] Releasing 2.6
There used to be Windows Jenkins slaves. I had them configured for Log4j here: https://builds.apache.org/job/Log4jWindows/ Not sure if they're working properly, but I see 3 nodes: https://builds.apache.org/label/Windows/ On 26 September 2017 at 17:52, Bruno P. Kinoshita wrote: > I wonder if we have some windows jenkins slaves. It would be nice to > identify these regressions earlier. > Bruno > > Sent from Yahoo Mail on Android > > On Wed, 27 Sep 2017 at 8:16, Gary Gregory > wrote: This test fails on Windows: > > org.apache.commons.io.FileUtilsTestCase > > FileUtilsTestCase > org.apache.commons.io.FileUtilsTestCase > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase) > java.lang.AssertionError > > at org.junit.Assert.fail(Assert.java:86) > > at org.junit.Assert.assertTrue(Assert.java:41) > > at org.junit.Assert.assertFalse(Assert.java:64) > > at org.junit.Assert.assertFalse(Assert.java:74) > > at > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL( > FileUtilsTestCase.java:681) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: > 57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( > FrameworkMethod.java:50) > > at > org.junit.internal.runners.model.ReflectiveCallable.run( > ReflectiveCallable.java:12) > > at > org.junit.runners.model.FrameworkMethod.invokeExplosively( > FrameworkMethod.java:47) > > at > org.junit.internal.runners.statements.InvokeMethod. > evaluate(InvokeMethod.java:17) > > at > org.junit.internal.runners.statements.RunBefores. > evaluate(RunBefores.java:26) > > at > org.junit.internal.runners.statements.RunAfters.evaluate( > RunAfters.java:27) > > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > > at > org.junit.runners.BlockJUnit4ClassRunner.runChild( > BlockJUnit4ClassRunner.java:78) > > at > org.junit.runners.BlockJUnit4ClassRunner.runChild( > BlockJUnit4ClassRunner.java:57) > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( > JUnit4TestReference.java:86) > > at > org.eclipse.jdt.internal.junit.runner.TestExecution. > run(TestExecution.java:38) > > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:539) > > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:761) > > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > run(RemoteTestRunner.java:461) > > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > main(RemoteTestRunner.java:207) > > > Gary > > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter > wrote: > > > Hey, > > > > I’m going through the list of components I happen to work with and make > > them ready for Java 9. Since I’m blocked in the release process of > > collections because of the Windows test failures, I’m going to cut a RC > for > > IO 2.6 probably tomorrow night. > > > > Regards, > > Benedikt > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [DRAFT][REPORT] Apache Commons Board Report for September 2017
Worth mentioning the trademark thing? On 11 September 2017 at 13:51, Gary Gregory wrote: > Hi All: > > Any and all feedback welcome. > > Thank you! > Gary > > === > > ## Description: > - The Apache Commons project focuses on all aspects of reusable Java > components. > > - The Apache Commons components are widely used in many projects, both > within > Apache and without. Any ASF committer can commit to Apache Commons. > > - The last report was for the meeting of June 21, 2017. > > ## Issues: > - There are no issues requiring board attention at this time. > > ## Activity: > - The project is active with four (4) releases this reporting period. > > ## Health report: > - Most components in Commons are mature, but are still actively maintained >(4 releases). The dev list is active. JIRA is active. Speed of responses >to users is reasonable in most cases. We have 2 new PMC member, 2 new >committer, and Commons is still open to any Apache Committer. > - We are still experiencing some growing pains toward Commons Math 4. > There >is a backlog of issues in JIRA (not unlike other components) but no > clear >concensus in the community. Do-ocracy is likely to prevail. There is a >proposal on how to move the code base forward, either as a multi-module >project or multiple components within Commons. All of which can be read >on the developer's mailing list. > > ## PMC changes: > > - Currently 38 PMC members. > - New PMC members: > - Rob Tompkins was added to the PMC on Fri Jun 30 2017 > - Pascal Schumacher was added to the PMC on Fri Jun 30 2017 > > ## Committer base changes: > > - Currently 146 committers. > - New commmitters: > - Pascal Schumacher was added as a committer on Sat Jul 01 2017 > - Carl Franklin Hall was added as a committer on Wed Jul 05 2017 > > ## Releases: > > - Apache Commons CSV-1.5 was released on Sat Sep 02 2017 > - Apache Commons EMAIL 1.5 was released on Mon Jul 31 2017 > - Apache Commons FILEUPLOAD 1.3.3 was released on Mon Jun 12 2017 > - Apache Commons JCS-2.2 was released on Tue Aug 01 2017 > > ## JIRA activity: > > - 161 JIRA tickets created in the last 3 months > - 120 JIRA tickets closed/resolved in the last 3 months > > [If there are any security issues, these would be added here in a PRIVATE > section, not appropriate for a public list like the dev ML] > > Gary Gregory > Apache Commons Chair > -- Matt Sicker
Re: [JCS] update to Log4j 2 facade API
The log4j-api to JUL bridge would be for users who have a JUL logging config already that don't want to change, but do want all code to log to the same location. On 5 September 2017 at 08:45, Romain Manni-Bucau wrote: > 2017-09-05 15:33 GMT+02:00 Ralph Goers : > > > > > > On Sep 5, 2017, at 12:11 AM, Romain Manni-Bucau > > > wrote: > > > > > > 2017-09-05 9:01 GMT+02:00 Apache > ralph.go...@dslextreme.com>>: > > > > > >> > > >> > > >> > > >> Sent from my iPad > > >>> On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > >> wrote: > > >>> > > >>> Le 5 sept. 2017 05:40, "Ralph Goers" a > > >> écrit : > > >>> > > >>> > > >>>> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > >>> wrote: > > >>>> > > >>>> Le 4 sept. 2017 20:44, "Matt Sicker" a écrit : > > >>>> > > >>>> You don't duplicate any logging config. You can use both slf4j-api > and > > >>>> log4j-api with either logback or log4j2. > > >>>> > > >>>> > > >>>> Except you dont always have the choice with 2 apis. It also messes > up > > >>>> logging lifecycle and setup which needs 2 integrations in the > > >> environment. > > >>>> Whatever reason you use it is not free to switch and even if log4j2 > is > > >>>> awesome, it is far to be a first citizen api for a common library > used > > >> in > > >>> a > > >>>> lot of contexts IMHO. > > >>> > > >>> Now you have me curious about your last sentence. In you opinion, > what > > is > > >>> keeping Log4j2 from being a first citizen api for a common library? > You > > >>> didn’t mention SLF4J in that sentence so I am assuming you consider > it > > to > > >>> be one. Why? > > >>> > > >>> > > >>> Purely usages as an api. Once again the fact I'm very cautious moving > > to > > >>> log4j2 api is not about the quality of log4j2. Take most of asf > project > > >>> stacks and I guess slf4j, jul or even commons logging will be more > used > > >>> than log4j2 as an API. Side question: wonder if we can extract this > > stat > > >>> through asf infra? > > >>> > > >>> I hear the "if noone starts" side of the issue but it must be more > > global > > >>> than just one lib by lib (a bit like when tomee needs to support one > > more > > >>> java version and upgrades asm in openjpa, cxf, tomee, owb, ... at > > once). > > >>> > > >> > > >> You can look at the download stats from repository.apache.org. You > will > > >> see there are more downloads of the API than Log4J-core, but to be > > honest I > > >> have no idea what that means. I am just happy that the trend keeps > > going up. > > >> > > >> What does it really matter if it used more (or less) as an API? What > > >> matters most is how well it works for you and your users. In addition, > > if > > >> you look at the Github and Jira stats you will see that Log4J has been > > far > > >> more active over the last few years, so you are much more likely to > get > > >> better support. > > >> > > > > > > I think we agree on the user first point but not on what it means. By > > > itself log4j2 is awesome but in a container it just leads to issue > until > > > the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3 > of > > > the full distribution and not that far from a user app in term of > stack): > > > - cxf > > > - tomcat > > > - [beanutils] > > > - [collections] > > > - [dbcp2] > > > - [digester] > > > - [lang3] > > > - [pool2] > > > - geronimo-javamail > > > - geronimo-transaction > > > - hsqldb > > > - johnzon > > > - myfaces > > > - openejb/tomee > > > - openwebbeans > > > - quartz > > > - xbean > > > > > > How many use log4j2-api? None. All have potential bridges based on JUL, > > > slf4j or [logging] but none use log
Re: [JCS] update to Log4j 2 facade API
You don't duplicate any logging config. You can use both slf4j-api and log4j-api with either logback or log4j2. On 4 September 2017 at 00:08, Romain Manni-Bucau wrote: > If you ignore the container point - which for me is already blocking - you > have 2 issues with migratong to log4j2: > > 1. it is not mainstream compared to slf4j for instance so means once again > duplicating logging configs in user apps > 2. what would give stability to jcs users? Commons logging was targetting > this goal then it has been sl4j and now log4j2? Means each time you upgrade > you switch the lib which sounds horrible for a commons project. > > Side note on tomee isolating jcs: compared to other servers tomee doesnt do > it to let users inherit from all features and integrate with the libs > naturally. It has the drawback you mention bit the advantage to be able to > use the full ecosystem so will likely not change soon. > > Le 4 sept. 2017 02:30, "Ralph Goers" a écrit > : > > > Although I am a big fan of Log4j 2, there are use cases where more > thought > > needs to be given then just adopting it, SLF4J, JUL, etc. > > > > The problem comes into play in in frameworks like Tomcat, TomEE or JBoss > > AS. These frameworks need to perform logging but whatever they use has to > > be able to meet a few types of users: > > 1. Users that have multiple apps running in the container and want them > > all to use the same configuration and log to the same files. > > 2. Users that have multiple apps running in the container and want them > to > > have separate logging and log to different files. > > 3. Users that have multiple apps running in the container and want all > the > > container logs and application logs to use the same configuration. > > > > In addition, we know that various libraries and frameworks have chosen to > > use different logging frameworks. Usually, users want all of these > > consolidated so that they can use a single configuration for the > > application. This is easily doable except when the frameworks use > > java.util.logging AND the container also uses java.util.logging. Due to > the > > way java.util.logging works the logging framework jars have to be placed > in > > the class path of the container which makes it impossible to achieve > item 2 > > above. Similarly, if the container uses ANY of the common logging > > libraries, and they are exposed on the application’s class path then > users > > are required to use the logging libraries provided by the container and > > cannot use their own versions. > > > > That statement made in one of the emails that if JCS switches logging > > frameworks it would mean it would have to be dropped from TomEE since > TomEE > > will be using JUL. This is a prime example of what I mentioned in the > > previous paragraph. The correct solution here is to get TomEE’s use of > JCS > > out of the user’s application class path. Unfortunately, that isn’t > trivial. > > > > However, containers are a special case. Most frameworks just use a > logging > > framework and aren’t creating their own class loaders. In that case my > > advice is always “NEVER use java.util.logging”. First, its performance is > > terrible and second it is extremely difficult to use it as an API and > > direct the calls to another framework. I have been told the implementers > of > > jul spoke with Ceki before implementing it but they must not have asked > him > > the correct questions to come up with a design that is so bad. > > > > So just saying that Log4j 2 or SLF4J (or whatever else) should always be > > used isn’t necessarily correct. In the case of Tomcat or TomEE, if they > > cannot completely hide the logging framework from applications then it > > needs to use its own custom facade that any logging framework can > implement > > (and NOT use JUL). What they have done with JULI was on the right track > but > > still uses the java.util.logging design, which makes it very difficult > for > > users to achieve item 3 above. > > > > As far as I can tell JCS is a general purpose caching system meant to be > > used as a library within an application. For that use case, in my opinion > > using the Log4j 2 API is a much better choice than using Commons Logging. > > > > > > Ralph > > > > > > > > > On Sep 3, 2017, at 2:09 PM, Matt Sicker wrote: > > > > > > As an end user of libraries, I much prefer when they stick to using > > > log4j-api or slf4j-api instead of some annoying library-specific facade > > > which requires
Re: [JCS] update to Log4j 2 facade API
As an end user of libraries, I much prefer when they stick to using log4j-api or slf4j-api instead of some annoying library-specific facade which requires even more configuration to set up in the end. As long as I can pull in log4j-api, log4j-core, and log4j-slf4j-impl, everything "just works" essentially across all my libraries and in house code. I understand that some libraries are old and stuck to commons-logging as it was the main facade at the time (e.g., in Spring Framework), but chances are that nowadays, at least one or more of your libraries are going to bring in log4j-api or slf4j-api anyways. On 3 September 2017 at 14:22, Romain Manni-Bucau wrote: > Had a test using cdi integration but moving the level test reduced > execution time from ~1.4 to 1.25 (normalized numbers). It was ror millions > of calls but still worth it IMO. Log impl was indeed jul ;). > > > > Le 3 sept. 2017 20:16, "Thomas Vandahl" a écrit : > > On 03.09.17 20:11, Romain Manni-Bucau wrote: > > On the perf thing: isXXXEnabled can be costly by itself - see my last > > commit. > > Could you please provide some numbers to this claim? > > Bye, Thomas. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker
Re: [JCS] update to Log4j 2 facade API
That would definitely duplicate effort. I've seen a few libraries out there that abstract out logging only to make the default implementation slf4j or log4j-api which just makes yet another hop of indirection. On 3 September 2017 at 13:05, Gary Gregory wrote: > On Sep 3, 2017 12:00, "Thomas Vandahl" wrote: > > On 03.09.17 09:02, Romain Manni-Bucau wrote: > > Once again the issue is the risk to break users and to ensure the api is > > consistent accross all libs (jcs, openjpa, tomee, cxf, activemq, commons, > > ...). It is clearly not "is it good or bad" and tomee switch from log4j1 > to > > jul reduced the number of issues about the logging quite a lot and > increase > > the logging consistency. There is no free lunch ;). > > I guess the only real solution is a logging stub in JCS that can be tied > to any logging sub-system by configuration. It's not that difficult to do. > > > Would that not duplicate what logging facades (like log4j-api) already > provide? > > Gary > > > Bye, Thomas. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker
Re: [JCS] update to Log4j 2 facade API
Using JUL for any library, while dependency-free, is the worst of all worlds as it creates a huge overhead in logging. The only workaround in production applications is to disable logging to any logger tied to JUL, and then you have the fun of debugging production issues without logs. On 2 September 2017 at 13:04, Romain Manni-Bucau wrote: > Hi Gary, > > Can only be done in 3.x since we can't break it in a minor. > > Now more on the ecosystem it would also mean dropping or forking JCS from > TomEE since TomEE will stay JUL first for its stack and provides a light > facade to switch to log4j2 (long story short: it is to avoid to enforce a > lib users can not want or to avoid potential conflicts). > > However reworking the logging in JCS can be interesting, current log usage > is slow and sometimes in synchronized blocks so I guess we can be better. > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-09-02 19:55 GMT+02:00 Gary Gregory : > > > Hi All, > > > > How about updating JCS from Commons Logging to Log4j 2? > > > > Gary > > > -- Matt Sicker
Re: Attaching Apache repository pushes to GitHub page
Add your GitHub username to your LDAP profile by visiting https://id.apache.org/ On 3 August 2017 at 06:55, Jörg Schaible wrote: > Hi Eric, > > Eric Barnhill wrote: > > > I am applying for jobs soon and want my work on commons-numbers to be > > visible on my GitHub page. However I am pushing to an Apache repository > > rather than to my own fork, so it doesn't show up on my GitHub page. Is > > there a way to link the two? > > it should work if you add your Apache email address to the email addresses > in your GitHub profile. > > Cheers, > Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [VOTE] Release Commons Email 1.5 Based on RC1
If the build is anything like Log4j's, it probably has a separate rat config for the release profile than it does by default. On 30 July 2017 at 10:27, Gary Gregory wrote: > I always run: > > mvn apache-rat:check > > And > > mvn clirr:check > > Gary > > On Jul 30, 2017 07:12, "Stefan Bodewig" wrote: > > > On 2017-07-30, Gary Gregory wrote: > > > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > > Email Package" instead of "Commons Email Package". > > > > I was under the impression it had been generated by the commons-build > > plugin. Anyway, will fix it when I publish the release (no reason to > > vote on that). > > > > > RAT check fails with: > > > > > Unapproved licenses: > > > > > src/test/resources/eml/attachment-only.eml > > > src/test/resources/eml/html-attachment-content-disposition.eml > > > src/test/resources/eml/html-attachment-encoded-filename.eml > > > src/test/resources/eml/html-attachment.eml > > > src/test/resources/eml/multipart-report.eml > > > src/test/resources/eml/multipart-text-attachment-only.eml > > > src/test/resources/eml/multipart-text-attachment.eml > > > src/test/resources/eml/outofmemory-no-header-seperation.eml > > > src/test/resources/eml/simple-reply.eml > > > src/test/resources/eml/simple.eml > > > > The pom contains > > > > > > org.apache.rat > > apache-rat-plugin > > > > > > src/test/resources/eml/*.eml > > > > > > > > > > and RAT is prefectly happy inside the site build. How do you execute the > > rat check? Comparing the POM with the one of Compress I see the plugin > > is configured inside the section for Email only, while it is > > inside for Compress. This may explain the difference when > > running rat checks directly. > > > > Stefan > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [log4j] Announce Scala release?
Also, this isn't the right mailing list now that I look more closely. Anyways, just sent out a release to announce, dev, and log4j-user. On 29 July 2017 at 20:41, Gary Gregory wrote: > I think you'll want to hit announce@a.o as well as our dev and user MLs. > > Gary > > On Sat, Jul 29, 2017 at 6:34 PM, Matt Sicker wrote: > > > Oh no, sending the email completely passed my mind. I'll follow up. > > > > On 29 July 2017 at 20:19, Gary Gregory wrote: > > > > > Hi All: > > > > > > Did I miss the announcement email for the log4j scala 11.0 components > > > release? > > > > > > Gary > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: [log4j] Announce Scala release?
Oh no, sending the email completely passed my mind. I'll follow up. On 29 July 2017 at 20:19, Gary Gregory wrote: > Hi All: > > Did I miss the announcement email for the log4j scala 11.0 components > release? > > Gary > -- Matt Sicker
Re: [all] Removal of old pgp key from https://www.apache.org/dist/commons/KEYS
I think so. On 19 July 2017 at 10:46, Gary Gregory wrote: > On Jul 19, 2017 08:43, "Matt Sicker" wrote: > > On 18 July 2017 at 15:02, Stefan Bodewig wrote: > > > > We shouldn't remove any key that has been used to sign a release in the > > past. No matter how long in the past :-) > > > > What about expired keys? > > > Can't those still be used to validate old releases? > > Gary > > > -- > Matt Sicker > -- Matt Sicker
Re: [all] Removal of old pgp key from https://www.apache.org/dist/commons/KEYS
On 18 July 2017 at 15:02, Stefan Bodewig wrote: > > We shouldn't remove any key that has been used to sign a release in the > past. No matter how long in the past :-) > What about expired keys? -- Matt Sicker
Re: [lang][collections] SortedProperties
Yeah, I was confused. Persistent collections have a meaning (e.g., see < https://pcollections.org/> for a Java library implementation) a bit different from persistent entities. On 18 July 2017 at 05:18, Jonathan Bluett-Duncan wrote: > Javen, > > Just for clarity, by persistent collections, are you talking about > _functional_ persistent collections (a la Scala, Clojure and Haskell), > _disk_-persisted collections, or some other definition of "persistent"? > > Jonathan > > On 18 Jul 2017 08:41, "Javen O'Neal" wrote: > > +1 for Lang. > > There aren't any persistent data structures in Collections, nor would I > think to look in Collections to find one. > > Properties is a persistent hashtable. SortedProperties is a persistent > TreeMap. > > Unless you're thinking about a new family of SortedProperties. Were you > thinking about letting the user provide the Map implementation and the > SortedProperties would handle the persistence? > For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I > do that? > new PersistentMap>(); > new PersistentMap>(); > Is there a real scenario where this would be needed? > > On Jul 18, 2017 00:19, "Amey Jadiye" wrote: > > > My opinion is this should go to *lang* because the fact is it's extended > > utility and not exactly as data structures though it looks like one. It's > > main purpose is to hold properties and not the data. Commons collection > > aims to provide utlilities and extension to data structures and not to > > properties related utilities. Properties is very basic thing no matter > > it's sorted or not sorted and should go to lang. > > > > Regards, > > Amey > > > > On Tue, Jul 18, 2017, 11:58 AM Gary Gregory > > wrote: > > > > > Hi, > > > > > > I'd to have a new class called SortedProperties that extends > > > java.util.Properties. > > > > > > Should that go in [lang] or [collections]? > > > > > > I first thought [lang], but it _is_ a collection after all. > > > > > > Gary > > > > > > -- Matt Sicker
Re: [VOTE] Release Apache Commons DbUtils 1.7 based on RC2
; > These are the Maven Artifacts and their hashes: > > >> > > > > >> > > commons-dbutils-1.7-javadoc.jar > > >> > > (SHA: 23ba15ea4ff18419fb17715e8956846b863c2d9d) > > >> > > commons-dbutils-1.7-javadoc.jar.asc > > >> > > (SHA: fb5f36b61e056c31ea3181c0a67c9bf395cd56e0) > > >> > > commons-dbutils-1.7-javadoc.jar.md5 > > >> > > (SHA: daae48f032e6f96a63c8b47241de7fae7c53e176) > > >> > > commons-dbutils-1.7-javadoc.jar.sha1 > > >> > > (SHA: 092fbb145d61a4d93dd645a529e212fe01099d14) > > >> > > commons-dbutils-1.7-sources.jar > > >> > > (SHA: 38e00df900c6c0dd01dec42ad411ff44de10ac0b) > > >> > > commons-dbutils-1.7-sources.jar.asc > > >> > > (SHA: 601b900b1a6079c09a81da903f0bd418dc552f09) > > >> > > commons-dbutils-1.7-sources.jar.md5 > > >> > > (SHA: 1fce7ad72fc18d639705a1573c34cc012e076a25) > > >> > > commons-dbutils-1.7-sources.jar.sha1 > > >> > > (SHA: 198663d496d62b4f78ab8edf85c7125e79213f32) > > >> > > commons-dbutils-1.7-test-sources.jar > > >> > > (SHA: 6c61c9324218009db50415bfdf8b1c6675dcbbf0) > > >> > > commons-dbutils-1.7-test-sources.jar.asc > > >> > > (SHA: 120cd3f4f4d673eb49cd976f814110a74bde438f) > > >> > > commons-dbutils-1.7-test-sources.jar.md5 > > >> > > (SHA: 135c8c5dd7c868c116d17dc694731ff6230270f7) > > >> > > commons-dbutils-1.7-test-sources.jar.sha1 > > >> > > (SHA: 38d6480819b9d813ad18307349a19603ed53f453) > > >> > > commons-dbutils-1.7-tests.jar > > >> > > (SHA: be58f64000d4b5a5932f5c18afbb847b3fe6caf3) > > >> > > commons-dbutils-1.7-tests.jar.asc > > >> > > (SHA: b93e9d1b23bbf051630b60ba917af03f0fd2a8cc) > > >> > > commons-dbutils-1.7-tests.jar.md5 > > >> > > (SHA: beb09dfdd239b5a09d96132546e6a9cb5899617e) > > >> > > commons-dbutils-1.7-tests.jar.sha1 > > >> > > (SHA: d25629f7ea7d3e352ad98f6d955ce473606d3ecf) > > >> > > commons-dbutils-1.7.jar > > >> > > (SHA: 8b750837334b0c92f3f09a481ff6638aa0a7e370) > > >> > > commons-dbutils-1.7.jar.asc > > >> > > (SHA: bbd4a9cdb128233e2bf67c252789385091576a6c) > > >> > > commons-dbutils-1.7.jar.md5 > > >> > > (SHA: 5b90d74d0967dcb3ba4422489910730c3ff396b5) > > >> > > commons-dbutils-1.7.jar.sha1 > > >> > > (SHA: ecb00abbc04548398986b80d1f0e48373d55c2b8) > > >> > > commons-dbutils-1.7.pom > > >> > > (SHA: dcaebe462df8501f14d764f2bece496e942586eb) > > >> > > commons-dbutils-1.7.pom.asc > > >> > > (SHA: 0547d14d07117cc496c018ef7fd320ae32884287) > > >> > > commons-dbutils-1.7.pom.md5 > > >> > > (SHA: c5a32289a952a40202461528eeffcad474d0ef6c) > > >> > > commons-dbutils-1.7.pom.sha1 > > >> > > (SHA: 0aa622dc6fa860ceeaf86fcb3e1a48f9530c3398) > > >> > > > > >> > > Details of changes since 1.6 are in the release notes: > > >> > > > > >> > > https://dist.apache.org/repos/dist/dev/commons/dbutils/ > > >> > > DBUTILS_1_7_RC2/RELEASE-NOTES.txt > > >> > >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > > >> > > changes-report.html > > >> > > > > >> > > Site: > > >> > >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > > >> > > > > >> > > Clirr Report (compared to 1.6): > > >> > >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > > >> > clirr-report.html > > >> > > > > >> > >- All changes are additions and do not represent any > fundamental > > or > > >> > > breaking changes in how to use the library, so not revving the > > version. > > >> > > > > >> > > RAT Report: > > >> > >https://home.apache.org/~thecarlhall/dbutils-1.7-RC2/ > > >> rat-report.html > > >> > > > > >> > > KEYS: > > >> > >https://www.apache.org/dist/commons/KEYS > > >> > > > > >> > > Please review the release candidate and vote. > > >> > > This vote will close no sooner that 72 hours from now, > > >> > > i.e. sometime after 23:00 UTC 19-July-2017 > > >> > > > > >> > > [ ] +1 Release these artifacts > > >> > > [ ] +0 OK, but... > > >> > > [ ] -0 OK, but really should fix... > > >> > > [ ] -1 I oppose this release because... > > >> > > > > >> > > Thanks! > > >> > > -Carl > > >> > > > > >> > > > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [daemon] moving to git ? and bump java version.
C quality somewhat depends on which version of C you're trying to remain compatible with (I'm guessing C89 due to Windows, though I could be wrong). Valgrind and other tracing tools are typically used. I'd take a look at what OpenOffice is doing for local examples (though they have a crazy build system last I heard), or the FSF, Linux, Xorg, FreeDesktop, GNOME, KDE, or other major users of C and C++. On the modern front, it'd be interesting if it were written in Rust, though I don't know enough about the language to say if it's worth porting to eventually. On 15 July 2017 at 09:26, sebb wrote: > On 15 July 2017 at 15:21, Amey Jadiye wrote: > > Yes, that's mentioned in my previous mail, I was also curious to know > from > > the C developers here in dev-list that how can we make *that* C code > > better? basically I'm looking findbug, checkstyle, jococo, junit > > *equivalent* for C code. > > No idea on automated tools. > However when I last looked there was plenty of scope for better > documentation. > > Also I did wonder if the Prunmgr GUI might be better coded as a > (mainly) Java application. > > The procrun stuff has to remain as C. > > > Regards, > > Amey > > > > On Sat, Jul 15, 2017 at 7:44 PM, sebb wrote: > > > >> Also note that there is hardly any Java code; most of it is written in > C. > >> > >> On 14 July 2017 at 00:43, Gary Gregory wrote: > >> > It seems OK to me to update to Java 6 for now and get this to compile > >> under > >> > java 9 for those folks who will try... > >> > > >> > Gary > >> > > >> > On Wed, Jul 12, 2017 at 9:09 AM, Amey Jadiye > >> wrote: > >> > > >> >> Thanks for great insights Mark. > >> >> > >> >> On Wed, Jul 12, 2017, 9:28 PM Mark Thomas wrote: > >> >> > >> >> > On 12 July 2017 16:33:01 CEST, Matt Sicker > wrote: > >> >> > >Are there plans to require 1.7 for Tomcat anytime? Otherwise, it > >> might > >> >> > >be > >> >> > >necessary to make a new major version of daemon eventually for > Java 8 > >> >> > >or 9. > >> >> > > >> >> > Tomcat major versions are aligned with Java EE versions which in > turn > >> >> have > >> >> > a minimum Java version. > >> >> > > >> >> > Tomcat supports 3 current versions in parallel so we currently > have: > >> >> > > >> >> > Tomcat 9 - Java EE 8 - Java 8 > >> >> > Tomcat 8 - Java EE 7 - Java 7 > >> >> > Tomcat 7 - Java EE 6 - Java 6 > >> >> > > >> >> > Tomcat 7 support will continue until at least Java EE 9 is > released. > >> That > >> >> > is meant to be next year but there are no firm dates yet and > >> experience > >> >> > suggests the Java EE 9 release date will slip. > >> >> > > >> >> > On that basis I expect Tomcat to need a Daemon that supports Java 6 > >> for > >> >> at > >> >> > least 2 more years. > >> >> > > >> >> > Is there a user requirement driving an increase in the minimum Java > >> >> > version? If not, I suggest we stick with 6 for now. > >> >> > > >> >> > >> >> There is no user requirement , Commons daemon is still keeping > minimum > >> >> dependency on java 1.5, we were thinking to move on minimum 1.6, > nice to > >> >> hear there won't be any issue with tomcat since it's already on 1.6 > >> >> > >> >> For moving to much higher i.e. java 1.7 I'm sure daemon will take > >> another > >> >> 2-3 year for keeping stability across projects. > >> >> > >> >> Regards, > >> >> Amey > >> >> > >> >> Mark > >> >> > > >> >> > > >> >> > > > >> >> > >Anyways, 1.6 minimum makes sense to me mainly due to Java 9's > >> compiler > >> >> > >not > >> >> > >supporting Java 5 targets anymore. > >> >> > > > >> >> > >On 12 July 2017 at 09:19, Mark Thomas wrote: > >> >> > > > >> >> > >> On 11 July 2017 21:02:54 CEST, Amey Jadiye < > am
Re: [daemon] moving to git ? and bump java version.
Are there plans to require 1.7 for Tomcat anytime? Otherwise, it might be necessary to make a new major version of daemon eventually for Java 8 or 9. Anyways, 1.6 minimum makes sense to me mainly due to Java 9's compiler not supporting Java 5 targets anymore. On 12 July 2017 at 09:19, Mark Thomas wrote: > On 11 July 2017 21:02:54 CEST, Amey Jadiye wrote: > >Hi Daemon Maintainers / All, > > > >Daemon seems to be still being maintained on svn, do we have any plan > >moving code base to git ? > > No preference on this. > > >As fact there is low activity in daemon no one thought of bumping > >version > >from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ? > >shall we bump it minimum to 1.6 ? > > 1.6 is OK for Tomcat. Anything higher will cause problems. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [daemon] moving to git ? and bump java version.
We could migrate to git as we've been slowly doing for most of Commons. Someone needs to take charge and handle it, though. A lazy vote thread to do so is the usual way to start the process. On 11 July 2017 at 14:02, Amey Jadiye wrote: > Hi Daemon Maintainers / All, > > Daemon seems to be still being maintained on svn, do we have any plan > moving code base to git ? > > As fact there is low activity in daemon no one thought of bumping version > from 1.5 to 1.6 OR we are keeping it purposefully to 1.5 ? > shall we bump it minimum to 1.6 ? > > Regards, > Amey > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker
Re: [compress] HasCharset is a bad name
The colour, dish, or liqueur? Or mountains apparently. On 10 July 2017 at 17:53, Gary Gregory wrote: > On Mon, Jul 10, 2017 at 3:04 PM, Matt Sicker wrote: > > > Charsetable? CharsetAware? ;P > > > > Chartreuse? ChartreuseDeParme? > > Gary > > > > > > On 10 July 2017 at 17:03, Gary Gregory wrote: > > > > > I renamed HasCharset to CharsetAccessor (until someone comes up with a > > > better name before 1.15.) > > > > > > Gary > > > > > > On Wed, Jul 5, 2017 at 11:57 PM, Stefan Bodewig > > > wrote: > > > > > > > On 2017-07-05, Gary Gregory wrote: > > > > > > > > > The new interface name HasCharset is pretty bad IMO. > > > > > > > > fair enough. > > > > > > > > > CharsetProvider is the obvious (to me) better name even though > there > > > > > already is a class called java.nio.charset.spi.CharsetProvider. > > > > > > > > I don't think so, this really is a marker interface for classes also > > > > implementing ZipEncoding (Simon didn't want to extend the existing > > > > interface). > > > > > > > > Hmm, maybe we could make it extend ZipEncoding and call it something > > > > like ZipEncodingWithCharset? > > > > > > > > Stefan > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: [compress] HasCharset is a bad name
Charsetable? CharsetAware? ;P On 10 July 2017 at 17:03, Gary Gregory wrote: > I renamed HasCharset to CharsetAccessor (until someone comes up with a > better name before 1.15.) > > Gary > > On Wed, Jul 5, 2017 at 11:57 PM, Stefan Bodewig > wrote: > > > On 2017-07-05, Gary Gregory wrote: > > > > > The new interface name HasCharset is pretty bad IMO. > > > > fair enough. > > > > > CharsetProvider is the obvious (to me) better name even though there > > > already is a class called java.nio.charset.spi.CharsetProvider. > > > > I don't think so, this really is a marker interface for classes also > > implementing ZipEncoding (Simon didn't want to extend the existing > > interface). > > > > Hmm, maybe we could make it extend ZipEncoding and call it something > > like ZipEncodingWithCharset? > > > > Stefan > > > > ----- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [lang] Applying IntelliJ IDEA refactorings
I personally don't see the point of making a jira issue for it. On 9 July 2017 at 20:19, Jonathan Bluett-Duncan wrote: > Okay, thanks for the clarification Gary. > > Does this mean, by extension, that there's no need to create a new JIRA > issue? In other words, would just a new GitHub PR be fine (at least for > now)? > > Jonathan > > On 10 July 2017 at 01:32, Gary Gregory wrote: > > > I would think an ICLA is not needed if the only thing we are talking > about > > are clean-up style refactoring. > > > > Gary > > > > On Sun, Jul 9, 2017 at 2:27 PM, Jonathan Bluett-Duncan < > > jbluettdun...@gmail.com> wrote: > > > > > I've re-read the contribution guidelines > > > <https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md>, > > but > > > it's not clear to me if my changes are non-trivial enough to warrant a > > new > > > JIRA issue. > > > > > > Can someone advise me on this? > > > > > > Jonathan > > > > > > On 6 July 2017 at 00:51, Jonathan Bluett-Duncan < > jbluettdun...@gmail.com > > > > > > wrote: > > > > > > > Okay, I don't intend to apply any `@SuppressWarnings` during my > > > > refactoring efforts - if IntelliJ still reports warnings after my > > > efforts, > > > > then I can live with that. :) > > > > > > > > Jonathan > > > > > > > > On 6 July 2017 at 00:31, Matt Sicker wrote: > > > > > > > >> The only thing I can think of that conflicts sometimes with IDEA > > versus > > > >> Eclipse are custom @SupressWarnings strings causing warnings in > > Eclipse. > > > >> The default IntelliJ warnings tend to be simple things that wouldn't > > > cause > > > >> an issue, however, based in my experience. It's only some of the > > > advanced > > > >> inspections that can get strange. > > > >> > > > >> On 5 July 2017 at 17:24, Jonathan Bluett-Duncan < > > > jbluettdun...@gmail.com> > > > >> wrote: > > > >> > > > >> > Great! Sounds like there's general agreement on me pursuing at > least > > > >> some > > > >> > of these refactorings, right? > > > >> > > > > >> > On the subject of code style guidelines, AFAIK [lang] uses > > Checkstyle > > > to > > > >> > check style adherence? So I assume that if the corresponding Maven > > > goal > > > >> > passes after a refactoring, then it's okay to submit it as a > GitHub > > > PR. > > > >> > > > > >> > I don't expect changes suggested by IDEA to cause warnings/errors > in > > > >> > Eclipse or for the Eclipse Java compiler either. Is there an > > automated > > > >> way > > > >> > to explicitly check for things like this through Apache's > > > >> infrastructure? > > > >> > Or would I need to manually download Eclipse and check on my > > machine? > > > >> > > > > >> > I've already created an Apache JIRA account and signed the CLA, > but > > > now > > > >> > it's not clear to me what to do next. Can someone kindly advise me > > on > > > >> the > > > >> > next step? > > > >> > > > > >> > Jonathan > > > >> > > > > >> > On 5 July 2017 at 20:33, Gary Gregory > > wrote: > > > >> > > > > >> > > Keep in mind that not all of us use IDEA. For example, I am on > > > >> Eclipse. I > > > >> > > do not think this should be an issue for any of these changes > > > thougg. > > > >> I > > > >> > do > > > >> > > not expect that changes from IDEA warnings would cause the > Eclipse > > > >> Java > > > >> > > compiler to issue warnings, and vice-versa. > > > >> > > > > > >> > > Gary > > > >> > > > > > >> > > On Jul 5, 2017 12:23, "Allon Mureinik" > > wrote: > > > >> > > > > > >> > > > I've submitted several such cleanups over the past couple of > > > month, > > > >> and > > > >> >
Re: [lang] Applying IntelliJ IDEA refactorings
The only thing I can think of that conflicts sometimes with IDEA versus
Eclipse are custom @SupressWarnings strings causing warnings in Eclipse.
The default IntelliJ warnings tend to be simple things that wouldn't cause
an issue, however, based in my experience. It's only some of the advanced
inspections that can get strange.
On 5 July 2017 at 17:24, Jonathan Bluett-Duncan
wrote:
> Great! Sounds like there's general agreement on me pursuing at least some
> of these refactorings, right?
>
> On the subject of code style guidelines, AFAIK [lang] uses Checkstyle to
> check style adherence? So I assume that if the corresponding Maven goal
> passes after a refactoring, then it's okay to submit it as a GitHub PR.
>
> I don't expect changes suggested by IDEA to cause warnings/errors in
> Eclipse or for the Eclipse Java compiler either. Is there an automated way
> to explicitly check for things like this through Apache's infrastructure?
> Or would I need to manually download Eclipse and check on my machine?
>
> I've already created an Apache JIRA account and signed the CLA, but now
> it's not clear to me what to do next. Can someone kindly advise me on the
> next step?
>
> Jonathan
>
> On 5 July 2017 at 20:33, Gary Gregory wrote:
>
> > Keep in mind that not all of us use IDEA. For example, I am on Eclipse. I
> > do not think this should be an issue for any of these changes thougg. I
> do
> > not expect that changes from IDEA warnings would cause the Eclipse Java
> > compiler to issue warnings, and vice-versa.
> >
> > Gary
> >
> > On Jul 5, 2017 12:23, "Allon Mureinik" wrote:
> >
> > > I've submitted several such cleanups over the past couple of month, and
> > for
> > > the most part, they've been well received.
> > >
> > > I think the key here is to improve the codebase when possible but to
> > leave
> > > room to deviate from IntelliJ's norms when there's a good reason to.
> > > Perhaps annotating such places with @SuppressWarning would be the best
> > > approach, to signal to future developers that the warning was
> considered,
> > > and we explicitly decided to suppress it (possibly with a comment in
> the
> > > code explaining why).
> > >
> > >
> > > On Wed, Jul 5, 2017 at 6:42 PM, Matt Sicker wrote:
> > >
> > > > I like the idea myself at least, though I'm not sure if it conflicts
> > with
> > > > any coding styleguides established.
> > > >
> > > > On 4 July 2017 at 18:18, Jonathan Bluett-Duncan <
> > jbluettdun...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'm interested in going through commons-lang with IntelliJ IDEA and
> > > > > applying small refactorings to make the code base easier to read
> > and/or
> > > > > more performant (and also make IntelliJ IDEA itself report less
> > > > warnings).
> > > > >
> > > > > Is this something that the [lang] team would find useful?
> > > > >
> > > > > Examples of refactorings that I could apply include:
> > > > >
> > > > >- Replace manual array-to-collection copy operations with
> > > > >`Collections.addAll()`.
> > > > >- Replace simple `String{Buffer,Builder}` usages with direct
> > > `String`
> > > > >concatenations or `String.format()`.
> > > > >- Simplifying boolean expressions like `obj instanceof CharRange
> > ==
> > > > >false` to `!(obj instanceof CharRange)`.
> > > > >
> > > > >
> > > > > Cheers,
> > > > > Jonathan
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker
> > > >
> > >
> >
>
--
Matt Sicker
Re: [lang] Applying IntelliJ IDEA refactorings
I like the idea myself at least, though I'm not sure if it conflicts with
any coding styleguides established.
On 4 July 2017 at 18:18, Jonathan Bluett-Duncan
wrote:
> Hi all,
>
> I'm interested in going through commons-lang with IntelliJ IDEA and
> applying small refactorings to make the code base easier to read and/or
> more performant (and also make IntelliJ IDEA itself report less warnings).
>
> Is this something that the [lang] team would find useful?
>
> Examples of refactorings that I could apply include:
>
>- Replace manual array-to-collection copy operations with
>`Collections.addAll()`.
>- Replace simple `String{Buffer,Builder}` usages with direct `String`
>concatenations or `String.format()`.
>- Simplifying boolean expressions like `obj instanceof CharRange ==
>false` to `!(obj instanceof CharRange)`.
>
>
> Cheers,
> Jonathan
>
--
Matt Sicker
Re: Things in a POM file that are not probably incorrect
Java 9 can still run old bytecode, but they're removing compiler support for outputting that bytecode apparently (either that or syntax support). On 27 June 2017 at 18:45, Emmanuel Bourg wrote: > Le 27/06/2017 à 00:02, Simon Spero a écrit : > > > JDK 9 cannot generate or parse class files compiled with -target 1.5 > [1]. > > AFAIK Java 9 can still parse 1.5 (and lower) class files. > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [DISCUSS] Do we need a vote for moving components to git?
The only objection I've seen to switching on any project so far was other projects using svn:external to sync up a commons project, but there are workarounds for that (e.g., the GitHub svn mirror). On 28 June 2017 at 03:45, Amey Jadiye wrote: > unless there is strong reason to stick with svn we should move on git(as > many other already moved). I agree that in few cases svn is preferred and > that may open huge discussion but atleast for Commons I don't see much > advantages to use svn. people who are using svn from long time usually > comes in comfort zone since svn is really really easy to use. :) > > Regards, > Amey > > On Wed, Jun 28, 2017, 1:00 PM Stefan Bodewig wrote: > > > On 2017-06-28, Amey Jadiye wrote: > > > > > I think just announcing with intention is enough as git is always > better > > > than svn and at some point everyone will wish to move on git. > > > > There certainly are people who disagree with your (I'm not one of them) > ;-) > > > > Stefan > > > -- Matt Sicker
Re: Commons sub project for parallel method execution
There's also some interesting execution APIs available in the Scala
standard library. Those are built on top of ForkJoinPool and such nowadays,
but the idea is there for a nicer API on top of ExecutorService and other
low level details.
In the interests of concurrency, there are other thread-like models that
can be explored. For example: http://docs.paralleluniverse.co/quasar/
On 12 June 2017 at 21:22, Bruno P. Kinoshita <
brunodepau...@yahoo.com.br.invalid> wrote:
> Interesting idea. And great discussion. Can't really say I'd have a use
> case for that right now, so abstaining from the discussion around the
> implementation.
>
> I believe if we decide to explore this idea in Commons, we will probably
> move it to sandbox? Even if we do not move that to Commons or to sandbox, I
> intend to find some time in the next days to try Apache Commons Javaflow
> with this library.
>
> Jenkins implemented pipelines + continuations with code that when started
> it looked a lot like Javaflow. The execution in parallel is taken care in
> some internal modules in Jenkins, but I would like to see how if simpler
> implementation like this one would work.
>
> Ideally, this utility would execute in parallel, say, 20 tasks each taking
> 5 minutes (haven't looked if it supports fork/join). Then I would be able
> to have checkpoints during the execution and if the whole workflow fails, I
> would be able to restart it from the last checkpoint.
>
>
> I use Java7+ concurrent classes when I need to execute tasks in parallel
> (though I'm adding a flag to Paul King's message in this thread to give
> GPars a try too!), but I am unaware of any way to have persistentable (?)
> continuation workflows as in Jenkins, but with simple Java code.
>
> Cheers
> Bruno
>
>
> From: Gary Gregory
> To: Commons Developers List
> Sent: Tuesday, 13 June 2017 2:08 PM
> Subject: Re: Commons sub project for parallel method execution
>
>
>
> On Mon, Jun 12, 2017 at 6:56 PM, Matt Sicker wrote:
>
> > So wouldn't something like ASM or Javassist or one of the zillion other
> > bytecode libraries be a better alternative to using reflection for
> > performance? Also, using the Java 7 reflections API improvements helps
> > speed things up quite a bit.
> >
>
> IMO, unless you are doing scripting, reflection should be a used as a
> workaround, but that's just me. For example, like we do in Commons IO's
> Java7Support class.
>
> But I digress ;-)
>
> This is clearly an interesting topic. My concern is that there is a LOT of
> code out there that does stuff like this at the low and high level from the
> JRE's fork/join to Apache Spark and so on as I've stated.
>
> IMO something new would have to be both unique and since this is Commons,
> potentially pluggable into other frameworks.
>
> Gary
>
>
>
> > On 12 June 2017 at 20:37, Paul King wrote:
> >
> > > My goto library for such tasks would be GPars. It has both Java and
> > > Groovy support for most things (actors/dataflow) but less so for
> > > asynchronous task execution. It's one of the things that would be good
> > > to explore in light of Java 8. Groovy is now Apache, GPars not at this
> > > stage.
> > >
> > > So with adding two jars (GPars + Groovy), you can use Groovy like this:
> > >
> > > @Grab('org.codehaus.gpars:gpars:1.2.1')
> > > import com.arun.student.StudentService
> > > import groovyx.gpars.GParsExecutorsPool
> > >
> > > long startTime = System.nanoTime()
> > > def service = new StudentService()
> > > def bookSeries = ["A Song of Ice and Fire": 7, "Wheel of Time": 14,
> > > "Harry Potter": 7]
> > >
> > > def tasks = [
> > > { println service.findStudent("j...@gmail.com", 11, false) },
> > > { println service.getStudentMarks(1L) },
> > > { println service.getStudentsByFirstNames(["John","Alice"]) },
> > > { println service.getRandomLastName() },
> > > { println service.findStudentIdByName("Kate", "Williams") },
> > > { service.printMapValues(bookSeries) }
> > > ]
> > >
> > > GParsExecutorsPool.withPool {
> > > tasks.collect{ it.callAsync() }.collect{ it.get() }
> > > //tasks.eachParallel{ it() } // one of numerous alternatives
> > > }
> > >
> > > long executionTime = (System.nanoTime() - startTime) / 100
> > > println "\nTotal elapsed time is
Re: Commons sub project for parallel method execution
So wouldn't something like ASM or Javassist or one of the zillion other
bytecode libraries be a better alternative to using reflection for
performance? Also, using the Java 7 reflections API improvements helps
speed things up quite a bit.
On 12 June 2017 at 20:37, Paul King wrote:
> My goto library for such tasks would be GPars. It has both Java and
> Groovy support for most things (actors/dataflow) but less so for
> asynchronous task execution. It's one of the things that would be good
> to explore in light of Java 8. Groovy is now Apache, GPars not at this
> stage.
>
> So with adding two jars (GPars + Groovy), you can use Groovy like this:
>
> @Grab('org.codehaus.gpars:gpars:1.2.1')
> import com.arun.student.StudentService
> import groovyx.gpars.GParsExecutorsPool
>
> long startTime = System.nanoTime()
> def service = new StudentService()
> def bookSeries = ["A Song of Ice and Fire": 7, "Wheel of Time": 14,
> "Harry Potter": 7]
>
> def tasks = [
> { println service.findStudent("j...@gmail.com", 11, false) },
> { println service.getStudentMarks(1L) },
> { println service.getStudentsByFirstNames(["John","Alice"]) },
> { println service.getRandomLastName() },
> { println service.findStudentIdByName("Kate", "Williams") },
> { service.printMapValues(bookSeries) }
> ]
>
> GParsExecutorsPool.withPool {
> tasks.collect{ it.callAsync() }.collect{ it.get() }
> //tasks.eachParallel{ it() } // one of numerous alternatives
> }
>
> long executionTime = (System.nanoTime() - startTime) / 100
> println "\nTotal elapsed time is $executionTime\n\n"
>
>
> Cheers, Paul.
>
>
> On Tue, Jun 13, 2017 at 9:29 AM, Matt Sicker wrote:
> > I'd be interested to see where this leads to. It could end up as a sort
> of
> > Commons Parallel library. Besides providing an execution API, there could
> > be plenty of support utilities that tend to be found in all the
> > *Util(s)/*Helper classes in projects like all the ones I mentioned
> earlier
> > (basically all sorts of Hadoop-related projects and other distributed
> > systems here).
> >
> > Really, there's so many ways that such a project could head, I'd like to
> > hear more ideas on what to focus on.
> >
> > On 12 June 2017 at 18:19, Gary Gregory wrote:
> >
> >> The upshot is that there has to be a way to do this with some custom
> code
> >> to at least have the ability to 'fast path' the code without reflection.
> >> Using lambdas should make this fairly syntactically unobtrusive.
> >>
> >> On Mon, Jun 12, 2017 at 4:02 PM, Arun Mohan
> >> wrote:
> >>
> >> > Yes, reflection is not very performant but I don't think I have any
> other
> >> > choice since the library has to inspect the object supplied by the
> client
> >> > at runtime to pick out the methods to be invoked using
> CompletableFuture.
> >> > But the performance penalty paid for using reflection will be more
> than
> >> > offset by the savings of parallel method execution, more so as the no
> of
> >> > methods executed in parallel increases.
> >> >
> >> > On Mon, Jun 12, 2017 at 3:21 PM, Gary Gregory >
> >> > wrote:
> >> >
> >> > > On a lower-level, if you want to use this for lower-level services
> >> (where
> >> > > there is no network latency for example), you will need to avoid
> using
> >> > > reflection to get the best performance.
> >> > >
> >> > > Gary
> >> > >
> >> > > On Mon, Jun 12, 2017 at 3:15 PM, Arun Mohan <
> strider90a...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi Gary,
> >> > > >
> >> > > > Thanks for your response. You have some valid and interesting
> points
> >> > :-)
> >> > > > Of course you are right that Spark is much more mature. Thanks for
> >> your
> >> > > > insight.
> >> > > > It will be interesting indeed to find out if the core
> parallelization
> >> > > > engine of Spark can be isolated like you suggest.
> >> > > >
> >> > > > I started working on this project because I felt that there was no
> >> good
> >> > > > library for parallelizing method calls which can be plugged in
> easily
> >> > > into
> >
Re: Commons sub project for parallel method execution
Last time I used Spring, they had an @Async annotation you could use which would automatically execute in an executor service (all handled via bean proxies as usual). On 12 June 2017 at 19:22, Gary Gregory wrote: > Hi All, > > I think it would be most helpful to note the distinction between the > parallelism aspect and the bridge to domain classes aspect (currently done > with reflection in the proposed github repo.) > > It seems (to me) that in between the ForkJoin framework already in Java (a > low-level library) and up to Apache Spark (an lowel-level set of classes > and high-level application-server-like code base), there are a ton of > options already out there. I am not sure what yet another framework would > do that is not already there. > > Maybe the distinguishing factor here is the use of reflection? What about > annotations? That seems to be more modern approach (Java 5! :-) than the > typing of method names in code (as currently done in the repo) which is a > nightmare to maintain especially when you are in an evolving code base and > refactoring all the time. > > Maybe an interesting angle would be decorating domain classes with > annotations and submitting those to fork/join. Just thinkin' aloud... > > Gary > > On Mon, Jun 12, 2017 at 4:29 PM, Matt Sicker wrote: > > > I'd be interested to see where this leads to. It could end up as a sort > of > > Commons Parallel library. Besides providing an execution API, there could > > be plenty of support utilities that tend to be found in all the > > *Util(s)/*Helper classes in projects like all the ones I mentioned > earlier > > (basically all sorts of Hadoop-related projects and other distributed > > systems here). > > > > Really, there's so many ways that such a project could head, I'd like to > > hear more ideas on what to focus on. > > > > On 12 June 2017 at 18:19, Gary Gregory wrote: > > > > > The upshot is that there has to be a way to do this with some custom > code > > > to at least have the ability to 'fast path' the code without > reflection. > > > Using lambdas should make this fairly syntactically unobtrusive. > > > > > > On Mon, Jun 12, 2017 at 4:02 PM, Arun Mohan > > > wrote: > > > > > > > Yes, reflection is not very performant but I don't think I have any > > other > > > > choice since the library has to inspect the object supplied by the > > client > > > > at runtime to pick out the methods to be invoked using > > CompletableFuture. > > > > But the performance penalty paid for using reflection will be more > than > > > > offset by the savings of parallel method execution, more so as the no > > of > > > > methods executed in parallel increases. > > > > > > > > On Mon, Jun 12, 2017 at 3:21 PM, Gary Gregory < > garydgreg...@gmail.com> > > > > wrote: > > > > > > > > > On a lower-level, if you want to use this for lower-level services > > > (where > > > > > there is no network latency for example), you will need to avoid > > using > > > > > reflection to get the best performance. > > > > > > > > > > Gary > > > > > > > > > > On Mon, Jun 12, 2017 at 3:15 PM, Arun Mohan < > strider90a...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > Hi Gary, > > > > > > > > > > > > Thanks for your response. You have some valid and interesting > > points > > > > :-) > > > > > > Of course you are right that Spark is much more mature. Thanks > for > > > your > > > > > > insight. > > > > > > It will be interesting indeed to find out if the core > > parallelization > > > > > > engine of Spark can be isolated like you suggest. > > > > > > > > > > > > I started working on this project because I felt that there was > no > > > good > > > > > > library for parallelizing method calls which can be plugged in > > easily > > > > > into > > > > > > an existing java project. Ultimately, if such a solution can be > > > > > > incorporated in the Apache Commons, it would be a useful addition > > to > > > > the > > > > > > Commons repository. > > > > > > > > > > > > Thanks, > > > > > > Arun > > > > > > > >
Re: Commons sub project for parallel method execution
I'd be interested to see where this leads to. It could end up as a sort of Commons Parallel library. Besides providing an execution API, there could be plenty of support utilities that tend to be found in all the *Util(s)/*Helper classes in projects like all the ones I mentioned earlier (basically all sorts of Hadoop-related projects and other distributed systems here). Really, there's so many ways that such a project could head, I'd like to hear more ideas on what to focus on. On 12 June 2017 at 18:19, Gary Gregory wrote: > The upshot is that there has to be a way to do this with some custom code > to at least have the ability to 'fast path' the code without reflection. > Using lambdas should make this fairly syntactically unobtrusive. > > On Mon, Jun 12, 2017 at 4:02 PM, Arun Mohan > wrote: > > > Yes, reflection is not very performant but I don't think I have any other > > choice since the library has to inspect the object supplied by the client > > at runtime to pick out the methods to be invoked using CompletableFuture. > > But the performance penalty paid for using reflection will be more than > > offset by the savings of parallel method execution, more so as the no of > > methods executed in parallel increases. > > > > On Mon, Jun 12, 2017 at 3:21 PM, Gary Gregory > > wrote: > > > > > On a lower-level, if you want to use this for lower-level services > (where > > > there is no network latency for example), you will need to avoid using > > > reflection to get the best performance. > > > > > > Gary > > > > > > On Mon, Jun 12, 2017 at 3:15 PM, Arun Mohan > > > wrote: > > > > > > > Hi Gary, > > > > > > > > Thanks for your response. You have some valid and interesting points > > :-) > > > > Of course you are right that Spark is much more mature. Thanks for > your > > > > insight. > > > > It will be interesting indeed to find out if the core parallelization > > > > engine of Spark can be isolated like you suggest. > > > > > > > > I started working on this project because I felt that there was no > good > > > > library for parallelizing method calls which can be plugged in easily > > > into > > > > an existing java project. Ultimately, if such a solution can be > > > > incorporated in the Apache Commons, it would be a useful addition to > > the > > > > Commons repository. > > > > > > > > Thanks, > > > > Arun > > > > > > > > > > > > > > > > On Mon, Jun 12, 2017 at 3:01 PM, Gary Gregory < > garydgreg...@gmail.com> > > > > wrote: > > > > > > > > > Hi Arun, > > > > > > > > > > Sure, and that is to be expected, Spark is more mature than a four > > > class > > > > > prototype. What I am trying to get to is that in order for the > > library > > > to > > > > > be useful, you will end up with more in a first release, and after > a > > > > couple > > > > > more releases, there will be more and more. Would Spark not have in > > its > > > > > guts the same kind of code your are proposing here? By extension, > > will > > > > you > > > > > not end up with more framework-like (Spark-like) code and solutions > > as > > > > > found in Spark? I am just playing devil's advocate here ;-) > > > > > > > > > > > > > > > What would be interesting would be to find out if there is a core > > part > > > of > > > > > Spark that is separable and ex tractable into a Commons component. > > > Since > > > > > Spark has a proven track record, it is more likely, that such a > > library > > > > > would be generally useful than one created from scratch that does > not > > > > > integrate with anything else. Again, please do not take any of this > > > > > personally, I am just playing here :-) > > > > > > > > > > Gary > > > > > > > > > > > > > > > On Mon, Jun 12, 2017 at 2:29 PM, Matt Sicker > > wrote: > > > > > > > > > > > I already see a huge difference here: Spark requires a bunch of > > > > > > infrastructure to be set up, while this library is just a > library. > > > > > Similar > > > > > > to Kafka Streams versus Spark Strea
Re: Commons sub project for parallel method execution
I already see a huge difference here: Spark requires a bunch of infrastructure to be set up, while this library is just a library. Similar to Kafka Streams versus Spark Streaming or Flink or Storm or Samza or the others. On 12 June 2017 at 16:28, Gary Gregory wrote: > On Mon, Jun 12, 2017 at 2:26 PM, Arun Mohan > wrote: > > > Hi All, > > > > Good afternoon. > > > > I have been working on a java generic parallel execution library which > will > > allow clients to execute methods in parallel irrespective of the number > of > > method arguments, type of method arguments, return type of the method > etc. > > > > Here is the link to the source code: > > https://github.com/striderarun/parallel-execution-engine > > > > The project is in a nascent state and I am the only contributor so far. I > > am new to the Apache community and I would like to bring this project > into > > Apache and improve, expand and build a developer community around it. > > > > I think this project can be a sub project of Apache Commons since it > > provides generic components for parallelizing any kind of methods. > > > > Can somebody please guide me or suggest what other options I can explore > ? > > > > Hi Arun, > > Thank you for your proposal. > > How would this be different from Apache Spark? > > Thank you, > Gary > > > > > > Thanks, > > Arun > > > -- Matt Sicker
Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
I'd love to have a semantic versioning plugin like that which can suggest what the version number is for the entire project. Elm (programming language) has a tool like that, and it works rather well in practice (even though there are some popular libraries that are at version 5.0.0 already because of it). On 11 June 2017 at 18:37, Gary Gregory wrote: > Is one upshot of this is that we should base the version number based on > this OSGi report tool? > > Gary > > On Jun 11, 2017 1:58 PM, "Simon Spero" wrote: > > > On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory > > wrote: > > > > > My POV is that I only see a possible use cases for this in multi-module > > > components where one module defines an API and others different > > > implementation. Our release process is enough of a pain. Asking > everyone > > > to consider if a change warrants a package version change is a pain. I > > still > > > do not see what practical and concrete problem this would solve for a > > > single module component. Granted COMPRESSA defines an API and > > > implementations all is one jar. But we work for 100% BC within a minor > > > release, so no problem there right? For BC breaks, we use a new version > > and > > > new package name, so no problem either, right? > > > > > > Can you show us a real problem that this would have solved? If not, > write > > > up a realistic imaginary problem? > > > > > > > See: e.g http://www.sciencedirect.com/science/article/pii/ > > S1571066111000399 > > > > Note that the specific versions of *org.apache.commons.fileupload *are > not > > completely on point, since as far as I know the first version of > > commons-fileupload to include bundle headers was 1.2.1 > > > > However, we don't have to go much further to find more examples in that > > series. > > The bundles org.apache.commons.fileupload , version 1.2.*1*, and > > org.apache.commons.fileupload, version 1.2.*2* use the same version > > numbers for all packages, are two *micro* (aka bug-fix) version numbers > > within the same micro version. Under semantic versioning rules, micro > > versions must not have any API changes. > > > > However, between those 1.2.1 and 1.2.2, there are *minor* level changes > to > > two of the five packages (the other three remain unchanged. > > Moving from version 1.2.2 to version 1.3.0, there are *major* breaking > > binary changes to four packages (meaning they should have version 2.0.0). > > From version 1.3.0 to 1.3.1 there are minor (backwards compatible > changes) > > to one package, with the other four having no API changes. > > From 1.3.1 to 1.3.2 has no API changes, so is the micro version bump is > > correct. > > > > Looking at commons-math, there were major breaking changes to 6 packages > > between versions 2.0 and 2.1. > > There were five more packages with major level changes between 2.1 and > > 2.2. This was the second set of breaking changes for three of of these > > packages; their correct version number should have been 4.0. Note that > > this is *before* the packages prefix got changes to > > org.apache.commons.math3 > > > > The nature of the major changes in commons-math (mostly changing the > return > > types of methods) suggests that the developers might have used a > different > > approach rather than breaking binary compatibility. To me, it seems that > > automatically bumping the major version would have been the wrong > response. > > > > > > If you like, I can post a list of what the package version should have > > been, assuming that every compatibility change was intentional, and > > versioning was properly applied, for every bundle series under > > org.apache.commons and commons-* that was on maven-central as of mid-may? > > > > Simon > > > -- Matt Sicker
Re: [VOTE] Release Commons Fileupload 1.3.3 based on RC5
Adding the appropriate key to the KEYS file after the fact should still work. It would have the same cryptographic reliability as being added beforehand as you can't exactly imitate a key. On 8 June 2017 at 07:17, Rob Tompkins wrote: > > > > On Jun 8, 2017, at 8:09 AM, sebb wrote: > > > >> On 8 June 2017 at 01:20, Gary Gregory wrote: > >> The ASC does not seem to have a public key.: > >> > >> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc > > > > That is not the recommended way to check a sig; you also need the target > file > > > > $ gpg --verify downloaded_file.asc downloaded_file > > Indeed, but if you don't specify it looks in the current directory for the > file. > > > > >> gpg: assuming signed data in 'commons-fileupload-1.3.3- > source-release.zip' > > > > Note that gpg is assuming where to find the data. > > > >> gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA > key > >> ID 7188601C > >> *gpg: Can't check signature: No public key* > > > > However if the .asc file was not detached, gpg would not check the > target file. > > > > https://www.apache.org/info/verification.html#specify_both > > > >> > >> Also, the file naming should be consistent, > >> https://dist.apache.org/repos/dist/dev/commons/fileupload/source/ has > both > >> "source-release" and "src". Not sure how you can end up with the > >> differences beyond just the file extension. > >> > >> Gary > >> > >> > >>> On Tue, Jun 6, 2017 at 11:20 AM, Rob Tompkins > wrote: > >>> > >>> Hello all, > >>> > >>> This is a [VOTE] for releasing Apache Commons Fileupload 1.3.3 (from > RC5). > >>> > >>> Tag name: > >>> commons-fileupload-1.3.3-RC5 (signature can be checked from git using > >>> 'git tag -v') > >>> > >>> Tag URL: > >>> https://git-wip-us.apache.org/repos/asf?p=commons- > >>> fileupload.git;a=commit;h=dd2238b1671644cfead0e87c24a8ac61b4039084 > >>> > >>> Commit ID the tag points at: > >>> dd2238b1671644cfead0e87c24a8ac61b4039084 > >>> > >>> Site: > >>> http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5 > >>> > >>> Distribution files (committed at revision 19901): > >>> https://dist.apache.org/repos/dist/dev/commons/fileupload/ > >>> > >>> Distribution files hashes (SHA1): > >>> commons-fileupload-1.3.3-bin.tar.gz > >>> (SHA1: 2f4a9672168641ff726974a3b7cc68b97d1212fa) > >>> commons-fileupload-1.3.3-bin.zip > >>> (SHA1: b66e2c434ddbda90dfc9e92af4775d9777524bfa) > >>> commons-fileupload-1.3.3-src.tar.gz > >>> (SHA1: 71294a7d737a8ced04934c222ae6dfb16e4d8d73) > >>> commons-fileupload-1.3.3-src.zip > >>> (SHA1: 661172a2f62b460c4b754b7a0f04d412afabde52) > >>> > >>> These are the Maven artifacts and their hashes: > >>> commons-fileupload-1.3.3-javadoc.jar > >>> (SHA1: 92d2fc371379d64a822150ca3882157564dd3f99) > >>> commons-fileupload-1.3.3-sources.jar > >>> (SHA1: c8c7bcb851fb5af0b19e4ea845cf2fc03de6f673) > >>> commons-fileupload-1.3.3-test-sources.jar > >>> (SHA1: 5e0d8c621d38694e0f2960ab2899ee1d67f2b708) > >>> commons-fileupload-1.3.3-tests.jar > >>> (SHA1: 20510147958fc759582e6ede789ccf31d056b232) > >>> commons-fileupload-1.3.3.jar > >>> (SHA1: fd754c7518772453aea1d5ffc32cb5ce0ebc0e40) > >>> commons-fileupload-1.3.3.pom > >>> (SHA1: 97d781eafc190f4fee3abf11f9ec8076f5f7b58c) > >>> > >>> KEYS file to check signatures: > >>> http://www.apache.org/dist/commons/KEYS > >>> > >>> Maven artifacts: > >>> https://repository.apache.org/content/repositories/ > >>> orgapachecommons-1249 > >>> > >>> Please select one of the following options[1]: > >>> [ ] +1 Release it. > >>> [ ] +0 Go ahead; I don't care. > >>> [ ] -0 There are a few minor glitches: ... > >>> [ ] -1 No, do not release it because ... > >>> > >>> This vote will be open at least 72 hours, i.e. until > >>> 2017-06-09T19:00:00Z > >>> (this is UTC time). > >>> > >>> > >>> Cheers, > >>> -Rob > >>> > >>> [1] http://apache.org/foundation/voting.html > >>> - > >>> 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] Should our gitignore files contain only build-related entries?
/commons/UsingGIT and/or to the > CONTRIBUTING.md > >>>>> perhaps with a sample global gitignore file? > >>>>> > >>>>> Cheers > >>>>> Bruno > >>>>> > >>>>> [1] https://github.com/apache/commons-collections/pull/21 > >>>>> [2] > >>>>> http://markmail.org/message/yvflc6kxgjalhldx?q=global+ > >>>> gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global% > >>>> 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid: > >>>> ioex63sxnf6culwb+state:results > >>>>> [3] https://github.com/apache/commons-collections/pull/17 > >>>>> > >>>>> > - > >>>>> 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 > >> > > > > - > > 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 > > -- Matt Sicker
Re: Compiler targets and Java 9
I'm confused about one thing here. Sure, you can't use javac in 9 to compile for 5, but can't java in 9 still run class files compiled against 5? If you couldn't run older java classes anymore, then I don't know why Oracle continues to maintain backward compatibility in places that are annoying. On 5 June 2017 at 11:54, Ralph Goers wrote: > This whole discussion has me really confused. According to > https://en.wikipedia.org/wiki/Java_version_history < > https://en.wikipedia.org/wiki/Java_version_history> the free version of > Java 5 reached end-of-life in 2009 and Oracle's supported version reached > end-of-life in 2015. https://developer.ibm.com/javasdk/support/lifecycle/ > <https://developer.ibm.com/javasdk/support/lifecycle/> doesn’t even show > Java 5 any more but https://www.ibm.com/developerworks/community/ > forums/html/topic?id=----14807464 < > https://www.ibm.com/developerworks/community/ > forums/html/topic?id=----14807464> indicates that > it also was dropped in 2015. > > So why are we discussing support for Java 1.5 when not even the vendors > who ship it support it? > > Ralph > > > > On Jun 5, 2017, at 9:45 AM, Gary Gregory wrote: > > > > On Mon, Jun 5, 2017 at 9:17 AM, Jochen Wiedmann < > jochen.wiedm...@gmail.com <mailto:jochen.wiedm...@gmail.com>> > > wrote: > > > >> On Mon, Jun 5, 2017 at 5:20 PM, sebb wrote: > >> > >>>> I'd like us to be able to push out a new release with minimal changes > >>>> at any given time. If we have, for example, 1.6 as the target, and the > >>>> previous > >>>> release had 1.5 as the target, then we'd loose that ability, IMO. > >>>> (Think security releases.We've had quite a few in the past.) > >>> > >>> Understood, but I'm not sure why you feel the lack of a 1.6 release > >>> would prevent a security release. > >>> Surely we could just apply the fixes to the previously released code > >>> and change to 1.6 at the same time? > >> > >> Because the result clearly be binary incompatible to its predecessor, > >> and that's the whole point of such an emergency release. We'd want a > >> drop-in replacement. > >> > > > > If someone wants a fix for something that runs on 1.5, they are welcome > to > > provide a PR. I do not think we need to handcuff ourselves to Java 5. If > > your runtime is stuck on Java 5, your likely to have other more pressing > > security issues to address... > > > > Gary > > > >> > >> Jochen > >> > >> > >> -- > >> The next time you hear: "Don't reinvent the wheel!" > >> > >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ < > http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/> > >> evolution-of-the-wheel-300x85.jpg > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org dev-unsubscr...@commons.apache.org> > >> For additional commands, e-mail: dev-h...@commons.apache.org dev-h...@commons.apache.org> > -- Matt Sicker
Re: [LANG] Fix date related test failures on IBM JDKs (Was: Re: [CANCEL][VOTE] Release Apache Commons Lang 3.6 based on RC2)
>>>>>>>> (SHA1: e6e1ca5e4574da2af0f8d2891410857e36ce5969) > >>>>>>>> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- > tests.jar.asc > >>>> < > >>>>>> https://repository.apache.org/content/repositories/ > >>>>>> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >>>>>> 3.6/commons-lang3-3.6-tests.jar.asc> > >>>>>>>> (SHA1: b8d25f4a01a5f50ab450044dd2a7688e37554bed) > >>>>>>>> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test > >>>> -sources.jar.asc > >>>>>> <https://repository.apache.org/content/repositories/ > >>>>>> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >>>>>> 3.6/commons-lang3-3.6-test-sources.jar.asc> > >>>>>>>> (SHA1: ccca81cd4539437f3def2644119a6f187168963c) > >>>>>>>> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test > >>>> -sources.jar > >>>>>> <https://repository.apache.org/content/repositories/ > >>>>>> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >>>>>> 3.6/commons-lang3-3.6-test-sources.jar> > >>>>>>>> (SHA1: 8daf4979fb38811bd4a5bf39e38bc7a3a6582104) > >>>>>>>> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar > < > >>>>>> https://repository.apache.org/content/repositories/ > >>>>>> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >>>>>> 3.6/commons-lang3-3.6-tests.jar> > >>>>>>>> (SHA1: 1f158e950250efab7cbca635e8393ab2ef666bca) > >>>>>>>> > >>>>>>>> I have tested this with JDK 7, JDK 8 and JDK 9 EA b165 using Maven > >>>>>> 3.5.0. > >>>>>>>> > >>>>>>>> Details of changes since 3.5 are in the release notes: > >>>>>>>> https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE- > >>>> NOTES.txt > >>>>>>>> http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >>>>>> RC2/changes-report.html > >>>>>>>> > >>>>>>>> Site: > >>>>>>>> http://home.apache.org/~britter/commons/lang/LANG_3_6_RC2/ > >>>>>>>> (note some *relative* links are broken and the 3.6 directories are > >>>>>>>> not yet created - these will be OK once the site is deployed) > >>>>>>>> > >>>>>>>> Clirr Report (compared to 3.5): > >>>>>>>> http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >>>>>> RC2/clirr-report.html > >>>>>>>> > >>>>>>>> RAT Report: > >>>>>>>> http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >>>>>> RC2/rat-report.html > >>>>>>>> > >>>>>>>> KEYS: > >>>>>>>> https://www.apache.org/dist/commons/KEYS > >>>>>>>> > >>>>>>>> Please review the release candidate and vote. > >>>>>>>> This vote will close no sooner that 72 hours from now, > >>>>>>>> i.e. sometime after 12:00 EDT (UTC-4) 20-May 2017 > >>>>>>>> > >>>>>>>> [ ] +1 Release these artifacts > >>>>>>>> [ ] +0 OK, but... > >>>>>>>> [ ] -0 OK, but really should fix... > >>>>>>>> [ ] -1 I oppose this release because… > >>>>>>> > >>>>>>> This vote is still pending. Please review the RC and cast your > vote. > >>>> The > >>>>>> following issues have been found: > >>>>>>> > >>>>>>> - mvn site does not work from the source archive > >>>>>>> - Jigsaw meta data is missing > >>>>>>> > >>>>>>> I consider neither as a blocker for releasing 3.6 and would rather > >>>> like > >>>>>> to fix those in 3.6.1 (which I can prepare after my vacation). So > >>>> unless > >>>>>> nobody finds something else, I’d like to release this code. > >>>>>>> > >>>>>>> Thank you, > >>>>>>> Benedikt > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> Benedikt > >>>>>>> > >>>>>>> > >>>>>>> > - > >>>>>>> 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 > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >>>>> Java Persistence with Hibernate, Second Edition > >>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl? > >>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&link > >>>> Code=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > >>>>> > >>>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= > >>>> am2&o=1&a=1617290459> > >>>>> JUnit in Action, Second Edition > >>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl? > >>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&link > >>>> Code=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > 18%22> > >>>>> > >>>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= > >>>> am2&o=1&a=1935182021> > >>>>> Spring Batch in Action > >>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl? > >>>> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&link > >>>> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli > >>>> nk_id%7D%7D%22%3ESpring+Batch+in+Action> > >>>>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= > >>>> am2&o=1&a=1935182951> > >>>>> Blog: http://garygregory.wordpress.com > >>>>> Home: http://garygregory.com/ > >>>>> Tweet! http://twitter.com/GaryGregory > >>>> > >>>> > >>> > >>> > >>> -- > >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >>> Java Persistence with Hibernate, Second Edition > >>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > >>> > >>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > >>> JUnit in Action, Second Edition > >>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > >>> > >>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > >>> Spring Batch in Action > >>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > >>> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > >>> Blog: http://garygregory.wordpress.com > >>> Home: http://garygregory.com/ > >>> Tweet! http://twitter.com/GaryGregory > >>> > >> > >> > >> > >> -- > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >> Java Persistence with Hibernate, Second Edition > >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > >> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > >> JUnit in Action, Second Edition > >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > >> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > >> Spring Batch in Action > >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > >> Blog: http://garygregory.wordpress.com > >> Home: http://garygregory.com/ > >> Tweet! http://twitter.com/GaryGregory > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org dev-unsubscr...@commons.apache.org> > > For additional commands, e-mail: dev-h...@commons.apache.org dev-h...@commons.apache.org> > -- Matt Sicker
Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
I like the idea. I've written similar code in a log4j2 branch for normalizing configuration property names into camel case names. On 1 June 2017 at 10:31, Amey Jadiye wrote: > +1 seems good to have in toolbox. pretty similar method I have seen in > Commons text WordUtils.capitalize() almost similar logic we will need here > ,just not to capitalize first word and join them all, I'm in favour of > having this in WordUtils. > > Regards, > Amey > > On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins wrote: > > > Hello all, > > > > Folks at my day job have a method that takes in a space delimited String > > (or arbitrarily delimited string for that matter), and returns a camel > > cased string. Is there any reason that this shouldn’t be in StringUtils? > It > > feels reasonable to me. What are folks thoughts? > > > > Cheers, > > -Rob > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [LANG] Thoughts about Lang 4.0
Tying versions of commons-lang to releases of Java itself makes a bit of sense to me, but then I do foresee projects containing like 5 different versions of commons-lang in the future which is somewhat annoying. On 23 May 2017 at 10:07, sebb wrote: > On 23 May 2017 at 12:18, Stephen Colebourne wrote: > > On 23 May 2017 at 11:54, sebb wrote: > >>> Fixing it properly requires a major release, which implies that Lang > >>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3` > >>> package name. > >> > >> I think that depends on whether the API is backwards-compatible or not. > >> > >> If it *is* backwards-compatible, then do we need a major release? > >> > >> If *not*, then 4.0 needs a new package. > >> > >> Why? > >> > >> Suppose code A depends on a LANG 3 method not present in 4 > >> and code B depends on some new feature in LANG 4 > >> > >> It's not possible to use A and B together on the same classpath. > >> > >> In which case 4.0 must use a new package and Maven coordinates. > > > > The change to remove PropertyChangeListener will be incompatible. > > Thus, if you want to be strict then you have to have a new package and > > maven co-ordinates. But IMO, this would simply cause end-user projects > > to have v2.x, v3.x and v4.x on the classpath - its bad enough with two > > versions right now, I don't personally think removing these two > > methods is enough to justify a new package/maven co-ordinate and the > > downstream mess that ensues. > > Huh? > > The whole point of changing the package name and Maven coords is to > allow mutually incompatible jars to coexist peacefully on a single > classpath. > > > > I will note that the JDK is removing methods due to exactly the same > > issue - modular Java is quite disruptive.. > > All the more reason not to cause additional unnecessary problems. > > > Options that leave the methods in: > > > > 1) Add module-info for v3.x that "requires java.desktop" and accept > > that end-users get Swing/AWT > > OK > > > 2) Add module-info for v3.x that "requires static java.desktop" (an > > optional dependency) and accept that users of circuit breaker must > > manually "require java.desktop". > > OK > > > Options that remove the methods: > > > > 3) Make a backwards incompatible change to remove the bad methods in > > v3.7 (no package name change) > > -1 > > This is a recipe for jar hell. > > > 4) Make a backwards incompatible change to remove the bad methods in > > v4.0 (no package name change) > > -1 > > This is a recipe for jar hell. > > > > > 5) Make a backwards incompatible change to remove the bad methods in > > v4.0 (with package name change) > > OK > > > If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is > > aggressive but gets rid of the issue in the fastest way. > > > > Stephen > > > > - > > 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 > > -- Matt Sicker
Re: [LANG] Thoughts about Lang 4.0
On 22 May 2017 at 14:35, Jan Matèrne (jhm) wrote: > > One benefit of having an ASF commons "tuple library" is it's from the > ASF. > I am not joking. An ASF library promisses to have a community and a life > cycle you can > precognize. In contrast a "simple" github library is just a peace of code. This is a great point, honestly. I don't like using random tuple util classes from my dependencies (other than in Scala now since they have it in their standard library) in any public code (though it's usable in private methods, etc.). Given a nice enough tuple library, it may be possible to see it start to replace all the random tuple utils elsewhere. > I think converter functions between java.util.Date and java.time could be > helpful. > Think of "old" modules of your application (maybe 3rd party libs) which > require the one > and other parts which require the other. Like these? https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#from-java.time.Instant- https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#toInstant-- -- Matt Sicker
Re: [LANG] Thoughts about Lang 4.0
For the tuple classes, it would be possible to make an entire tuples library. Might be handy to generate code for it as it'd be useful to support tuples up to, say, 22 fields (Scala has tuple classes and anonymous function classes up to 22 arguments, for example). See < https://www.scala-lang.org/api/current/scala/Tuple22.html>. If we go to Java 8 as a base line (which would make sense), we don't need a commons-date library anymore, though if we did, it would be based on the java.time API instead. Not sure which functionality would be useful here. For commons-concurrent and -system, I like the ideas. As for -reflection versus -beanutils, perhaps some exploration toward merging the two could be made? On 22 May 2017 at 06:47, Rob Tompkins wrote: > > > On May 21, 2017, at 7:56 PM, Benedikt Ritter wrote: > > > > Hi, > > > > I think the time has come to start thinking about Lang 4.0. A new major > release is a chance to clean up stuff and get rid of APIs we don’t need > anymore/don’t want to maintain anymore. Lang has become rather large. It’s > description still is > > > > „Lang provides a host of helper utilities for the java.lang API […]" > > > > When I look at Lang I see a lot of stuff which has nothing to do with > the java.lang package. I think our aim for 4.0 should be to get back to > that again. I like the approach we took with math. Splitting a large > package down into smaller individual components is a good idea. So my > proposal is to split out more new components from Lang like we did with > commons-text and deprecate that stuff in lang. Then we can start with Lang > 4.0 and remove all that stuff. > > > > Here are some components I think we could extract from Lang: > > > > - commons-system: a library focused on working with system properties > and detection of the operation system, system’s architecture and Java > version > > - commons-concurrent: a library providing additional abstractions and > implementations for the java.util.concurrent package > > - commons-reflect: a library which helps working with reflection (where > is the line to beanutils here?) > > - commons-date: a library which helps working with the java.util.Date > and java.util.Calendar APIs > > > > Furthermore I’d remove the o.a.c.lang3.event package. The stuff in > o.a.c.lang3.math could maybe find a new home in one of the commons-math > components. > > > > The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to > o.a.c.lang4.object (if that’s possible). Further more I’d remove the > Builder interface. > > > > The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the > o.a.c.lang3.exception package can stay as they are. > > > > WDYT? > > The only thing that occurs to me is that we should make sure that Java 9 > is fully in general availability before releasing 4.0. > > > Benedikt > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [ALL] Build Javadoc with Java 9
Speaking of javadoc checks, maybe I'll considering enabling them when OpenJDK does. On 18 May 2017 at 03:10, Stian Soiland-Reyes wrote: > Agree to wait for Java 9 GA before it's general practice. Would not -1 a > release candidate with nicer Java 9 javadoc though! > > With Java 8 there were many issues with javadoc checks and options > incompatible with Java 7. I I don't know if anything changes here for > Java 9, but trying to comply both with Java 8 and a pre-release of Java 9 > sounds like wasted effort if Java 9 javadoc defaults still can change. > > On 17 May 2017 9:55 pm, "Benedikt Ritter" wrote: > > > Hi, > > > > > Am 17.05.2017 um 15:25 schrieb Gary Gregory : > > > > > > Hi All: > > > > > > I wonder if we should build all of our Javadocs for our sites with > Java 9 > > > since it provides nice new features like searchable Javadocs and HTML5. > > > Notice the search box on the page > > > http://download.java.net/java/jdk9/docs/api/overview-summary.html < > > http://download.java.net/java/jdk9/docs/api/overview-summary.html> > > > > Looks nice! But I think every RM should decide which JDK she want’s to > > build the JavaDocs with. I for example wait until Java 9 goes GA, before > I > > use it as my main build environment. > > > > Regards, > > Benedikt > > > > > > > > Gary > > > > > > -- > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > Java Persistence with Hibernate, Second Edition > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > 1617290459> > > > JUnit in Action, Second Edition > > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > 18%22 > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > 1935182021> > > > Spring Batch in Action > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > 1935182951> > > > Blog: http://garygregory.wordpress.com > > > Home: http://garygregory.com/ > > > Tweet! http://twitter.com/GaryGregory > > > > > -- Matt Sicker
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC2
ps://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6-sources.jar> > >> (SHA1: d9c5bbfb0b97c1f87e3f75cedd7eedbc5ec81182) > >> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar < > >> https://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6.jar> > >> (SHA1: e6e1ca5e4574da2af0f8d2891410857e36ce5969) > >> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar.asc < > >> https://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6-tests.jar.asc> > >> (SHA1: b8d25f4a01a5f50ab450044dd2a7688e37554bed) > >> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6- > test-sources.jar.asc > >> <https://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6-test-sources.jar.asc> > >> (SHA1: ccca81cd4539437f3def2644119a6f187168963c) > >> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-test-sources.jar > < > >> https://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6-test-sources.jar> > >> (SHA1: 8daf4979fb38811bd4a5bf39e38bc7a3a6582104) > >> /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-tests.jar < > >> https://repository.apache.org/content/repositories/ > >> orgapachecommons-1247/org/apache/commons/commons-lang3/ > >> 3.6/commons-lang3-3.6-tests.jar> > >> (SHA1: 1f158e950250efab7cbca635e8393ab2ef666bca) > >> > >> I have tested this with JDK 7, JDK 8 and JDK 9 EA b165 using Maven > 3.5.0. > >> > >> Details of changes since 3.5 are in the release notes: > >>https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE- > NOTES.txt > >>http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >> RC2/changes-report.html > >> > >> Site: > >> http://home.apache.org/~britter/commons/lang/LANG_3_6_RC2/ > >> (note some *relative* links are broken and the 3.6 directories are > >> not yet created - these will be OK once the site is deployed) > >> > >> Clirr Report (compared to 3.5): > >>http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >> RC2/clirr-report.html > >> > >> RAT Report: > >>http://home.apache.org/~britter/commons/lang/LANG_3_6_ > >> RC2/rat-report.html > >> > >> KEYS: > >> https://www.apache.org/dist/commons/KEYS > >> > >> Please review the release candidate and vote. > >> This vote will close no sooner that 72 hours from now, > >> i.e. sometime after 12:00 EDT (UTC-4) 20-May 2017 > >> > >> [ ] +1 Release these artifacts > >> [ ] +0 OK, but... > >> [ ] -0 OK, but really should fix... > >> [ ] -1 I oppose this release because... > >> > >> Thanks! > >> Benedikt > > > > - > > 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 > > -- Matt Sicker
Re: [math] porting other code bases into ours
Depending on license, you may also want or need to add something in your NOTICE.txt file as well. Could be handy either way as a pointer to the project whose algorithms this one is based on. On 16 May 2017 at 09:11, Rob Tompkins wrote: > > > On May 16, 2017, at 10:10 AM, Stefan Bodewig wrote: > > > > On 2017-05-16, Rob Tompkins wrote: > > > >> I’m currently working on an issue in the [math] codebase, and the > suggested fix is to port some python code over to Java from scipy ( > https://github.com/scipy/scipy <https://github.com/scipy/scipy>, > https://scipy.org <https://scipy.org/>, license: BSD-3-clause). Clearly I > can’t copy and paste their exact code in to our codebase as it’s python, > but clearly I’m lifting their ideas. > > > >> So, what is and isn’t allowed in this case? Do I simply go through the > exercise of porting the code over and make a reference or is there > something else that I should do? > > > > I've been doing similar things in [compress] coming from C rather than > > Python. My code is usually not a verbatim port but rather a Java rewrite > > of the ideas of the original algorithm. > > > > AFAIU a straight port would be fine as well as the license is > > compatible. You may want to keep pointers to the original code base and > > license with your code. > > > > Many thanks for that, > -Rob > > > Stefan > > > > - > > 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 > > -- Matt Sicker
Re: [Numbers] Angle class?
I'd also like to add that I'm not sure comparing what's included in java.lang and other old Java packages isn't the best indicator of modularisation. Sure, you could say that about newer Java releases where there was quite a bit more discipline toward breaking functionality up into appropriate packages, but when you compare that with what was available since Java 1.0 or 1.1 or so, you may notice that original versions of Java weren't so disciplined about it (which seems to be a pretty typical way that Java libraries are developed where the original version doesn't have to break everything up so fine grained just yet). On 13 May 2017 at 13:50, Matt Sicker wrote: > On 13 May 2017 at 06:29, Raymond DeCampo wrote: >> >> > As for the module, do we mind a few more bytes? >> > It leaves room for expansion (not that I intend to do it personally), >> > and it avoids that "core" becomes the place where we put every little >> > thing that does not belong elsewhere. [If it turns out that "core" >> > contains only two classes, a question might be whether those should >> > not also belong to their own module with a name that better reflects >> > its content.] >> > >> >> It's not the "bytes" it's the overhead. Having a module containing only >> one class is extreme. >> > > What I find amusing here is that if there were a standard an easy way to > share artefacts containing only a single class file, we'd end up with an > npm-style ecosystem where a basic project would require downloading and > maintaining dozens or hundreds of dependencies without doing anything > particularly special. When it comes down to it, finding a proper point of > modularisation is difficult as there are trade offs in maintenance versus > purity. Since Java still doesn't have any good way to enforce automatic > semantic versioning and simple code isolation (JPMS in Java 9 refuses to > address this still which was one of Red Hat's criticisms), we're stuck > bundling a bunch of somewhat related code together just for usability > purposes. Contract this with the C development world where libraries pride > themselves on being distributable as a single source file for simplicity > (even though said file is usually thousands of lines long). > > -- > Matt Sicker > -- Matt Sicker
Re: [Numbers] Angle class?
On 13 May 2017 at 06:29, Raymond DeCampo wrote: > > > As for the module, do we mind a few more bytes? > > It leaves room for expansion (not that I intend to do it personally), > > and it avoids that "core" becomes the place where we put every little > > thing that does not belong elsewhere. [If it turns out that "core" > > contains only two classes, a question might be whether those should > > not also belong to their own module with a name that better reflects > > its content.] > > > > It's not the "bytes" it's the overhead. Having a module containing only > one class is extreme. > What I find amusing here is that if there were a standard an easy way to share artefacts containing only a single class file, we'd end up with an npm-style ecosystem where a basic project would require downloading and maintaining dozens or hundreds of dependencies without doing anything particularly special. When it comes down to it, finding a proper point of modularisation is difficult as there are trade offs in maintenance versus purity. Since Java still doesn't have any good way to enforce automatic semantic versioning and simple code isolation (JPMS in Java 9 refuses to address this still which was one of Red Hat's criticisms), we're stuck bundling a bunch of somewhat related code together just for usability purposes. Contract this with the C development world where libraries pride themselves on being distributable as a single source file for simplicity (even though said file is usually thousands of lines long). -- Matt Sicker
Re: Pair of nulls
I meant this:
@SuppressWarnings("unchecked")
public static ImmutablePair nullPair() {
return (ImmutablePair) NULL;
}
On 11 May 2017 at 11:17, Gary Gregory wrote:
> On Thu, May 11, 2017 at 5:35 AM, Matt Benson wrote:
>
> > On May 11, 2017 1:03 AM, "Gary Gregory" wrote:
> >
> > On Wed, May 10, 2017 at 10:58 PM, Matt Sicker wrote:
> >
> > > Matching the of() static factories, how about ImmutablePair.ofNull()
> > >
> >
> > I like it but at the same time it feels to me like I am getting a NEW
> > object like ImmutablePair.of(x, y) give me a new object. Might just be me
> > ;-)
> >
> >
> > You provide the methods so that people can get an instance parameterized
> > for their compilation needs. In reality you can return the same empty,
> > immutable instance.
> >
>
> Yes, of course:
>
> /**
> * An immutable pair of nulls.
> */
> // This is not defined with generics to avoid warnings in call sites.
> @SuppressWarnings("rawtypes")
> private static final ImmutablePair NULL = ImmutablePair.of(null, null);
>
> @SuppressWarnings("rawtypes")
> // This is not defined with generics to avoid warnings in call sites.
> public static ImmutablePair nullPair() {
> return NULL;
> }
>
> Gary
>
>
>
> >
> > Matt
> >
> >
> > Gary
> >
> >
> > > On 11 May 2017 at 00:03, Gary Gregory wrote:
> > >
> > > > On Wed, May 10, 2017 at 9:27 PM, Matt Sicker
> wrote:
> > > >
> > > > > Wouldn't it make sense to expose typed methods like in
> > > > > Collections.emptyList() et al.?
> > > > >
> > > >
> > > > So in this case:
> > > >
> > > > ImmutablePair.nullPair()
> > > >
> > > > Gary
> > > >
> > > > >
> > > > > On 10 May 2017 at 22:10, Javen O'Neal wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > The of method should check if all elements are null, and if so to
> > > > return
> > > > > > the NULL singleton. This would reduce the number of objects
> created
> > > and
> > > > > > garbage collected.
> > > > > >
> > > > > > So long as ImmutablePair and ImmutableTriple classes are final
> (not
> > > > > > subclassable), then identity checking could be used in place of
> > > > equality
> > > > > > checking when comparing against a null tuple. This would be
> > > marginally
> > > > > > faster.
> > > > > >
> > > > > > Any preference of being explicit (redundant) here?
> > > > > > ImmutablePair.NULL_PAIR and ImmutableTriple.NULL_TRIPLE
> > > > > >
> > > > > > On May 10, 2017 7:35 PM, "Gary Gregory"
> > > > wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Any thoughts for or against adding the following to
> ImmutablePair:
> > > > > >
> > > > > >
> > > > > > /**
> > > > > > * An immutable pair of nulls.
> > > > > > */
> > > > > > // This is not defined with generics to avoid warnings in
> call
> > > > sites.
> > > > > > @SuppressWarnings("rawtypes")
> > > > > > public static final ImmutablePair NULL =
> ImmutablePair.of(null,
> > > > > null);
> > > > > >
> > > > > > Same for ImmutableTriple.
> > > > > >
> > > > > > ?
> > > > > >
> > > > > > Thank you,
> > > > > > Gary
> > > > > >
> > > > > > --
> > > > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > > Java Persistence with Hibernate, Second Edition
> > > > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > > > > > linkCode=as2&tag=garygregory-20&linkId=
> > > cadb800f39946ec62ea2b1af9fe6a2
> > > > b8>
> > > > > >
> > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=
> > > garygregory-20
Re: Pair of nulls
Matching the of() static factories, how about ImmutablePair.ofNull()
On 11 May 2017 at 00:03, Gary Gregory wrote:
> On Wed, May 10, 2017 at 9:27 PM, Matt Sicker wrote:
>
> > Wouldn't it make sense to expose typed methods like in
> > Collections.emptyList() et al.?
> >
>
> So in this case:
>
> ImmutablePair.nullPair()
>
> Gary
>
> >
> > On 10 May 2017 at 22:10, Javen O'Neal wrote:
> >
> > > +1
> > >
> > > The of method should check if all elements are null, and if so to
> return
> > > the NULL singleton. This would reduce the number of objects created and
> > > garbage collected.
> > >
> > > So long as ImmutablePair and ImmutableTriple classes are final (not
> > > subclassable), then identity checking could be used in place of
> equality
> > > checking when comparing against a null tuple. This would be marginally
> > > faster.
> > >
> > > Any preference of being explicit (redundant) here?
> > > ImmutablePair.NULL_PAIR and ImmutableTriple.NULL_TRIPLE
> > >
> > > On May 10, 2017 7:35 PM, "Gary Gregory"
> wrote:
> > >
> > > Hi All,
> > >
> > > Any thoughts for or against adding the following to ImmutablePair:
> > >
> > >
> > > /**
> > > * An immutable pair of nulls.
> > > */
> > > // This is not defined with generics to avoid warnings in call
> sites.
> > > @SuppressWarnings("rawtypes")
> > > public static final ImmutablePair NULL = ImmutablePair.of(null,
> > null);
> > >
> > > Same for ImmutableTriple.
> > >
> > > ?
> > >
> > > Thank you,
> > > Gary
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2
> b8>
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1617290459>
> > > JUnit in Action, Second Edition
> > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> > > 18%22>
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1935182021>
> > > Spring Batch in Action
> > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
> >
> >
> > --
> > Matt Sicker
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker
Re: Pair of nulls
Wouldn't it make sense to expose typed methods like in
Collections.emptyList() et al.?
On 10 May 2017 at 22:10, Javen O'Neal wrote:
> +1
>
> The of method should check if all elements are null, and if so to return
> the NULL singleton. This would reduce the number of objects created and
> garbage collected.
>
> So long as ImmutablePair and ImmutableTriple classes are final (not
> subclassable), then identity checking could be used in place of equality
> checking when comparing against a null tuple. This would be marginally
> faster.
>
> Any preference of being explicit (redundant) here?
> ImmutablePair.NULL_PAIR and ImmutableTriple.NULL_TRIPLE
>
> On May 10, 2017 7:35 PM, "Gary Gregory" wrote:
>
> Hi All,
>
> Any thoughts for or against adding the following to ImmutablePair:
>
>
> /**
> * An immutable pair of nulls.
> */
> // This is not defined with generics to avoid warnings in call sites.
> @SuppressWarnings("rawtypes")
> public static final ImmutablePair NULL = ImmutablePair.of(null, null);
>
> Same for ImmutableTriple.
>
> ?
>
> Thank you,
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> 18%22>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker
Re: [COMPRESS] Anyone implemented "pigz"?
Would the scattering and gathering byte channel APIs in java.nio be helpful in splitting up a stream into chunks for parallel processing? On 10 May 2017 at 02:57, Stefan Bodewig wrote: > On 2017-05-10, Gary Gregory wrote: > > > I think the question is can/should [Compress] use any of the stock code > > in java.util.zip in a multi-threaded fashion for performance gains. > > We rely on java.util.zip.Deflater for DEFLATE which isn't thread safe by > itself. > > But we could implement the same strategy pigz uses, which is to break up > the stream into chunks and work on the chunks in parallel. Combining the > output of several streams may become tricky using the Java API. > > If my first read of the comments in > https://github.com/madler/pigz/blob/master/pigz.c is correct then we'd > need to manipulate the output of Deflater in order to strip headers and > trailers and insert empty stored blocks as well as create headers and > trailers of our own for the combined output. > > In theory we could implement something like pigz on top of the LZ77 > support I've added for Snappy and LZ4 (and some additional Hufmann code > yet to be written) but it would be slower than zlib - probably a lot - > and likely eat up the speed gain provided by parallel processing. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [COMPRESS] Anyone implemented "pigz"?
Those C libraries are pthread (don't need that in Java as it has its own thread API) and zlib (pretty standard gz library). With that in mind, this may be a useful reference: http://www.jcraft.com/jzlib/ On 9 May 2017 at 19:22, sebb wrote: > AFAICT the implementation is written in C and uses some C libraries. > > It would have to be completely rewritten for Java. > Not a trivial job, though it may be possible to use the algorithm. > > On 10 May 2017 at 01:03, Gary Gregory wrote: > > I've not heard of it on the ML yet. Go for it! ;-) > > > > Gary > > > > On Tue, May 9, 2017 at 4:44 PM, Roger Whitcomb < > roger.whitc...@actian.com> > > wrote: > > > >> Someone here was doing benchmarks using "pigz" (see here: > >> http://zlib.net/pigz/, basically multi-threaded "gzip") and I couldn't > >> find any "reasonable" Java implementations. Anyone thought about it for > >> Commons Compress? > >> > >> Thanks, > >> Roger Whitcomb > >> > > ----- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [math] Proposed resolution for MATH-1284
Oh, nevermind then. :) On 8 May 2017 at 09:21, Raymond DeCampo wrote: > On Sun, May 7, 2017 at 5:22 PM, Matt Sicker wrote: > > > I find using "tuples" here confusing since a tuple can have multiple > types, > > while a vector or point are all the same type (given the space it's in, > so > > reals -> doubles for example). > > > > > There is no mention of tuples in the code, only in my explanation of the > code on the ML. > -- Matt Sicker
Re: [math] Proposed resolution for MATH-1284
I find using "tuples" here confusing since a tuple can have multiple types, while a vector or point are all the same type (given the space it's in, so reals -> doubles for example). On 7 May 2017 at 07:26, Raymond DeCampo wrote: > I have prepared a resolution for issue MATH-1284 ( > https://issues.apache.org/jira/browse/MATH-1284) in the feature-MATH-1284 > branch. > > I'd appreciate a review by any interested parties. I am particularly > concerned to know if the changes represent to much of an API change, even > given the target is 4.0. Boring details about the reasoning behind the > approach follow. > > I originally started out intending to keep the Vector?D classes pretty much > as-is, dropping the implementation of the Point interface and introducing > concrete Point?D classes. In the process of implementing this I learned > that the existing code switches between using Vector?D as a Vector and a > Point fairly frequently. I started by adding conversion methods but I felt > this introduced potential inefficiencies. > > So I decided to try a different approach. Leveraging the fact that a point > and a vector in finite dimensional Euclidean space can both be represented > by n-tuples, I created a class for the n-tuples, Cartesian?D (h/t Gilles > for the name) which can represent a vector or a point. > > This approach was much more easily propagated to the remainder of the code > and in many places allowed the removal of casts. I also kept the Vector?D > classes as an intermediary abstract class in the hope of reducing the > burden on a user upgrading from 3.x. > > Thanks, > Ray > -- Matt Sicker
Re: [all][osgi] how to deal with non-bundle dependencies?
Without a container, the "easy" way would be to embed Felix and start up the OSGi framework itself. The easiest way to do this in unit tests would be using something like Pax Exam < https://ops4j1.jira.com/wiki/display/PAXEXAM4/Pax+Exam>. On 4 May 2017 at 01:11, Stefan Bodewig wrote: > On 2017-05-02, Matt Sicker wrote: > > > Apache ServiceMix tends to repackage a lot of 3rd party libraries as > > bundles, so that's one method. End users can use things like bnd to > > generate a manifest for 3rd party jars (e.g., installing jars using the > > "wrap:" URI in Apache Karaf), though that's kind of similar to > automodules > > in JPMS which isn't the best thing. > > In our case with org.brotli:dec at Compress the "automodules" approach > would be good enough. The whole library has a single public class and no > dependencies, the bundle definition would be trivial. > > We've now marked the dependency with "resolution:=optional" and hope > this allows Compress to remain a valid bundle. Do you know whether there > is an easy way to test whether a library would work as a bundle without > actually trying to deploy an application using it into a container? > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all][osgi] how to deal with non-bundle dependencies?
Apache ServiceMix tends to repackage a lot of 3rd party libraries as bundles, so that's one method. End users can use things like bnd to generate a manifest for 3rd party jars (e.g., installing jars using the "wrap:" URI in Apache Karaf), though that's kind of similar to automodules in JPMS which isn't the best thing. On 2 May 2017 at 02:30, Stefan Bodewig wrote: > Hi all > > I must admit I've never been a fan of OSGi and likely don't know enough > about it. > > Compress like many of the components around here is an OSGi bundle and I > recall I submitted a trivial patch to XZ for Java - our only dependency > as of now - to turn it into a bundle as well. > > How does one deal with adding dependencies on jars that are not bundles? > Is it possible at all? > > A quick search seems to imply we'd either have to bundle the dependency > jar with ours or turn it into a bundle ourselves (by wrapping it). > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: StopWatch stop
What about a fluent package for classes like this so you can still call it StopWatch? On 1 May 2017 at 21:02, Gary Gregory wrote: > I am down to copying StopWatch as FluentStopWatch and adding "return this;" > to all the void methods. > > I can so that in my code base but does it induce vomiting if Commons Lang > has both StopWatch AND FluentStopWatch? > > Gary > > On Sun, Apr 30, 2017 at 2:47 PM, Gary Gregory > wrote: > > > Sorry, Commons Lang. > > > > Gary > > > > On Apr 30, 2017 1:47 PM, "Matt Sicker" wrote: > > > >> Which subproject are you speaking of anyways? > >> > >> On 30 April 2017 at 15:46, Gary Gregory wrote: > >> > >> > A new method perhaps or a new class a la fluent? > >> > > >> > Gary > >> > > >> > On Apr 30, 2017 1:32 PM, "Matt Sicker" wrote: > >> > > >> > > Yup, here it is: > >> > > 13.4.15. Method Result Type > >> > > > >> > > Changing the result type of a method, or replacing a result type > with > >> > void, > >> > > or replacing void with a result type, has the combined effect of > >> deleting > >> > > the old method and adding a new method with the new result type or > >> newly > >> > > void result (see §13.4.12 > >> > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > >> > 13.html#jls-13.4.12 > >> > > > > >> > > ). > >> > > > >> > > For purposes of binary compatibility, adding or removing a method or > >> > > constructor m whose return type involves type variables (§4.4 > >> > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > 4.html#jls-4.4 > >> >) > >> > or > >> > > parameterized types (§4.5 > >> > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > 4.html#jls-4.5 > >> >) > >> > is > >> > > equivalent to the addition (respectively, removal) of the an > otherwise > >> > > equivalent method whose return type is the erasure (§4.6 > >> > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > 4.html#jls-4.6 > >> >) > >> > of > >> > > the return type of m. > >> > > > >> > > On 30 April 2017 at 15:30, Matt Sicker wrote: > >> > > > >> > > > https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html > >> > > > > >> > > > A reference to a method must be resolved at compile time to a > >> symbolic > >> > > > reference to the erasure (§4.6 > >> > > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4. > >> html#jls-4.6 > >> > >) > >> > > > of the qualifying type of the invocation, plus the erasure of the > >> > > signature > >> > > > (§8.4.2 > >> > > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > >> > 8.html#jls-8.4.2 > >> > > >) > >> > > > of the method. > >> > > > > >> > > > I'm getting the impression here that the ABI follows the same > rules > >> as > >> > > > using MethodHandle.invokeExact(). > >> > > > > >> > > > On 30 April 2017 at 15:21, Gary Gregory > >> > wrote: > >> > > > > >> > > >> On Apr 30, 2017 1:19 PM, "Oliver Heger" < > >> oliver.he...@oliver-heger.de > >> > > > >> > > >> wrote: > >> > > >> > >> > > >> I think client code has to be recompiled, otherwise a > >> > NoSuchMethodError > >> > > >> is thrown. > >> > > >> > >> > > >> > >> > > >> > >> > > >> Dang it. Are you sure? > >> > > >> > >> > > >> Gary > >> > > >> > >> > > >> > >> > > >> Oliver > >> > > >> > >> > > >> Am 30.04.2017 um 21:24 schrieb Matt Sicker: > >> > > >> > That sort of thing changes the binary signature, but source > >> > > >> compatibility > >> > > >> > is retained. > >> > > >> > > >> > > >>
Re: commons-dbcp patch
You can fork the repo and make a PR that way. The GitHub repos are read-only mirrors. On 30 April 2017 at 17:57, Gary Evesson wrote: > I have a potential bugfix/patch for DBCP but I cannot create a PR on the > GitHub site because I cannot push a branch. Any ideas on how I can get it > submitted? > > Gary Evesson > -- Matt Sicker
Re: StopWatch stop
Which subproject are you speaking of anyways? On 30 April 2017 at 15:46, Gary Gregory wrote: > A new method perhaps or a new class a la fluent? > > Gary > > On Apr 30, 2017 1:32 PM, "Matt Sicker" wrote: > > > Yup, here it is: > > 13.4.15. Method Result Type > > > > Changing the result type of a method, or replacing a result type with > void, > > or replacing void with a result type, has the combined effect of deleting > > the old method and adding a new method with the new result type or newly > > void result (see §13.4.12 > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > 13.html#jls-13.4.12 > > > > > ). > > > > For purposes of binary compatibility, adding or removing a method or > > constructor m whose return type involves type variables (§4.4 > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4>) > or > > parameterized types (§4.5 > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.5>) > is > > equivalent to the addition (respectively, removal) of the an otherwise > > equivalent method whose return type is the erasure (§4.6 > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.6>) > of > > the return type of m. > > > > On 30 April 2017 at 15:30, Matt Sicker wrote: > > > > > https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html > > > > > > A reference to a method must be resolved at compile time to a symbolic > > > reference to the erasure (§4.6 > > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.6 > >) > > > of the qualifying type of the invocation, plus the erasure of the > > signature > > > (§8.4.2 > > > <https://docs.oracle.com/javase/specs/jls/se7/html/jls- > 8.html#jls-8.4.2 > > >) > > > of the method. > > > > > > I'm getting the impression here that the ABI follows the same rules as > > > using MethodHandle.invokeExact(). > > > > > > On 30 April 2017 at 15:21, Gary Gregory > wrote: > > > > > >> On Apr 30, 2017 1:19 PM, "Oliver Heger" > > > >> wrote: > > >> > > >> I think client code has to be recompiled, otherwise a > NoSuchMethodError > > >> is thrown. > > >> > > >> > > >> > > >> Dang it. Are you sure? > > >> > > >> Gary > > >> > > >> > > >> Oliver > > >> > > >> Am 30.04.2017 um 21:24 schrieb Matt Sicker: > > >> > That sort of thing changes the binary signature, but source > > >> compatibility > > >> > is retained. > > >> > > > >> > On 30 April 2017 at 14:20, Gary Gregory > > wrote: > > >> > > > >> >> Hi, > > >> >> > > >> >> Would it break BC to change StopWatch.stop() to return "this"? > > >> >> > > >> >> Gary > > >> >> > > >> >> -- > > >> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > >> >> Java Persistence with Hibernate, Second Edition > > >> >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > >> >> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b > > >> 1af9fe6a2b8> > > >> >> > > >> >> <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > >> >> 1617290459> > > >> >> JUnit in Action, Second Edition > > >> >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > >> >> linkCode=as2&tag=garygregory-20&linkId= > > 31ecd1f6b6d1eaf8886ac902a24de4 > > >> 18%22 > > >> >>> > > >> >> > > >> >> <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > >> >> 1935182021> > > >> >> Spring Batch in Action > > >> >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > >> >> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > >> >> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > >> >> <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > >> >> 1935182951> > > >> >> Blog: http://garygregory.wordpress.com > > >> >> Home: http://garygregory.com/ > > >> >> Tweet! http://twitter.com/GaryGregory > > >> >> > > >> > > > >> > > > >> > > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: StopWatch stop
Yup, here it is: 13.4.15. Method Result Type Changing the result type of a method, or replacing a result type with void, or replacing void with a result type, has the combined effect of deleting the old method and adding a new method with the new result type or newly void result (see §13.4.12 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.12> ). For purposes of binary compatibility, adding or removing a method or constructor m whose return type involves type variables (§4.4 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4>) or parameterized types (§4.5 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.5>) is equivalent to the addition (respectively, removal) of the an otherwise equivalent method whose return type is the erasure (§4.6 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.6>) of the return type of m. On 30 April 2017 at 15:30, Matt Sicker wrote: > https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html > > A reference to a method must be resolved at compile time to a symbolic > reference to the erasure (§4.6 > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.6>) > of the qualifying type of the invocation, plus the erasure of the signature > (§8.4.2 > <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>) > of the method. > > I'm getting the impression here that the ABI follows the same rules as > using MethodHandle.invokeExact(). > > On 30 April 2017 at 15:21, Gary Gregory wrote: > >> On Apr 30, 2017 1:19 PM, "Oliver Heger" >> wrote: >> >> I think client code has to be recompiled, otherwise a NoSuchMethodError >> is thrown. >> >> >> >> Dang it. Are you sure? >> >> Gary >> >> >> Oliver >> >> Am 30.04.2017 um 21:24 schrieb Matt Sicker: >> > That sort of thing changes the binary signature, but source >> compatibility >> > is retained. >> > >> > On 30 April 2017 at 14:20, Gary Gregory wrote: >> > >> >> Hi, >> >> >> >> Would it break BC to change StopWatch.stop() to return "this"? >> >> >> >> Gary >> >> >> >> -- >> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> >> Java Persistence with Hibernate, Second Edition >> >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >> >> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b >> 1af9fe6a2b8> >> >> >> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> >> 1617290459> >> >> JUnit in Action, Second Edition >> >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >> >> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 >> 18%22 >> >>> >> >> >> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> >> 1935182021> >> >> Spring Batch in Action >> >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >> >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >> >> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >> >> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> >> 1935182951> >> >> Blog: http://garygregory.wordpress.com >> >> Home: http://garygregory.com/ >> >> Tweet! http://twitter.com/GaryGregory >> >> >> > >> > >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > Matt Sicker > -- Matt Sicker
Re: StopWatch stop
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html A reference to a method must be resolved at compile time to a symbolic reference to the erasure (§4.6 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.6>) of the qualifying type of the invocation, plus the erasure of the signature ( §8.4.2 <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>) of the method. I'm getting the impression here that the ABI follows the same rules as using MethodHandle.invokeExact(). On 30 April 2017 at 15:21, Gary Gregory wrote: > On Apr 30, 2017 1:19 PM, "Oliver Heger" > wrote: > > I think client code has to be recompiled, otherwise a NoSuchMethodError > is thrown. > > > > Dang it. Are you sure? > > Gary > > > Oliver > > Am 30.04.2017 um 21:24 schrieb Matt Sicker: > > That sort of thing changes the binary signature, but source compatibility > > is retained. > > > > On 30 April 2017 at 14:20, Gary Gregory wrote: > > > >> Hi, > >> > >> Would it break BC to change StopWatch.stop() to return "this"? > >> > >> Gary > >> > >> -- > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >> Java Persistence with Hibernate, Second Edition > >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > >> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2 > b8> > >> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > >> 1617290459> > >> JUnit in Action, Second Edition > >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > >> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > 18%22 > >>> > >> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > >> 1935182021> > >> Spring Batch in Action > >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > >> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > >> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > >> 1935182951> > >> Blog: http://garygregory.wordpress.com > >> Home: http://garygregory.com/ > >> Tweet! http://twitter.com/GaryGregory > >> > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Matt Sicker
Re: StopWatch stop
That sort of thing changes the binary signature, but source compatibility is retained. On 30 April 2017 at 14:20, Gary Gregory wrote: > Hi, > > Would it break BC to change StopWatch.stop() to return "this"? > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [Numbers] Java version?
Supporting Java 6 is going to continue to become harder and harder to do with infrastructural upgrades across the board. Recent versions of Gradle require Java 7 to run, for example, just like Jenkins, even though you can still use those to compile for Java 6. Ant has finally moved on from the Java 5 baseline, though IIRC, they jumped straight to Java 8. Considering how long it was between Maven 3.3.9 and 3.5.0, I'm guessing the discussion there about the baseline Java version is still ongoing. Really, what this is all pointing toward is that the greater Java developer community is moving on from Java 6, and if we want to continue supporting Java 6 in projects that otherwise shouldn't need anything newer, we may need some better tooling or documented standards on how to continue doing so. If Java 6 just never dies, then I almost think that we'll need to take a leaf from the Javascript developer community and get some sort of transpiler to support Java 6 using newer syntax and libraries (which could be compile-time re-linked to compatibility libraries). On 30 April 2017 at 09:55, Gilles wrote: > On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote: > >> On 30 April 2017 at 15:32, Gilles wrote: >> >>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote: >>> >>>> >>>> On 29 April 2017 at 19:10, Gilles wrote: >>>> >>>>> >>>>> Hi. >>>>> >>>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote: >>>>> >>>>>> >>>>>> >>>>>> Please note I wrote an issue concerning this last week or so. >>>>>> >>>>>> https://issues.apache.org/jira/browse/NUMBERS-21 >>>>>> >>>>>> I noticed when moving code from [math] to [numbers] that [math] >>>>>> targets >>>>>> 7. >>>>>> >>>>> >>>>> >>>>> >>>>> As a general rule, this must formally asked on the "dev" ML. >>>>> [And, we'll take for granted that if no one raises an objection >>>>> within 72 hours, the proposal is accepted.] >>>>> >>>>> I had to make some minor downgrades in the code (use of diamond >>>>>> operator). >>>>>> >>>>>> Given that [math] targets Java 7 and [numbers] is based on it, I see >>>>>> no >>>>>> reason [numbers] shouldn't target 7 as well. >>>>>> >>>>> >>>>> >>>>> >>>>> That's fine with me; however let's note (for the record) that the >>>>> last official release of CM (3.6.1) was still Java 5 (five) compatible. >>>>> I don't think (TBC) that any of the CM codes intended (as of now) for >>>>> inclusion _requires_ Java 7. >>>>> >>>>> Hence my question about the necessity (seems not) or willingness >>>>> (could well be, if just for the comfort of contributors) to upgrade. >>>>> >>>>> Now, concretely, you could make the "downgrades" and the code is >>>>> now Java 6 compatible. >>>>> However, as concretely, it is not obvious that we want to loose >>>>> more time fiddling with Jenkins to make it perform the build of >>>>> code targeted to old Java. >>>>> >>>> >>>> >>>> IMO it is wrong for Jenkins to dictate the Java compat level of the >>>> items it builds. >>>> >>> >>> >>> I agree. >>> >>> Besides, it is not difficult to do. >>>> >>> >>> >>> Then why doesn't INFRA do it when they perform an upgrade that >>> breaks what used to work? >>> >> >> Don't ask me, ask them... >> > > I first asked here because I might have missed an announcement > explaining how to upgrade the config. [I seem to recall having > done what was required when the issue with Java 6 was first > mentioned; then it broke again.] > > >> Help welcome, since I must have missed the "easy" part in my >>> attempts to fix it... >>> >> >> Which job is failing? >> > > I've just seen that you fixed it for "RNG". Thanks! > I've reviewed the changes and did the same in "Numbers". > Fixed now! > > Thanks, > Gilles > > > >> Gilles >>> >>> >>> >>>> >>>>> Regards, >>>>>
Re: [lang] Add StringUtils#getDigits?
This one I like. Could be handy in implementing things like permissive configuration parsing and other similar things. On 28 April 2017 at 09:57, Pascal Schumacher wrote: > Hello everybody, > > requested in: https://issues.apache.org/jira/browse/LANG-1307 > > pull request: https://github.com/apache/commons-lang/pull/225 > > Should we add this? > > What do you think? > > Thanks, > > Pascal > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [lang] Add StringUtils#isMixedCase?
Makes sense to me at least. On 28 April 2017 at 09:58, Pascal Schumacher wrote: > Hello everybody, > > requested in: https://issues.apache.org/jira/browse/LANG-1304 > > pull request: https://github.com/apache/commons-lang/pull/223 > > Should we add this? > > What do you think? > > Thanks, > > Pascal > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [Numbers] Java version?
If you're going to build for Java 6 using Java 7, then you should really use something like < http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to prevent accidental usage of Java 7. On 28 April 2017 at 09:51, sebb wrote: > On 28 April 2017 at 13:01, Gilles wrote: > > Hi. > > > > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote: > >> > >> On Apr 27, 2017 8:21 AM, "Gilles" wrote: > >> > >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote: > >> > >>> Choosing Java 8 or 7 for a new component depends on the APIs you want > to > >>> use for it more so than what's current. > >>> > >> > >> Indeed, the question could be rephrased as: Is there anything to loose > >> (for a new component) if we allow the larger API of Java 8? > >> > >> > >> I hear people are still using Java > >>> > >>> 6, but I doubt those projects are adapting new libraries or upgrading > any > >>> of their dependencies as it is... > >>> > >> > >> That has seemed logical to me for a long time... > >> > >> > >> +1 > >> > >> I say pick the version you think is best. > > > > > > At this point, I can't say exactly. > > The current code doesn't seem to need Java APIs beyond 6, but other > > utilities yet to be added might benefit. > > The only argument for leaving Java 6 is that we have to go through > > hoops with the Jenkins configuration. > > That is not an argument for upping the Java version > > > Currently it fails in a way that looks cryptic to me. > > That's because Jenkins now requires Java 7 to run Maven jobs, though > it does not seem to need it for all job types. > > > So, unless someone can fix it, I'll bump the dependency to Java 7. > > Huh? > Surely you can just tell Jenkins to use Java 7 to build and test? > There's no need for the source to be updated as well (there might be > some Javadoc warnings, I suppose, but those can be fixed without > compromising Java 6 compat.) > > But it's pretty easy to fix so it builds and tests using Java 6 - > which job is it? > > > Regards, > > Gilles > > > > > > > >> > >> Gary > >> > >> > >> Regards, > >> Gilles > >> > >> > >> On 27 April 2017 at 09:41, Gilles wrote: > >>> > >>> > >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote: > >>>> > >>>> > >>>> Hi. > >>>>> > >>>>> > >>>>> The POM indicates: > >>>>> > >>>>> 1.6 > >>>>> 1.6 > >>>>> > >>>>> but also: > >>>>> > >>>>> (requires Java 7+) > >>>>> > >>>>> Which is wrong? > >>>>> > >>>>> > >>>>> Also, please not that keeping 1.6 compatibility seems to complicate > >>>> > >>>> the Jenkins configuration: > >>>> https://builds.apache.org/view/Apache%20Commons/job/Commons_ > >>>> Numbers/14/console > >>>> > >>>> For a new component, shouldn't we just go to Java 8? > >>>> > >>>> > >>>> 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 > > -- Matt Sicker
Re: [Numbers] Java version?
Choosing Java 8 or 7 for a new component depends on the APIs you want to use for it more so than what's current. I hear people are still using Java 6, but I doubt those projects are adapting new libraries or upgrading any of their dependencies as it is... On 27 April 2017 at 09:41, Gilles wrote: > On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote: > >> Hi. >> >> The POM indicates: >> >> 1.6 >> 1.6 >> >> but also: >> >> (requires Java 7+) >> >> Which is wrong? >> >> > Also, please not that keeping 1.6 compatibility seems to complicate > the Jenkins configuration: > https://builds.apache.org/view/Apache%20Commons/job/Commons_ > Numbers/14/console > > For a new component, shouldn't we just go to Java 8? > > > Gilles > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [all] Java 9 module names
duct/1935182021/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > 18%22 > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > 18%22 > > >> > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > 1935182021 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= > > am2&o=1&a=1935182021>> > > > Spring Batch in Action > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action <https://www.amazon.com/gp/ > > product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative= > > 9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D& > > tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+ > Batch+in+Action > > >> > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > 1935182951 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= > > am2&o=1&a=1935182951>> > > > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress. > > com/> > > > Home: http://garygregory.com/ <http://garygregory.com/> > > > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> > > > -- Matt Sicker
Re: [all] Java 9 module names
>>>> Yes, as it stands, [net] would be a bad modular citizen, because it > >>>> exposes the "examples" package, and thus prevents any other module > >>>> from using that package. Just move it to > >>>> org.apache.commons.net.examples. > >>>> > >>>> Stephen > >>>> > >>>> --------- > >>>> 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 > >>> > >> > >> - > >> 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 > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [lang] [LANG-1291] Provide annotations to document thread safety.
;>>> + * <http://www.apache.org/>.
> >>>> + *
> >>>> + */
> >>>> +package org.apache.commons.lang3.concurrent.annotation;
> >>>> +
> >>>> +/**
> >>>> + * Defines types of threading behavior enforced at runtime.
> >>>> + */
> >>>> +public enum ThreadingBehavior {
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> be
> >>> fully immutable and thread-safe.
> >>>> + */
> >>>> +IMMUTABLE,
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> be
> >>> immutable if their dependencies injected at
> >>>> + * construction time are immutable and are expected to be
> >>> thread-safe if their dependencies are thread-safe.
> >>>> + */
> >>>> +IMMUTABLE_CONDITIONAL,
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> >>> maintain no state and to be thread-safe.
> >>>> + */
> >>>> +STATELESS,
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> be
> >>> fully thread-safe.
> >>>> + */
> >>>> +SAFE,
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> be
> >>> thread-safe if their dependencies injected at
> >>>> + * construction time are thread-safe.
> >>>> + */
> >>>> +SAFE_CONDITIONAL,
> >>>> +
> >>>> +/**
> >>>> + * Instances of classes with the given contract are expected to
> be
> >>> non thread-safe.
> >>>> + */
> >>>> +UNSAFE
> >>>> +
> >>>> +}
> >>>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> >>
> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> >> JUnit in Action, Second Edition
> >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> >>
> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> >> Spring Batch in Action
> >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> >
> > -
> > 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
>
>
--
Matt Sicker
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC1
Sounds like something that needs to be improved for Commons, quite possibly useful for other Apache projects, too. I've seen some neat continuous delivery style setups outside Apache, but that's not super feasible without integrating into automatic vote emails or something similar. Actually, that's not a bad idea. On 18 April 2017 at 01:54, Gary Gregory wrote: > On Mon, Apr 17, 2017 at 11:48 PM, Benedikt Ritter > wrote: > > > Hello, > > > > > Am 18.04.2017 um 08:32 schrieb Gary Gregory : > > > > > > On Mon, Apr 17, 2017 at 11:23 PM, Benedikt Ritter > <mailto:brit...@apache.org>> > > > wrote: > > > > > >> Hello, > > >> > > >>> Am 17.04.2017 um 21:19 schrieb Gary Gregory >: > > >>> > > >>> On Mon, Apr 17, 2017 at 12:01 PM, Gary Gregory < > garydgreg...@gmail.com > > >> <mailto:garydgreg...@gmail.com>> > > >>> wrote: > > >>> > > >>>> I am also wondering if the package should be the more > > >>>> generic org.apache.commons.lang3.annotation instead > > >>>> of org.apache.commons.lang3.concurrent.annotation. > > >>>> > > >>>> Thoughts? > > >>>> > > >>> > > >>> Resending, I am getting a weird bounce back saying: > > >>> > > >>> *newmx101.qq.com <http://newmx101.qq.com/> <http://newmx101.qq.com/ > < > > >> http://newmx101.qq.com/>> rejected your message to the > > >>> following email addresses:* > > >>> > > >>> liujichun1...@qq.com <mailto:liujichun1...@qq.com> > > >>> > > >>> > > >>> I've seen this before once or twice and I am wondering if I should > care > > >> or > > >>> if the list manager should… > > >> > > >> > > >> Gary, there’s no need to apologize for not bringing this up earlier. > > Like > > >> you must have missed my previous announcements that I’m planning to > push > > >> out an RC, I must have missed the discussions around > > >> org.apache.commons.lang3.concurrent.annotation. > > >> > > >> Nevertheless, I’m unhappy with the way this has been handled. Instead > of > > >> voting +/-1 people start discussing stuff that has been committed > weeks > > >> ago. This way you took the decision to cancel the vote for me, because > > we > > >> all know nobody is going to review this RC now that the VOTE thread > has > > >> been derailed. > > >> > > >> In the future, please just vote be it +1 or -1, but create new threads > > for > > >> any discussions. > > >> > > > > > > Dang, and here I am thinking I was handling this with kid gloved with > my > > > apology and "I think I should wait until this VOTE in canceled (if it > is) > > > before removing the current code.“ > > > > Yes you were. > > > > I probably was pissed, because it’s a lot a work to create an RC. But it > > was my decision to invest that time, so who am I to blame you for that > :-) > > > > I've ranted about our release process a couple of times on this ML. For me > the painful part is not cutting an RC, it is more what has to happen after > a VOTE passes. Releasing sources and binaries to Apache and then releasing > artifacts to Nexus after pruning all of the extra files. And the site. > > Gary > > > > > > > > > > I did not cancel anything nor voted -1, but in retrospect I should have > > > voted -1 so here is my -1 which is based on a technical reasons. I'll > > start > > > another thread. > > > > Thank you. > > > > Benedikt > > > > > > > > Gary > > > > > > > > >> Benedikt > > >> > > >>> > > >>> > > >>> Gary > > >>> > > >>>> > > >>>> Gary > > >>>> > > >>>> On Mon, Apr 17, 2017 at 11:55 AM, Gary Gregory < > > garydgreg...@gmail.com> > > >>>> wrote: > > >>>> > > >>>>> I've added the two types needed for HC style annotations. I think I > > >>>>> should wait until this VOTE in canceled (if it is) before removing > > the > > >>>>> current code. > > >>>>>
Re: [VOTE] Release Apache Commons Lang 3.6 based on RC1
g/~britt > >> er/commons/lang/LANG_3_6_RC1/clirr-report.html> > >> > >> RAT Report: > >> http://home.apache.org/~britter/commons/lang/LANG_3_6_RC1/ > >> rat-report.html > >> > >> KEYS: > >> https://www.apache.org/dist/commons/KEYS > >> > >> Please review the release candidate and vote. > >> This vote will close no sooner that 72 hours from now, > >> i.e. sometime after 15:00 CEST (UTC+2) 20-April 2017 > >> > >> [ ] +1 Release these artifacts > >> [ ] +0 OK, but... > >> [ ] -0 OK, but really should fix... > >> [ ] -1 I oppose this release because... > >> > >> Thanks! > >> > >> Benedikt > >> > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > Java Persistence with Hibernate, Second Edition > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > > JUnit in Action, Second Edition > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > > Spring Batch in Action > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [net] URLStreamHandler / URLStreamHandlerFactory implementations
That sounds like an overlapping concern with commons vfs. I've never really seen custom URL handlers out in the wild besides some basic zip file system sorts of things. On 9 April 2017 at 15:20, Charles Honton wrote: > Has anyone considered implementing URLStreamHandler(s) for the protocols > in commons net? > > thanks, > chas > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [DBCP]
MethodHandles.Lookup lookup = MethodHandles.lookup(); MethodType mt = MethodType.methodType(boolean.class, int.class); MethodHandle handle = lookup.findVirtual(Connection.class, "isValid", mt); // ... boolean isValid = (boolean) handle.invokeExact(connection, timeout); The findVirtual() call above will throw NoSuchMethodException if it doesn't exist. This is basically the same thing as traditional reflection, but more direct. On 29 March 2017 at 13:09, Gary Gregory wrote: > On Wed, Mar 29, 2017 at 8:28 AM, Matt Sicker wrote: > > > Using a MethodHandle lookup ahead of time to create a fast invocation > proxy > > and using that where available would make sense. I don't like the idea of > > catching errors like that. > > > > Hi Matt, > > Thank you for the tip. Do you have an example handy? (short on time today, > scrambling like a madman, otherwise I'd hack around) > > Gary > > > > > > On 29 March 2017 at 01:53, Gary Gregory wrote: > > > > > Hi All: > > > > > > The method: > > > > > > org.apache.commons.dbcp2.DelegatingConnection.isValid(int) > > > > > > delegates to a JDBC method that is marked "@since 1.6" in the JDBC > > Javadoc. > > > > > > I am dealing with an old JDBC driver that throws an AbstractMethodError > > > when this method is called. > > > > > > How can I workaround this? Should we add some mode to DBCP2 to deal > with > > > pre-1.6 JDBC drivers? If so how? Catch the AME specifically and > return... > > > what? > > > > > > Gary > > > > > > -- > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > Java Persistence with Hibernate, Second Edition > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2 > b8> > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1617290459> > > > JUnit in Action, Second Edition > > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > > 18%22 > > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182021> > > > Spring Batch in Action > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182951> > > > Blog: http://garygregory.wordpress.com > > > Home: http://garygregory.com/ > > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > -- > > Matt Sicker > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [DBCP]
Using a MethodHandle lookup ahead of time to create a fast invocation proxy and using that where available would make sense. I don't like the idea of catching errors like that. On 29 March 2017 at 01:53, Gary Gregory wrote: > Hi All: > > The method: > > org.apache.commons.dbcp2.DelegatingConnection.isValid(int) > > delegates to a JDBC method that is marked "@since 1.6" in the JDBC Javadoc. > > I am dealing with an old JDBC driver that throws an AbstractMethodError > when this method is called. > > How can I workaround this? Should we add some mode to DBCP2 to deal with > pre-1.6 JDBC drivers? If so how? Catch the AME specifically and return... > what? > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: ImmutablePair and compareTo()
Considering the limitations in syntax available for this (compare to Rust
which makes things immutable by default and requires a "mut" modifier to
change things), I think it'd have to be documented that this sort of pair
would only work with objects that were effectively immutable. Let's see how
this definition works:
An effectively immutable object is an object where its fields are:
* final primitives or strings
* primitives or strings without the ability to change their values (so
effectively final like with lambdas)
* a final or effectively final object made up effectively immutable fields
I'm not sure how to fit arrays in there since you can only have an
effectively final array as the components themselves can't be marked final.
Another way to look at it is like this:
Objects are effectively immutable if a.equals(a) for the entire lifetime of
a.
The first definition gives a nice way to look at implementations while the
second definition gives the end result of what guarantee we'd need here.
On 26 March 2017 at 00:27, Gary Gregory wrote:
> On Fri, Mar 3, 2017 at 8:05 AM, Matt Sicker wrote:
>
> > So would a further specialization be useful here for an immutable pair of
> > immutable objects?
>
>
>
> Hi Matt,
>
> But how would you guarantee that aside from using a marker interface to
> denote an object as being immutable? Are you talking about specializing for
> primitives or known JRE immutables like String and Integer? Curious...
>
> Gary
>
> In my own applications, I tend to embrace immutability
> > everywhere (except for certain performance-intensive areas involving byte
> > buffers and encoding/decoding), so being able to make assumptions about
> the
> > underlying objects would be nice.
> >
> > On 3 March 2017 at 09:58, Jörg Schaible
> > wrote:
> >
> > > Hi Matt,
> > >
> > > Matt Sicker wrote:
> > >
> > > > I took a look at this yesterday and forgot to reply. Anyways, I agree
> > > that
> > > > ImmutablePair should override compareTo() since it can rely on its
> own
> > > > values not changing, whereas the implementation in Pair isn't as
> crazy
> > > > since it's mutable.
> > >
> > > ImmutablePair is only immutable concerning the referenced objects, it
> > > cannot
> > > make any assumptions about those objects' immutability.
> > >
> > > StringBuilder builder = new StringBuilder();
> > > ImmutablePair = new ImmutablePair<>("key",
> > builder);
> > > builder.append("a");
> > >
> > > ImmutablePair just guarantees here that you will always have the same
> > > StringBuilder instance.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > Matt Sicker
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker
Re: [Collections] UnmodifiableSet/UnmodifiableList
I think the idea is giving a subset of the Set methods that are read-only. Any write operations wouldn't be available on the interface, so you couldn't compile it. On 23 March 2017 at 08:37, sebb wrote: > On 23 March 2017 at 07:48, Lukasz Lenart wrote: > > Hi, > > > > I see that the Collections4 provides those classes. Anyway I wonder > > why I the constructor is private and why the factory method > > unmodifiableSet() returns Set? > > > > I would love to use those classes directly, to be straightforward that > > I expect the UnmodifiableSet and not just a Set. > > > > What about adding a method like in Guava? Something like this: > > > > public static UnmodifiableSet of(Set set) > > > > This allows define UnmodifiableSets in code and use compiler to check > > if everything is ok. > > Not sure I follow. > > What exactly can the compiler check? > > The API for UnmodifiableSet is basically the same as the API for Set. > > Yes, it implements Unmodifiable, but that is a Collections4 class and > means nothing to the compiler. > > It is only at run-time that the the classes throw an error for update > operations. > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > 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 > > -- Matt Sicker
Re: [Pool] Need PMC assistance to finish git migration
Looks like we've been migrated. Can I get some quick verification? On 21 March 2017 at 13:22, Gary Gregory wrote: > Oh good, it is moving along nicely then. > > Gary > > On Mar 21, 2017 6:26 PM, "Matt Sicker" wrote: > > > I followed up with my original ticket: > > https://issues.apache.org/jira/browse/INFRA-13630 > > > > On 18 March 2017 at 05:26, Gary Gregory wrote: > > > > > On Fri, Mar 17, 2017 at 6:38 PM, Matt Sicker wrote: > > > > > > > We need to update something in order to make the git.apache.org and > > > github > > > > mirrors point at the right repo. > > > > > > > > > > Hm right. I wonder if there is an INFRA request or something I can > do...? > > > > > > Gary > > > > > > > > > > > > > > On 17 March 2017 at 12:35, Gary Gregory > > wrote: > > > > > > > > > FYI: > > > > > > > > > > On the page I see: > > > > > > > > > > "1) Edit the projects data file (as below) and replace the location > > > > > reference if necessary: > > > > > > > > > > https://svn.apache.org/repos/asf/infrastructure/site-tools/ > > > > > trunk/projects/files.xml > > > > > > > > > > But there is no such file." > > > > > > > > > > Gary > > > > > > > > > > On Fri, Mar 17, 2017 at 4:30 AM, Matt Sicker > > wrote: > > > > > > > > > > > I imported the svn repo for commons-pool and uploaded it to the > > newly > > > > > > created git repo here: > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf/commons-pool.git > > > > > > > > > > > > I need a PMC to help finish this migration. Instructions are > here: > > > > > > > > > > > > https://wiki.apache.org/commons/MovingToGit > > > > > > > > > > > > When that is complete, we can update Jenkins. I already updated > the > > > pom > > > > > > metadata to point to the new repo. After migration is complete, I > > can > > > > > work > > > > > > on a release candidate. > > > > > > > > > > > > -- > > > > > > Matt Sicker > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > > > Java Persistence with Hibernate, Second Edition > > > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > > > > linkCode=as2&tag=garygregory-20&linkId= > > cadb800f39946ec62ea2b1af9fe6a2 > > > b8> > > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > > > > 1617290459> > > > > > JUnit in Action, Second Edition > > > > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > > > > linkCode=as2&tag=garygregory-20&linkId= > > 31ecd1f6b6d1eaf8886ac902a24de4 > > > > 18%22 > > > > > > > > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > > > > 1935182021> > > > > > Spring Batch in Action > > > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > > > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > > > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t= > > garygregory-20&l=am2&o=1&a= > > > > > 1935182951> > > > > > Blog: http://garygregory.wordpress.com > > > > > Home: http://garygregory.com/ > > > > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > > > > > -- > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > Java Persistence with Hibernate, Second Edition > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2 > b8> > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1617290459> > > > JUnit in Action, Second Edition > > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > > 18%22 > > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182021> > > > Spring Batch in Action > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182951> > > > Blog: http://garygregory.wordpress.com > > > Home: http://garygregory.com/ > > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
Re: [Pool] Need PMC assistance to finish git migration
I followed up with my original ticket: https://issues.apache.org/jira/browse/INFRA-13630 On 18 March 2017 at 05:26, Gary Gregory wrote: > On Fri, Mar 17, 2017 at 6:38 PM, Matt Sicker wrote: > > > We need to update something in order to make the git.apache.org and > github > > mirrors point at the right repo. > > > > Hm right. I wonder if there is an INFRA request or something I can do...? > > Gary > > > > > > On 17 March 2017 at 12:35, Gary Gregory wrote: > > > > > FYI: > > > > > > On the page I see: > > > > > > "1) Edit the projects data file (as below) and replace the location > > > reference if necessary: > > > > > > https://svn.apache.org/repos/asf/infrastructure/site-tools/ > > > trunk/projects/files.xml > > > > > > But there is no such file." > > > > > > Gary > > > > > > On Fri, Mar 17, 2017 at 4:30 AM, Matt Sicker wrote: > > > > > > > I imported the svn repo for commons-pool and uploaded it to the newly > > > > created git repo here: > > > > > > > > https://git-wip-us.apache.org/repos/asf/commons-pool.git > > > > > > > > I need a PMC to help finish this migration. Instructions are here: > > > > > > > > https://wiki.apache.org/commons/MovingToGit > > > > > > > > When that is complete, we can update Jenkins. I already updated the > pom > > > > metadata to point to the new repo. After migration is complete, I can > > > work > > > > on a release candidate. > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > > > > > -- > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > Java Persistence with Hibernate, Second Edition > > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2 > b8> > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1617290459> > > > JUnit in Action, Second Edition > > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4 > > 18%22 > > > > > > > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182021> > > > Spring Batch in Action > > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > > > 1935182951> > > > Blog: http://garygregory.wordpress.com > > > Home: http://garygregory.com/ > > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > -- > > Matt Sicker > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [VOTE][VFS][LAZY] Migrate VFS to Git
This vote passes with no objections. I'll be able to convert this after we figure out how to finish converting pool. On 17 March 2017 at 13:16, Gary Gregory wrote: > +1 > > Gary > > On Fri, Mar 17, 2017 at 4:32 AM, Matt Sicker wrote: > > > Before starting work on a VFS 3 branch, I'd like to migrate from > Subversion > > to Git. As with other repo migrations, this is a lazy majority vote that > > will be open for 72 hours. If there are no objections, I'll import the > svn > > repo into git, and with the help of a PMC or two, create a new git repo > on > > apache.org to host it, and then move the old svn repo into the > > _moved_to_git archives. > > > > -- > > Matt Sicker > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
They package ByteBuf and family in a package called netty-buffer which only depends on netty-common. We could add those as dependencies, or we could shade them. Do note that netty-common already shades jctools, so this would be a double-shading which is rather amusing. On 17 March 2017 at 12:35, Matt Sicker wrote: > Oh wait, I looked into it more. That might be usable actually. Plus it > could be useful for diving directly into the network code of networked file > systems to implement them more efficiently. I'm not sure how well isolated > those classes are, so we might need to just take them and do some renaming. > > On 17 March 2017 at 12:34, Matt Sicker wrote: > >> I'm actually learning a little bit about ByteBuf from Netty this >> afternoon. I don't know enough about the implementation to say. The thing >> is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are >> converted into ByteBuffers yet. >> >> On 17 March 2017 at 12:19, Gary Gregory wrote: >> >>> I'll be happy to help with PMC related tasks. >>> >>> Gary >>> >>> On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker wrote: >>> >>> > Commons VFS is still in Subversion. We're going to need a new Git repo >>> > regardless. I can do an import for that repo like I did for Pool, but I >>> > need PMC help to complete the transition. >>> > >>> > Also, I was thinking about which Java version to support. Java 7 is >>> > obviously the minimum due to the API being added there, and it doesn't >>> look >>> > like there was anything new added in Java 8 for NIO (other than an >>> improved >>> > SelectorProvider implementation on Solaris, but that's not a public >>> API). I >>> > don't see any additions in Java 9, either. Now I prefer using Java 8 >>> for >>> > development, but as there appears to be no specific reason to use Java >>> 8 >>> > for this version, we could really go either way. Using Java 7 makes >>> more >>> > sense for creating FileSystemProvider implementations, though >>> depending on >>> > any additional APIs added, I don't know if it'll turn out that >>> supporting >>> > Java 8 APIs will be all that useful. >>> > >>> > On 16 March 2017 at 02:39, Benedikt Ritter wrote: >>> > >>> > > Why not a new branch in the existing repo? >>> > > >>> > > Benedikt >>> > > >>> > > Ralph Goers schrieb am Do. 16. März >>> 2017 um >>> > > 06:54: >>> > > >>> > > > Yes, and here we are with Java 9 at our doorstep. Time flies. >>> > > > >>> > > > I would recommend that you create a commons-vfs3 git repo for this >>> as >>> > you >>> > > > will only be able to borrow some code. A lot will be different. >>> > > > >>> > > > Ralph >>> > > > >>> > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker >>> wrote: >>> > > > > >>> > > > > Ralph has mentioned in the past an idea about rewriting >>> commons-vfs >>> > > using >>> > > > > java.nio.file from Java 7. I was playing with this API today >>> > attempting >>> > > > to >>> > > > > abstract some S3 file operations using < >>> > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and >>> found >>> > > that >>> > > > > the API is pretty nice. OpenJDK already contains implementations >>> for >>> > > the >>> > > > > normal file system and zip files if I recall correctly (so >>> probably >>> > > also >>> > > > > jar files). >>> > > > > >>> > > > > Anyways, if we were to go forward with starting work on this, >>> should >>> > we >>> > > > > just make a commons-vfs3 branch in the vfs repo? Or does this >>> belong >>> > in >>> > > > the >>> > > > > sandbox? >>> > > > > >>> > > > > -- >>> > > > > Matt Sicker >>> > > > >>> > > > >>> > > > >>> > > > >&g
Re: [Pool] Need PMC assistance to finish git migration
We need to update something in order to make the git.apache.org and github mirrors point at the right repo. On 17 March 2017 at 12:35, Gary Gregory wrote: > FYI: > > On the page I see: > > "1) Edit the projects data file (as below) and replace the location > reference if necessary: > > https://svn.apache.org/repos/asf/infrastructure/site-tools/ > trunk/projects/files.xml > > But there is no such file." > > Gary > > On Fri, Mar 17, 2017 at 4:30 AM, Matt Sicker wrote: > > > I imported the svn repo for commons-pool and uploaded it to the newly > > created git repo here: > > > > https://git-wip-us.apache.org/repos/asf/commons-pool.git > > > > I need a PMC to help finish this migration. Instructions are here: > > > > https://wiki.apache.org/commons/MovingToGit > > > > When that is complete, we can update Jenkins. I already updated the pom > > metadata to point to the new repo. After migration is complete, I can > work > > on a release candidate. > > > > -- > > Matt Sicker > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
Oh wait, I looked into it more. That might be usable actually. Plus it could be useful for diving directly into the network code of networked file systems to implement them more efficiently. I'm not sure how well isolated those classes are, so we might need to just take them and do some renaming. On 17 March 2017 at 12:34, Matt Sicker wrote: > I'm actually learning a little bit about ByteBuf from Netty this > afternoon. I don't know enough about the implementation to say. The thing > is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are > converted into ByteBuffers yet. > > On 17 March 2017 at 12:19, Gary Gregory wrote: > >> I'll be happy to help with PMC related tasks. >> >> Gary >> >> On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker wrote: >> >> > Commons VFS is still in Subversion. We're going to need a new Git repo >> > regardless. I can do an import for that repo like I did for Pool, but I >> > need PMC help to complete the transition. >> > >> > Also, I was thinking about which Java version to support. Java 7 is >> > obviously the minimum due to the API being added there, and it doesn't >> look >> > like there was anything new added in Java 8 for NIO (other than an >> improved >> > SelectorProvider implementation on Solaris, but that's not a public >> API). I >> > don't see any additions in Java 9, either. Now I prefer using Java 8 for >> > development, but as there appears to be no specific reason to use Java 8 >> > for this version, we could really go either way. Using Java 7 makes more >> > sense for creating FileSystemProvider implementations, though depending >> on >> > any additional APIs added, I don't know if it'll turn out that >> supporting >> > Java 8 APIs will be all that useful. >> > >> > On 16 March 2017 at 02:39, Benedikt Ritter wrote: >> > >> > > Why not a new branch in the existing repo? >> > > >> > > Benedikt >> > > >> > > Ralph Goers schrieb am Do. 16. März >> 2017 um >> > > 06:54: >> > > >> > > > Yes, and here we are with Java 9 at our doorstep. Time flies. >> > > > >> > > > I would recommend that you create a commons-vfs3 git repo for this >> as >> > you >> > > > will only be able to borrow some code. A lot will be different. >> > > > >> > > > Ralph >> > > > >> > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker >> wrote: >> > > > > >> > > > > Ralph has mentioned in the past an idea about rewriting >> commons-vfs >> > > using >> > > > > java.nio.file from Java 7. I was playing with this API today >> > attempting >> > > > to >> > > > > abstract some S3 file operations using < >> > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and >> found >> > > that >> > > > > the API is pretty nice. OpenJDK already contains implementations >> for >> > > the >> > > > > normal file system and zip files if I recall correctly (so >> probably >> > > also >> > > > > jar files). >> > > > > >> > > > > Anyways, if we were to go forward with starting work on this, >> should >> > we >> > > > > just make a commons-vfs3 branch in the vfs repo? Or does this >> belong >> > in >> > > > the >> > > > > sandbox? >> > > > > >> > > > > -- >> > > > > Matt Sicker >> > > > >> > > > >> > > > >> > > > >> - >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > >> > > >> > >> > >> > >> > -- >> > Matt Sicker >> > >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&link >> Code=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1617290459> >> JUnit in Action, Second Edition >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&link >> Code=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1935182021> >> Spring Batch in Action >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&link >> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli >> nk_id%7D%7D%22%3ESpring+Batch+in+Action> >> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1935182951> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker > -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
I'm actually learning a little bit about ByteBuf from Netty this afternoon. I don't know enough about the implementation to say. The thing is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are converted into ByteBuffers yet. On 17 March 2017 at 12:19, Gary Gregory wrote: > I'll be happy to help with PMC related tasks. > > Gary > > On Thu, Mar 16, 2017 at 4:31 PM, Matt Sicker wrote: > > > Commons VFS is still in Subversion. We're going to need a new Git repo > > regardless. I can do an import for that repo like I did for Pool, but I > > need PMC help to complete the transition. > > > > Also, I was thinking about which Java version to support. Java 7 is > > obviously the minimum due to the API being added there, and it doesn't > look > > like there was anything new added in Java 8 for NIO (other than an > improved > > SelectorProvider implementation on Solaris, but that's not a public > API). I > > don't see any additions in Java 9, either. Now I prefer using Java 8 for > > development, but as there appears to be no specific reason to use Java 8 > > for this version, we could really go either way. Using Java 7 makes more > > sense for creating FileSystemProvider implementations, though depending > on > > any additional APIs added, I don't know if it'll turn out that supporting > > Java 8 APIs will be all that useful. > > > > On 16 March 2017 at 02:39, Benedikt Ritter wrote: > > > > > Why not a new branch in the existing repo? > > > > > > Benedikt > > > > > > Ralph Goers schrieb am Do. 16. März 2017 > um > > > 06:54: > > > > > > > Yes, and here we are with Java 9 at our doorstep. Time flies. > > > > > > > > I would recommend that you create a commons-vfs3 git repo for this as > > you > > > > will only be able to borrow some code. A lot will be different. > > > > > > > > Ralph > > > > > > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker wrote: > > > > > > > > > > Ralph has mentioned in the past an idea about rewriting commons-vfs > > > using > > > > > java.nio.file from Java 7. I was playing with this API today > > attempting > > > > to > > > > > abstract some S3 file operations using < > > > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and > found > > > that > > > > > the API is pretty nice. OpenJDK already contains implementations > for > > > the > > > > > normal file system and zip files if I recall correctly (so probably > > > also > > > > > jar files). > > > > > > > > > > Anyways, if we were to go forward with starting work on this, > should > > we > > > > > just make a commons-vfs3 branch in the vfs repo? Or does this > belong > > in > > > > the > > > > > sandbox? > > > > > > > > > > -- > > > > > Matt Sicker > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > -- > > Matt Sicker > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker
[VOTE][VFS][LAZY] Migrate VFS to Git
Before starting work on a VFS 3 branch, I'd like to migrate from Subversion to Git. As with other repo migrations, this is a lazy majority vote that will be open for 72 hours. If there are no objections, I'll import the svn repo into git, and with the help of a PMC or two, create a new git repo on apache.org to host it, and then move the old svn repo into the _moved_to_git archives. -- Matt Sicker
[Pool] Need PMC assistance to finish git migration
I imported the svn repo for commons-pool and uploaded it to the newly created git repo here: https://git-wip-us.apache.org/repos/asf/commons-pool.git I need a PMC to help finish this migration. Instructions are here: https://wiki.apache.org/commons/MovingToGit When that is complete, we can update Jenkins. I already updated the pom metadata to point to the new repo. After migration is complete, I can work on a release candidate. -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
Based on experience with ByteBuffers in the past, I have a feeling VFS3 may want to provide some sort of abstraction over it like how Netty does. Otherwise, managing ByteBuffers can become painful. On 16 March 2017 at 10:31, Matt Sicker wrote: > Commons VFS is still in Subversion. We're going to need a new Git repo > regardless. I can do an import for that repo like I did for Pool, but I > need PMC help to complete the transition. > > Also, I was thinking about which Java version to support. Java 7 is > obviously the minimum due to the API being added there, and it doesn't look > like there was anything new added in Java 8 for NIO (other than an improved > SelectorProvider implementation on Solaris, but that's not a public API). I > don't see any additions in Java 9, either. Now I prefer using Java 8 for > development, but as there appears to be no specific reason to use Java 8 > for this version, we could really go either way. Using Java 7 makes more > sense for creating FileSystemProvider implementations, though depending on > any additional APIs added, I don't know if it'll turn out that supporting > Java 8 APIs will be all that useful. > > On 16 March 2017 at 02:39, Benedikt Ritter wrote: > >> Why not a new branch in the existing repo? >> >> Benedikt >> >> Ralph Goers schrieb am Do. 16. März 2017 um >> 06:54: >> >> > Yes, and here we are with Java 9 at our doorstep. Time flies. >> > >> > I would recommend that you create a commons-vfs3 git repo for this as >> you >> > will only be able to borrow some code. A lot will be different. >> > >> > Ralph >> > >> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker wrote: >> > > >> > > Ralph has mentioned in the past an idea about rewriting commons-vfs >> using >> > > java.nio.file from Java 7. I was playing with this API today >> attempting >> > to >> > > abstract some S3 file operations using < >> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found >> that >> > > the API is pretty nice. OpenJDK already contains implementations for >> the >> > > normal file system and zip files if I recall correctly (so probably >> also >> > > jar files). >> > > >> > > Anyways, if we were to go forward with starting work on this, should >> we >> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong >> in >> > the >> > > sandbox? >> > > >> > > -- >> > > Matt Sicker >> > >> > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > > > > -- > Matt Sicker > -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
Commons VFS is still in Subversion. We're going to need a new Git repo regardless. I can do an import for that repo like I did for Pool, but I need PMC help to complete the transition. Also, I was thinking about which Java version to support. Java 7 is obviously the minimum due to the API being added there, and it doesn't look like there was anything new added in Java 8 for NIO (other than an improved SelectorProvider implementation on Solaris, but that's not a public API). I don't see any additions in Java 9, either. Now I prefer using Java 8 for development, but as there appears to be no specific reason to use Java 8 for this version, we could really go either way. Using Java 7 makes more sense for creating FileSystemProvider implementations, though depending on any additional APIs added, I don't know if it'll turn out that supporting Java 8 APIs will be all that useful. On 16 March 2017 at 02:39, Benedikt Ritter wrote: > Why not a new branch in the existing repo? > > Benedikt > > Ralph Goers schrieb am Do. 16. März 2017 um > 06:54: > > > Yes, and here we are with Java 9 at our doorstep. Time flies. > > > > I would recommend that you create a commons-vfs3 git repo for this as you > > will only be able to borrow some code. A lot will be different. > > > > Ralph > > > > > On Mar 15, 2017, at 8:12 PM, Matt Sicker wrote: > > > > > > Ralph has mentioned in the past an idea about rewriting commons-vfs > using > > > java.nio.file from Java 7. I was playing with this API today attempting > > to > > > abstract some S3 file operations using < > > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found > that > > > the API is pretty nice. OpenJDK already contains implementations for > the > > > normal file system and zip files if I recall correctly (so probably > also > > > jar files). > > > > > > Anyways, if we were to go forward with starting work on this, should we > > > just make a commons-vfs3 branch in the vfs repo? Or does this belong in > > the > > > sandbox? > > > > > > -- > > > Matt Sicker > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [VFS] Interest in starting a Java 7 FileSystem-based version?
There's also a ton of in-depth features like file attributes, ACLs, other permissions, etc. Then there's a bit of overlap with security concerns that come with that. It certainly provides a rather broad matrix of features that are possible to expose. There's also FileTypeDetector which has functional overlap with Tika. Also, the dependencies in vfs2 are pretty out of date at this point. On 15 March 2017 at 22:27, Schalk W. Cronjé wrote: > > > The ZIP implementation is very basic. I've started exoerimenting with this > quite a while ago writing a RAM filesystem as to experiment w.ith the > complexities. > I would definitely be interested in working with you on this even if it is > only for shared learning. As one dives deeper into it there's a lot of > 'devil in details' and two minds are better than one to bounce ideas around. > > > Sent from my Samsung device > > Original message > From: Matt Sicker > Date: 16/03/2017 08:42 (GMT+05:30) > To: Commons Developers List > Subject: [VFS] Interest in starting a Java 7 FileSystem-based version? > > Ralph has mentioned in the past an idea about rewriting commons-vfs using > java.nio.file from Java 7. I was playing with this API today attempting to > abstract some S3 file operations using < > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that > the API is pretty nice. OpenJDK already contains implementations for the > normal file system and zip files if I recall correctly (so probably also > jar files). > > Anyways, if we were to go forward with starting work on this, should we > just make a commons-vfs3 branch in the vfs repo? Or does this belong in the > sandbox? > > -- > Matt Sicker > -- Matt Sicker
[VFS] Interest in starting a Java 7 FileSystem-based version?
Ralph has mentioned in the past an idea about rewriting commons-vfs using java.nio.file from Java 7. I was playing with this API today attempting to abstract some S3 file operations using < https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found that the API is pretty nice. OpenJDK already contains implementations for the normal file system and zip files if I recall correctly (so probably also jar files). Anyways, if we were to go forward with starting work on this, should we just make a commons-vfs3 branch in the vfs repo? Or does this belong in the sandbox? -- Matt Sicker
Re: [jexl] 3.1 release review
Using interfaces and implementing them are two entirely separate things. For instance, people use Logger instances, but we've added new APIs to that interface in log4j-api while maintaining backwards compatibility (though we do that by providing abstract base classes for implementations to use). On 13 March 2017 at 21:08, sebb wrote: > On 14 March 2017 at 01:38, Matt Sicker wrote: > > If they're not user-implemented interfaces, then changing them isn't > really > > a backwards incompatible change. > > I agree, but since users asked for the changes to the interfaces that > suggests that the interfaces are being used externally. > > > On 13 March 2017 at 17:50, sebb wrote: > > > >> On 13 March 2017 at 20:12, henrib wrote: > >> > > >> > The interface modifications are fixes to user enhancement requests: > >> > > >> > JEXL-211: Add callable method to JexlExpression interface > >> > JEXL-198: JxltEngine Template deos not expose pragmas > >> > JEXL-201: Allow Interpreter to use live values from JexlEngine.Option > >> > interface implemented by JexlContext > >> > > >> > Note again that these interfaces are *not* expected to be implemented > by > >> > user code. > >> > >> I'm not sure I understand how that follows. > >> > >> If the JIRAs are enhancement requests for users, surely the intention > >> is to allow the users to make use of the new methods? > >> > >> That suggests that the users are currently using the interfaces. > >> > >> > The likelihood of any user implementing those and not filling > >> > enhancements requests or even asking questions in the Apache mailing > >> lists > >> > (or Stackoverflow) seems very small... > >> > >> Sorry, no idea what you mean by that. > >> > >> > Choice is please (the few) users using the library or stay true to a > rule > >> > that protects no real usage in this case. I wish this was seen as an > easy > >> > choice for the community. > >> > >> Nor that. > >> > >> > Cheers > >> > > >> > > >> > > >> > -- > >> > View this message in context: http://apache-commons.680414. > >> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html > >> > Sent from the Commons - Dev mailing list archive at Nabble.com. > >> > > >> > - > >> > 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 > >> > >> > > > > > > -- > > Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
Re: [jexl] 3.1 release review
If they're not user-implemented interfaces, then changing them isn't really a backwards incompatible change. On 13 March 2017 at 17:50, sebb wrote: > On 13 March 2017 at 20:12, henrib wrote: > > > > The interface modifications are fixes to user enhancement requests: > > > > JEXL-211: Add callable method to JexlExpression interface > > JEXL-198: JxltEngine Template deos not expose pragmas > > JEXL-201: Allow Interpreter to use live values from JexlEngine.Option > > interface implemented by JexlContext > > > > Note again that these interfaces are *not* expected to be implemented by > > user code. > > I'm not sure I understand how that follows. > > If the JIRAs are enhancement requests for users, surely the intention > is to allow the users to make use of the new methods? > > That suggests that the users are currently using the interfaces. > > > The likelihood of any user implementing those and not filling > > enhancements requests or even asking questions in the Apache mailing > lists > > (or Stackoverflow) seems very small... > > Sorry, no idea what you mean by that. > > > Choice is please (the few) users using the library or stay true to a rule > > that protects no real usage in this case. I wish this was seen as an easy > > choice for the community. > > Nor that. > > > Cheers > > > > > > > > -- > > View this message in context: http://apache-commons.680414. > n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html > > Sent from the Commons - Dev mailing list archive at Nabble.com. > > > > - > > 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 > > -- Matt Sicker
Re: [jexl] 3.1 release review
It's more of an issue for downstream users who implement the interface as they'd now have an illegally declared class not implementing all abstract methods. On 13 March 2017 at 07:13, sebb wrote: > AFAICT two of the interface changes are not needed: > > JexlExpression#Callable can be dropped; AFAICT no other changes are needed. > JxltEngine$Template#getPragmas() can be dropped if the test is > modified to use TemplateScript and TS drops the @Override marker > > It's probably not easy to drop JexlEngine$Options#isCancellable() from > the interface. > Nor does it look very easy to interpose an Abstract implementation method. > I don't know if one could add an extended Options interface. > > Is there a different way to implement isCancellable? > Does it really belong in Options, or could it be added to JexlEngine > instead? > > Adding methods to an interface does not break binary compatibility, > however AIUI many downstream consumers rely on source builds so > compatibility breaks of any kind should be avoided in the public API. > > > On 12 March 2017 at 17:09, Matt Sicker wrote: > > BC can be handled a couple ways here besides renaming: > > > > * Are there already abstract classes that implementations are meant to > > extend? If so, that limits the possibility of problems here without using > > default methods in Java 8. > > * If these are truly public interfaces for users to implement, then you > can > > extend the interface with an extended version which adds new methods. Try > > not to name them Options31 if you can help it. > > > > On 12 March 2017 at 05:16, henrib wrote: > > > >> > >> I've reworded the warning about the source compatibility break in the > >> release notes: > >> > >> > >> > >> If this source compatibility break is not 'permitted' despite its > >> improbability, what option should we take: > >> - move to another (jexl31) package ? > >> - add 'extended' interfaces (Options31, JexlExpression31, Template31) ? > >> - add a utility helper class (Jexl31Helper?) to put the 3 methods as > >> functions ( boolean isCancellable(JExlEngine.Options opt) ? > >> > >> > >> Comments welcome, > >> Thanks > >> > >> > >> > >> -- > >> View this message in context: http://apache-commons.680414. > >> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html > >> Sent from the Commons - Dev mailing list archive at Nabble.com. > >> > >> ----- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > -- > > Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker
