[committed] unnecessary string creation in log statements

dhdd said:

you can search all source files (e.g. with Eclipse) for the string

" +

  ;)

Thank you for the nice tip.  :)
I'll try but I think we can fix it when the inconsistencies are found.
Because sources are constantly added and changed, it can be inconsistent again at any time.
(And these logs doesn't affect the behavior of the engine at all)
If I have to fix all these inconsistency, I'll give up.  :cry:

log patch for Node


Index: src/com/jme/scene/Node.java
===================================================================
--- src/com/jme/scene/Node.java   (revision 4291)
+++ src/com/jme/scene/Node.java   (working copy)
@@ -161,11 +161,8 @@
                     children = Collections.synchronizedList(new ArrayList<Spatial>(1)); 
                 }
                 children.add(child);
-                if (logger.isLoggable(Level.INFO)) {
-                    logger.info("Child (" + child.getName()
-                            + ") attached to this" + " node (" + getName()
-                            + ")");
-                }
+                logger.log(Level.INFO, "Child ({0}) attached to this node ({1})",
+                            new String[] {child.getName(), getName()});
             }
         }
        
@@ -196,11 +193,8 @@
                     children = Collections.synchronizedList(new ArrayList<Spatial>(1)); 
                 }
                 children.add(index, child);
-                if (logger.isLoggable(Level.INFO)) {
-                    logger.info("Child (" + child.getName()
-                            + ") attached to this" + " node (" + getName()
-                            + ")");
-                }
+                logger.log(Level.INFO, "Child ({0}) attached to this node ({1})",
+                        new String[] {child.getName(), getName()});
             }
         }

mulova said:

If I have to fix all these inconsistency, I'll give up.  :'(


hehe, please don't, but you are right, a "fix on sight" policy will have to suffice.  :)

good work mulova :slight_smile:

dhdd said:

mulova said:

If I have to fix all these inconsistency, I'll give up.  :'(


hehe, please don't, but you are right, a "fix on sight" policy will have to suffice.  :)


I'm not the one who wants the refactor, but generally, discovery of code inconsistency doesn't have to be done on a "fix on sight" basis unless you are constrained to Windows with no Cygwin/MinGW.  The discoverer can be run nightly, for example, if the PC will be on, and if it has a job scheduling system, with a shell script of about 5 lines, starting with a cd and svn update.  If somebody wants to run this... the net work is a tiny fraction of repeated fix on slights... I can provide a sample shell script (and cron or at job if that's what you will use).

AFTERTHOUGHT:  This can also be set up on the Sourceforge shell server, assuming they haven't restricted things too much (they are always changing things at Sourceforge).  I set up similar SCM jobs in this way for 2 Sourceforge projects before.  Somebody needs to have shell privs for the project though.  I do realize that the Subversion repos is not hosted at Sourceforge, but that won't matter unless they filter incoming traffic... which they could do...  would be better if google had a shell service, but I have no idea about that.

DETAIL for Subversion experts:  I do know about server-side wrapper scripts, but (a) at least at Sourceforge, you can only choose from a few supplied scripts and cannot supply your own; and (b) too risky on a server that you don't directly manage, since an environment change on the server could break the script and cause all commits to be rejected.

That's good news. then I'll wait for someone to do this job.  XD

I'd say go ahead and commit your changes mulova.



Noone will take the time to set something like that up surely not for log statements.

If somebody has a Linux workstation that will be running at off-hours, or access to the Sourceforge or Google shell server, I can provide you with the scripts to automate, after I catch up on other things.  Just offering.  No problem if nobody wants the responsibility.


Core-Dump said:

I'd say go ahead and commit your changes mulova.

Noone will take the time to set something like that up surely not for log statements.

I’m not saying its a bad idea, i’m just saying, if you don’t do it yourself the chance is good that no one will :slight_smile:



If we start dong such scripts it would be a good idea to set them up in a hudson together with nigtly and a latest stable release builds.