awaitility / awaitility Goto Github PK

https://joel-costigliola.github.io/assertj/

What steps will reproduce the problem?
1. Write an assertion that checks objects/list of objects which do not have a 
toString() method implemented
2. Have the assertion condition fail with a timeout

What is the expected output? What do you see instead?
The original mismatch description is not preserved in the message of the 
ConditionTimeoutException, the second part of the message ("but was ...") just 
contains the return value of toString() 

What version of the product are you using? On what operating system?
awaitility 1.6.3 on Ubuntu 14.04 LTS x64, Java 1.8.0_40

Please provide any additional information below.

The code to display a more descriptive message is actually present in the code 
but commented out:
https://github.com/jayway/awaitility/blob/4e9a036ef9bada9cba9219875e0be5e8fc4c83
98/awaitility/src/main/java/com/jayway/awaitility/core/AbstractHamcrestCondition
.java#L63-L64

The reason we do not have toString() on our objects is that in most cases it 
would output a lengthy list of parameters that would just flood the console and 
make everything unreadable.

Judging by the code there is no way for me to enable more descriptive messages. 
Could you please consider changing the message to include more descriptive 
messages or include an option for enabling them?

Original issue reported on code.google.com by [email protected] on 18 Mar 2015 at 11:00

I was wondering if we can have an atMostTimes method with poll count as option.
await().atMostTimes(10).with().pollInterval(10,TimeUnit.MILLISECONDS).until(....)

My intention is try at most 10 times to obtain the desired result with until.

Please let me know your thoughts or if i have missed this already existing option.

What steps will reproduce the problem?
1.Awaitility.await().until(requestStatus(instanceService, requestId1), 
equalTo(RequestStatus.STARTED));
2.
3.

What is the expected output? What do you see instead?
requestStatus function is called just once instead of multiple times during 10 
seconds.

What version of the product are you using? On what operating system?
The bug is in versions 1.6.3 and 1.6.2, 
version 1.6.1 works ok.


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 9 Feb 2015 at 9:58

Apologies if I'm coming at this from the wrong angle but is there any support (or direction of how i should do this) for running some code after the condition has been evaluated to true e.g. my current code is as follows

await().atMost(5, SECONDS).until(() -> someList.size(), is(equalTo(1))

is there any support for something like

await().atMost(5, SECONDS).until(() -> someList.size(), is(equalTo(1)).andThen(() -> assertThat(someList.get(0), is(equalTo("hello")))

so I know there is definitely 1 message, now I can do more assertions on the contents of the list

I'm getting the following message:

java.util.concurrent.TimeoutException: 
com.test.AwaitilityTest.recievedMessageCount Callable expected a value greater 
than or equal to <7000> but was <7901> within 1 seconds.
    at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:82)
    at com.jayway.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:50)
    at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:560)
    at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:412)

What steps will reproduce the problem?
1. awaitility 1.3.3, junit 4.8.1, hamcrest-core 1.1, hamcrest-library
2. Using a Netty Client Server app to send messages asynchronously. Checking 
Server for messages received.
3. with().pollInterval(500, 
MILLISECONDS).and().timeout(1,SECONDS).await().until(recievedMessageCount(channe
lAddress), greaterThan(7000));

I have tried Matchers greaterThan and greaterThanOrEqualTo but both fail 
intermitentantly even if the value IS greater than the value expected. 

Original issue reported on code.google.com by desmond.kirrane on 16 Jan 2012 at 6:34

What steps will reproduce the problem?

1. Add the line "compile 'com.jayway.awaitility:awaitility-groovy:1.6.3'" to 
dependencies in an Android build.gradle.
2. Attempt to build the project.


What is the expected output? What do you see instead?

Expected nothing to happen as awaitility is not yet referenced from the tests.

Instead I get a build error:

Error:Execution failed for task ':app:dexDebug'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
    /home/chris/Android/Sdk/build-tools/21.1.2/dx --dex --no-optimize --output /home/chris/AndroidStudioProjects/androidmdt/app/build/intermediates/dex/debug --input-list=/home/chris/AndroidStudioProjects/androidmdt/app/build/intermediates/tmp/dex/debug/inputList.txt
  Error Code:
    2
  Output:
    UNEXPECTED TOP-LEVEL EXCEPTION:
    com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
        at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:502)
        at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:277)
        at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:491)
        at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:168)
        at com.android.dx.merge.DexMerger.merge(DexMerger.java:189)
        at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:454)
        at com.android.dx.command.dexer.Main.runMonoDex(Main.java:303)
        at com.android.dx.command.dexer.Main.run(Main.java:246)
        at com.android.dx.command.dexer.Main.main(Main.java:215)
        at com.android.dx.command.Main.main(Main.java:106)

