I'm building a PR [1] right now as a sort of "think-piece" to give us something
concrete to look at. I'm building it up out of ONLY things that Eclipse/javac
can determine are definitely impossible to execute or redundant or never used,
including:
- Private methods that are never used.
- Superi
+1 to removing dead code though what is "dead" is tricky. In arq and tdb
there was some but they included code that is a useful record (e.g.
features that didn't make it into SPARQL). I removed obvious junk.
Some is checking code that I'd like to leave.
I had a look - a regex of "if *\( *fals
On 07/05/15 13:35, Andy Seaborne wrote:
On 07/05/15 10:36, Dave Reynolds wrote:
Prior to the transition into Apache we made use of the domains
openjena.org and openjena.com.
These still exist and redirect to jena.apache.org.
The domains are up for renewal in the next couple of weeks. I am happ
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/57
Relying more on Guava impl for caching
The idea here is to simplify Jena's code by relying a little more on the
Guava implementation for caching.
You can merge this pull request into a Git repository by
[
https://issues.apache.org/jira/browse/JENA-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14533201#comment-14533201
]
ASF GitHub Bot commented on JENA-928:
-
Github user amiara514 commented on the pull reque
Github user amiara514 commented on the pull request:
https://github.com/apache/jena/pull/52#issuecomment-99979270
Hi,
with the last proposal :
1) It's now possible to set multilingual indexing via assembler
configuration file by defining the multilingual class and using it in t
I'd say just eliminate all of that dead code. Also any commented code as
well. We have a source control system, one can always look into the
history to get that stuff. Using a field just makes it worse IMO... it'll
never get removed if we do that.
-Stephen
On Thu, May 7, 2015 at 11:26 AM, A.
There are a goodly number of pieces (>150) of "dead code" in Jena, of the form:
org.apache.jena.mem.HashCommon:
void showkeys()
{
if (false)
{
System.err.print( ">> KEYS:" );
// some logging code
System.err.println();
Okay, that makes sense, although in some ways it seems more like a rationale
for keeping _an_ interface, rather than a rationale that Jena should have its
_own_ interface. But keeping Guava types from leaking through makes sense.
I will send a PR sometime soon with some Java 8 work in those Cach
On 07/05/15 10:36, Dave Reynolds wrote:
Prior to the transition into Apache we made use of the domains
openjena.org and openjena.com.
These still exist and redirect to jena.apache.org.
The domains are up for renewal in the next couple of weeks. I am happy
to renew them if people feel this would
On 06/05/15 22:30, A. Soroka wrote:
I've found another candidate for simplification (well, actually for
excision):
org.apache.jena.atlas.lib.cache contains several classes that
implement an interface org.apache.jena.atlas.lib.Cache. This
interface very closely resembles Guava's
com.google.common
Prior to the transition into Apache we made use of the domains
openjena.org and openjena.com.
These still exist and redirect to jena.apache.org.
The domains are up for renewal in the next couple of weeks. I am happy
to renew them if people feel this would be worthwhile, otherwise I'll
cancel the
12 matches
Mail list logo
