We Keep Coding

Jar hell for missing classes folder when running ESRestTestCase

So I'm running into a Jar hell problem when trying to run individual integration tests, using -Dtest=, that runs as a ESRestTestCase (ESTestCase). The issue here seems to be that some elasticsearch classpath validation class requires target/classes to exist. However, this project is only for testing so that requirement doesn't make sense.
This happened with Elasticsearch 7.0.0 and Java 1.8.0.251. Not sure if this is a problem with later versions.
java.lang.RuntimeException: found jar hell in test classpath
at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:98)
at org.elasticsearch.test.ESTestCase.<clinit>(ESTestCase.java:229)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:623)
Caused by: java.nio.file.NoSuchFileException: <MY PROJECT FOLDER PATH HERE>/target/classes
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
at java.nio.file.Files.walkFileTree(Files.java:2662)
at java.nio.file.Files.walkFileTree(Files.java:2742)
at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:199)
at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:86)
at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:96)
... 4 more

At first I tried various methods for making sure the classes folder was still created. I ran into new problems that seemed fixed in later versions so I upgraded to Elasticsearch 7.6.2 (And lucene 8.4.0). Upgrading seemed to remove the need for the folder to exist but triggered other issues (similar to this). I worked around such issues with -Dtests.security.manager=false. Then I got thread leak issues which I "solved" by setting #ThreadLeakScope(ThreadLeakScope.Scope.NONE) on the test class.
Then finally it seemed to work when running maven in command line for individual tests. But when trying to run the maven task with debugger in Intellij the debugger does not seem to attach.
So I try to run it as JUnit templated test in Intellij. Here I get jar hell when running it but it works to debug. The jar hell was later solved by setting idea.no.launcher=true in idea.properties.
Alright, good enough for now. These workarounds are far from ideal but it works for my current purposes. A lot of things will change before moving into mainline anyway. And maybe this will help someone else. Hopefully I can post a better solution later.

Error parsing emitter LibGDX ParticleEffects

I am using LibGDX 1.9.8 and attempting to add ParticleEffects made with the ParticleEditor.
I try to load a new effect with:
torchFX.load(Gdx.files.internal("effects/torch.p"), Gdx.files.internal("effects"));
But I am getting the below error
Exception in thread "LWJGL Application" java.lang.RuntimeException: Error parsing emitter: torch
at com.badlogic.gdx.graphics.g2d.ParticleEmitter.load(ParticleEmitter.java:1160)
at com.badlogic.gdx.graphics.g2d.ParticleEmitter.<init>(ParticleEmitter.java:103)
at com.badlogic.gdx.graphics.g2d.ParticleEffect.newEmitter(ParticleEffect.java:227)
at com.badlogic.gdx.graphics.g2d.ParticleEffect.loadEmitters(ParticleEffect.java:173)
at com.badlogic.gdx.graphics.g2d.ParticleEffect.load(ParticleEffect.java:153)
at com.bbg.dc.AssetLoader.getTorchFX(AssetLoader.java:92)
at com.bbg.dc.scenes.GameScene.setupMap(GameScene.java:202)
at com.bbg.dc.scenes.GameScene.switchMap(GameScene.java:159)
at com.bbg.dc.scenes.GameScene.start(GameScene.java:139)
at com.bbg.dc.DCGame.changeScene(DCGame.java:160)
at com.bbg.dc.scenes.MainMenu.buttonPressed(MainMenu.java:33)
at com.bbg.dc.iface.Button.update(Button.java:98)
at com.bbg.dc.iface.Scene.update(Scene.java:180)
at com.bbg.dc.scenes.MainMenu.update(MainMenu.java:49)
at com.bbg.dc.DCGame.render(DCGame.java:129)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication.mainLoop(LwjglApplication.java:225)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:126)
Caused by: java.lang.IllegalArgumentException: No enum constant com.badlogic.gdx.graphics.g2d.ParticleEmitter.SpawnShape.false
at java.lang.Enum.valueOf(Enum.java:238)
at com.badlogic.gdx.graphics.g2d.ParticleEmitter$SpawnShape.valueOf(ParticleEmitter.java:1637)
at com.badlogic.gdx.graphics.g2d.ParticleEmitter$SpawnShapeValue.load(ParticleEmitter.java:1622)
at com.badlogic.gdx.graphics.g2d.ParticleEmitter.load(ParticleEmitter.java:1107)
... 16 more
I have already made sure to have the particle.png in the effects directory. I have tried it with my own custom particle effect as well as the ParticleEditor default. I have tried altering the SpawnShape to no avail. I have been coming to SO for answers for years and this is the first problem I couldn't solve by searching. I have also just updated all my jars to latest 1.9.8 and latest version of ParticleEditor. Any ideas?

I solved this by running ParticleEditor from the same gdx-tools.jar as my project uses. I assumed the runnable jar in the runnables folder in the libgdx repo was identical, but it is not. You must use the same tools.jar for both.

