date:20150921

Re: [COMPRESS] pkware header id for crypto extensions

2015-09-21 Thread Bear Giles

I have a moment to explain why the PKWARE crypto is stronger than the
WinZip crypto.

1. The key has validation data, the VData and VCRC32 values.

There are a couple different ways to compute a message integrity check that
allows you to verify the encryption key and that the message contents have
not been modified. This is only available after encrypting all of the data
- in streaming mode this information would have to be written to a footer.
That's not difficult but it means that something has been written to the
disk before it's verified and that might cause problems.

Message integrity checks also require maintenance of a second key that's
independent of the first. Some ciphers have an encryption mode that handles
message integrity at the same time it does decryption but many ciphers do
not and you can't assume all readers supports those ciphers and modes.

Key validation won't detect message corruption but the file CRC gives us a
modest level of protection. It's only modest though since it's easy to set
the message CRC to whatever value you want if you can modify 4 bytes.
That's impractical with a true HMAC with strong algorithms.

2. Encrypted random data (ERD)

You can often predict the initial contents of a file from the filename
extension. For instance a .xml file probably starts with  or the compressed version of the same. This means you have
a "known plaintext" problem and it is a powerful tool used to break the
legacy ZIP encryption.

ERD handles that by prepending random data to the file. The reader knows to
ignore those bytes. The ERD is encrypted in the header with the same key
(but all-zero IV?) to avoid the same "known plaintext" problem.

One of the WW-II (or WW-I?) German ciphers was broken this way. Messages
were supposed to start with a unique value but one clerk repeated one by
accident. It was enough to break the cipher since all messages started the
same way.

Bear

On Sun, Sep 20, 2015 at 8:36 PM, Bear Giles  wrote:

> I took out some debugging scaffolding so you can check it out. One of the
> unit tests fails but it should since it's trying to read an archive with an
> encrypted CD. (I haven't gotten around to wrapping it with an exception
> handler that fails if an exception isn't thrown.)
>
> Theoretically you can do a pull request. I think.
>
> Bear
>
> On Tue, Sep 15, 2015 at 8:03 AM, Stefan Bodewig 
> wrote:
>
>> On 2015-09-14, Bear Giles wrote:
>>
>> > I want to capture as much information as possible but the documentation
>> is
>> > a weird mixture of details and hand-waving. Some is detailed, some is
>> > "compatible with the format used by the Microsoft CRYPTOAPI".  How is
>> > anyone supposed to use that if all they have is the APPNOTE.txt file?
>>
>> Compared to some other "specs" we implement, this is brilliant ;-)
>>
>> > Anyway I can demonstrate that the headers are recognized in at least one
>> > test case so I'll just remove the debugging code and add a few getters.
>>
>> Sounds great.
>>
>> > FWIW my initial impression from what's in the fields is that WinZip is
>> > competently implemented but PKWare is a LOT more solid. I can give
>> details
>> > if anyone wants to be bored. :-)
>>
>> Expect me to ask you for the boring details once I start breathing
>> again.  Probably better off-list :-)
>>
>> Cheers
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

Re: [Math] LeastSquaresOptimizer Design

2015-09-21 Thread Ole Ersoy


Hola,

On 09/21/2015 04:15 PM, Gilles wrote:

Hi.

On Sun, 20 Sep 2015 15:04:08 -0500, Ole Ersoy wrote:

On 09/20/2015 05:51 AM, Gilles wrote:

On Sun, 20 Sep 2015 01:12:49 -0500, Ole Ersoy wrote:

Wanted to float some ideas for the LeastSquaresOptimizer (Possibly
General Optimizer) design.  For example with the
LevenbergMarquardtOptimizer we would do:
`LevenbergMarquardtOptimizer.optimize(OptimizationContext c);`

Rough optimize() outline:
public static void optimise() {
//perform the optimization
//If successful
c.notify(LevenberMarquardtResultsEnum.SUCCESS, solution);
//If not successful


c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_COST_RELATIVE_TOLERANCE,
diagnostic);
//or


c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_PARAMETERS_RELATIVE_TOLERANCE,
diagnostic)
//etc
}

