Closed acoglio closed 5 years ago
@acoglio is it enough for full compatibility with OpenJDK?
@zilm13 It's a step in that direction. It got me past the first error I was getting, as I mentioned in Issue #1064, but I'm still getting another error. I started looking at your suggestions on that Issue's thread, but I'm not a Gradle expert; my first attempt at locally modifying build.gradle
didn't work.
@acoglio pushing it in the repository will not help you. Looks like you are running global gradle instead of local, that you've changed. If you are using linux or macos, by running ./gradlew run
you will run local gradle, by gradle run
- global.
@zilm13 I've been running ./gradlew clean farJar
, following the instructions under 'Building an executable JAR' at https://github.com/ethereum/ethereumj.
Try to run it with --info
. Works like a charm locally for me according to changes in gradle-wrapper.properties
➜ ethereumj git:(master) ./gradlew clean fatJar --info
Initialized native services in: /Users/work/.gradle/native
The client will now receive all logging from the daemon (pid: 6956). The daemon log file: /Users/work/.gradle/daemon/4.6/daemon-6956.out.log
Starting 2nd build in daemon [uptime: 17.859 secs, performance: 98%, GC rate: 0.50/s, tenured heap usage: 2% of 716.2 MB]
Using 8 worker leases.
Starting Build
Settings evaluated using settings file '/Users/work/projects/ethereumj/settings.gradle'.
Projects loaded. Root project using build file '/Users/work/projects/ethereumj/build.gradle'.
Included projects: [root project 'ethereumj', project ':ethereumj-core']
> Configure project :
^C%
➜ ethereumj git:(master) ./gradlew clean fatJar --info
Initialized native services in: /Users/work/.gradle/native
Removing 0 daemon stop events from registry
Starting a Gradle Daemon, 1 busy Daemon could not be reused, use --status for details
Starting process 'Gradle build daemon'. Working directory: /Users/work/.gradle/daemon/4.10 Command: /Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/bin/java -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /Users/work/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10/lib/gradle-launcher-4.10.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 4.10
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.133 secs.
The client will now receive all logging from the daemon (pid: 7022). The daemon log file: /Users/work/.gradle/daemon/4.10/daemon-7022.out.log
Starting build in new daemon [memory: 954.7 MB]
Using 8 worker leases.
Starting Build
<-------------> 0% INITIALIZING [0s]
> Evaluating settings
^C%
➜ ethereumj git:(master) ✗ ./gradlew clean fatJar --info
Downloading https://services.gradle.org/distributions/gradle-4.11-bin.zip
Exception in thread "main" java.io.FileNotFoundException: https://downloads.gradle.org/distributions/gradle-4.11-bin.zip
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1836)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at org.gradle.wrapper.Download.downloadInternal(Download.java:66)
at org.gradle.wrapper.Download.download(Download.java:51)
at org.gradle.wrapper.Install$1.call(Install.java:62)
at org.gradle.wrapper.Install$1.call(Install.java:48)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
at org.gradle.wrapper.Install.createDist(Install.java:48)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Thanks.
I got ./gradlew clean fatJar
to work by adding the block if (JavaVersion.current().ordinal() > 7) ...
from here, which you referenced in the conversation in Issue #1064, to ethereumj-core/build.gradle
. (A previous attempt of mine to do this was unsuccessful: I probably put it in the wrong place -- not familiar with Gradle.)
Should I make a PR with this addition to build.gradle
? Also, I wasn't sure if you were saying that this current PR to increase the Gradle version in gradle/wrapper/gradle-wrapper.properties
should not be merged.
Yeah, I don't think we need to bump gradle version alone. Any changes requires additional testing, increases risk of instability and are not valuable without fixes/improvements. If you are going to walk this path to OpenJDK compatibility, it will be cool and we are going to approve such PR, otherwise I'd prefer no merge.
I understand. My motivation to get EthereumJ built and running was to "compare" existing Ethereum implementations (starting with EthereumJ) with a formal specification and verified implementation of Ethereum that some colleagues and I are building in the ACL2 theorem prover (http://www.kestrel.edu/home/projects/ethereum/). In particular, I wrote a formal specification of RLP encoding and a verified implementation of RLP decoding. I might have some proposed PRs for the RLP code in EthereumJ, but before making the PRs I would want to test them -- compile, at the very least. The OpenJDK issues were the first obstacle I encountered, but I can keep the OpenJDK-related changes local to my files. Is there some test suite that I could run locally to test changes for potential PRs? (These changes shouldn't depend on OpenJDK.)
@acoglio I think you could start with ./gradlew test
, maybe ./gradlew assemble
and then verify it on samples from samples
folder. If it passes it, there is a small chance that something is still wrong.
The older version was unable to parse the version string of OpenJDK 11.