Monday, May 11, 2020

Kotlin vs Java continued

Kotlin has support for a number of tools to help with the compilation and build. 

Annotation processing is fine with the help of kapt tool. A plugin for gradle by the name Kotlin-Kapt is also available. Key value pairs can be passed in to Kapt as arguments.

Kapt tasks can be run in parallel. It can also leverage gradle’s compile avoidance feature to skip notation processing altogether. This plugin is available in the jar form to make it easy to be run from the command line. 

The language fit documentation in Kotlin is Kdoc. It takes the comments preceding class and member declarations and converts it into documentation. 
There is a convention to be followed for those comments to appear in the docs the first line. Is usually a summary followed by a more detailed description and then the parameters and return types described. The latter is specified with the help of prefixes such as 
@param, @return, @constructor, @properties, @throws, @exception, @sample, @see, @author, @since,@suppress. Text can also include link to references on the same page by enclosing terms in square braces. Module and package annotation is made with declarations in a separate file and passed to a tool called Dokka.

Dynamic component system can be specified with the help of OSGI specifications. 

Components are packaged in bundles which communicate locally or via services across the gateway and hence the acronym for open services gateway interface.

 Kotlin offers support for this specification with the help of a separate Kotlin-Osgi-bundle library which replaces regular libraries such as Kotlin-runtime, kotlin-stdlib and Kotlin-reflect. The usual gradle tag to specify exclusions Aldo works for these above referenced libraries. The manifest requirement in other languages to specify the Osgi bundle is also possible in Kotlin but it is not sufficient. That option is certainly the most preferred way but it does not solve a well-known package split issue. 


Sunday, May 10, 2020

Kotlin vs Java continued

Kotlin has a wide variety of tools available. These tools are available from gradle, maven, ant, compiler opts, plug-ins, Kapt, Dokka and Osgi. These tools and their plug-ins help Kotlin support multiple languages.  
Gradle has a number of plugins which are determined at the outset and very early before the compilation of the code.

Gradle can optimize the loading and re-use of plugin classes, allow different plugins for different versions of classes and provide editors which detail information about the potential properties and values in the buildscript.

The plugins can also be extracted during compilation rather than require pre-installation. It might look like the traditional apply() method in gradle is no different from the plugins block  and that they both serve to list plugins and their versions but the latter is actually more recent, has more rigorous checks, constraints and restrictions.  If we want to avoid the restrictions, we could make use of the buildScript block.  Gradle has support for multi-project builds so the build.gradle is composable for different projects

The KotlinOptions in gradle allows us to set compiler options. Common options include:

-nowarn to suppress display warnings during compilation. And it’s opposite 

-Werror which turns warnings into errors

-script which evaluates a Kotlin script file

-Kotlin-home which specifies a custom path to the Kotlin compiler

-plugin and corresponding version to include plugins

-progressive mode where the compiler evaluates deprecation and bug fixes for unstable code instead of going through a graceful migration cycle. The progressive mode is important for stability and backward compatibility of code because it makes the changes in the code for breaking changes in the compiler. A breaking change for a compiler is one where the compiler throws an error now when it did not earlier.

In addition to the above parameters, JVM parameters can also be passed to the build.

Saturday, May 9, 2020

Kotlin versus Java continued...


Global variables are an example of shared state but they bring about unintended concurrency runtime. Kotlin mitigates that by allowing global variables to be accessible only from main thread unless otherwise specified, allowing thread local storage and shared immutability. These enable race free programming. The freeze function enables immutability of object subgraph. Primitive references like AtomicInt and Atomic Reference are frozen by default.  


The checks for mutability involve immutability check as well as whether the object is mutable from a single thread. This is referred to as “mutable xor global” check. The freezing helps with the immutability while the thread local storage helps with mutability that is hidden from others.  


The native library is produced from Kotlin by specifying a parameter to the compiler.  


