Re: StopWatch stop

I suppose another approach is to punt any kind of fluent redo to 4.0, and break BC at that point, avoiding class duplication. Gary On May 3, 2017 4:10 AM, "Benedikt Ritter" wrote: > Am 02.05.2017 um 04:36 schrieb Matt Sicker : > > What about a fluent package for classes like this so you can s

Re: StopWatch stop

> Am 02.05.2017 um 04:36 schrieb Matt Sicker : > > What about a fluent package for classes like this so you can still call it > StopWatch? As I’ve argued for the concurrency annotations, I don’t think it’s good style to package stuff by their technical similarities. So I’d add those fluent cla

Re: StopWatch stop

Not sure about that. 1) it's not easy to tell which class is being used at a glance 2) cannot easily use both classes at once. 3) auto-complete may pick the wrong one c.f. java.util.Date and java.sql.Date I'm not saying the approach should not be used, however it has some disadvantages. On 2 Ma

Re: StopWatch stop

I'll note that I had proposed something similar with locks a while back. This may suffer from the same issue for some: Using AutoCloseable and try-with-resources in an unusual way. Gary On Tue, May 2, 2017 at 4:22 PM, Gary Gregory wrote: > Here is my version based on a fluent version of Apache

Re: StopWatch stop

Here is my version based on a fluent version of Apache Commons Lang's StopWatch: https://pastebin.com/biNfwu7S Example: try (final StopWatchLogger watch = StopWatchLogger.start(LOGGER, Level.DEBUG, "Executing {} {}", connectingIOReactor, "foo")) { connectingIOReactor.execute(connectingEventDis

Re: StopWatch stop

Great idea! Gary On Mon, May 1, 2017 at 7:36 PM, Matt Sicker wrote: > 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;" > >

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

Re: StopWatch stop

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

Re: StopWatch stop

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:

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

Re: StopWatch stop

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

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

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 ) of the qualifying type of the invocation, plus the erasure of

Re: StopWatch stop

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

Re: StopWatch stop

I think client code has to be recompiled, otherwise a NoSuchMethodError is thrown. 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, >> >> Wou

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

StopWatch stop

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