The diagnostic, when turned on, will contain a trace of the last N
iterations leading up to the failure.  When turned off, the Diagnostic
instance only contains the parameters used to detect failure. The
diagnostic could be viewed as an indirect way to log optimizer
iterations.

WDYT?


I'm wary of having several different ways to convey information to the
caller.

It would just be one way.


One way for optimizer, one way for solvers, one way for ...


Yes I see what you mean, but I think on a whole it will be worth it to add 
additional sugar code that removes the need for exceptions.




But the caller may not be the receiver
(It could be).  The receiver would be an observer attached to the
OptimizationContext that implements an interface allowing it to observe
the optimization.


I'm afraid that it will add to the questions of what to put in the
code and how.  [We already had sometimes heated discussions just for
the IMHO obvious (e.g. code formatting, documentation, exception...).]


Hehe.  Yes I remember some of these discussions.  I wonder how much time was 
spent debating the exceptions alone?  Surely everyone must have had this 
feeling in pit of their stomach that there's got to be a better way.  On the 
exception topic, these are some of the issues:

I18N
===
If you are new to commons math and thinking about designing a commons math 
compatible exception you should probably understand the I18N stuff that's bound 
to exception (and wonder why it's bound the the exception).  Grab a coffee and 
spend a few hours, unless you are obviously fairly new to Java like some ofthe 
people posting for help.  In this case when the exception occurs, there is 
going to be a lot of tutoring going on on the users list.

Number of Exceptions
===
Before you do actually design a new exception, you should probably see if there 
is an exception that already fits the category of what you are doing.  So you 
start reading.  Exception1...nop 
Exception2...nop...Exception3...Exception999..But I think I'm getting warmer.  
OK - Did not find it ... but I'm fairly certain that there is a elegant place 
for it somewhere in the exception hierarchy...


Handling of Exceptions
===
If our app uses several of the commons math classes (That throw exceptions of 
the same type), and one of those classes throws an exception,what is the app 
supposed to do?

I think most developers would find that question somewhat challenging.  There 
are numerous strategies.  Catch all exceptions and log what happened, etc.  But 
what if the requirement is that if an exception is thrown, the organization 
that receives it has 0 seconds to get to the root cause of it and understand 
the dynamics. Is this doable?  (Yes obviously, but how hard is it...?).



It seems that the reporting interfaces could quickly overwhelm
the "actual" code (one type of context per algorithm).

There would one type of Observer interface per algorithm.  It would
act on the solution and what are currently exceptions, although these
would be translated into enums.


Unless I'm mistaken, the most common use-case for codes implemented
in a library such as CM is to provide a correct answer or bail out
in a non-equivocal way.

Most java developers are used to synchronous coding...call the method get the 
response...catch the exception if needed.  This is changing with JDK8, and as 
we evolve and start using lambdas, we become more accustomed to the functional 
callback style of programming.  Personally I want to be able to use an API that 
gives me what I need when everything works as expected, allows me to resolve 
unexpected issues with minimal effort, and is as simple, fluid, and lightweight 
as possible.



It would make the code more involved to handle a minority of
(undefined) cases. [Actual examples would be welcome in order to
focus the discussion.]


Rough Outline (I've evolved the concept and moved away from the 
OptimizationContext in the process of writing):

interface LevenbergMarquardtObserver {

public void hola(Solution s);
public void sugarHoneyIceTea(ResultType rt, Dianostics d);
}

public class LMObserver implements

[site] please push update (was: svn commit: r1704337 - /commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml)

2015-09-21 Thread Bernd

Hello,

can somebody please review this change and push it to the commons
site? It removes the trunks-proper profile documentation, links to
version 39 and adds some additional hints.

Gruss
Bend


-- Forwarded message --
From:  
Date: 2015-09-21 18:00 GMT+02:00
Subject: svn commit: r1704337 -
/commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml
To: comm...@commons.apache.org


Author: ecki
Date: Mon Sep 21 16:00:40 2015
New Revision: 1704337

URL: http://svn.apache.org/viewvc?rev=1704337=rev
Log:
Updated for commons-parent 39 (removed trunks-proper)

Modified:
commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml

Modified: commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml
URL: 
http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml?rev=1704337=1704336=1704337=diff
==
--- commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml (original)
+++ commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml Mon Sep
21 16:00:40 2015
@@ -31,11 +31,11 @@
 http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml;>commons-parent
 pom.xml
 
-It has been updated for version 38 of the pom (but some
discrepancies may remain).
-Please consult http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-38/pom.xml;>version
38 source
+It has been updated for version 39 of the pom (but some
discrepancies may remain).
+Please consult http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-39/;>version
39 source
 in case of doubt.
 
-Release Notes for http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-38/RELEASE-NOTES.txt;>version
38
+Release Notes for http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-39/RELEASE-NOTES.txt;>version
39
   

   
@@ -109,7 +109,8 @@
 Java Version
- source and target
 options can be configured through properties, and
profiles are provided to test on
 different Java versions.
-Where necessary, plugin versions are down-graded to the
latest version that runs on earlier JVMs.
+Where necessary, plugin versions are down-graded to the
latest version that runs on earlier JVMs. If later Java versions
+require updated plugins, this is done in a conditional
profile (jdk7-plugin-fix-version).
   
   
 Testing
Coverage - both Jacoco and
Cobertura
@@ -409,6 +410,9 @@
 Import-Package instruction
  The
commons.osgi.dynamicImport property
configures the
 DynamicImport-Package
instruction
+ The
commons.osgi.excludeDependencies should be
set to
+ false if the bundle plugin should be able to scan
dependency versions and the optional
+ attribute.
   
 
   
@@ -551,38 +555,10 @@

 mvn -Prelease package

-  
-
-  
-
-  http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml;>commons-parent
-  contains a trunks-proper profile with the components set up
-  as modules. This is a
convenience profile so that Maven commands can be run
-  for all components.
-
-
-
-  N.B. This profile works with
-  http://svn.apache.org/repos/asf/commons/trunks-proper/;>http://svn.apache.org/repos/asf/commons/trunks-proper/
-  which, you need to check out first (it pulls in the
trunks of the components
-  using an svn:externals property  - see
-  http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-2.3.6;>here
for more details).
-
-
 
-  For example, if the template for the
-  http://commons.apache.org/commons-build-plugin/download-page.html;>download
page
-  was changed, you could re-generate the download pages for
all components
-  using the following command:
-
-
-mvn -Ptrunks-proper commons:download-page
-
+  You can also combine the -Prelease option with
deploy target and the -Ptest-deploy
+  profile to simulate staging to the repository.
 
-  ...or to test all components:
-
-
-mvn -Ptrunks-proper clean test
   

   

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

Re: Version number for next commons-io

2015-09-21 Thread Jörg Schaible

Gary Gregory wrote:

> Alternative to keep 100% BC
> 
> - Remove the new method, release 2.5, and add it back for SNAPSHOT
> - Add the new method in a new sub-interface

or catch and ignore this special RTE when calling the new method form our 
code. Old clients never asked for it, new/updated clients can use it. 
Listener interface is a special case here.

- Jörg

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

Re: Version number for next commons-io

2015-09-21 Thread Gary Gregory

Alternative to keep 100% BC

- Remove the new method, release 2.5, and add it back for SNAPSHOT
- Add the new method in a new sub-interface

Gary

On Mon, Sep 21, 2015 at 10:23 AM, Phil Steitz  wrote:

> On 9/19/15 9:55 AM, sebb wrote:
> > On 19 September 2015 at 17:26, Kristian Rosenvold 
> wrote:
> >> 2015-09-19 13:58 GMT+02:00 Kristian Rosenvold :
> >>> Just to be clear on this, the breach is adding an interface to
> >> Oops. The breach is adding a /method/.
> > That's what I assumed - adding a method to an interface does not
> > affect binary compat.
>
> I am +1 for avoiding the repackaging if this is in fact very low
> incidence, but calling it binary compatible is a bit of a stretch
> (unless I am missing something), since it seems to me that this will
> result in RTE if dropped in if a user supplies a listener that does
> not implement the new method, which pretty much all "old" listeners
> would not.  So anyone who uses the listener *must* add the
> implementation and recompile.  Am I missing something here?
> Definitely want to cover this in release notes, since for those who
> use TailerListeners, unless they add the new method, they will get
> unexpected RTE at EOF.
>
> Phil
> >
> >>> org.apache.commons.io.input.TailerListener#endOfFileReached
> >>> and will probably only affect a few users. I'm documenting this in
> >>> release notes.
> >> Kristian
> >>
> >> -
> >> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Version number for next commons-io

2015-09-21 Thread sebb

On 21 September 2015 at 18:36, Jörg Schaible  wrote:
> Gary Gregory wrote:
>
>> Alternative to keep 100% BC
>>
>> - Remove the new method, release 2.5, and add it back for SNAPSHOT
>> - Add the new method in a new sub-interface
>
> or catch and ignore this special RTE when calling the new method form our
> code. Old clients never asked for it, new/updated clients can use it.
> Listener interface is a special case here.

This is what the JLS says about binary compatibity of a method
addition to an interface:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100

If the code were to use reflection it would notice the difference, but
otherwise the change is BC according to the JLS.

I don't think we need to do anything here, beyond pointing out that
recompilated client code may need to be updated.
But that is not a binary compatible issue, it is source compatibilty.

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

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

Re: Version number for next commons-io

2015-09-21 Thread Phil Steitz

On 9/19/15 9:55 AM, sebb wrote:
> On 19 September 2015 at 17:26, Kristian Rosenvold  
> wrote:
>> 2015-09-19 13:58 GMT+02:00 Kristian Rosenvold :
>>> Just to be clear on this, the breach is adding an interface to
>> Oops. The breach is adding a /method/.
> That's what I assumed - adding a method to an interface does not
> affect binary compat.

I am +1 for avoiding the repackaging if this is in fact very low
incidence, but calling it binary compatible is a bit of a stretch
(unless I am missing something), since it seems to me that this will
result in RTE if dropped in if a user supplies a listener that does
not implement the new method, which pretty much all "old" listeners
would not.  So anyone who uses the listener *must* add the
implementation and recompile.  Am I missing something here? 
Definitely want to cover this in release notes, since for those who
use TailerListeners, unless they add the new method, they will get
unexpected RTE at EOF.

Phil
>
>>> org.apache.commons.io.input.TailerListener#endOfFileReached
>>> and will probably only affect a few users. I'm documenting this in
>>> release notes.
>> Kristian
>>
>> -
>> 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

Re: Version number for next commons-io

2015-09-21 Thread sebb

On 21 September 2015 at 20:03, Phil Steitz  wrote:
> On 9/21/15 10:59 AM, sebb wrote:
>> On 21 September 2015 at 18:36, Jörg Schaible  wrote:
>>> Gary Gregory wrote:
>>>
 Alternative to keep 100% BC

 - Remove the new method, release 2.5, and add it back for SNAPSHOT
 - Add the new method in a new sub-interface
>>> or catch and ignore this special RTE when calling the new method form our
>>> code. Old clients never asked for it, new/updated clients can use it.
>>> Listener interface is a special case here.
>> This is what the JLS says about binary compatibity of a method
>> addition to an interface:
>>
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100
>>
>> If the code were to use reflection it would notice the difference, but
>> otherwise the change is BC according to the JLS.
>>
>> I don't think we need to do anything here, beyond pointing out that
>> recompilated client code may need to be updated.
>> But that is not a binary compatible issue, it is source compatibilty.
>
> So you are saying that somehow if I have implemented a
> TailerListener with the old interface and I drop in the new release,
> I won't get RTE at EOF?  If that is the case, that is a nasty
> surprise, regardless of what the JLS says about binary compat.

OK, I see now.

If users have extended TailerListenerAdapter then they should be OK.

But it does look as though any code that implements the TailerListener
interface will have problems, as the new IO code won't find the
method.

This suggests another possible approach: add the method to the Adapter
only and only call the method if the adapter is an instance of the
Adapter.

We should perhaps deprecate the interface in favour of the Adapter.

And the code definitely needs some @since markers before it is ready
for release.

> Phil
>>
>>> - Jörg
>>>
>>>
>>> -
>>> 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

Re: Version number for next commons-io

2015-09-21 Thread Phil Steitz

On 9/21/15 10:36 AM, Jörg Schaible wrote:
> Gary Gregory wrote:
>
>> Alternative to keep 100% BC
>>
>> - Remove the new method, release 2.5, and add it back for SNAPSHOT
>> - Add the new method in a new sub-interface
> or catch and ignore this special RTE when calling the new method form our 
> code. Old clients never asked for it, new/updated clients can use it. 
> Listener interface is a special case here.

+1

Phil
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> .
>


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

Re: Version number for next commons-io

2015-09-21 Thread Phil Steitz

On 9/21/15 10:59 AM, sebb wrote:
> On 21 September 2015 at 18:36, Jörg Schaible  wrote:
>> Gary Gregory wrote:
>>
>>> Alternative to keep 100% BC
>>>
>>> - Remove the new method, release 2.5, and add it back for SNAPSHOT
>>> - Add the new method in a new sub-interface
>> or catch and ignore this special RTE when calling the new method form our
>> code. Old clients never asked for it, new/updated clients can use it.
>> Listener interface is a special case here.
> This is what the JLS says about binary compatibity of a method
> addition to an interface:
>
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100
>
> If the code were to use reflection it would notice the difference, but
> otherwise the change is BC according to the JLS.
>
> I don't think we need to do anything here, beyond pointing out that
> recompilated client code may need to be updated.
> But that is not a binary compatible issue, it is source compatibilty.

So you are saying that somehow if I have implemented a
TailerListener with the old interface and I drop in the new release,
I won't get RTE at EOF?  If that is the case, that is a nasty
surprise, regardless of what the JLS says about binary compat.

Phil
>
>> - Jörg
>>
>>
>> -
>> 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

Re: [Math] LeastSquaresOptimizer Design

2015-09-21 Thread Gilles


Hi.

On Sun, 20 Sep 2015 15:04:08 -0500, Ole Ersoy wrote:

On 09/20/2015 05:51 AM, Gilles wrote:

On Sun, 20 Sep 2015 01:12:49 -0500, Ole Ersoy wrote:

Wanted to float some ideas for the LeastSquaresOptimizer (Possibly
General Optimizer) design.  For example with the
LevenbergMarquardtOptimizer we would do:
`LevenbergMarquardtOptimizer.optimize(OptimizationContext c);`

Rough optimize() outline:
public static void optimise() {
//perform the optimization
//If successful
c.notify(LevenberMarquardtResultsEnum.SUCCESS, solution);
//If not successful


c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_COST_RELATIVE_TOLERANCE,
diagnostic);
//or


c.notify(LevenberMarquardtResultsEnum.TOO_SMALL_PARAMETERS_RELATIVE_TOLERANCE,
diagnostic)
//etc
}

