deadcode4j v2.0.0 released

deadcode4j v2.0.0 is out! It is available via Maven central, so it is conveniently available for your Maven project.

What's new?

Although version 2.0.0 adds only a few frameworks to its feature list, e.g. Jetty XML configuration and Spring Data custom repositories, changes "under the hood" were massive and allowed to eliminate two of the most common reasons for false positives: type erasure and constants inlining. Additionally, the custom analyzers are now much more powerful: they now recognize transitive implementation of an interface or a superclass. To keep configuration slick, unnecessary configuration (like ignoring classes that don't even exist) is recognized by deadcode4j and is requested to be removed from the configuration.
All changes are listed in the change log.

Major Release: Usage Statistics

The major release is due to two changes: the deprecated goal find-without-packaging was removed; but most importantly, deadcode4j now requests your permission to send some usage statistics. Those usage statistics will help me understand usage scenarios, project sizes, configuration usage etc. - allowing to improve deadcode4j furthermore. Sending statistics is completely transparent; it is optional and can be skipped permanently or on a per-usage basis.
Do you have an opinion on usage statistics? Do you find it invasive, or do you appreciate my intentions to improve by gathering feedback?

How to use

It's so simple: go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Looking for reference projects & users

Currently I'm using the big legacy application of my employer as a reference project. But I'm slowly running out of false positives, so my feature list is shrinking. That's why I'd love to analyze some more projects to get more feedback. So, if you know of an (open source) candidate I can analyze or if you are using deadcode4j for yourself and want something added or you have some nice ideas, please comment!

Here you can read how it all started.

Coveralls for Java, Travis & the Maven Invoker

The other day, a colleague of mine integrated deadcode4j with Coveralls.
I had looked at Coveralls before, but seeing it did not support Java, I quickly turned away. Fortunately, my colleague knew of a neat Maven Plugin that does the job: it simply sends a JaCoCo (or Cobertura or Saga) coverage report to Coveralls using their API.

Integration was pretty easy. Then again, I noticed some missing paths and worse coverage than on my local machine. It took me a considerable amount of time to track down the problem; also, I found no place describing the issue (let alone a solution). In case you have some issues with Maven running on Travis, you might want to read on.

Missing Coverage

To record the code coverage, I actually executed unit tests, integration tests and (as deadcode4j is a Maven Plugin) the Invoker Plugin. By comparing the coverage reported on Coveralls with my local results, I could narrow down my problems to the Invoker Plugin: coverage results from the invoker execution were not showing up at Coveralls. After endless trickery with the travis.yml file, I finally stumbled over the problem: Travis exports a MAVEN_OPTS variable just before Maven is executed (by the usage of /etc/mavenrc), thus effectively preventing it from being overwritten. As this is how the JaCoCo Maven Plugin records the Invoker's code coverage, it just couldn't enable code coverage for the Invoker.

Solution

There are two approaches to work around that issue, all coming down to adding something to your travis.yml file:

The sledgehammer method would be to remove the /etc/mavenrc file:

  before_install: sudo rm /etc/mavenrc

If you refrain from using sudo, you may skip the execution of /etc/mavenrc (note however, that this approach also skips the execution of ~/.mavenrc:

  before_install: export MAVEN_SKIP_RC=true

That's about it. Enjoy running your tests! ;)

About deadcode4j

deadcode4j is a Maven plugin which finds dead code. To use it, go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Here you can read how it all started.

dead code in Jetty

During today's coding session of our Scout IT Day (ImmobilienScout24's flavor of the FedEx or ShipIt Day), I spent some time analyzing the Jetty project.
It's been a bit cumbersome, as Jetty provides a bunch of classes whose usage is configurable (e.g. the RewriteHandler), so I ended up manually analyzing (i.e. figuring out what the class does) many classes. In the end, only a few classes of the org.eclipse.jetty.util package seem to be dead - if one could say so about classes from a near-public library.

Setup

To analyze Jetty, I used a yet unreleased version, but the current 1.5 release only produces 4 more false positives. Here's the plugin configuration I used:

<plugin>
  <groupId>de.is24.mavenplugins</groupId>
  <artifactId>deadcode4j-maven-plugin</artifactId>
  <version>1.5</version>
  <configuration>
    <modulesToSkip>
      <modulesToSkip>jetty-runner</modulesToSkip>
      <modulesToSkip>examples</modulesToSkip>
      <modulesToSkip>tests/test-webapps</modulesToSkip>
    </modulesToSkip>
  </configuration>
</plugin

I excluded jetty-runner because it unpacks all of Jetty's dependencies and thus classes from e.g. the JSP-API are analyzed and partly recognized as dead. Not what we want to know.
The other two modules define tests and other classes that are not recognized by deadcode4j (and intentionally so).

Results

I ended up with ~150 presumably dead classes out of ~2.000 - but as mentioned before, most of them are simply optional classes that some users probably use. Only candidates that I struggle with are:

• org.eclipse.jetty.start.Version: Parses a version string. Seems to me like an old "internal" class that is no longer used, hard to imagine that anyone outside of Jetty itself makes use of it.
• org.eclipse.jetty.util.HostMap: Maps hosts & domains to anything, provides a method to retrieve all entries for a host or it's parent domains. While this has its merits, the fact that it defines its own method to distinguish it from a regular HashMap, one would assume some Jetty code would use it (like e.g. the org.eclipse.jetty.util.IPAddressMap).
• org.eclipse.jetty.util.TreeTrie: Kind of Map, but with fuzzy getters. This seems so specific (and other flavors like e.g. ArrayTernaryTrie being used internally), it's hard to imagine usages outside of Jetty.

To remove this classes may be too rash (after all, those are public classes in a publicly accessible library), but it seems like they could easily be deprecated for now.
Good job, Jetty maintainers!

About deadcode4j

deadcode4j is a Maven plugin which finds dead code. To use it, go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Here you can read how it all started.

deadcode4j v1.5 released

deadcode4j v1.5 is out! It is available via Maven central, so it is conveniently available for your Maven project.

What's new?

Version 1.5 comes with a ton of new features, nearly doubling the analysis capabilities of deadcode4j: aspects (AOP); Axis & CXF endpoints; a lot of classes being specified in faces-config.xml files, Spring Web Flow XML files, and Apache Tiles XML definition files; Spring XML Namespace Handlers; Hibernate's GenericGenerator annotation is considered even more thoroughly; implementations of ServletContainerInitializer and Spring's flavor, WebApplicationInitializer - just to name the most spectacular. The full list can be found in the change log.

Given that list, if your project uses no other technologies than Spring, Hibernate, Axis, CXF, JAXB, Castor, JEE, JSF, Apache Tiles, Spring MVC or Spring Web Flow, deadcode4j won't report many false positives. With the customization possibilities deadcode4j provides (subclasses, implementations of an interface, annotations and XML parsing), you will be enabled to easily clean up your code base and get rid of classes that just aren't needed anymore.

How to use

It's so simple: go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Looking for reference projects & users

Currently I'm using the big legacy application of my employer as a reference project. But I'm slowly running out of false positives, so my feature list is shrinking. That's why I'd love to analyze some more projects to get more feedback. So, if you know of an (open source) candidate I can analyze or if you are using deadcode4j for yourself and want something added or you have some nice ideas, please comment!

Here you can read how it all started.

deadcode4j v1.4 released

deadcode4j v1.4 is out! It is available via Maven central, so it is conveniently available for your Maven project.

What's new?

Version 1.4 was all about customization, so that you can unleash the power of deadcode4j without waiting for the n^th feature to be added:

• Additionally to the annotations that can be configured, you can now define interfaces which, if implemented by a class, mark that code as being in use
• With annotations and interfaces, there's only one thing missing: superclasses - and they can be configured as well, thus marking subclasses as being in use
• As deadcode4j processes the whole reactor, there may be some example/testing modules which should not be considered - so now you can specify if a module shouldn't be part of the analysis

This should help you eliminate a good portion of the false positives being found by deadcode4j right now, helping you set up a configuration which recognizes dead code.
Nevertheless, v1.4 brings some more analysis features:

• Classes being listed in web.xml files as contextClass or contextInitializerClasses parameter for Spring's ContextLoader or FrameworkServlet are recognized as live code
• Hibernate Annotations processing:
• Classes referenced by the strategy parameter of a @GenericGenerator annotation are recognized as live code
• Classes referenced by the type parameter of a @Type annotation are recognized as live code
• Classes annotated with @TypeDef being referenced by a @Type annotation are recognized as live code
• package-info classes annotated with JAXB's @XmlSchema annotation are recognized as live code
• Classes being annotated with any of a bunch of JSF annotations are recognized as live code
• *Descriptor classes being generated by Castor are recognized as live code

How to use

It's so simple: go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Looking for reference projects & users

Currently I'm using the big legacy application of my employer as a reference project. But I'm slowly running out of false positives, so my feature list is shrinking. That's why I'd love to analyze some more projects to get more feedback. So, if you know of an (open source) candidate I can analyze or if you are using deadcode4j for yourself and want something added or you have some nice ideas, please comment!

Here you can read how it all started.

deadcode4j v1.3 released

I recently released deadcode4j v1.3. It is available via Maven central, so it is conveniently available for your Maven project.

What's new?

Two now analysis modes were added:

• Classes annotated with Spring annotations like @Component or @Repository (amongst others) are considered to be live code
• Classes annotated with JEE annotations like @ManagedBean, @Named or @StaticMetamodel are considered to be live code

Additionally, you can specify which annotations mark classes as live code, and configure a custom XML analysis such that an XML element's text content or an attribute is considered to be a class in use. This should help enormously to reduce the number of false positives being recognized.

How to use

It's so simple: go to the console, navigate to your Maven project, type
  mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find -Dmaven.test.skip=true
and see what it finds.

Hop on over to GitHub to learn more, browse the code, or contribute.

Looking for reference projects & users

Currently I'm using the big legacy application of my employer as a reference project. This is ok, as there are still some false positives, providing me with a feature list for a couple of more releases. However, I'd love to analyze some more projects to get even more feedback. So, if you know of an (open source) candidate I can analyze or if you are using deadcode4j for yourself and want something added or you have some nice ideas, please comment!