Update README.md

README.md

@@ -12,7 +12,7 @@ The last Windows version 4.6.0 was released on 2016 and the last Linux version 4
 
 The latest community activities were around Android versions. The NodeJS API was dropped. The Windows build has been seriously broken for years. The Linux build is nearly broken.
 
-Its API has stopped evolving for years. Many new features I expect just don't get any chances to be implemented. Obviously, if the build system was broken and couldn't be easily fixed, almost no one would like to contribute. That includes me. When I was trying to fix the build system for Windows and Linux, I had to admit that's so, so, so, challenging. Why is that? I think it's not merely J2V8 community problem because in the meanwhile V8, NodeJS, ECMAScript move forward rapidly causing many unexpected challenges. Someone or some team needs to look after J2V8 from time to time. Unfortunately, reality is cruel.
+Its API has stopped evolving for years. Many new features I expect just don't get any chances to be implemented. Obviously, if the build system was broken and couldn't be easily fixed, almost no one would like to contribute. That includes me. When I was trying to fix the build system for Windows and Linux, I had to admit that's so, so, so, challenging. Why is that? I think it's not merely J2V8 community's problem because in the meanwhile V8, NodeJS and ECMAScript move forward rapidly causing many unexpected challenges. Someone or some team needs to look after J2V8 from time to time. Unfortunately, reality is cruel.
 
 ### Well, Why not Let Me Start from Scratch?
 
@@ -48,7 +48,7 @@ I've tested the performance between `j2v8_win32_x86_64-4.6.0.jar` and `j2v8_win3
 |--------------------------------|--------------|--------------|
 | Single Session with 1 Thread   |    1,003,009 |    1,338,688 |
 | Ad-hoc Session with 1 Thread   |           35 |          299 |
-| Multiple Threaded (4 threads)  |    2,274,019 |    4,571,428 |
+| 4 Sessions with 4 threads      |    2,274,019 |    4,571,428 |
 
 With this kind of performance improvement, what are the reasons of sticking to `v4.6.0`?
 
@@ -67,7 +67,7 @@ TL;DR: It's too hard.
   * Gradle v2.14.1 is far from the lowest supported gradle version in my latest IntelliJ IDEA. And I don't have interest in installing a legacy Eclipse to play with that version of gradle. Hey, why not upgrade gradle to satisfy IDEA? I tried, but all was bad luck. You may take a try, then understand what I have suffered from.
   * CMake is old and seriously broken on Windows. Nowadays, V8 only supports VS 2017 or 2019, but `CMakeLists.txt` is still at the VS 2015 age. No surprise, it doesn't work at all.
   * Docker build is deeply broken as well. The dependent docker image was gone. There are many errors in many steps. Sitting there, watching the docker build breaks made me full of frustration because I thought it would take me a few months fixing the problems, but I don't have a few months. No one pays me to do that.
-  * Python2 scripts form the outer layer of the build system, also hide the actual building logic from someone who tries to fix the build system. I don't want to spend my precious time fixing Python2 scripts, because I've been on Python3 for many years. I wish my hair could be as much as Guido van Rossum. Obviously, I am not, so no more Python2.
+  * Python2 scripts form the outer layer of the build system, also hide the actual building logic from someone who tries to fix the build system. I don't want to spend my precious time fixing Python2 scripts, because I've been on Python3 for many years. I wish my hair could be as much as Guido van Rossum's. Obviously, I am not, so no more Python2.
   * Maven is old but the least problematic. At least it allows me to package the jar files with my hack to the `pom.xml`.
 
 With these uncertainties, to me, automating the build system is something with ROI closing to 0. Supposing I achieved it in a particular version of V8, let's say v8.3.110.9, it would for sure break in v8.9.213. Yes, I've confirmed that.