The diagnostic, when turned on, will contain a trace of the last N
iterations leading up to the failure.  When turned off, the 
Diagnostic

instance only contains the parameters used to detect failure. The
diagnostic could be viewed as an indirect way to log optimizer
iterations.

WDYT?


I'm wary of having several different ways to convey information to 
the

caller.

It would just be one way.


One way for optimizer, one way for solvers, one way for ...


But the caller may not be the receiver
(It could be).  The receiver would be an observer attached to the
OptimizationContext that implements an interface allowing it to 
observe

the optimization.


I'm afraid that it will add to the questions of what to put in the
code and how.  [We already had sometimes heated discussions just for
the IMHO obvious (e.g. code formatting, documentation, exception...).]


It seems that the reporting interfaces could quickly overwhelm
the "actual" code (one type of context per algorithm).

There would one type of Observer interface per algorithm.  It would
act on the solution and what are currently exceptions, although these
would be translated into enums.


Unless I'm mistaken, the most common use-case for codes implemented
in a library such as CM is to provide a correct answer or bail out
in a non-equivocal way.

It would make the code more involved to handle a minority of
(undefined) cases. [Actual examples would be welcome in order to
focus the discussion.]


The current reporting is based on exceptions, and assumes that if no
exception was thrown, then the user's request completed 
successfully.