There are also toolsaside from the compiler Kotlinc, such as Cinterop which produces klib wrappers for native libraries. The klib tool allows us to inspect and install these libraries the Kotlin native libraries are an archive file of predefined directory structure. Some libraries have proper module.Map file that describe the relation between header file and modules 

Kotlin has a wide variety of tools available. 


These tools are available from gradle, maven, ant, compiler opts, plug-insKaptDokka and Osgi. These toolsand their plug-ins help Kotlin support multiple languages.  


The plugins can also be extracted during compilation rather than require pre-installation. It might look like the traditional apply() method in gradle is no different from the plugins block  and that they both serve to list plugins and their versions but the latter is actually more recent, has more rigorous checks, constraints and restrictions.  If we want to avoid the restrictions, we could make use of the buildScript block.  Gradle has support for multi-project builds so the build.gradle is composable for different projects 

Thursday, May 7, 2020

Kotlin vs Java continued

Kotlin vs Java continued... 
As with many platform independent language, JavaScript supports reflection but it does not include all of the Kotlin reflection API. It is restricted to the class corresponding to the given type.  Even the class information is pared down to just the simpleName and isInstance members. The JavaScript class information can be found from the jsClass instance retrieved via the KClass. This can be used to interoperate with JS functions with the help of a reference to a constructor.
The Kotlin/gradle plugin also has some useful features for JavaScript integration with Kotlin. For example, the gradle plugin allows us to publish the javascript as resources using nonmodule reference to as content in a content distribution network represented by an S3 storage.  The plugin directly publishes the jar and resources to the S3 storage.
The Kotlin/gradle plugin supports dead code elimination. This is often referred to as “tree shaking”. It reduces the size of the JavaScript code by removing unused properties, functions and classes. It does not minify the JavaScript. That can be done independent of this step.  Some examples of unused declarations include inlined functions that never get called, module that uses a shared library such as the Kotlin standard library which is about 1.3 Mb while only a smaller portion of it might be needed to compile and any unused variables. The corresponding gradle task that invokes this step is ‘browserProductionWebpack’
Certain declarations help override elimination such as ‘dceTask’ block and ‘keep’ function.  The parameter to this function must include the module name prefix-ed fully qualified name of the decaration. If the declaration is not recognized, it may need to be decorated in a documented manner.
The gradle plugin allows dependencies to be shown with the task by the same name. The dependencies task helps view the transitive dependencies other than what is included in build.gradle. This comes helpful to specify exclusion of older redundant dependencies, remove those with potential security vulnerability and specify upgrades to existing versions of transitive dependencies. 
The CVE specific to Javascript/kotlin can be addressed with prudent use of dependencies and code changes. Code access security is not implemented either in JavaScript or Kotlin. The runtime can enhanced to make demands before code can be executed but jvm is already providing ability to sandbox so special language constructs for specific blocks of code are deemed unnecessary. 


Wednesday, May 6, 2020

Kotlin vs Java continued...
for browser targets. Directories can be distributed by specifying it in the build script. 
When JavaScript is called from Kotlin function, it can be inlined with the js(…) function. Other than that, all member functions, optional parameters, classes and interfaces can be written in pure JavaScript and marked with the external modifier. The compiler skips these declarations for generating JavaScript code and the onus on the developer to provide the necessary implementation.
JavaScript does not have the concept of interfaces. Instead JavaScript objects with those methods are passed to the code. A good example for the application of this pattern is the settings object.
The reverse is also made popular with Kotlin being called from JavaScript. For this purpose, Kotlin creates an object that contains all the declarations from the current module. 
The KotlinJS module allows generated functions and attributes in JavaScript code to have specific names when the generated names are unfriendly. This is done with the help of @JsName annotation. This annotation parameters takes a string literal
Kotlin has some direct mappings between its basic types and those in JavaScript. For example, a String and an Array map directly to the JavaScript. Primitive array translation is mapped to JavaScript TypedArray in more recent versions.
The compilation of Kotlin projects to Javascript modules is supported in one of four options:
1) Plain when there is no compilation for any module system
2) Asynchronous module definition which is used by require.js library
3) CommonJS convention which is used by npm and involves both require function and module.exports object
4) Unified Module Definitions which is compatible with both AMD and common JS.
This ‘moduleKind’ option is specified in the build.gradle in the ‘compileKotlinJs’ task.
Just like Javascript libraries can export multiple packages from within a module, Kotlin also allows multiple packages to be exported but each package will require a new source file with .kt extension.
Finally, Kotlin also supports a JsNonModule notation which allows the code to be imported in non-module environments such as in Project’s static resources.

