ConcurrentHashMap bug compiling on Java 8 for Java 7

It's been a long couple of months, but I'm back with another quirky discovery.

TL;DR - we changed all declarations of ConcurrentHashMap to Map.

The current project has a number of components. Some are to be deployed on a Java 7 runtime, others make use of newer capabilities on a Java 8 runtime. While trying to streamline the build process using Jenkins, this issue came up while I was switching over from Java 7 to 8. We'd normally assume that it'd suffice for Maven to build with the specific major version in mind using maven.compiler.source and maven.compiler.target configured either in the POM or over the command line. Despite these additions, the runtime would still complain of the following error somewhere in our codes:

java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;

A bit of searching turned up this post that explained

Notably the Java 1.7 ConcurrentHashMap#keySet() returns a Set<K> while the 1.8 ConcurrentHashMap#keySet() returns a ConcurrentHashMap.KeySetView<K,V>.

The OP then proceeded to suggested to simply edit the declaration of the ConcurrentHashMap to Map as a workaround.

Other solutions I found mentioned

1. configuring the -bootclasspath of the Maven build path to point to the rt.jar of the older JDK;
2. setting up a separate Jenkins/Maven for both halves of the project targetting different Java versions;

Both solutions are not feasible essentially because besides the fact that I'm unwilling to break up the Jenkins for the components using Java 7 and 8 respectively, such a differentiation would eventually get lost in translation, and anybody on the team that tries building similarly on their own (using any combination of JDK/Maven/IDE) may still encounter the same problem unwittingly, thereby costing even more man-hours to investigate and fix.

Editing the declaration would still seem less painful in the long run.

Digging further turned up a bug report which was closed as "Not an issue". The workaround suggested was not exactly helpful, compared to the first article I'd located, but apparently it was related to JSR166.

XMLHttpRequest fails on Internet Explorer 11 with "Access is denied"

Steps to reproduce:

1. Open Internet Explorer 11
2. Access "google.com"
3. Browser should redirect to "https://www.google.com"
4. Load Developer Console
5. Enter this line into the console
1. new XMLHttpRequest().open("GET", "http://www.google.com", true)
6. Console returns "Access is denied."
7. Enter this line into the console
1. new XMLHttpRequest().open("GET", "https://www.google.com", true)
8. Console returns "undefined"

When I first encountered the problem, what I found from here was this

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://localhost/', true); // This line will trigger an error
xhr.send();

 
What I didn't notice (until much later, now) on the very same page was this

In addition to the trusted site requirement I found that the problem was not fixed until I used the same protocol for the request as my origin, e.g. my test site was hosted on a https but failed with any destination using http (without the s).
This only applies to IE, Chrome just politely logs a warning in the debug console and doesn't fail.

Which led me to finding this which mentioned

Requests must be targeted to the same scheme as the hosting page
This restriction means that if your AJAX page is at http://example.com, then your target URL must also begin with HTTP. Similarly, if your AJAX page is at https://example.com, then your target URL must also begin with HTTPS.

This was a pain in my butt for the past few weeks now. It didn't have anything to do with the hardened workstation, whitelisting of URLs, or firewall configuration. The "Acces is denied" could have been a little bit more helpful with clues. It wouldn't show up in development, until you start deploying your codes into staging or production environments that stuff like SSL starts getting in the way with this kind of issues.

I'd been swamped with working on something massive for the past half a year. It hasn't been easy at all with the long drawn marathon of development work that I've been involved in. But I still think that computers are easier to understand than humans.

MySQL intermittent disconnects

Something happened. I'm not sure what. I didn't think much of it in the beginning, and for the previous few days, assumed that the exceptions being thrown out were because of bug in my codes. I was wrong.

The main problem revealed itself as a message of "SQL Error: 0, SQLState: 08S01- SqlExceptionHelper:144 - Communications link failure", which doesn't really say much.

Upon closer inspection, I realised that, even without the application running, my connection to the database over TOAD was failing. It was failing especially when I mouseover a specific table. Bad news. It was useless to run mysqlcheck because the connection would kill itself the same.

Extra parameters for autoReconnect didn't work too. Obviously, because the table was corrupt. There was no easy way to recovering it. Fortunately, as it was an ARCHIVE table, I made the decision to drop the table entirely, and recreate it anew. And that put me back on track... to fixing other bugs.