I had a very similar issue, looking at an older file which worked and a newer file I noticed there were a number of entries in the newer one which was not present in the working file.
Namely the line;
independent: false
Deleting all instances on this seemed to do the trick for me.
I assume it's an updated feature not present in the current stable version of libgdx (1.9.8 at the time of writing). It may be available in the nightly version.
Looks like a property that's been added to the tweens on each individual property.
It would be useful if the older builds of the tools were more easily accessible.

Run demo of JBullet in IntelliJ

Has anyone successfully run demo of JBullet in IntelliJ?
When I run the demo using the ant build script, i found a mistake like this :
C:\Users\halin_000\ProgrammingProjects\Java\CS351L\JBullet\build.xml:77:
java.lang.IllegalStateException: first parameter of Stack.alloc(Class)
must be constant (in class
com.bulletphysics.collision.dispatch.ConvexConcaveCollisionAlgorithm,
method processCollision)
How do you solve the problem?

I ran into the same issue today. I used to be able to build jbullet a few years ago and I had the source put under version control back then.
It turns out building with a Java 7 compiler (from jdk1.7.0_79) works fine while building with a Java 8 compiler (from jdk1.8.0_101) fails with the message the OP reported.
I suppose a more definitive solution would be to update the vecmath library to satisfy the higher standards of a Java 8 compiler, but in the meantime I have reverted my toolchain to a state where I can get going.
Update 2016-10-08 22h30 EDT
Not satisfied of reverting my toolchain to Java7, I have dwelved a bit deeper into this issue and traced it to JStackAlloc, not vecmath as I previously thought.
It would seem compiling with Java8 adds more instruction nodes to the bytecode where there was none before. Specifically, LineNumberNode and LabelNode are being added between LdcInsnNode and MethodInsnNode.
JStackAlloc is looking for the later two but is not expecting to find the extra two nodes. It is easy to fix the library to skip these extra nodes and carry its job despite their presence.
Starting from a maven'ized build of jbullet, here is the diff required to make it work again.
Note that the Javadoc build of this release seems to be broken. It can be disabled by commenting out the jar goal of the maven-javadoc-plugin in the pom.xml config file.

NoSuchMethodError with Camel RouteDefinition class

I am trying to debug a Java / Maven project with a lot of depencies on various libraries.
When I run it on a Linux server the program starts up fine, but when I try to run it in Eclipse it throws the following exception:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.camel.model.RouteDefinition.getErrorHandlerBuilder()Lorg/apache/camel/ErrorHandlerFactory;
at org.apache.camel.spring.spi.SpringTransactionPolicy.wrap(SpringTransactionPolicy.java:69)
at org.apache.camel.model.PolicyDefinition.createProcessor(PolicyDefinition.java:133)
at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:437)
at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:183)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:817)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:165)
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:697)
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:1654)
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1441)
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1338)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1316)
Now, I can see that the RouteDefinition class is in the camel-core-2.9.3,jar and I can see that this library is imported. So how come it doesn't see that method?
How do I go about debugging this?
Could I get info from the process running on the Linux server? For example can I get the list of Jars that are imported and the order in which they are imported?
Many thanks!

The error that you're getting is caused by Maven pulling in the wrong version. Try deleting all versions out of your local repo, add it explicitly to your pom, clean out all of your builds, pray to the eclipse gods, etc. If it still gives you the error, check your local repo to see which wrong versions it pulled in, figure out what depends on them, and add explicit ignores for them while keeping the explicit include.

AWS Java SDK Error - java.lang.NoSuchMethodError

I've seen this type of error over here for exceptions that are thrown by various classes, though I haven't found the right solution for mine just yet.
I'm trying to get AWS Java SDK work locally so I can write a test application that reads data from a Kinesis stream.
Problem is, when I run the init() static method I encounter the following error:
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.http.impl.conn.DefaultClientConnectionOperator.<init>
(Lorg/apache/http/conn/scheme/SchemeRegistry;Lorg/apache/http/conn/DnsResolver;)V
Now, this is not the first error I've been thrown. I've been thrown four or five exceptions prior to this one, and the solution to all of them was just importing some jar's into the project. e.g.:
apache-httpcomponents-httpclient.jar
com.fasterxml.jackson.databind.jar
commons-codec-1.9.jar / commons-codec-1.9-javadoc.jar / commons-codec-1.9-sources.jar
httpclient-4.2.jar
httpcore-4.0.1.jar
I've seen in other threads around here that it could be the version of the httpcore library, however I imported the latest one.
Any ideas how I can resolve this? I'm thinking about starting over, as my project seems to be a heap of imports I'm not sure I'll actually utilize. Furthermore, I can't debug the binary imports of the AWS SDK (or can't I?).
Cheers.

Problem solved, I gradually added the missing libraries to the project and when the apache httpclient jar should be version 4.0 or later, and without any previous version to contradict.
I imported httpclient-4.2.jar and it worked.
Other than that, I just solved the exception that followed by importing joda-time-2.4.jar and it's all up and running.