Tuesday, May 5, 2020

We continue with our discussion on Java versus Kotlin
There were a few requirements of invoking JavaScript in languages like Kotlin that doesn’t change. These include:
Specifying keywords to denote external code implementation in JavaScript
Allowing inheritance and static membership.
Ability to proxy and extend the implementation with extension classes by giving it the same level of representation as first class citizens of Kotlin.
Ability to bridge the programming paradigm of Javascript with the functional languages. For example, Kotlin does not support dynamic types when targeting ‘jvm’ plugin type
Ability to perform code access security when running in server mode
Ability to maintain strict level for JavaScript consistency and canonicalization of logic expressed in JavaScript
Support for the numerous frameworks and plug-ins that JavaScript comes with. For example, Json with padding provides a method to request data from a server in a different domain. This was previously prohibhited to ensure same origin policy but has since been addressed with Cross-Origin resource sharing (CORS). This way JsonP helps with script element injection or reuse of an existing one. CORS may improve security but JsonP improves functionality providing different purposes and need to run with the language support.
JavaScript dependencies are managed by npm which is a public repository with tools to download the packages. Kotlin allows us to declare these dependencies in the build script and leverages the Yarn package manager to download the packages. It also generates a webpack module bundler configuration for browser targets. Directories can be distributed by specifying it in the build script.
When JavaScript is called from Kotlin function, it can be inlined with the js(…) function. Other than that, all member functions, optional parameters, classes and interfaces can be written in pure JavaScript and marked with the external modifier. The compiler skips these declarations for generating JavaScript code and the onus on the developer to provide the necessary implementation.
JavaScript does not have the concept of interfaces. Instead JavaScript objects with those methods are passed to the code. A good example for the application of this pattern is the settings object.
The reverse is also made popular with Kotlin being called from JavaScript. For this purpose, Kotlin creates an object that contains all the declarations from the current module

Monday, May 4, 2020

We continue with our discussion on Java vs Kotlin


One of the best advantages of using Kotlin code is its ability to invoke JavaScript consider the equivalence in ASP. NET programming where the server side could invoke JavaScript. Theree were limitations to what the server could execute that the client cannot but overall the facility was widely appreciated because it gave the convenience of not being limited by resources. The server side was always heavy duty and had better hooks than client side. The server side also provided the ability to run custom controls and the ability to allow seamless debugging.

There were a few requirements of invoking JavaScript in languages like Kotlin that doesn’t change. These include:

Specifying keywords to denote external code implementation in JavaScript

Allowing inheritance and static membership.

Ability to proxy and extend the implementation with extension classes by giving it the same level of representation as first class citizens of Kotlin.

Ability to bridge the programming paradigm of Javascript with the functional languages. For example, Kotlin does not support dynamic types when targeting ‘jvm’ plugin type

Ability to perform code access security when running in server mode

Ability to maintain strict level for JavaScript consistency and canonicalization of logic expressed in JavaScript

Support for the numerous frameworks and plug-ins that JavaScript comes with. For example, Json with padding provides a method to request data from a server in a different domain. This was previously prohibhited to ensure same origin policy but has since been addressed with Cross-Origin resource sharing (CORS). This way JsonP helps with script element injection or reuse of an existing one. CORS may improve security but JsonP improves functionality providing different purposes and need to run with the language support.