I've recently stumbled across a bunch of JDBC problems boiling down to
org.postgresql.util.PSQLException: This connection has been closed.
Found out that this is because of setting the socketTimeout connection parameter - jump to http://techblog.scout24.com to find out more...
deadcode4j v2.0.0 is out! It is available via Maven central, so it is conveniently available for your Maven project.
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.
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?
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.
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.
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.
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.
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! ;)
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.
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.
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.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.
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.
During today's coding session of our Scout IT Day (ImmobilienScout24's flavor of the FedEx or ShipIt Day), I spent some hours to clean & refactor the unit tests of the Analyzer implementations.
I'm pretty happy with the results: for example, have a look at the test of the ServletContainerInitializerAnalyzer. It now consists of only 37 lines instead of 56. What's more important: it's much more readable & understandable now (besides the fact that as a non-native, my English could certainly be improved).
With clean code, software craftsmanship at al. people started to write better code. Unfortunately, that was oftentimes only true for "real" code; test code was left at an awful decaying state. It's funny to note that not so long ago, developers being new to a team were only allowed to write test code, not production code. Whereas I think it's the other way around. When I was assigned to a new team last year - me having that funny role of an software architect, I am shuffled around every now & then to where "the important" things are happening -, I made the team focus on tests primarily. And I didn't shy away from implementing test code, the software architect I am.
And here's why: tests, representing the business requirements, are here to stay, while productive code changes with every feature and refactoring. And if your test code is crap, you end up changing twice, thrice, umpteen times more test than productive code. And because your test code is crap, it takes you twice, thrice, umpteen times longer to understand what you are doing. And because that darn test code is crap, you're doing twice, thrice, umpteen times more faults than with your productive code.
So after some TDD and increasing test coverage, I noticed some developers getting reluctant to writing tests - because they feel they their doing more harm than help ("I need to change the tests along with the implementation anyway, so what can they detect besides the fact that I changed the code?").
Now what? "How do I write better test code?" you ask?
I'm certainly no expert, but I bet if you embrace test code as "the real deal" and approach test code with your best clean code attitude, you'll find the answers. Name things correctly, extract common logic, use Test Data Builders, etc., you know - be a craftsman. You'll get there.
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 is out! It is available via Maven central, so it is conveniently available for your Maven project.
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.
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.
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 is out! It is available via Maven central, so it is conveniently available for your Maven project.
Version 1.4 was all about customization, so that you can unleash the power of deadcode4j without waiting for the nth feature to be added:
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:
web.xml files as contextClass or contextInitializerClasses parameter for Spring's ContextLoader or FrameworkServlet are recognized as live codestrategy parameter of a @GenericGenerator annotation are recognized as live codetype parameter of a @Type annotation are recognized as live code@TypeDef being referenced by a @Type annotation are recognized as live codepackage-info classes annotated with JAXB's @XmlSchema annotation are recognized as live code*Descriptor classes being generated by Castor are recognized as live code
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.
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.