>
> Only if the binary layout has changed.
>
> - Jörg
>
Thanks Jörg for this answer. Only, could you be a bit more specific,
please? I suppose that if I only change comments,or rename variables,
I do not change the binary layout. In all other instances I do. Is
that correct?
Thanks,
Sébastien
---
Sébastien Brisard wrote:
> Dear all,
> I'm currently modifying a class which implements serializable. Before
> committing the changes, should I create a new serialVersionUID?
Only if the binary layout has changed.
- Jörg
-
To
Dear all,
I'm currently modifying a class which implements serializable. Before
committing the changes, should I create a new serialVersionUID?
Thanks beforehand,
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-configuration has an issue affecting its community integration.
Th
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-exec-test has an issue affecting its community integration.
This i
On Thu, Dec 01, 2011 at 10:10:05PM +0100, Luc Maisonobe wrote:
> Le 01/12/2011 20:21, l...@apache.org a écrit :
> > Author: luc
> > Date: Thu Dec 1 19:21:11 2011
> > New Revision: 1209198
> >
> > URL: http://svn.apache.org/viewvc?rev=1209198&view=rev
> > Log:
> > Updated patch from original contr
Le 01/12/2011 20:21, l...@apache.org a écrit :
> Author: luc
> Date: Thu Dec 1 19:21:11 2011
> New Revision: 1209198
>
> URL: http://svn.apache.org/viewvc?rev=1209198&view=rev
> Log:
> Updated patch from original contributor.
>
> Modified:
>
> commons/proper/math/trunk/src/main/java/org/apa
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-configuration has an issue affecting its community integration.
Th
>
> more consistent. ;-)
>
You got me...
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On Thu, Dec 01, 2011 at 04:28:12PM +0100, Sébastien Brisard wrote:
> Hello,
> >
> > IMHO, no.
> > The fact 0 is signed for doubles is really a trick set up in the IEE754
> > standard only for dealing with branch cuts (like the division you present).
> > It is not available for other types like in
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15237&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 1 Dec 2011 15:38:26 +
Finished at: Thu 1 Dec 2011 15:39:12 +
Total time: 46s
Build Trigger: Schedule
Build Num
Do as you wish, I will no longer bug you.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128952.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---
Hello,
>
> IMHO, no.
> The fact 0 is signed for doubles is really a trick set up in the IEE754
> standard only for dealing with branch cuts (like the division you present).
> It is not available for other types like int or longs where 0 is not signed
> and special numbers like infinity and NaN a
Hello.
>
> >
> > Should the "Fraction" type be able to represent
> > -0 / 1
> > and keep a record of the sign, such that, if "c" is the above
> > fraction,
> > 1d / c.doubleValue()
> > is equals "Double.NEGATIVE_INFITNITY"?
>
> IMHO, no.
> [...]
OK.
I've added a few (trivial) unit tests in
On 1 December 2011 15:01, henrib wrote:
> After more thoughts on the matter, I tried to be attractive to pragmatic
Sorry, what matter?
> coder with JEXL which is antagonist to the more rigorous approach you want
> to impose.
I'm just being cautious, see below.
> As a user of some other librari
On 1 December 2011 14:15, henrib wrote:
(BTW, please quote some context (as I do here) when replying.
Otherwise it becomes rather difficult to follow the thread.)
> I don't think the JexlEngine mutable fields should be made volatile. Same as
> JexlArithmetic btw.
>
> The intent is not to change
After more thoughts on the matter, I tried to be attractive to pragmatic
coder with JEXL which is antagonist to the more rigorous approach you want
to impose.
As a user of some other libraries, I find bothersome not being able to
derive classes because all methods/fields are private and/or final wh
- Mail original -
> Hi.
Hello Gilles,
>
> Should the "Fraction" type be able to represent
> -0 / 1
> and keep a record of the sign, such that, if "c" is the above
> fraction,
> 1d / c.doubleValue()
> is equals "Double.NEGATIVE_INFITNITY"?
IMHO, no.
The fact 0 is signed for doubles
I don't think the JexlEngine mutable fields should be made volatile. Same as
JexlArithmetic btw.
The intent is not to change them but just to allow configuration of the
behavior after the ctor but before usage. In the future, those should also
be made final and/or use "feature" ala JexlThreadeAri
On 1 December 2011 13:31, henrib wrote:
> Fair enough; do you make the change or do I make the change ?
I can make the changes.
Are you happy with the changes I made in the API-COMPAT branch?
If so, I can bring them back to the 2.0 branch.
> --
> View this message in context:
> http://apache-
Hi.
Should the "Fraction" type be able to represent
-0 / 1
and keep a record of the sign, such that, if "c" is the above fraction,
1d / c.doubleValue()
is equals "Double.NEGATIVE_INFITNITY"?
Gilles
-
To unsubscribe, e-mail:
Fair enough; do you make the change or do I make the change ?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128334.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---
On 1 December 2011 12:50, henrib wrote:
> Both 'parameters' and 'cancelled' are protected so they can be used by
> derived classes easily; having a private field + protected setter and getter
> is clutter in this specific case.
The problem with mutable non-private fields is that they are non-OO;
Both 'parameters' and 'cancelled' are protected so they can be used by
derived classes easily; having a private field + protected setter and getter
is clutter in this specific case.
Parameters holds the register 'names' which proves useful when debugging;
the 2 arrays are parallel.
--
View this
Clirr reports that there are some new mutable non-private fields.
Mutable fields should be private, and only updated through a setter method.
Can the following be made private?
They don't appear to be used externally.
INFO: 6000: org.apache.commons.jexl2.Interpreter: Added protected
field cancel
26 matches
Mail list logo
