Interesting Links, 22 January 2016

  • Every so often you need to see exactly what headers your HTTP-based application is working with. One way to look at the HTTP headers is to use an HTTP proxy: possibilities in this space include Fiddler, Charles Proxy, and Paros Proxy (with Paros’ website being the Sourceforge project site, which isn’t very confidence-inspiring). There are certainly others (feel free to send them to me, if you’ve used one you like!). You can also use Wireshark if you need to examine all network traffic, but for HTTP Wireshark’s a bit of overkill.
  • Picking correct Java executors for background tasks, by ZeroTurnaround (makers of JRebel), goes into how (and why) you would choose specific Executors. Good reading, spoken as one who more or less uses Executors.newFixedThreadPool(int) by default.
  • Use JUnit’s expected exceptions sparingly, from the JOOQ blog, talks about a feature I love from TestNG: the ability to expect exceptions from a test, as opposed to a try/catch block that uses fail() to fail the test if an exception isn’t thrown. The JOOQ people argue against using expected exceptions, and if you’re using JUnit, they’re right. TestNG, of course, has a better alternative as usual.
  • Auditing with JPA, Hibernate, and Spring Data JPA discusses writing audit data with basic JPA (which looks like a pain, relying on JPA lifecycle events) and both Hibernate Envers and Spring Data JPA. Spring Data JPA and JPA have difficulty auditing removals; Spring Data JPA has integration with Spring Security; Hibernate Envers is probably the least intrusive, but doesn’t have Spring Security integration.

Interesting Links, 20 Jan 2016

Sorry for the change of date format, folks. Some interesting links that came up include:

  • Don’t tell me what to make, tell me how to make it, by David Whiting, talks about using Java 8’s Supplier to help clean up construction of objects. Actually pretty useful stuff – it’s a common pattern to use no-argument constructors with mutable objects, and Supplier<t> might help us use immutable objects more often.
  • Arrays of Wisdom of the Ancients, by Alexei Shipilev, takes on the question of Collection.toArray(new T[0]) or Collection.toArray(new T[size]) in a long, well-written (and well-reasoned) post. It takes a long time to get to the point (Collection.toArray(new T[0]) wins, and has for “five years now”) but it also walks through the reasoning for the conclusion, and is fascinating reading.
  • The Java Security Manager: Why and How, by Nicolas Fränkel, shows a use of reflection to change a reference to a Character to a reference to a String and talks a bit about how to set up your security manager to be useful in addressing potentially malicious code.
  • Testing persistence with Arquillian on TomEE describes an end-to-end test for persistence with Arquillian. This is different from an embedded unit test for persistence in that Arquillian can actually start up an application server (TomEE in this case) and run the test there – which serves as a better integration test than a custom persistence configuration for the testing scope.
  • Neo4J published Graph Databases for Beginners: ACID vs. BASE Explained, explaining the two consistency models for transactions typically found in storage systems. ACID is typically trumpeted as a strength for relational databases, and stands for “Atomic, Consistent, Isolated, and Durable” transactions, and BASE stands for “Basic Availability, Soft-State, and Eventually Consistent” transactions. BASE is a strength of NoSQL datastores.
  • Jihed Amine Maaref posted Setup a docker environment for Liferay with MySQL inside a VirtualBox VM, which walks through a Docker configuration. It’s not so much that Liferay (an open source portal) and MySQL are fascinating (although they’re useful, I guess, especially Liferay), but the walkthrough is a good read, including explanations of how and why along the way.
  • ByteBuddy 1.0 has been released. ByteBuddy is a code generation library for Java – which can be used to build mocks, interceptors, or just plain classes out of thin air. Cheesy name and logo, but it seems worthwhile.

If you have interesting links that you’ve run across, please send them my way! It’s worth noting that Petri Kainulainen noted some of the same links as being interesting – check out Petri’s stuff for more focus on testing.

Some interesting links for and from ##java, Jan 15 2016

Some links relevant to Java, as of Jan 15 2016:

  • A git-flow cheatsheet. git-flow is a set of command-line scripts that implement Vincent Driessen‘s branching model for git projects, such as commands to complete feature requests, and the like.
  • Yahoo has released a giant dataset for machine learning.
  • jQuery has reached 3.0 beta. jQuery may not be the framework du jour for implementing a Javascript front end for Java web applications (Angular.js is, based on anecdata), but it’s still relevant. Lots of little changes, but one big one is that IE 6-8 support is being dropped. Die, Internet Exploder. Die.
  • Azul Systems has published “Four Reasons why Java is still #1“. In short, they are:
    • Practicality
    • Backwards Compatibility
    • Scalability/Performance/Reliability
    • Freshness, largely centering around all of the changes introduced in Java 8.
  • The Hibernate blog published “JPA test case templates“, documenting a set of templates (go figure) to help replicate bugs in tests. Templates exist for the native Hibernate APIs and, obviously, JPA as well. This would be useful for all kinds of test cases – if you have a problem with JPA or Hibernate, consider using one of these to show the problem, even if you’re not using Hibernate – you should be able to change the JPA provider fairly easily if you’re avoiding Hibernate.
  • A set of Java EE 7 sample projects built by the “WASdev” — whom I don’t know, but it looks like they’re the people who gave us Liberty – an Java EE 7 application server built with technology from IBM. Seems like useful stuff, though, and if it’s written properly it’s portable to other Java EE 7 containers.

Using karma on ##java

Ah, karma:

me> ~karma
javabot> All living beings have actions (karma) as their own,
         their inheritance, their congenital cause, their
         kinsman, their refuge. It is karma that differentiates
         beings into low and high states.
me> ... what?

Karma is normally a way of referring to the kind of person you are. It’s the sum of your actions in Hinduism and Buddhism.
IRC isn’t Hinduism or Buddhism, but karma in ##java is a way of showing what people think of you; positive karma (and lots of it) means you do a lot of good things, and negative karma (and lots of that) show that people don’t care for you much.
In ##java, there are a few operations related to karma. You can:

  • Add or subtract karma.
  • Query for karma.
  • Complain about there being no third point.

Adding or subtracting karma

The grammar for changing karma is pretty simple:

~ TARGET ( ++ | -- ) COMMENT

Thus, you might see:

someone> ~ eclipse -- for never working the way I want it to

This means that the user someone is decrementing Eclipse’ karma, which – given Eclipse’ karma of -673 as of this writing – happens a lot.
The text that follows the operation (the ++ or --) isn’t significant – it’s just a way to allow people to say why they’re changing karma, without the burden of an extra line.
There are a few problems with the syntax: note that changing C++’ karma is rather hard, because it looks like an increment of C’s karma…

Note that you can’t positively affect your own karma! Doing so is lame, and attempting to do so lowers your karma… let others sing your praises.

Querying for karma

The grammar for querying karma is also simple:

~ karma TARGET

This will tell you what TARGET‘s present karma score is, much as you’d expect. You can tell if nobody’s ever tried to change something’s karma, based on whether the score is 0 or “neutral” – neutral karma means there are no karma changes for the subject of the query.


Javabot is, of course, open source; if you have suggestions or improvements, feel free to contribute. File issues! Fork the project and submit pull requests; most of the code in Javabot is fairly simple, and we all benefit when things in the bot get smarter.