|
Valentinor wrote: So yeah, they don't need to install java,
On Windows a Java install consists basically of the following.
1. Lay down the files into the file system.
2. Create the registry data so the user can uninstall it.
So apparently what you are actually doing is giving the user the option to use the Java that is already installed or to use the VM that comes with your application.
Besides my other suggestion you might also want to consider whether the VM they have installed is the correct version for your appliction.
|
|
|
|
|
jschell wrote: 1. Lay down the files into the file system.
Yes or no, depending what you mean by "file system". When the app is installed, inside it's folder structure it will also have Eclipse Adoptium (...\MyApp\ThirdParty\Eclipse Adoptium\jre-17.0.7.7-hotspot)
jschell wrote: 2. Create the registry data so the user can uninstall it.
It will be for the app itself and not just for java, as Eclipse Adoptium will be a part of the app, integrated into it, and not separate. When the app is uninstalled, so will Eclipse Adoptium as it is part of its files. If the user has any other form of Java installed, they won't be affected in any way.
jschell wrote: So apparently what you are actually doing is giving the user the option to use the Java that is already installed or to use the VM that comes with your application.
No. The app will only use Java that comes with it, as the app won't even look in another location if Java is installed, only inside it's file structure.
jschell wrote: whether the VM they have installed is the correct version for your appliction
I explained in the above statement why this doesn't matter for my case.
jschell wrote: As a suggestion only you might want to work on your error handling if it turns out Java isn't installed. Telling a user that a dll is missing is not going to help them nor you when they ask why it isn't working.
I never said that I don't have an error handling system already added. If any of Java files are missing or are corrupted, or any of the other app files are missing or are corrupted, an error will appear telling the user to run the check for corrupted files or reinstall the app, accompanied by an error message, that will tell me exactly which file is the problem, if it is missing or if it is corrupted.
|
|
|
|
|
I have a socket though which I'm sending files. If the file is under the buffer size (8192 in my case) then it is fine, but if the file is over that size, then when it writes to file, it writes the first chunk of 8192 bites every time. I'm using ObjectStream because beside the file, I'm sending other objects as well in the actual app, but this is the part of sending the file.
Client it sends the file data (testing):
System.out.println("Starting client");
Socket socket = new Socket("localhost", port);
System.out.println("Client sending data");
ObjectOutputStream dataOut = new ObjectOutputStream(socket.getOutputStream());
BufferedInputStream is = new BufferedInputStream(new FileInputStream(inFile));
byte[] buffer = new byte[8192];
int sizeRead = 0;
while ((sizeRead = is.read(buffer, 0, 8192)) >= 0) {
printByte(buffer, "in");
dataOut.writeObject(true);
dataOut.writeObject(buffer);
dataOut.writeObject(sizeRead);
dataOut.flush();
}
is.close();
System.out.println("Done sending file");
dataOut.writeObject(false);
socket.close();
System.out.println("Client closed");
Server that creates the file:
System.out.println("Starting server");
ServerSocket server = new ServerSocket(port);
System.out.println("Server waiting");
Socket socket = server.accept();
System.out.println("Client connected");
ObjectInputStream dataIn = new ObjectInputStream(socket.getInputStream());
BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(outFile));
Object auxKeepReading = dataIn.readObject();
if (auxKeepReading instanceof Boolean) {
while ((boolean) auxKeepReading) {
Object auxBuffer = dataIn.readObject();
if (!(auxBuffer instanceof byte[])) {
System.out.println("Broke byte");
break;
}
Object auxSize = dataIn.readObject();
if (!(auxSize instanceof Integer)) {
System.out.println("Broke int");
break;
}
printByte((byte[]) auxBuffer, "out");
bos.write((byte[]) auxBuffer, 0, (int) auxSize);
auxKeepReading = dataIn.readObject();
if (!(auxKeepReading instanceof Boolean)) {
System.out.println("Broke boolean");
break;
}
}
} else {
System.out.println("Broke boolean");
}
bos.close();
socket.close();
server.close();
System.out.println("Server stopped");
Why is it that it keeps sending the first chunk of byte[], and not what it reads new?
|
|
|
|
|
On client side after sending the size that it read, I added buffer = new byte[8192]; and now I don't have the problem and it is sending new data but there are 2 problems:
1. I don't know if this is what you should do;
2. The speed is limited to 3 MB/s when using IP instead of localhost, on an internet connection of 1.000 Mbps (~125 MB/s) upload/download (they are the same). I tried to increase the buffer size but still the same speed.
|
|
|
|
|
I was looking at this code earlier and wondered why you sent the buffer size after the data. It makes much more sense to send the size first. Also there is no point in sending 8192 bytes if you have only read one byte from the input file. So only send the amount of data that has been read. Tuning TCP performance is not an exact science unfortunately, but you can find plenty of discussions of the subject on the internet.
|
|
|
|
|
Richard MacCutchan wrote: I was looking at this code earlier and wondered why you sent the buffer size after the data. It makes much more sense to send the size first.
Because when they are used it doesn't matter the order they were sent, I didn't even think about that.
Richard MacCutchan wrote: Also there is no point in sending 8192 bytes if you have only read one byte from the input file. So only send the amount of data that has been read.
I changed that now on client: dataOut.writeObject(Arrays.copyOf(buffer, sizeRead));
What about buffer = new byte[8192]; I added, is that how it should be done to send now data each time?
dataOut.writeObject(true);
dataOut.writeObject(sizeRead);
dataOut.writeObject(Arrays.copyOf(buffer, sizeRead));
dataOut.flush();
buffer = new byte[8192];
Richard MacCutchan wrote: Tuning TCP performance is not an exact science unfortunately, but you can find plenty of discussions of the subject on the internet.
From what I've seen they suggest two things most of the time:
1. Setting socket.setTcpNoDelay(true);. I tried that on both client and server bust still no use;
2. Using BufferedOutputStream/BufferedInputStream inside ObjectOutputStream/ObjectInputStream, but still the same 3 MB/s. Even after combining 1. and 2.
|
|
|
|
|
JohnCodding wrote: What about buffer = new byte[8192]; I added, is that how it should be done to send now data each time?
Yes, that is fine, as you allocate the buffer before you start the read/write loop. So each read from the input file will refill the same buffer. But I would be tempted to use ObjectOutputStream write(byte[](Java Platform SE 7 )[^], rather than writeObject, to send the byte data.
I have never had to do any TCP tuning so can't offer any useful suggestions, sorry.
|
|
|
|
|
Richard MacCutchan wrote: But I would be tempted to use ObjectOutputStream write(byte[](Java Platform SE 7 )[^], rather than writeObject, to send the byte data.
In the past when I used socket but not for files, I had some problems when I was using combination of ObjectOutputStream writeBoolean(), writeInt(), writeUTF(), writeObject(), the order was correct when writing/reading but I was still getting some exceptions, and when I switch to only writeObject() I didn't had any problems. And with objects I have more control over what the server gets from the client when the data is wrong, and shadow ban the IP if it keeps sending the wrong data based on some checks. As java class files can easily be decompiled, they can recreate the code and send part of the data good then wrong one just to be jerks or for phishing data. I have some checks on the server to know when someone clearly wasn't supposed to send data, and ignore it, and it did help.
Richard MacCutchan wrote: I have never had to do any TCP tuning so can't offer any useful suggestions, sorry.
Yeah, until now I didn't had problems, but now with files, also some that can be big, I do care about speed a lot. I'll keep looking and maybe I find a way to remove the limit. As there is clearly a limit because the speed stays around 3 MB/s and I did see someone complaining about the same exact speed, but there wasn't a solution on that thread.
|
|
|
|
|
JohnCodding wrote: The speed is limited to 3 MB/s when using IP instead of localhost, on an internet connection of 1.000 Mbps
Not quite sure what you are saying there but...
Yes localhost and the actual network are different. So a speed difference is expected. Matter of fact if it was the same I would expect (most likely) a problem with the actual measurement or that there was a hardware/software throttle happening in the client.
JohnCodding wrote: internet connection ... upload/download (they are the same).
Noting also that I would not expect that. Even for a business. But I do want to emphasize that there is a difference between 'network' and 'internet'.
|
|
|
|
|
jschell wrote: Noting also that I would not expect that. Even for a business.
SpeedTest[^]
jschell wrote: Not quite sure what you are saying there but...
When transferring files over internet using the code I posted for sending/receiving, the transfer speed is always limited to 3 MB/s (bounces around 3 MB/s, it goes over or under with 100-200 KB/s) instead of the actual capabilities of internet speed and hardware (SSD).
If localhost is used, then the transfer is not limited to 3 MB/s.
|
|
|
|
|
JohnCodding wrote: If localhost is used, then the transfer is not limited to 3 MB/s.
I meant that 'localhost' and 'network' should not have the same speed.
A connection, any connection, goes through actual hardware.
So your speedtest is connecting to a computer somewhere.
You client test app is connecting to a different computer somewhere.
So something is throttling it.
Best way is to test your app with another app that you control. You need two boxes. They can be local but you could also spin on a cloud box. Probably ideal on the cloud (internet connected.)
If that test shows a speed limitation then it is your apps problem (with I doubt.)
If not then it indicates that something at the other end is probably throttling it.
Also possible that your service provider is throttling it. They are 'faking' the results with speedtest by explicitly looking for it. Or you might be hitting a data limit with your app that the document (or don't.)
|
|
|
|
|
I made an app (Windows only) with which you can create a backup of a folder/file locally or to a server. I'm done with the copy/restore process, but when it comes to restoring I have a small technical problem. If the file in originally hidden, then this is easy as you can call Files.setAttribute(file.toPath(), "dos:hidden", true); which will make the file hidden on client side after it is created/restored, but there are files like desktop.ini which aren't simply hidden but are system protected hidden and the above code will only give it the hidden status, and not system protected hidden.
There is also Files.getAttribute() but as the name suggests it only returns the attribute value for a single attribute, and not all of them to easily be able to do Files.setAttributes(file.toPath(), Files.getAttributes(file.toPath()));. So my question is, is there a way to get a list will all the attributes a file has and then setting them in a more dynamically way and not having to call Files.getAttribute(); / Files.setAttribute(); for each of them line by line? If unfortunately there isn't one, and you do have to set them line by line, can someone give me a list with all the attributes for Windows OS like there is here for example with DateTimeFormatter[^] for pattern symbols?
modified 26-Sep-23 3:34am.
|
|
|
|
|
|
This doesn't look all that hard to do in C++, which makes me believe that there might be a way to do it in Java as well. If it was locally only (on the same machine) then I could make a dll and copy the attribues that way as both the backup and restored files are on the same machine, but the app also has the Socket part and sending the C++ attributes might give a a headache when trying to crate the code, compared to just sending java objects.
Even so, this is good info, thanks!
|
|
|
|
|
I found a solution for the information when you open the Properties of a file, from the General tab, as for Details tab, that info it is copied with the file.
Example for General tab:
DosFileAttributes dos = Files.readAttributes(original.toPath(), DosFileAttributes.class);
DosFileAttributeView dosView = Files.getFileAttributeView(copy.toPath(), DosFileAttributeView.class);
dosView.setArchive(dos.isArchive());
dosView.setHidden(dos.isHidden());
dosView.setReadOnly(dos.isReadOnly());
dosView.setSystem(dos.isSystem());
dosView.setTimes(dos.lastModifiedTime(), dos.lastAccessTime(), dos.creationTime());
modified 26-Sep-23 3:05am.
|
|
|
|
|
Hi,
My Junit test cases are compiled and running fine with
'zerocode-tdd', version: '1.3.1'
'rest-assured', version: '2.9.0'
'JAVA' version '1.8.0'
'gradle' version '6.9.2
Now it is upgraded to
'zerocode-tdd', version: '1.3.33'
'rest-assured', version: '5.3.0'
'JAVA' version '1.11.0'
'gradle' version '8.0.2
My test is compiled. while running getting below error
Test _mytest FAILED
java.lang.RuntimeException: ZeroCode Step execution failed. Details:java.lang.NullPointerException
snippet of code is myTest.java
@Test
@JsonTestCase("zerocode/11_Test.zero")
public void _11_Test() throws Exception {}
Could you please suggest what is wrong.
Thanks in Advance
|
|
|
|
|
You've provided no details of the affected code, so we can't tell you precisely what the problem is.
All we can tell you is that a NullPointerException means that somewhere in your code you are trying to access a member of an object which has not been initialized, and is set to null.
You need to debug your code to find out what object is null when it shouldn't be. Then work out why it hasn't been initialized.
We can't do that for you.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
here is the file 11_Test.zero
{
"scenarioName": "Cleanup dr network",
"steps": [
// source1
{
"name": "step1_source1",
"url": "com.storvisor.backup.TestPreconditions",
"operation": "drNetworkCleanup",
"request": {
"____test_step": "1a_p001_cleanup_network_step1_source1",
"X-OperationID": "${RANDOM.NUMBER}", // actually System.currentTimeMillis()
"stdatasvcmgr": "http://10.198.74.45:9339/stdatasvcmgr",
"user": "[:]",
"rootsessionid": "564d1ec7-b0ec-e9d0-445f-7455b4d1bcdd-12532"
},
"assertions": {
"result": true
}
},
// source2
{
"name": "step1_source2",
"url": "com.storvisor.backup.TestPreconditions",
"operation": "drNetworkCleanup",
"request": {
"____test_step": "1a_p001_cleanup_network_step1_source2",
"X-OperationID": "${RANDOM.NUMBER}", // actually System.currentTimeMillis()
"stdatasvcmgr": "http://10.198.73.61:9339/stdatasvcmgr",
"user": "[:]",
"rootsessionid": "564dc67c-1f45-7270-6795-32a72f436514-23376"
},
"assertions": {
"result": true
}
},
// target
{
"name": "step1_target",
"url": "com.storvisor.backup.TestPreconditions",
"operation": "drNetworkCleanup",
"request": {
"____test_step": "1a_p001_cleanup_network_step1_target",
"X-OperationID": "${RANDOM.NUMBER}", // actually System.currentTimeMillis()
"stdatasvcmgr": "http://10.198.73.67:9339/stdatasvcmgr",
"user": "[:]",
"rootsessionid": "564dc295-844a-89ad-091e-6033987ce14b-29868"
},
"assertions": {
"result": true
}
}
]
}
under zerocode directory
File :myTest.java
------------------
package com.storvisor.backup;
import static org.junit.Assert.*;
import org.jsmart.zerocode.core.domain.JsonTestCase;
import org.jsmart.zerocode.core.domain.TargetEnv;
import org.jsmart.zerocode.core.runner.ZeroCodeUnitRunner;
import org.junit.FixMethodOrder;
import org.junit.Ignore;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.Timeout;
import org.junit.runner.RunWith;
import org.junit.runners.MethodSorters;
@TargetEnv("test.properties")
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
@RunWith(PolicyTestUnitRunner.class)
public class myTest {
@Rule
public Timeout globalTimeout = Timeout.seconds(120);
@Test @JsonTestCase("zerocode/11_Test.zero")
public void _11_Test() throws Exception {}
}
---------------------------
PolicyTestUnitRunner.java
----------------------------
package com.storvisor.backup;
import org.jsmart.zerocode.core.runner.ZeroCodeUnitRunner;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.model.InitializationError;
public class PolicyTestUnitRunner extends ZeroCodeUnitRunner
{
public PolicyTestUnitRunner(Class klass) throws InitializationError
{
super(klass);
}
@Override
public void run(RunNotifier notifier)
{
PolicyTestListener failFastListener = new PolicyTestListener(notifier);
notifier.addListener(failFastListener);
super.run(notifier);
}
}
Thanks
|
|
|
|
|
Also Observed it is executing till source afterward it is throughing Java Runtime Exception
java.lang.RuntimeException: ZeroCode Step execution failed. Details:java.lang.NullPointerException
|
|
|
|
|
source1 is worked perfectly when it start consume soure2 it is througing
java.lang.RuntimeException: ZeroCode Step execution failed. Details:java.lang.NullPointerException.
Can you please let me know what is wrong on zero file
Thanking you
|
|
|
|
|
No one here can tell you what is wrong with your file since we have no idea what the data represents. Also we have no idea where ther exception occurs, or why the variable in question has not been initialised. You are the only person that can diagnose the problem, by using the debugger, and examining what is happening when the code runs.
|
|
|
|
|
Member 16085274 wrote: Could you please suggest what is wrong.
The stack trace will tell you the exact line with the null pointer.
|
|
|
|
|
* What went wrong:
Execution failed for task ':backup:integration_test'.
> There were failing tests. See the report at: file:
* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':backup:integration_test'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:149)
at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:147)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:135)
at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:42)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:338)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:325)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:318)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:304)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:463)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:380)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49)
Caused by: org.gradle.api.tasks.VerificationException: There were failing tests. See the report at: file: at org.gradle.api.tasks.testing.AbstractTestTask.handleTestFailures(AbstractTestTask.java:621)
at org.gradle.api.tasks.testing.AbstractTestTask.handleCollectedResults(AbstractTestTask.java:483)
at org.gradle.api.tasks.testing.AbstractTestTask.executeTests(AbstractTestTask.java:478)
at org.gradle.api.tasks.testing.Test.executeTests(Test.java:685)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
at org.gradle.api.internal.tasks.execution.TaskExecution$3.run(TaskExecution.java:242)
at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68)
at org.gradle.api.internal.tasks.execution.TaskExecution.executeAction(TaskExecution.java:227)
at org.gradle.api.internal.tasks.execution.TaskExecution.executeActions(TaskExecution.java:210)
at org.gradle.api.internal.tasks.execution.TaskExecution.executeWithPreviousOutputFiles(TaskExecution.java:193)
at org.gradle.api.internal.tasks.execution.TaskExecution.execute(TaskExecution.java:166)
at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:93)
at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:44)
at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:57)
at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:54)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:54)
at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:44)
at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:67)
at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:37)
at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:41)
at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:74)
at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55)
at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:50)
at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:28)
at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.executeDelegateBroadcastingChanges(CaptureStateAfterExecutionStep.java:100)
at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:72)
at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:50)
at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:40)
at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:29)
at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:166)
at org.gradle.internal.execution.steps.BuildCacheStep.executeAndStoreInCache(BuildCacheStep.java:139)
at org.gradle.internal.execution.steps.BuildCacheStep.lambda$executeWithCache$4(BuildCacheStep.java:106)
at org.gradle.internal.execution.steps.BuildCacheStep.lambda$executeWithCache$5(BuildCacheStep.java:106)
at org.gradle.internal.Try$Success.map(Try.java:164)
at org.gradle.internal.execution.steps.BuildCacheStep.executeWithCache(BuildCacheStep.java:80)
at org.gradle.internal.execution.steps.BuildCacheStep.lambda$execute$0(BuildCacheStep.java:69)
at org.gradle.internal.Either$Left.fold(Either.java:115)
at org.gradle.internal.execution.caching.CachingState.fold(CachingState.java:59)
at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:68)
at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:46)
at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:36)
at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:25)
at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:36)
at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:22)
at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:91)
at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$2(SkipUpToDateStep.java:55)
at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:55)
at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:37)
at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:65)
at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:36)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27)
at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:76)
at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:37)
at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:94)
at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:49)
at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:71)
at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:45)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.executeWithNonEmptySources(SkipEmptyWorkStep.java:177)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:86)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:53)
at org.gradle.internal.execution.steps.RemoveUntrackedExecutionStateStep.execute(RemoveUntrackedExecutionStateStep.java:32)
at org.gradle.internal.execution.steps.RemoveUntrackedExecutionStateStep.execute(RemoveUntrackedExecutionStateStep.java:21)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:36)
at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:23)
at org.gradle.internal.execution.steps.CleanupStaleOutputsStep.execute(CleanupStaleOutputsStep.java:75)
at org.gradle.internal.execution.steps.CleanupStaleOutputsStep.execute(CleanupStaleOutputsStep.java:41)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:32)
at org.gradle.api.internal.tasks.execution.TaskExecution$4.withWorkspace(TaskExecution.java:287)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:30)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:21)
at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:37)
at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:27)
at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:42)
at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:31)
at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:64)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:146)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:135)
at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:42)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:338)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:325)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:318)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:304)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:463)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:380)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49)
|
|
|
|
|
Member 16085274 wrote: these java files not the part of the code, it is part of used jars
Then either there's a bug in the libraries you're using, or you're using them wrong.
Either way, there's still nothing we can do to help you. You need to contact the library authors for support.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