The build error goes away when I remove the dependency on awaitility.

I also get repeated warnings when awaitility is a dependency:

Warning:Ignoring InnerClasses attribute for an anonymous inner class
(net.sf.cglib.util.StringSwitcher$Generator$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.


What version of the product are you using? On what operating system?

awaitility 1.6.3
android studio 1.2
java 1.8.0_40-b25 amd64
ubuntu 14.04 x86_64

Original issue reported on code.google.com by [email protected] on 14 May 2015 at 12:58

I would like to use awaitility in pax exam for doing OSGi testing. This requires the jar to be a bundle though. I can provide the needed changes if you are interested.

CGLib can be specially troublesome when you have different versions of the library that are being pulled by different libraries.
It seems it's a common practice to shade this library (see Spring, Mockito) in order to avoid these problems.
Can you consider this?
Also, the version being used is almost 3 years old, it would be good to upgrade it (latest at this moment is 3.2.4)

Add untilNot( () -> checkIfCrashedError() ) feature

Idea is to wait x sec and throw exception if condition is meet.
Example:

publish(message)
awaits().atMost(5, SECONDS).untilNot( () -> errorQueue.size()==0 )

Awesome project!
Just my 0.02

For example it would be cool to be able to do:

await().between(ONE_SECOND, FIVE_SECONDS).until(..)

Perhaps it's more clear to do:

await().atLeast(ONE_SECOND).and().atMost(FIVE_SECONDS).until(..)

In
org.awaitility.core.ConditionAwaiter#pollSchedulingThread
a thread is created that doesn't have a name.

I think it could be helpful if that thread had a name containing "awaitility"

Hi, the links at the bottom of the documentation page https://github.com/awaitility/awaitility/wiki/Usage has a few links that no longer have a valid endpoint.

• Awaitility test case
• Field supplier test case

Thank you for Awaitiliy. We use it extensively!

We're using Awaitility in integration tests and it would be great if we could supply a more useful failure message. For example instead of "expected not null but was within 10 seconds." we'd like to see "transfer order not set within 10 seconds" or something like that.

Right now it throws an exception

Classes implementing the AwaitilitySupport trait are failing when using scala 2.12.x with the following message

failed: java.lang.NoSuchMethodError: org.awaitility.scala.AwaitilitySupport.$init$(Lorg/awaitility
/scala/AwaitilitySupport;)V

The same code works fine with scala 2.11.8

It might be nice if there was .untilNotify(Object obj) that waited until notify was invoked on the obj argument.

The reason for this is that I have a legacy application that is already significantly relying upon wait/notify, and there are various usages of wait could be simplified to something like await().atMost(ONE_SECOND).untilNotify(myObj) without forcing me to refactor all of the existing synchronization logic.

Consider providing until version that accepts lambda expression that is able to throw:

Awaitility.await().atMost(...).until(() -> {
...
callThatThrowsException();
...
})

Right now this looks like:

Awaitility.await().atMost(...).until(() -> {
...
try {
    callThatThrowsException();
} catch(Exception e) {
    throw new RuntimeException(e);
}
...
})

I can provide an implementation if you are ok with until() accepting something like ThrowableRunnable.

Awaitility already works fine with Kotlin, but there are a few instances where you can't inline calls to until.

It would also be nice to be able to use Kotlin idioms such as:

Awaitility.await().until {
    x > y
}

Code:

Awaitility.await().until({ "something" })

1.7.0: passes
2.0.0: fails with

java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
	at org.awaitility.core.CallableCondition$ConditionEvaluationWrapper.eval(CallableCondition.java:100)
	at org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

AwaitilityGroovyBridge used runnable as Callable<Boolean> while AwaitilityExtensionModule uses runnable as Callable.

Implementing AwaitilityTrait does not help, it seems that the extension module takes precedence. You need to change the closure to { "something" != null }.

Release Notes don't mention any breaking changes, so I consider this as a regression.

Also, please update examples from https://github.com/awaitility/awaitility/wiki/Groovy - they use deprecated classes.

In my current project we use a library that heavily depends on thread local variables. We have our own ExecutorService implementation that manages propagation of thread local variables between threads when needed.

When code is executed within await().until() blocks this thread local magic breaks because Awaitility uses its own ExecutorService. It would be nice to allow client code to set custom ExecutorService to enable this type of scenarios.

Awaitility is almost ideal for our purposes with one exception: we'd like to back off exponentially (or perhaps with a Fibonacci sequence) in our polling rather than use a fixed interval.

I may have missed it, but I didn't see a way in the docs or code to provide my own retry policy.

I was wondering how I would go about adding the downloaded dependencies and jars to eclipse

In the below fragment only the 1st from the two await().untilAsserted(...) calls is executed:

        Awaitility.pollInSameThread();

        await().untilAsserted(() -> {
            System.out.println("checking stuff 1...");
            assertThat("1234").isEqualTo("1234");
        });

        await().untilAsserted(() -> {
            System.out.println("checking stuff 2..."); // This is never reached
            assertThat("1234").isEqualTo("1234");
        });

The problem seems to be that the SameThreadExecutor instance which is created upon pollInSameThread mutates after the 1st execution and cannot be reused after that.

I think it'd be useful to be able to do sth like:
Awaitility.await().atMost(ONE_SECOND).metFor(ONE_SECOND).until(...)
Meaning that if the condition is met within one second,
then we continue to check it with the same interval for another second
to make sure it still gives the same result.
That'd be useful for scenarios where you're checking for example
number of received messages, to make sure nothing more then expected was actually received.

This simple test case, leaves a thread running:

@test
public void checkThreadsLeft() throws Exception {
await("asdf").until(() -> true);
}

Stack trace of the thread that has been left:

Thread[Thread-0,5,main]
at java.lang.Thread.sleep(Native Method)
at org.awaitility.core.ConditionAwaiter$1.run(ConditionAwaiter.java:163)
at java.lang.Thread.run(Thread.java:745)

Is there a way to terminate this thread?

In the page "https://github.com/awaitility/awaitility/wiki/Usage", under the section Links and code examples, the links mentioned are broken.

Eg.
The link mentioned is:
http://github.org/awaitility/blob/master/awaitility/src/test/java/org/awaitility/UsingAtomicTest.java

but it should be:
https://github.com/awaitility/awaitility/blob/master/awaitility/src/test/java/org/awaitility/UsingAtomicTest.java

Kindly update. Unfortunately we can't create Pull request for Github Wiki, or else I would have fixed it myself.

Thanks for a wonderful library.

(This is verified on 1.7.0, I have not tested 2.0.0, but at least the documentation has not changed)

The following three test cases have different behaviour.

The first one rethrows the exception immediately. The second one swallows the exception, waits for 10 seconds, then rethrows it. The third one succeeds.

I would expect that at least the latter two cases would succeed, since handling of AssertionFailedErrors is clearly already special, and arguably also the first one should succeed, since the API documentation of until(Callable<Boolean>) does not say anything about passing through exceptions, and some exceptions are already handled in special manner.

public class AwaitTest {
    @Test
    public void testUntilCallableBoolean_RuntimeException() {
        final AtomicInteger counter = new AtomicInteger(0);
        await().atMost(10, TimeUnit.SECONDS).until(() -> {
            if (counter.get() < 2) {
                counter.incrementAndGet();
                throw new RuntimeException("Not yet");
            } else {
                return true;
            }
        });
    }

    @Test
    public void testUntilCallableBoolean_AssertionFailedError() {
        final AtomicInteger counter = new AtomicInteger(0);
        await().atMost(10, TimeUnit.SECONDS).until(() -> {
            counter.incrementAndGet();
            assertTrue(counter.get() >= 2);
            return true;
        });
    }

    @Test
    public void testUntilRunnable() {
        final AtomicInteger counter = new AtomicInteger(0);
        await().atMost(10, TimeUnit.SECONDS).until(() -> {
            counter.incrementAndGet();
            assertTrue(counter.get() >= 2);
        });
    }
}

Having the complete stacktrace of the last assertion failure would make things easier.

Currently I cannot use something like

await()...(() -> {
    ...
    assertNotNull(var1);
    assertNotNull(var2);
}

because the ConditionTimeoutException is the same for both assertions.

Thanks
Lars

This test passes:

    @Test(expected = IllegalStateException.class)
    public void rethrows() {
        Awaitility.await()
            .atMost(1, TimeUnit.SECONDS)
            .until(
                new Callable<Boolean>() {
                    @Override
                    public Boolean call() throws Exception {
                        throw new IllegalStateException("Hello");
                    }
                }
            );
    }

If you replace IllegalStateException with AssertionError or any other kind of error, it will fail.

Hi,
Great project, been using it for a while now and very pleased :)
I wanted to know if there is any way to limit the number of used threads so Awaitilty will block until a new thread is available.

Went over the code and saw that AbstractHamcrestCondition creates a new thread each time, if I'd like to introduce a ThreadPool or executor would this be the right place?

With awaitility-groovy module on a classpath it is not possible to use unitl(Runnable) with Groovy Closure, e.g.

await().until({ assertThat(foo).isEqualTo(bar) })
//or
await().until({ wiremock.verifyThat(postRequestedFor(urlEqualTo("...")) }

Where verifyThat throws AssertError if condition is not fulfilled (the same as AssertJ). This is caused by the fact that AwaitilityExtensionModule treats all Clusures as Runnable:

    if (runnable instanceof Callable)
      self.until(runnable as Callable)
    else
      self.until(new AssertionCondition(runnable, self.generateConditionSettings()))

In general it is good, because Groovy by default would use until(Runnable) instead of until(Callable). Nevertheless the use case mentioned above is broken.

Unfortunately I don't see a good way to fix it. All ideas I have are far from being perfect:

1. Use new Runnable() { void run() { ... } } explicitly.
2. Add marker interface AwaitilityGroovySupplier to mark Closures which should be treated as Runnable and use it in AwaitilityExtensionModule
3. Add another method with different name just for Groovy users
4. Document this limitation in until(Runnable) JavaDoc to give people a chance to get know about that.

Maybe you will have some other ideas.

One more thing. Probably not much people use aforementioned path as AssertJ with Groovy is usually not needed and Wiremock is also only for specific scenarios. In addition people using Spock can as an alternative to Awaitility use PollingCondition from Spock. In that case maybe the 4rd point would be enough?

What steps will reproduce the problem?
1. Run awaitly for unit tests in android. Allow the callable to timeout.

What is the expected output? What do you see instead?
It should fail gracefully. Instead a NoClassDefFoundError exception is thrown 
because android doesn't have the java.lang.management.ManagementFactory class.

What version of the product are you using? On what operating system?
1.6.3

Please provide any additional information below.
java.lang.NoClassDefFoundError: Failed resolution of: 
Ljava/lang/management/ManagementFactory;
at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:98)
at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:78)
at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:25)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:590)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:582)

Ultimately, awaitly still works with android tests, it just fails erroneously 
when timing out.

Original issue reported on code.google.com by [email protected] on 3 Feb 2015 at 6:50

Hi,

Sometimes we need to wait for something if it gonna happen, but it's fine if it's not.
"Wait until a condition is true or timeout is reached" semantic, where reaching a timeout is not an exceptional case.

Example:
We have an application that writes logs. These logs are flushed asynchronously and with non-deterministic delay. In our unit test, we want to check the state of the application log, which could be empty and it could be fine. So, we need to wait for 5 seconds, abort waiting if the log became non-empty, or just silently continue execution after this 5 seconds if the log is still empty because it's a normal case.

Now we need to deal with ConditionTimeoutException which will be thrown if the condition is not met after the waiting period, which is ugly and makes the code messy.

Proposal:
Add .silent() method to awaitility building chain which disables throwing the exception.

Optional:
Add result value to .until() method to make it possible to understand if the condition has been met during waiting without one more explicit check

fyi, the current release of Hamcrest is, org.hamcrest:java-hamcrest:2.0.0.0 (note the coordinate changed). There isn't much that has visibly changed, but helps avoid needing to add exclusions for those who've upgraded.

Why does the MethodCallRecorder use static fields to record the lastTarget?

I frequently get Method call not recorded error message. Could it be connected to the MethodCallRecorder static fields and parallel test execution?

java.lang.IllegalStateException: No method call has been recorded. Perhaps the method was final?
    at com.jayway.awaitility.core.MethodCallRecorder.getLastTarget(MethodCallRecorder.java:68)
    at com.jayway.awaitility.core.ConditionFactory.untilCall(ConditionFactory.java:363)
    at com.hazelcast.concurrent.lock.ConditionBasicTest.testSignalWithMultipleWaiters(ConditionBasicTest.java:372)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
    at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.lang.Thread.run(Thread.java:745)

I have a few situations where I don't want certain exceptions to interrupt my wait, but for debugging purposes it's quite valuable to have the information that this exception occured. Therefore it would be nice to be able to register a ExceptionListener (or extend the ConditionEvaluationListener) to handle those exceptions.

E.g.

await().until(repo::isNotEmpty, repo::hasAnyX);

Original issue reported on code.google.com by [email protected] on 22 May 2014 at 11:54

What about a new release of awaitility?

The last release was half a year ago and I like to use the new groovy extension: 1c1d0b2

Hi!
I would like to know if there's a possibility to set an initial delay for polling.

I need to test an async feature that, when invoked, clear some data and then do some stuff.

In that scenario will be useful to set a initial delay before the assertion, otherwise the test will pass because the assertion will verify before the feature clear the data.

