On Sat, 29 Mar 2003, Benjamin Simpson wrote:
> Adding servlet.jar to the build is a bad idea. In my experience, I
> have found that j2ee build dependencies can be resolved with a simple
> ${servletOrJ2ee.classpath} variable resolved in the developer maintained
> build.properties file. This would also be a great place to stick the
> developer's preferred logging configuration. Both dependencies I object
> to in the current env.
Well, I personally dislike customizing a build for my specific
installation, especially in a file that's held in CVS. If servlet.jar is
part of the source tree, it means I don't have to worry about my unique
configuration finding its way into CVS (a bad thing, indeed). Consider the
current situation, where Matt's JRun directory is referred to on MY
machine, which will never be infected with that crap.
Is there a slippery slope? You bet. Are we on it? Hmm, dunno.
> Following this rule, we don't have to keep the actual j2ee or servlet
> jars in the tree.
Except they're fairly standard and nonviral. One nice thing about
servlet.jar, in particular, is that it doesn't even imply any container
specifics. To me, that's good: it means that I don't have the potential to
bind in Orion things, because Orion doesn't factor into the build at all.
> This is a slippery slope of additions and bug fixes without direction.
> Or am I missing something?
Well, bug fixes need to be put in, regardless. Extant bugs are a bad
thing. Additions, now: they need to be tracked. Besides, servlet.jar is a
convenience thing, not a "bug fix" or "addition."
> While I am at it, could someone explain to me why the addition of
> features and dependencies is more important than fixing problems like
> this below?
Well, where's the addition of features or dependencies? We're already
dependent on the servlet API; the only thing I've done is made sure the
servlet API is available in a specific location, one that doesn't imply
use of any given container. So there's no addition dependency there. Nor
is there a feature change, unless "runs on 1.3" is a feature. I guess it
would be, but I'd consider it to be a pretty important one.
Going on with the problem you specify.. extra string creation is a big
deal, I guess, if it's causing you a lot of grief. I assume you've run the
code through a profiler, and noticed this as a huge problem, allocating
megabytes of memory and taking seconds to run, because at first glance,
*my* thought was "Gee, we are creating a lot of extra stuff there, and we
could make that a little better... but it works well enough. It's slow,
but barely noticably so."
I'm honestly not trying to be sarcastic here, but I think that the
performance of those two methods is not likely to be a huge time sink.
Chances are, over the lifetime of a project, we'd spend more time fixing
them than we would save by optimizing the code a bit. We all scratch the
itches we have. If this is an itch you notice, submit a patch and a test.
I can already see LOTS of places where we can refactor and optimize; this
is hardly the only unique case. We're all busy; refactoring the display
tag isn't really something I woke up and thought about; the performance
isn't bad enough for me to really care as long as it *works.* That's MY
situation. If yours is different, please be my guest and fix the code.
> /**
> * Replace character at given index with the same character to upper
> case
> *
> * @param oldString old string
> * @param index of replacement
> * @return String new string
> * @exception StringIndexOutOfBoundsException
> *
> **/
> public static String toUpperCaseAt( String oldString, int index )
> throws NullPointerException, StringIndexOutOfBoundsException
> {
> int length = oldString.length();
> String newString = "";
>
> if( index >= length || index < 0 ) {
> throw new StringIndexOutOfBoundsException(
> "Index " + index
> + " is out of bounds for string length " + length );
> }
>
> //get upper case replacement
> String upper = String.valueOf( oldString.charAt( index )
> ).toUpperCase();
>
> //avoid index out of bounds
> String paddedString = oldString + " ";
>
> //get reusable parts
> String beforeIndex = paddedString.substring( 0, index );
> String afterIndex = paddedString.substring( index + 1 );
>
> //generate new String - remove padding spaces
> newString = ( beforeIndex + upper + afterIndex ).substring( 0,
> length );
>
> return newString;
> }
>
>
> <<<<<<<<<<<<<<<<< Hmm. Looks like we like making new strings.
> >>>>>>>>>>>>>>>>>>>>>>
>
>
> /**
> * Replace character at given index with the same character to upper
> case
> * This utility was refactored from the StringUtils class in the
> * display taglibs project. The replaced code is commented out
> below to see the
> * changes that were made.
> *
> * @param oldString old string
> * @param index of replacement
> * @return String new string
> **/
> public static String toUpperCaseAt(final String oldString,
> final int index) {
> final int len = oldString == null ? -1 : oldString.length();
> if(len <= index) return "";
> final char [] chars = oldString.toCharArray();
> chars[index] = Character.toUpperCase(chars[index]);
> return String.valueOf(chars);
> }
>
> <<<<<<<<<<<<<<<<< Hmm. Looks better, but I am sure there is an even
> more efficient way to perform the simple task.. >>>>>>>>>>>>>>>>>>>>>>
>
> Through shared examples of how we have taken apart and put back together
> the .85 release of Ed Hill's Display Tag Library we will discover the
> best way to do the simple task of bringing back tabular data for the
> user. There should be more arguments about where to inject an Interface
> and less discussion about who is going to contribute a one off bug fix.
>
> I don't mean to sound angry, but wtf??? It's a Saturday. I want to
> contribute while my kids are napping. Where is this project going?
>
> Ben Simpson
>
>
---------------------------------------------------------
Joseph B. Ottinger [EMAIL PROTECTED]
http://enigmastation.com IT Consultant
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
