[prev in list] [next in list] [prev in thread] [next in thread]
List: sonar-user
Subject: Re: [sonar-user] RE: Sonar 3.7.1 : Java Ecosystem 1.3 to 1.4 - Complement
From: Alexander Lorenz <alexander.lorenz () tomtom ! com>
Date: 2013-10-30 15:36:03
Message-ID: 52712763.1080008 () tomtom ! com
[Download RAW message or body]
Hello,
also
S1192
should have a configurable threshold, like the old rule.
It seems to me that with a number of new rules, we now have less
flexibility/configuration options than before.
Cheers
LX
On 10/29/2013 04:54 PM, Alexander Lorenz wrote:
> Hello,
>
>
> concerning S1166, we have a lot of cases where developers do not log
> both exception and context, but just a context, the exception or the
> exception message.
> These cases cover expected exceptions like file not found or network
> exceptions, where the complete stack trace is not needed because we
> know what went wrong, or things like JBoss exceptions which can easily
> be 6 or more pages long, with most of it not really useful information.
>
> Those reasons seem justified, so shouldn't this rule be made more
> lenient (or configurable) to also accept:
>
> try { /* ... */ } catch (Exception e) { LOGGER.info(e); } // \
> Non-Compliant - context is required try { /* ... */ } catch (Exception e) { \
> LOGGER.info(e.getMessage()); } // Non-Compliant - exception is lost (only \
> message is preserved)
>
> Thanks
>
> Alex
>
>
> On 10/13/2013 03:07 PM, Freddy Mallet wrote:
> > Ticket created Alix to prevent logging an issue when todo is part of
> > word/identifier like "toDomain" :
> > http://jira.codehaus.org/browse/SONARJAVA-356
> >
> > Thanks for your feedback
> > Freddy
> >
> > -----
> > twitter.com/FreddyMallet <https://twitter.com/FreddyMallet>
> > SonarQube for Continuous Inspection
> >
> >
> > On Thu, Oct 10, 2013 at 6:46 PM, ALIX LOURME <alix.lourme@mpsa.com
> > <mailto:alix.lourme@mpsa.com>> wrote:
> >
> > Hi Freddy,
> >
> > _Synthesis_ : Perhaps one more ticket about TODO squid implementation
> >
> > --
> >
> > Thanks for quick response.
> >
> > */> squid:S1166 - Exception handlers should provide some context
> > and preserve the original exception/***
> >
> > You are right, best implementation (and the case of multiple
> > exception treatment after finally block is rare and not easy to
> > detect).
> >
> > *> common-java:DuplicatedBlocks - Duplicated blocks*
> >
> > Oops, sorry for question .. I'm still little newbie !
> >
> > */> squid:AssignmentInSubExpressionCheck - Assignments should not
> > be made from within sub-expressions/*
> >
> > */> squid:S106 - System.out and System.err should not be used as
> > loggers/*
> >
> > */> squid:TrailingCommentCheck - Comments should not be located
> > at the end of lines of code/*
> >
> > Thanks for tickets.
> >
> > */> squid:S1135 - TODO tags should be handled/*
> >
> > [point 1] The "squid:S1135" considers a javadoc comment of a
> > parameter spelled todoXX as a "TODO" task to comment ⦠but todo
> > prefix is not forbidden in a java variable ... => perhaps this
> > case is a bug
> >
> > [point 2] Sorry, it is my rule interpretation. I thought a "TODO"
> > with comment could be valid and not considered as violation ...
> > so it is OK (a todo must be realized, with or not comments, so it
> > is a violation).
> >
> > Best Regards.
> >
> > *De :*Freddy Mallet [mailto:freddy.mallet@gmail.com
> > <mailto:freddy.mallet@gmail.com>]
> > *Envoyé :* jeudi 10 octobre 2013 16:35
> > *Ã :* user
> > *Objet :* Re: [sonar-user] RE: Sonar 3.7.1 : Java Ecosystem 1.3
> > to 1.4 - Complement
> >
> > Hi Alexis,
> >
> > Thanks for this valuable feedback about new SonarQube Java rules.
> > See my comments below:
> >
> > My previous post outlined the rules were by default in 1.3
> > and not in 1.4 java ecosystem and some little differences
> > between squid implementation compared to previous
> > implementation (pmd, checkstyle).
> >
> > By definition there are some differences as our goal was not
> > "just" to migrate rules but to group and improve them as best as
> > possible. But of course, as any new implementations, there might
> > be some unexpected false-positives and that's why your feedback
> > matters.
> >
> > To continue the work of using 1.4 default java ecosystem and
> > transfer deprecated rules to squid, a more representative
> > project in (more than 10K loc) displays some differences
> > compared to java 1.3 default ecosystem (where it was âperfect').
> >
> > Rules with some (personal) remarks / code snipet coverage :
> >
> > ----------------------------------------------------------------------------------
> >
> > squid:S1166 - *Exception handlers should provide some context
> > and preserve the original exception* --> Next case not
> > covered (is it a really bad practice ?)
> >
> > try { ...
> >
> > } catch (VelocityException e) {
> >
> > throwable = e;
> >
> > } catch (IOException e) {
> >
> > throwable = e;
> >
> > } finally { ...
> >
> > }
> >
> > if (throwable != null) {
> >
> > logger.error("...", throwable);
> >
> > throw new MyException("...", throwable);
> >
> > }
> >
> > the question is here "how to factorize a piece of code between
> > several catch blocks ? ". In Java 7 this is no more an issue as
> > multiple Exception types can be caught by the same catch block.
> > In Java 6, I think the following design would be better and would
> > comply with the rule. Indeed with the current implementation
> > nothing prevents a developer from unexpectedly appendind a piece
> > of code just after the finally block and just before the
> > "if(throwable != null)" whereas this piece of code should never
> > be executed when an exception is thrown.
> >
> > try { ...
> >
> > } catch( VelocityException e) {
> >
> > error("yyy", e);
> >
> > } catch( IOException e ) {
> >
> > error("xxx", e);
> >
> > } finally {
> >
> > ...
> >
> > }
> >
> > public void error(String message, Exception e) {
> >
> > logger.error(message, e);
> >
> > throw new MyException(message, e);
> >
> > }
> >
> > -----------------------------------------------------------------------------------
> >
> > common-java:DuplicatedBlocks - *Duplicated blocks* --> OK but
> > not easy to correct ... indication of "1 duplicated blocks of
> > code" on package ... but no lines indicated, normal ?
> >
> > -----------------------------------------------------------------------------------
> >
> > To get this information you just need to switch to the
> > "Duplications" tab
> >
> > squid:AssignmentInSubExpressionCheck - *Assignments should
> > not be made from within sub-expressions* --> A little
> > intransigeant with classic process of BufferedReader file
> > parsing :
> >
> > BufferedReader br = new BufferedReader(...);
> >
> > String ligne = "";
> >
> > while ((ligne = br.readLine()) != null) {
> >
> > builder.append(ligne);
> >
> > builder.append("\n");
> >
> > }
> >
> > -----------------------------------------------------------------------------------
> >
> > Indeed, ticket created :
> > http://jira.codehaus.org/browse/SONARJAVA-346
> >
> > squid:S106 - *System.out and System.err should not be used as
> > loggers* --> Stream usage not covered
> >
> > /**
> >
> > * Constructor
> >
> > *
> >
> > * @param out stream to write output
> >
> > * @param err stream to write error
> >
> > */
> >
> > public MyClass(OutputStream out, OutputStream err) {
> >
> > ...
> >
> > }
> >
> > /**
> >
> > * Default Constructor
> >
> > */
> >
> > public MyClass() {
> >
> > this(System.out, System.err); <-- This case is really a
> > bad practice ?
> >
> > }
> >
> > -----------------------------------------------------------------------------------
> >
> > Indeed, ticket created http://jira.codehaus.org/browse/SONARJAVA-347
> >
> > squid:TrailingCommentCheck - *Comments should not be located
> > at the end of lines of code* --> Some interrogations on this
> > rare code :
> >
> > try {
> >
> > ...
> >
> > // CHECKSTYLE:OFF we need to return a failed status !!!
> >
> > } catch (Exception e) {// NOSONAR : we need to return a
> > failed status !!!
> >
> > // CHECKSTYLE:ON
> >
> > logger.error("Problem ...", e);
> >
> > ...
> >
> > }
> >
> > -----------------------------------------------------------------------------------
> >
> > Indeed ticket created : http://jira.codehaus.org/browse/SONARJAVA-348
> >
> > squid:S1135 - *TODO tags should be handled* --> 2 points
> >
> > 1) The javadoc parameters are considered :
> >
> > /**
> >
> > * ...
> >
> > *
> >
> > * @param toDomain
> >
> > * the domain on which to get the management module
> >
> > */
> >
> > void myMethod(String toDomain);
> >
> > 2) How to write a correct TODO ? these patterns are considered :
> >
> > // TODO - The case xxx must be implemented
> >
> > // TODO : The case xxx must be implemented
> >
> > // TODO-The case xxx must be implemented
> >
> > // TODO:The case xxx must be implemented
> >
> > Not sure to understand the issue Alexie, could you rephrase ?
> >
> > thanks
> >
> > Freddy
> >
> > ----------------------------------- For information, "New
> > rules" detected (in 1.4 by default, not in 1.3 by default)
> > but justified ---------------------------------------
> >
> > squid:S128 - Switch cases should end with an unconditional
> > break statement
> >
> > common-java:InsufficientBranchCoverage : Insufficient branch
> > coverage by unit tests --> justified, but many people will
> > grumble :-)
> >
> > squid:UndocumentedApi - Public types, methods and fields
> > (API) should be documented with Javadoc
> >
> > squid:S1171 - Non-static class initializers should not be used
> >
> > squid:S1118 - Utility classes should not have a public
> > constructor
> >
> > squid:S1163 - Exceptions should not be thrown in finally
> > blocks
> >
> > squid:CommentedOutCodeLine - Avoid commented-out
> > lines of code
> >
> > squid:S1132 - Strings literals should be placed on the left
> > side when checking for equality
> >
> > squid:HiddenFieldCheck - Local variables should not shadow
> > class fields (and algorithm is very performant !)
> >
> > squid:S1149 - Synchronized classes Vector, Hashtable and
> > StringBuffer should not be used
> >
> > squid:S1192 - String literals should not be duplicated
> >
> > squid:S1142 - Methods should not contain too many return
> > statements
> >
> > squid:S1141 - Try-catch blocks should not be nested
> >
> > -------------
> >
> > Available for more informations if needed.
> >
> > Best Regards.
> >
> > Alix Lourme
> >
> > *De :*ALIX LOURME - U171755
> > *Envoyé :* lundi 7 octobre 2013 12:55
> > *Ã :* user@sonar.codehaus.org <mailto:user@sonar.codehaus.org>
> > *Objet :* Sonar 3.7.1 : Java Ecosystem 1.3 to 1.4
> >
> > Hi,
> >
> > After migrate from java ecosystem 1.3 to 1.4, I have some
> > remarks about process and rules.
> >
> > Info : our strategy is to use "Sonar way" (considered as
> > default for many people, so "a good set of rules") as parent
> > of a "[my company] way" with some specific rules for respect
> > our historic.
> >
> > About the process, the only way having the 132 rules of Java
> > 1.4 in replacement of 113 rules of Java 1.3 is to backup them
> > from a "clean" installation (=> replace the content of
> > [sonar]/extensions/downloads/sonar-[ALL]-plugin-1.3.jar by
> > 1.4 equivalents) ; and reimport backup on existing instance.
> >
> > So a "reset to default" on "sonar way" could be a nice
> > feature, because the below procedure is not the most easiest
> > to follow updates on java ecosystem.
> >
> > About java ecosystem 1.4, there are some differences about
> > content and squid result compared to checkstyle/pmd.
> >
> > 1)*Javadoc*: The update from "checkstyle:JavadocMethodCheck"
> > to "squid:UndocumentedApi " rule doesn't check the javadoc
> > exception (allowMissingThrowsTags equivalent), even on public
> > elements. Using "squid:UndocumentedApi" is a major but
> > interessant change (public APIs concentration ... so having
> > a good documentation without to be intransigent on javadoc),
> > but this point about exception could be important.
> >
> > 2)*Magic Number*( « Checkstyle:MagicNumberCheck ») was by
> > default in 1.3, not 1.4
> >
> > 3)*Parameter Assignment*( «
> > checkstyle:ParameterAssignmentCheck ») was by default in 1.3,
> > not in 1.4
> >
> > 4)*Redundant Modifier*( « checkstyle:RedundantModifierCheck »)
> > was by default in 1.3, not in 1.4
> >
> > 5)*Nested Try Depth*: « squid:S1141 » : doesn't work on a
> > code that « checkstyle:NestedTryDepthCheck » found (code on
> > one line to save space : « public int test() {int i = 1;try
> > {try {try {try {i = 0;} finally {i = 0;}} finally {i = 0;}}
> > finally {i = 0;}} finally {i = 0;}return i;} »)
> >
> > 6)*Boolean expressions*: « squid: squid:S1125 » : doesn't
> > work on a code that «
> > checkstyle:SimplifyBooleanExpressionCheck » found (on [N]OR :
> > « public boolean test() {boolean b = false;if (b || true) {b
> > = false;}return b;} » ainsi que « public boolean test()
> > {boolean b = false;if (!false) {b = false;}return b;} »)
> >
> > 7)*Mutable Exception*: « squid:S1165 » : doesn't work on a
> > code that « checkstyle:MutableExceptionCheck » found : one «
> > private int i » in a class « public class
> > MutableExceptionError extends Exception { » (checkstyle use
> > regexp Exception|Error without extend verification, squid
> > seems more accurate and uses « extends Exception + Exception
> > suffix » ⦠more logical ⦠but is Exception suffix mandatory
> > in java to definite an exception ?)
> >
> > Thanks in advance.
> >
> > Best regards.
> >
> > Alix LOURME.
> >
> >
>
>
> --
> Alexander Lorenz | Test Engineer Traffic | TomTom Content Production Unit Berlin \
> |alexander.lorenz@tomtom.com | +49-30-756543-194 |www.tomtom.com
--
Alexander Lorenz | Test Engineer Traffic | TomTom Content Production Unit Berlin | \
alexander.lorenz@tomtom.com | +49-30-756543-194 | www.tomtom.com
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<br>
also<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
S1192<br>
<br>
should have a configurable threshold, like the old rule.<br>
It seems to me that with a number of new rules, we now have less
flexibility/configuration options than before.<br>
<br>
<br>
Cheers<br>
<br>
LX<br>
<br>
<br>
<br>
On 10/29/2013 04:54 PM, Alexander Lorenz wrote:
<blockquote cite="mid:526FDA3F.4060402@tomtom.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hello,<br>
<br>
<br>
concerning S1166, we have a lot of cases where developers do not
log both exception and context, but just a context, the exception
or the exception message.<br>
These cases cover expected exceptions like file not found or
network exceptions, where the complete stack trace is not needed
because we know what went wrong, or things like JBoss exceptions
which can easily be 6 or more pages long, with most of it not
really useful information.<br>
<br>
Those reasons seem justified, so shouldn't this rule be made more
lenient (or configurable) to also accept:<br>
<br>
<pre style="margin: 0px; padding: 0px 5px; font-family: monospace; line-height: \
11.111111640930176px; border: 1px dashed rgb(170, 170, 170); font-size: \
11.111111640930176px; color: rgb(17, 17, 17); font-style: normal; font-variant: \
normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: \
start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; background-color: rgb(239, 239, 239);">try { /* ... \
*/ } catch (Exception e) { LOGGER.info(e); } // Non-Compliant - \
context is required try { /* ... */ } catch (Exception e) { \
LOGGER.info(e.getMessage()); } // Non-Compliant - exception is lost (only message \
is preserved)</pre> <br>
<br>
Thanks<br>
<br>
Alex<br>
<br>
<br>
On 10/13/2013 03:07 PM, Freddy Mallet wrote:
<blockquote
cite="mid:CAPyGxihyyfPEP7_WrnV3tts0+Y_TzqrNXd65H83bAOUVXEawRQ@mail.gmail.com"
type="cite">
<div dir="ltr">Ticket created Alix <span class="" style="">to</span>
prevent logging an issue when <span class="" style="">todo</span>
<span class="" style="">is</span> part <span class=""
style="">of</span> word/identifier like "<span class=""
style="">toDomain</span>" : <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://">http://</a><span
class="" style="">jira</span>.<span class="" \
style="">codehaus</span>.<span
class="" style="">org</span>/browse/<span class="" \
style="">SONARJAVA</span>-356
<div> <br>
</div>
<div>Thanks for <span class="" style="">your</span> feedback </div>
<div>Freddy</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr">
<div><span
style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">-----</span></div>
<div><a moz-do-not-send="true"
href="https://twitter.com/FreddyMallet"
style="font-family:arial,sans-serif;background-color:rgb(255,255,255)"
target="_blank">twitter.com/FreddyMallet</a></div>
<div><span style="background-color:rgb(255,255,255)">SonarQube
for Continuous Inspection</span></div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">On Thu, Oct 10, 2013 at 6:46 PM, ALIX
LOURME <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:alix.lourme@mpsa.com" \
target="_blank">alix.lourme@mpsa.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="FR">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi
Freddy, </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span></p> <p class="MsoNormal"><u><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Synthesis</span></u><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> : Perhaps one more ticket about TODO
squid implementation</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span></p> <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span></p> <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks
for quick response.</span></p>
<div class="im">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span></p> <p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">> squid:S1166 - Exception
handlers should provide some context and
preserve the original exception</span></i></b><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"></span></b></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">You are right, best implementation
(and the case of multiple exception treatment
after finally block is rare and not easy to
detect).</span></p>
<div class="im">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">> common-java:DuplicatedBlocks
- Duplicated blocks</span></b></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Oops, sorry for question .. I'm still
little newbie !</span></p>
<div class="im">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">>
squid:AssignmentInSubExpressionCheck -
Assignments should not be made from within
sub-expressions</span></i></b></p>
</div>
<p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">> squid:S106 - System.out and
System.err should not be used as loggers</span></i></b></p>
<p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">> squid:TrailingCommentCheck -
Comments should not be located at the end of
lines of code</span></i></b></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Thanks for tickets.</span></p>
<div class="im">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><b><i><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">> squid:S1135 - TODO tags
should be handled</span></i></b></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">[point 1] The “squid:S1135” considers
a javadoc comment of a parameter spelled todoXX as
a "TODO" task to comment … but todo prefix is not
forbidden in a java variable ... => perhaps
this case is a bug</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">[point 2] Sorry, it is my rule
interpretation. I thought a "TODO" with comment
could be valid and not considered as violation ...
so it is OK (a todo must be realized, with or not
comments, so it is a violation).</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Best Regards.</span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">De \
:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Freddy Mallet [mailto:<a moz-do-not-send="true"
href="mailto:freddy.mallet@gmail.com"
target="_blank">freddy.mallet@gmail.com</a>] <br>
<b>Envoyé :</b> jeudi 10 octobre 2013 16:35<br>
<b>À :</b> user<br>
<b>Objet :</b> Re: [sonar-user] RE: Sonar 3.7.1 :
Java Ecosystem 1.3 to 1.4 - Complement</span></p>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Hi Alexis, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks for this valuable
feedback about new SonarQube Java rules. See
my comments below:</p>
</div>
<div>
<div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d">My previous
post outlined the rules were by
default in 1.3 and not in 1.4 java
ecosystem and some little
differences between squid
implementation compared to
previous implementation (pmd,
checkstyle).</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">By definition there
are some differences as our goal was not
"just" to migrate rules but to group and
improve them as best as possible. But of
course, as any new implementations,
there might be some unexpected
false-positives and that's why your
feedback matters. </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">To
continue the work of using 1.4
default java ecosystem and transfer
deprecated rules to squid, a more
representative project in (more than
10K loc) displays some differences
compared to java 1.3 default
ecosystem (where it was ‘perfect’).</span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Rules with
some (personal) remarks / code
snipet coverage :</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">----------------------------------------------------------------------------------</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1166
- <b>Exception handlers should
provide some context and preserve
the original exception</b> -->
Next case not covered (is it a
really bad practice ?)</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">try
{</span><span style="color:#1f497d">
...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}
catch (VelocityException e) {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
throwable = e;</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}
catch (IOException e) {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
throwable = e;</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}
finally {</span><span
style="color:#1f497d"> ...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">if
(throwable != null) {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
logger.error("...", throwable);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
throw new MyException("...",
throwable);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">the question is here
"how to factorize a piece of code
between several catch blocks ? ". In
Java 7 this is no more an issue as
multiple Exception types can be caught
by the same catch block. In Java 6, I
think the following design would be
better and would comply with the rule.
Indeed with the current implementation
nothing prevents a developer from
unexpectedly appendind a piece of code
just after the finally block and just
before the "if(throwable != null)"
whereas this piece of code should never
be executed when an exception is
thrown. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">try { ...</p>
</div>
<div>
<p class="MsoNormal">} catch(
VelocityException e) {</p>
</div>
<div>
<p class="MsoNormal"> error("yyy", e);</p>
</div>
<div>
<p class="MsoNormal">} catch( IOException
e ) {</p>
</div>
<div>
<p class="MsoNormal"> error("xxx", e);</p>
</div>
<div>
<p class="MsoNormal">} finally {</p>
</div>
<div>
<p class="MsoNormal"> ...</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">public void
error(String message, Exception e) {</p>
</div>
<div>
<p class="MsoNormal">
logger.error(message, e);</p>
</div>
<div>
<p class="MsoNormal"> throw new
MyException(message, e);</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------------------------------------------------------</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">common-java:DuplicatedBlocks
- <b>Duplicated blocks</b> -->
OK but not easy to correct ...
indication of "1 duplicated blocks
of code" on package ... but no
lines indicated, normal ?</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------------------------------------------------------</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">To get this
information you just need to switch to
the "Duplications" tab </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">squid:AssignmentInSubExpressionCheck
- <b>Assignments should not be made
from within sub-expressions</b>
--> A little intransigeant with
classic process of BufferedReader
file parsing :</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">BufferedReader
br = new BufferedReader(...);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">String
ligne = "";</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">while
((ligne = br.readLine()) != null) {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> \
builder.append(ligne);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> \
builder.append("\n");</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------------------------------------------------------</span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Indeed, ticket
created : <a moz-do-not-send="true"
\
href="http://jira.codehaus.org/browse/SONARJAVA-346"
\
target="_blank">http://jira.codehaus.org/browse/SONARJAVA-346</a></p> </div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S106
- <b>System.out and System.err
should not be used as loggers</b>
--> Stream usage not covered</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> \
</span><span style="color:#1f497d">/**</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
Constructor</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> *
@param out stream to write output</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
@param err stream to write error</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">*/</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">public
MyClass(OutputStream out,
OutputStream err) {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">/**</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
Default Constructor</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">*/</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">public
MyClass() {</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
this(System.out,
System.err); <-- This
case is really a bad practice ?</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------------------------------------------------------</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Indeed, ticket
created <a moz-do-not-send="true"
\
href="http://jira.codehaus.org/browse/SONARJAVA-347" target="_blank">
http://jira.codehaus.org/browse/SONARJAVA-347</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">squid:TrailingCommentCheck
- <b>Comments should not be
located at the end of lines of
code</b> --> Some
interrogations on this rare code :</span><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">try
{</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
// CHECKSTYLE:OFF we need to
return a failed status !!!</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}
catch (Exception e) {// NOSONAR :
we need to return a failed status
!!!</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
// CHECKSTYLE:ON</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
logger.error("Problem ...", e);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">
...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">}</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------------------------------------------------------</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Indeed ticket created
: <a moz-do-not-send="true"
\
href="http://jira.codehaus.org/browse/SONARJAVA-348" target="_blank">
http://jira.codehaus.org/browse/SONARJAVA-348</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1135
- <b>TODO tags should be handled</b>
--> 2 points</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">1)
The javadoc parameters are
considered :</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">/**</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
...</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> *
@param toDomain</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">*
the domain on which to get the
management module</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">*/</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">void
myMethod(String toDomain);</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">2)
How to write a correct TODO ?
these patterns are considered :</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">//
TODO - The case xxx must be
implemented</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">//
TODO : The case xxx must be
implemented</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">//
TODO-The case xxx must be
implemented</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">//
TODO:The case xxx must be
implemented</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Not sure to
understand the issue Alexie, could you
rephrase ?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">thanks</p>
</div>
<div>
<p class="MsoNormal">Freddy </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-----------------------------------
For information, "New rules"
detected (in 1.4 by default, not
in 1.3 by default) but justified
\
---------------------------------------</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S128
- Switch cases should end with an
unconditional break statement</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">common-java:InsufficientBranchCoverage
: Insufficient branch coverage by
unit tests --> justified, but
many people will grumble :-)</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">squid:UndocumentedApi
- Public types, methods and fields
(API) should be documented with
Javadoc</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1171
- Non-static class initializers
should not be used</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1118
- Utility classes should not have
a public constructor</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1163
- Exceptions should not be
thrown in finally blocks</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">squid:CommentedOutCodeLine
- Avoid commented-out
lines of code</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1132
- Strings literals should be
placed on the left side when
checking for equality</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">squid:HiddenFieldCheck
- Local variables should not
shadow class fields (and algorithm
is very performant !) </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1149
- Synchronized classes Vector,
Hashtable and StringBuffer should
not be used</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1192
- String literals should not be
duplicated</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1142
- Methods should not contain too
many return statements</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">squid:S1141
- Try-catch blocks should not be
nested</span></p>
<p class="MsoNormal"><span
style="color:#1f497d" \
lang="EN-US">-------------</span></p> <p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d" lang="EN-US">Available
for more informations if needed.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Best
Regards.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Alix Lourme</span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df 1.0pt;padding:3.0pt 0cm
0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">De \
:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
ALIX LOURME - U171755 <br>
<b>Envoyé :</b> lundi 7
octobre 2013 12:55<br>
<b>À :</b> <a
moz-do-not-send="true"
href="mailto:user@sonar.codehaus.org"
\
target="_blank">user@sonar.codehaus.org</a><br> <b>Objet :</b> Sonar 3.7.1 :
Java Ecosystem 1.3 to 1.4</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi, </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
lang="EN-US">After migrate from
java ecosystem 1.3 to 1.4, I have
some remarks about process and
rules.</span></p>
<p class="MsoNormal"><span
lang="EN-US">Info : our strategy
is to use "Sonar way" (considered
as default for many people, so "a
good set of rules") as parent of a
"[my company] way" with some
specific rules for respect our
historic.</span></p>
<p class="MsoNormal"><span
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
lang="EN-US">About the process,
the only way having the 132 rules
of Java 1.4 in replacement of 113
rules of Java 1.3 is to backup
them from a "clean" installation
(=> replace the content of
\
[sonar]/extensions/downloads/sonar-[ALL]-plugin-1.3.jar by 1.4 equivalents) ; and \
reimport
backup on existing instance.</span></p>
<p class="MsoNormal"><span
lang="EN-US">So a “reset to
default” on “sonar way” could be a
nice feature, because the below
procedure is not the most easiest
to follow updates on java
ecosystem.</span></p>
<p class="MsoNormal"><span
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
lang="EN-US">About java ecosystem
1.4, there are some differences
about content and squid result
compared to checkstyle/pmd.</span></p>
<p><span lang="EN-US">1)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Javadoc</span></b><span
lang="EN-US"> : The update from
“checkstyle:JavadocMethodCheck” to
“squid:UndocumentedApi “ rule
doesn’t check the javadoc
exception (allowMissingThrowsTags
equivalent), even on public
elements. Using
"squid:UndocumentedApi" is a major
but interessant change (public
APIs concentration ... so having
a good documentation without to be
intransigent on javadoc), but this
point about exception could be
important.</span></p>
<p><span lang="EN-US">2)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Magic Number</span></b><span
lang="EN-US"> («
Checkstyle:MagicNumberCheck ») was
by default in 1.3, not 1.4</span></p>
<p><span lang="EN-US">3)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Parameter
Assignment</span></b><span
lang="EN-US"> («
checkstyle:ParameterAssignmentCheck
») was by default in 1.3, not in
1.4</span></p>
<p><span lang="EN-US">4)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Redundant \
Modifier</span></b><span lang="EN-US"> («
checkstyle:RedundantModifierCheck
») was by default in 1.3, not in
1.4</span></p>
<p><span lang="EN-US">5)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Nested Try Depth</span></b><span
lang="EN-US"> : « squid:S1141 » :
doesn’t work on a code that «
checkstyle:NestedTryDepthCheck »
found (code on one line to save
space : « public int test() {int i
= 1;try {try {try {try {i = 0;}
finally {i = 0;}} finally {i =
0;}} finally {i = 0;}} finally {i
= 0;}return i;} »)</span></p>
<p><span lang="EN-US">6)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Boolean \
expressions</span></b><span lang="EN-US"> : « squid:
squid:S1125 » : doesn’t work on a
code that «
checkstyle:SimplifyBooleanExpressionCheck
» found (on [N]OR : « public
boolean test() {boolean b =
false;if (b || true) {b =
false;}return b;} » ainsi que «
public boolean test() {boolean b =
false;if (!false) {b =
false;}return b;} »)</span></p>
<p><span lang="EN-US">7)</span><span
style="font-size:7.0pt"
lang="EN-US"> </span> <b><span
lang="EN-US">Mutable \
Exception</span></b><span lang="EN-US"> : « squid:S1165 » :
doesn’t work on a code that «
checkstyle:MutableExceptionCheck »
found : one « private int i » in a
class « public class
MutableExceptionError extends
Exception { » (checkstyle use
regexp Exception|Error without
extend verification, squid seems
more accurate and uses « extends
Exception + Exception suffix » …
more logical … but is Exception
suffix mandatory in java to
definite an exception ?)</span></p>
<p class="MsoNormal"><span
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
lang="EN-US">Thanks in advance.</span></p>
<p class="MsoNormal"><span
lang="EN-US">Best regards.</span></p>
<p class="MsoNormal"><span
style="color:#888888" lang="EN-US"> \
</span><span style="color:#888888"></span></p>
<p class="MsoNormal"><span
style="color:#888888" lang="EN-US">Alix
LOURME.</span><span
style="color:#888888"></span></p>
<p class="MsoNormal"><span
style="color:#888888" lang="EN-US"> \
</span><span style="color:#888888"></span></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Alexander Lorenz | Test Engineer Traffic | TomTom Content Production Unit Berlin | <a \
moz-do-not-send="true" class="moz-txt-link-abbreviated" \
href="mailto:alexander.lorenz@tomtom.com">alexander.lorenz@tomtom.com</a> | \
+49-30-756543-194 | <a moz-do-not-send="true" class="moz-txt-link-abbreviated" \
href="http://www.tomtom.com">www.tomtom.com</a> </pre> </blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Alexander Lorenz | Test Engineer Traffic | TomTom Content Production Unit Berlin | <a \
class="moz-txt-link-abbreviated" \
href="mailto:alexander.lorenz@tomtom.com">alexander.lorenz@tomtom.com</a> | \
+49-30-756543-194 | <a class="moz-txt-link-abbreviated" \
href="http://www.tomtom.com">www.tomtom.com</a> </pre> </body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic