commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: proposal for performance/usability optimisations in commons.lang.Validate
Date Sun, 07 Jun 2009 20:04:50 GMT

Hiho!

I wrote a version based on the mirror on github which is available here:
http://github.com/struberg/commons-lang/commit/ed8515f63290eba6e38ff5b79772e87b27dde32b

I will create a JIRA and  also attached a patch for those not familiar with git.

LieGrue,
strub

--- Mark Struberg <struberg@yahoo.de> schrieb am Do, 7.5.2009:

> Von: Mark Struberg <struberg@yahoo.de>
> Betreff: Re: proposal for performance/usability optimisations in  commons.lang.Validate
> An: "Commons Developers List" <dev@commons.apache.org>
> Datum: Donnerstag, 7. Mai 2009, 11:23
> 
> Thanks a lot Henri!
> 
> I talked with Shawn Pearce about possible performance
> issues and we now ended up with 3 function
> groups:
> 
> notNull(Object)
> notNull(Object, String)
> notNull(Object, String, Object...);
> 
> So the JVM doesn't need to create an Object[] if we only
> like to provide a single String message.
> I think we could do the same for all the notNull(Object,
> String, Integer) for binary compatibility
> although I believe this will make the library more complex
> to use. And since the packages will
> change too ...
> 
> In any case we should do 2 things (also for the 'old'
> functions with (Object, String, Integer) or
> whatever). Remember ALL those things will happen _only_ if
> the validation fails, so we don't have
> to care about performance - we don't need to fail fast ;)
> 
> 1.) 
> if (o == null ) {
>   if (msg contains {0} or something that indicates the
> use of MessageFormat) {
>     use MessageFormat;
>   } else {
>     use msg + ": " + msgIntParam;
>   }
> }
> 
> So this should then even be compatible to use for 'old'
> invocations where one doesn't like to use
> the MessageFormat feature.
> 
> wdyt?
> 
> Patch will follow in about ~1-2 weeks.
> 
> txs and LieGrue,
> strub
> 
> 
> --- Henri Yandell <flamefew@gmail.com>
> schrieb:
> 
> > trunk/ is now JDK 5 focused. It'll be Lang 3.0, but is
> very unlikely
> > to keep the same package naming.
> > 
> > My biggest concern with ellipsis code is that null
> moves from being
> > null to being null inside an Object[]. So we could see
> some
> > unnecessary API changing if we're not careful.
> > 
> > Otherwise - the below sounds good and a JIRA issue
> with a patch would rock :)
> > 
> > Thanks,
> > 
> > Hen
> > 
> > On Sat, May 2, 2009 at 10:06 AM, Mark Struberg <struberg@yahoo.de>
> wrote:
> > >
> > > Hi!
> > >
> > > I'm a long time user (and big fan) of
> commons.lang.Validate because it's a very neat pattern
> > for getting stable software modules.
> > >
> > > I'm PMC member on Apache OpenWebBeans and
> currently also writing the maven-scm-provider-jgit
> > (JGIT is a native Java implementation of GIT). Since
> jgit-core (the part of EGIT we use for the
> > maven-scm-provider-jgit) is BSD and Shawn likes to
> have not too much external dependencies, I
> > started writing my own little Validate helper class
> and had a hopefully good idea which imho
> > would also be a good extension to
> commons.lang.Validate:
> > >
> > > A main problem on validation is the message
> creation which costs a lot of String operations
> > and therefor also garbage collection. I've now seen
> that the latest version in SVN has an
> > additional object parameter for a few functions which
> addresses this problem. My proposal now
> > goes even further but requires java-5 since it uses
> ellipsis notation.
> > >
> > > If msgObject[0] is a String
> java.text.MessageFormat will be used for creating the
> failure
> > message, e.g.
> > > Validate.notNull(nullInt, "testMessageText
> Integer={0} btw! and Integer2={1}.", new
> > Integer(42), new Integer(43));
> > >
> > > example for isTrue with message construction:
> > >
> > > /**
> > >  * Validate that b is
> <code>true</code>
> > >  *
> > >  * @param b boolean to validate
> > >  * @param msgObjects additional Objects added as
> text message to the InvalidArgumentException
> > >  */
> > > public static void isTrue(boolean b, Object...
> msgObjects) {
> > >        if (!b) {
> > >                throw new
> IllegalArgumentException(getMessage(msgObjects));
> > >        }
> > > }
> > >
> > > /**
> > >  * private helper function to create an error
> message from the given Objects
> > >  * If the first object in msgObjects is of type
> {@code String} then
> > >  * {@code MessageFormat} will be used to format
> the output message.
> > >  *
> > >  * @param msgObjects
> > >  * @return concatenated String representation of
> all the objects
> > >  */
> > > private static String getMessage(Object...
> msgObjects) {
> > >        if (msgObjects.length > 0
> && msgObjects[0] instanceof String) {
> > >                MessageFormat form = new
> MessageFormat((String) msgObjects[0]);
> > >                Object[] params = new
> Object[msgObjects.length - 1];
> > >              
>  System.arraycopy(msgObjects, 1, params, 0,
> msgObjects.length - 1);
> > >                return
> form.format(params);
> > >        }
> > >        else {
> > >                StringBuffer sb = new
> StringBuffer("Validation failed: [");
> > >                for(int i = 0; i <
> msgObjects.length; i++) {
> > >                        if (i > 0)
> {
> > >                              
>  sb.append(' ');
> > >                        }
> > >                      
>  sb.append(msgObjects[i]);
> > >                }
> > >                sb.append(']');
> > >                return sb.toString();
> > >        }
> > > }
> > >
> > > I've tested those functions against 'old'
> Validate handling to ensure that there are no
> > performance side effects with Java ellipsis handling,
> and the performance win is huge [1]. The
> > ellipsis Version only takes < 5% of the time of the
> 'old' handling.
> > >
> > > WDYT?
> > > a.) Is the implementation ok?
> > > b.) Will there be a java-5 only version of
> commons.lang in the near future?
> > > c.) Imho we could replace the 1-parameter
> versions with the proper ellipsis functions and we
> > are still compile compatible. But I'm not sure if we
> stay binary-compatible (needs to be
> > tested).
> > >
> > > I wrote a Validate class this way for jgit-core
> [2] but also have to like this features in our
> > owns commons.lang.Validate if possible!
> > >
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > > [1] http://pastebin.com/m2cf887a9
> > >
> > > [2]
> >
> http://github.com/sonatype/JGit/blob/2ab3a576fa67145d6a9f66efd7437c52d567eb68/org.spearce.jgit/src/org/spearce/jgit/util/Validate.java
> > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> > 
> > 
> 
> 
> 
>       
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


      

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


Mime
View raw message