now we setted a thread sleep before using awaitility.

Could be an interesting enhancement?

Awaitility depends on cglib (which is quite large and makes osgi integration harder) only because of the "to" method that creates class proxies. Perhaps we should extract support for creating cglib proxies into a legacy library, awaitility-legacy. Note that "to" could still be retained for non-class proxy purposes that only uses the standard java Proxy class.

For use with pollDelay

We are using Awaitility inside our tests and some test are throwing 
AssertionError from inside of Callable supplier. As the result we got 
ConditionTimeoutException without any cause and it looked like Awaitility just 
stopped calling our supplier for no reason. I think the problem is that 
AssertionError is not an Exception, but Awaitility catches only Exceptions in 
ConditionAwaiter line 57

What is the expected output? What do you see instead?
We expect to see stack trace of the AssertionError or it being re-thrown. 
Instead we see ConditionTimeoutException which doesn't show the real cause


What version of the product are you using? On what operating system?
1.6.3 on any operating system

Original issue reported on code.google.com by [email protected] on 16 Jun 2015 at 12:32

according to Changelog 2.0.0: "Awaitility now requires Java 6"
but "Long.compare(getValueInMS(), other.getValueInMS());" which is used in "Duration.java", is since from java 1.7

Methods for ignoring exceptions should have Class<Throwable> arguments

await().until(fakeServer::recordedRequestUrls, hasItem(endsWith("/api/v2/11")));

gives:

org.awaitility.core.ConditionTimeoutException: Lambda expression in SomeTest that uses SomeTest: expected a collection containing a string ending with "/api/v2/11" but  within 10 seconds.

note double space after "but". This happens when there's no elements in fakeServer::recordedRequestUrls, if there are elements in fakeServer::recordedRequestUrls (but they don't match with the expectation) then the error message is fine.

It would be very nice to be able to intercept the lifecycle of a condition each time before it is evaluated. This hook could be used to refresh the state before checking the condition.

I'm thinking of the following syntax:
await("data).atMost(ONE_MINUTE).repeat(this::refreshData).until(this::checkData);

In this example the "refreshData" method fetches some data from a remote data store and saves it in a class field. The "checkData" checks the field if it matches a certain condition.

Currently I have to combine both operations into the "checkData" method. Introducing that new concept would make my code more modular and reusable.

Thanks!

This will also allow for waiting for void methods.

Original issue reported on code.google.com by [email protected] on 12 Apr 2011 at 7:48

Sometimes, and I repeat sometimes I get the following error while running my junit tests on Android
I'm using version 1.6.5 but 1.6.3 used to have the same issue.

java.lang.NoClassDefFoundError: Failed resolution of: Ljava/lang/management/ManagementFactory;
at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:100)
at com.jayway.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:87)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:713)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:530)
at com.myapp.test.test.MainTests.testLogin(MainTests.java:488)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1853)
Caused by: java.lang.ClassNotFoundException: Didn't find class "java.lang.management.ManagementFactory" on path: DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/com.myapp.test.test-2/base.apk", zip file "/data/app/com.myapp.test-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
... 17 more
Suppressed: java.lang.ClassNotFoundException: java.lang.management.ManagementFactory
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
... 18 more
Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack available