MacBook Air mid-2012 from Lion to Catalina

I had been asked by potential Javet users for Mac OS release for many moths before the first Mac OS release was published. I have to admit I have no plan to purchase Mac OS devices in the new future for financial reason.

Luckily, I have a MacBook Air mid-2012 resting in the dust. I revived it and would like to upgrade it to the latest Mac OS.

The problem was I had to upgrade it to Lion, then to El Capitan, Mojave, eventually to Catalina which is the last version supported by MacBook Air mid-2012.

It took ~8 hours to get there. Then, I installed xcode and related tools. Luckily, it met the lowest requirement for building V8 v9.2.

Obviously, MacBook Air mid-2012 is tooooo slow in building modern applications. It took ~4 hours to build V8, and another ~4 hours to build Node.js. The result was good as Javet for Mac OS x86_64 was built successfully.

However, MacBook Air mid-2012 will soon been retired by a new release of V8. When that day comes, I will no longer release Mac OS x86_64 version unless I get enough donation for me to purchase a new device.

Migrate from J2V8 to Javet

How to migrate from J2V8 to Javet is a frequently asked question, especially when people are evaluating Javet. I created Javet in Jan, 2021 for various reasons (What is the Motivation?, History with J2V8). After the first release v0.7.0 was published, I started migrating from J2V8 to Javet. It was quite smooth, though it took a week.

Why Migrate from J2V8 to Javet?

• Its Linux, Mac OS and Windows releases have been abandoned for years.

• Its type hierarchy is inconsistent because primitive types are out of the hierarchy so that tedious if-else sentences have to be repeated all over the code base.

• Its function registration API is kind of verbose.

• Segfaults take place so frequently and don't get maintainers' attention for years.

• Its locking mechanism heavily increases mental pressure in the code base.

• Its V8 runtime is not multi-threaded friendly unless application adds a synchronous layer on top of it.

Migration Guides

V8 ⟶ V8Runtime

• V8 in J2V8 is V8Runtime in Javet.

• V8 in J2V8 carries 2 roles: 1 as the V8 runtime and 1 as the global object (globalThis or global). In Javet, V8Runtime no longer inherits from V8Value so that it literally represents the V8 runtime. V8Runtime.getGlobalObject() is dedicated to the global object.

• V8Runtime has much richer API than V8 has. E.g. compileV8Module(), lowMemoryNotification(), terminateExecution().

Primitive Types

• Primitive types in Javet inherit from V8ValuePrimitive ⟶ V8Value ⟶ V8Data.

• The Javet type hierarchy is consistent so that V8Value in all supported API can represent all V8 types. This is hard in J2V8 because Object has to be used to represent all types, however, by using Object the type check during compilation doesn't work at all and that is a rich source of runtime bugs or even segfaults.

registerJavaMethod() ⟶ @V8Function

• It is quite painful to register many functions in J2V8. Javet makes that a declarative one instead of the imperative one. Just decorate the target function with @V8Function, then call V8ValueObject.bind(javaObject) to bind that Java object, it's done.

• In addition, Javet provides @V8Property which allows registering getters and setters in the same manner. That feature has never been delivered by J2V8.

• Javet also allows unbinding the registration. Just call V8ValueObject.unbind(javaObject).

Please refer to V8 Function for more details.

V8Locker

• Javet introduced Implicit Mode which allows applications to eliminate V8Locker from the code base and still be able to share the same V8Runtime among multiple threads, because Javet does the synchronization automatically. That frees applications developers from the tedious acquire() and release() calls, and gets the rid of the runtime exceptions caused by multiple threads.

• Javet also has Explicit Mode for performance sensitive scenarios.

Please refer to Know the Lock for more details.

Type Conversion

• Javet has built-in JavetObjectConverter which covers the majority cases on type conversion so that the arguments of Javet API can be of any type and the converter just does the conversion transparently. That frees application developers from writing tedious type conversion code everywhere.

• Javet also provides JavetProxyConverter which allows injecting arbitrary Java objects in V8 and polyfilling Java interfaces with JavaScript functions or objects. Especially the polyfilling feature implies hotfixing business logic without restarting the JVM.

Please refer to Object Converter for more details.

Node.js and V8

• Javet provides both Node.js mode and V8 mode for various usages. Each mode stays at a dedicated classloader so that both modes don't cross each other, and are completely isolated. If the application only uses one mode, it doesn't need to pay extra amount of memory for the other mode because the other mode is not loaded at all. Of course, both modes can be unloaded as well without shutting down the JVM.

• In Node.js mode, all node modules can be directly used including the native modules. Please refer to Modularization for more detail.

• In V8 mode, it is much more secure than the Node.js mode is, but lacks of some basic ES API, e.g. setTimeout(). Project Javenode is the one that aims at simulating Node.js with Java in Javet V8 mode.

Please refer to Javet Design for more details.

ES6 Module

• Javet supports import { *** } from '***.js' and exposes module resolve event for applications to specify where to locate the modules.

Please refer to Modularization for more detail.

Blessing

In case this migration guide couldn't cover all your use cases, please contact the maintainer at discord. Wish you a successful migration!

Javet v0.9.11 is released with some exciting features

Javet v0.9.11 is released with some exciting features.

• Mac OS (x86_64)
• Node.js v14.17.6
• V8 v9.3.345.16
• Getter/Setter by Symbol
• Dynamic Proxy for Java Objects by JavaScript Objects
• Promise

How to Efficiently Wait for RxJava Observer to Complete?

Almost all tutorials including the RxJava official ones deliver a message to RxJava developers that Thread.sleep(...) is recommended in testing RxJava code snippets. However, that is not efficient enough.

Here is an alternative way for your reference.

AtomicBoolean atomicBoolean = new AtomicBoolean(false);
ExecutorService executorService = Executors.newFixedThreadPool(4);
Observable.timer(10, TimeUnit.MILLISECONDS, Schedulers.from(executorService))
        .subscribe(t -> atomicBoolean.set(true));
executorService.awaitTermination(100, TimeUnit.MILLISECONDS);
assertTrue(atomicBoolean.get());

The key is to inject a custom thread pool and wait for that thread pool to complete.

V8 v9.3 and Mac OS: error: no member named 'forward' in namespace 'std'

As Chrome v93 is stable, I began to upgrade Javet to V8 v9.3.345.16. However, the build failed on my MacBook Air with the following error messages.

../../include/cppgc/allocation.h:168:39: error: no member named 'forward' in namespace 'std'
    T* object = ::new (memory) T(std::forward<Args>(args)...);   
                                 ~~~~~^                
../../include/cppgc/allocation.h:168:47: error: 'Args' does not refer to a value
    T* object = ::new (memory) T(std::forward<Args>(args)...);
                                              ^

Well, as std::forward is missing, the fix is simple. Just add #include <utility> into include/cppgc/allocation.h and it works.