JIRA is sensitive to the order JARs are loaded from WEB-INF/lib

I'm currently using Jira to test Apache Tomcat 8. I know Tomcat 8 isn't a supported platform and the ASF isn't looking to run on Tomcat 8 in production (yet) but I have discovered a bug in Jira that will occur on Tomcat 8 and could occur on earlier Tomcat versions as well.
Jira ships classes from the package com.atlassian.jira.web.util in three places:

• /WEB-INF/classes
• /WEB-INF/lib/jira-api-6.1.2.jar
• /WEB-INF/lib/jira-screenshot-applet-6.1.2.jar

jira-screenshot-applet-6.1.2.jar is a signed JAR.

The Servlet specification defines that classes are always loaded from /WEB-INF/classes in preference to /WEB-INF/lib
The Servlet specification defines no priority order if the same class exists in multiple JARs in /WEB-INF/lib
Tomcat's web application class loader extends URLClassLoader which requires that all classes in a package must be consistently signed. That means if any class is signed, they must all be signed.
The problem occurs if the application server opts to load classes from jira-screenshot-applet-6.1.2.jar before jira-api-6.1.2.jar. The sequence of events is:

1. Classes in the com.atlassian.jira.web.util package are loaded from /WEB-INF/classes. These are unsigned.
2. An attempt is made to load FileNameCharacterCheckerUtil from that package
3. It is not present in /WEB-INF/classes so the JARs in /WEB-INF/lib are searched
4. The class is found in jira-screenshot-applet-6.1.2.jar. This class is signed.
5. Because classes in the same package have different signatures (some are unsigned, some are signed) a SecurityException is thrown, FileNameCharacterCheckerUtil fails to load and Jira fails to start.

I am currently working around this by ensuring that JARs are prioritised in an order that avoids this problem. However, Jira should not be relying on a priority order for JARs in /WEB-INF/lib
Based on the name, jira-screenshot-applet-6.1.2.jar might not even be required on the server side and could be moved to somewhere else under /WEB-INF. If it is required server side, then the simplest solution may be to sign all the Jira JARs.