It sounds to me like you're reinventing Spring here.
The initialization order is very tricky, yes. A better solution would be
to have a dependency manager (you could declare the dependencies using
annotations) for example, and then autodiscover the components from the
class path. XML is just doing manually stuff that should be done
automatically anyway.
/Janne
On Jul 20, 2013, at 16:18 , Ichiro Furusato <[email protected]>
wrote:
Well, what I'm doing right now is pretty drastic. I don't in the end know
what's going to happen to this but I continue to move forward.
As a progress report, I've so far begun to gradually replace some of the
managers with interfaces, built the EntityManager that acts like a
bootstrap loader and creates all of the managers from an XML
configuration
file, then provides Map-style access to them (so that all of the getter
methods in WikiEngine could be removed). Instantiation of managers is now
happening within the EntityManager rather than within the WikiEngine.
I've
managed to do the first five managers (in instantiation order), but I'm
noting that the order in which things are instantiated and initialised is
in the future going to get a bit tricky, so if everything fails my
fallback
is to let the WikiEngine request the managers from the EntityManager
using
the existing instantiation/initialisation order via local variables,
providing access only via the EntityManager once everything is up and
running.
Not sure that makes sense written down but my tests are passing.
Changing the coding convention to "Style C" is relatively easy within
Eclipse: just select the code you want formatted and choose
Source:Format,
then go in and make any minor adjustments. With all due respect, I wish I
agreed with your idea of a readable convention -- I frankly don't find
the
long-and-drawn-out vertical of the Avalon style easy to read at all since
even with a reasonable size screen it's about twice as many lines as the
Eclipse/Sun standard. But I likewise respect that each of us has norms
that
we've grown used to. I didn't bring the subject up and I think computers
telling us what to do (e.g. Sonar) is regrettable, but I would like this
resolved so I don't spend too much time formatting and reformatting the
code I'm working on. I've so far touched probably two dozen files and I
don't want to spend hours trying to match Style B. Getting to Style C
takes
seconds since (as I mentioned above) it's roughly the default in Eclipse.
And frankly, I'm not myself all *that* fussed about what the convention
is
but recognise that it's better to be consistent across a project. I'd
just
rather have this resolved.
This reminds me of a two line aphorism a friend and I wrote (each one
line)
on a post-it during a meeting:
Code is poetry
Machines don't care
With that in mind I'm going back to coding...
Ichiro
On Sat, Jul 20, 2013 at 11:28 PM, Janne Jalkanen
<[email protected]>wrote:
BTW, changing the coding convention also means that anyone maintaining
any
sort of a patch against the current codebase will need to do a complete
rebase. Which is why I would advise against doing anything so drastic
except during major releases (which can be expected to break backwards
compatibility anyway).
/Janne
On Jul 20, 2013, at 13:32 , Ichiro Furusato <[email protected]>
wrote:
Hi Janne,
I've looked around the Apache site and unfortunately can find no
ASF-wide
coding conventions. It seems that ASF has never had a consistent set of
conventions across its many projects, with some choosing an Avalon-like
style for braces to avoid the K&R style (with all other syntax
following
the Sun standard). Other projects adopted other styles. There are many
to
choose from: Ambler, Lea, ESA (yes, the European Space Agency). Given
no
one "standard" is without flaws in someone's eyes this is not entirely
surprising. While I don't like every bit of it, the one benefit of the
Sun
standard is that it is by far the most widely known and practiced, if
we
aren't too strict in interpretation.
I do note one thing clearly expressed on the JSPWikiCodingStandard
page:
no
one seemed remotely in agreement about what constitutes "increased
readability". It seems what one person thought readable others thought
not
so readable.
A point you made was that once anyone had checked code into the JSPWiki
project it was no longer the domain of the original programmer but
became
"common code". By the same token, code checked into the Apache JSPWiki
project is now the domain of the ASF. Since historically it seems that
each
ASF team has chosen its own coding conventions, developers should
therefore
follow whatever conventions are chosen for the project by the project
team,
which I guess is the question before us.
That is, unless someone from ASF has some guidance.
Ichiro
On Sat, Jul 20, 2013 at 6:47 PM, Janne Jalkanen <
[email protected]>wrote:
Reasoning for style "B", aka K&R is here:
http://ecyrd.com/JSPWiki/wiki/JSPWikiCodingStandard
I do believe Sun made a mistake going for not aligning the braces - my
experience is that keeping braces on the same line significantly
increases
code readability and works better in multi-line conditionals.
/Janne
On Jul 20, 2013, at 06:26 , Ichiro Furusato <
[email protected]>
wrote:
Hi,
I'd much prefer Style C as that's the "Sun standard", as you note
used
in
many Apache projects, and the default style of Eclipse's Format
command,
which means that it's easy to auto-format an existing file to match
the
Sun
standard. Style B is IMO a bit ridiculous -- it extends the logic of
a
class vertically across so many lines that it becomes actually hard
to
read
and the only benefit seems to be increasing the count of lines for
those
who think that's a benefit. But rather than be ambiguous about it,
I'd
suggest we simply reference the actual style of "Style B" in
JSPWiki's
documentation:
Code Conventions for the Java Programming Language
http://www.oracle.com/technetwork/java/codeconv-138413.html (home
page)
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html(web
TOC)
http://www.oracle.com/technetwork/java/codeconventions-150003.pdf(PDF)
I'm not sure where Style B came from in the JSPWiki project, as the
Sun
standard has been around for a very long time.
FWIW, all of the code for the Neocortext project (which uses JSPWiki
as a
component) is roughly in the Sun standard (without being anal about
it),
and I'd much prefer to not have to reformat the code for Style B in
order
to submit any portions of it, such as plugins, etc.
So while I don't have a vote, +1 for Style C.
Ichiro
On Sat, Jul 20, 2013 at 9:35 AM, Glen Mazza <[email protected]>
wrote:
Hi Team, the next Sonar complaint, and there's a significant 500 of
them
within JSPWiki, is that we're not using braces for single-line
if/while/for
loops. I know for CXF braces are always required, and I suspect the
majority of Apache projects today also disallow them, so the
requirement is
not unreasonable. Fixing them is not the problem, what *is* the
problem is
our older-fashioned bracing system, i.e., instead of switching from
this
Style A:
if (a > b)
c = 10;
else if (d > e)
f = 20;
to this (the bracing system JSPWiki presently uses):
Style B:
if (a > b)
{
c = 10;
}
else if (d > e)
{
f = 20;
}
I'd like to be doing this instead:
Style C:
if (a > b) {
c = 10;
} else if (d > e) {
f = 20;
}
I've checked five major open source projects -- Style C is all they
use:
CXF -
http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/http/**
src/main/java/org/apache/cxf/**transport/https/**
CertConstraintsFeature.java?**revision=828758&view=markup<
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/https/CertConstraintsFeature.java?revision=828758&view=markup
Camel -
http://svn.apache.org/viewvc/**camel/trunk/components/camel-**
atom/src/main/java/org/apache/**camel/component/atom/**
AtomUtils.java?revision=**1190212&view=markup<
http://svn.apache.org/viewvc/camel/trunk/components/camel-atom/src/main/java/org/apache/camel/component/atom/AtomUtils.java?revision=1190212&view=markup
Tomcat -
http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/**
catalina/filters/FilterBase.**java?revision=1189413&view=**markup<
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?revision=1189413&view=markup
Hadoop -
http://svn.apache.org/viewvc/**hadoop/common/trunk/hadoop-**
mapreduce-project/hadoop-**mapreduce-client/hadoop-**
mapreduce-client-common/src/**main/java/org/apache/hadoop/**mapred/**
LocalDistributedCacheManager.**java?revision=1466196&view=**markup<
http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-common/src/main/java/org/apache/hadoop/mapred/LocalDistributedCacheManager.java?revision=1466196&view=markup
Spring Framework:
https://github.com/**SpringSource/spring-framework/**
blob/master/spring-jdbc/src/**main/java/org/springframework/**
jdbc/object/SqlFunction.java<
https://github.com/SpringSource/spring-framework/blob/master/spring-jdbc/src/main/java/org/springframework/jdbc/object/SqlFunction.java
Style B might be OK for projects that still allow Style A, but it
makes
the code too bloated once Style A is disallowed. I don't think
we'll
be
able to attract many committers sticking with Style B anymore.
Basically,
to avoid the busywork of converting Style B to Style C, we'll allow
either
in our source code but with the expectation that more and more code
will be
adopting Style C as time moves on, how does that sound? (Or, do we
want to
continue with allowing Style A and Style B?--we're welcome to ignore
Sonar
on this.)
Regards,
Glen