Sure - personally I'd much rather deal with something similar to an
HTTP status code in a callback, than an exception .  I think the code
is cleaner and the calback makes it more elegant to apply an adaptive
approach to handling the response, like slightly relaxing 
constraints,

convergence parameters, etc.  Also by getting rid of the exceptions,
we no longer depend on the I18N layer that they are tied to and now
the messages can be more informative, since they target the root
cause.  The observer can also run in the 'main' thread' while the
optimization can run asynchronously.  Also WRT JDK9 and modules,
loosing the exceptions would mean one less dependency when the 
library

is up into JDK9 modules...which would be more in line with this
philosophy:
https://github.com/substack/browserify-handbook#module-philosophy


I'm not sure I fully understood the philosophy from the text in this
short paragraph.
But I do not agree with the idea that the possibility to quickly find
some code is more important than standards and best practices.


I totally agree that in some circumstances, more information on the
inner working of an algorithm would be quite useful.

... Algorithm iterations become unit testable.


But I don't see the point in devoting resources to reinvent the 
wheel:

You mean pimping the wheel?  Big pimpin.


I think that logging statements are easy to add, not disruptive at all,
and come in handy to understand a code's unexpected behaviour.
Assuming that a "logging" feature is useful, it can be added *now* 
using

a dependency towards a weight-less (!) framework such as "slf4j".
IMO, it would be a waste of time to implement a new communication layer
that can do that, and more, if it would be used for logging only in 99%
of the cases.



I longed several times for the use of a logging library.
The only show-stopper has been the informal "no-dependency" 
policy...

JDK9 Jigsaw should solve dependency hell, so the less coupling
between commons math classes the better.


I wouldn't call "coupling" the dependency towards exception classes:
they are little utilities that can make sense in various parts of the
library.

[Unless one wants to embark on yet another discussion about exceptions;
whether there should be one class for each of the "messages" that exist
in "LocalizedFormats"; whether localization should be done in CM;
etc.]


Anyways I'm obviously
interested in playing with this stuff, so when I get something up 
into

a repository I'll to do a callback :).


If you are interested in big overhauls, there is one that gathered
relative consensus: rewrite the algorithms in a

Re: Version number for next commons-io

2015-09-21 Thread Jörg Schaible

sebb wrote:

> On 21 September 2015 at 20:03, Phil Steitz  wrote:
>> On 9/21/15 10:59 AM, sebb wrote:
>>> On 21 September 2015 at 18:36, Jörg Schaible 
>>> wrote:
 Gary Gregory wrote:

> Alternative to keep 100% BC
>
> - Remove the new method, release 2.5, and add it back for SNAPSHOT
> - Add the new method in a new sub-interface
 or catch and ignore this special RTE when calling the new method form
 our code. Old clients never asked for it, new/updated clients can use
 it. Listener interface is a special case here.
>>> This is what the JLS says about binary compatibity of a method
>>> addition to an interface:
>>>
>>> 
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100
>>>
>>> If the code were to use reflection it would notice the difference, but
>>> otherwise the change is BC according to the JLS.
>>>
>>> I don't think we need to do anything here, beyond pointing out that
>>> recompilated client code may need to be updated.
>>> But that is not a binary compatible issue, it is source compatibilty.
>>
>> So you are saying that somehow if I have implemented a
>> TailerListener with the old interface and I drop in the new release,
>> I won't get RTE at EOF?  If that is the case, that is a nasty
>> surprise, regardless of what the JLS says about binary compat.
> 
> OK, I see now.
> 
> If users have extended TailerListenerAdapter then they should be OK.
> 
> But it does look as though any code that implements the TailerListener
> interface will have problems, as the new IO code won't find the
> method.
> 
> This suggests another possible approach: add the method to the Adapter
> only and only call the method if the adapter is an instance of the
> Adapter.
> 
> We should perhaps deprecate the interface in favour of the Adapter.
> 
> And the code definitely needs some @since markers before it is ready
> for release.

+0

In the light of a future release based on Java 8, I am not sure if it the 
best action to deprecate the interface now, because then we could use 
default implementations. Just for consideration.

Cheers,
Jörg


> 
>> Phil
>>>
 - Jörg


 -
 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

Re: [COMPRESS] pkware header id for crypto extensions

Re: [Math] LeastSquaresOptimizer Design

[site] please push update (was: svn commit: r1704337 - /commons/cms-site/trunk/content/xdoc/commons-parent-pom.xml)

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: Version number for next commons-io

Re: [Math] LeastSquaresOptimizer Design

Re: Version number for next commons-io

12 matches

Site Navigation

Mail list logo

Footer information