21 posts

Jan 08 2021

Bug Fixing Day 278

This Thursday we had our Bug Fixing Day #278. We've managed to close 2 bugs (1 real fix) with 2 participant. We are still at -189 bugs behind the 500 days period. ...

Aug 26 2019

My GSOC19 Experience

Hello there! My name is Divyansh Jain. I am a student at Mahatma Jyoti Rao Phoole University. I have been selected as an Android developer for the XWiki organization and I've finished working on their XWiki Android Authenticator application in GSOC19. ...

Jun 26 2019

Reasons to choose Kotlin

Hello there! My name is Divyansh Jain. I am a student of Mahatma Jyoti Rao Phoole University. I have been selected as the Android developer for the XWiki organization and I am working on their XWiki Android Authenticator application in GSOC19.

XWiki android Authenticator aims to integrate a wiki instance in Android accounts, mainly including the synchronization of contacts and the XWiki authenticator. By synchronizing contacts of your company on your phone, it becomes easier to communicate and collaborate with each other.

Ever since the start of my work on the XWiki Android Authenticator app, I have been constantly learning new things. In the first week, I migrated most of the XWiki Android Application code from Java to Kotlin. And on this page, I would like to share my understanding of Kotlin that I have gained so far.

Getting started with Kotlin

Kotlin is officially supported by Google for mobile development on Android. It was released in Android Studio 3.0 on October 2017. At first, I was a bit afraid to switch to Kotlin since I feared that the code might crash and not run properly, but as I read the documentation, I started understanding the nuances of the language which made the switch from Java to Kotlin an easier process. I started realizing the advantages of Kotlin over Java. Some of them being:

Java Interoperability

I started with migrating the whole XWiki Android Authenticator app code from Java to Kotlin. I was replacing one Java file at a time, and while migrating I saw that Kotlin worked with Java smoothly. Though it required some direct imports, there were no errors in running the app on the device.

Changed variable declaration

In Java, we declare string for instance, String str = "Hello";.

In Kotlin, we declare string for instance, val str = "Hello" or val str: String = "Hello". Here val declares a read-only property or local variable whereas var declares a mutable property or local variable.

The final keyword is default in class

In Kotlin final is a default. E.g.

class Button {
   fun click() = print("Click")

class displayToast : Button() {  // Error
   override fun click() = print("Toast Displayed") // Error

In the above example, class displayToast can’t inherit Button class because it is final. Moreover, it can’t override click(), because it is final in Button.

open class Button {
   open fun click() = print("Click")
   fun doubleClick() = print("Double Click")

class displayToast () : Button {           // Inheritance is now possible
   override fun click() = print("Toast Displayed") // Now it works
   override fun displayToast () = print("Toast Displayed") // Error

In order to inherit and override, we put “open” keyword that allows inheritance and overriding.

Fun keyword for defining functions

Now in Kotlin, there is a new way to define functions. E.g.

fun displayToast() { } //with no arguments inside functions

fun addDigitis (a: int, b: int) : String { }  //with arguments inside function

It is same as the Java parameterized method or empty method.

The when expression

The "switch-case" is replaced with the much more readable and flexible "when" expression: E.g.

int x = 3
when (x) {
   1 -> print("x is 1")
   2 -> print("x is 2")
   3, 4 -> print("x is 3 or 4")
   in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10")
   else -> print("x is out of range")

It works without the argument too.

Static keywords

For declaring static methods & variables, you can put them above the class name, then you can use them by importing directly in other classes.

Null Safety

One of the biggest flaws in Java is the way it handles “null,” leading to the dreaded NulPointerException (NPE). Kotlin resolves this by distinguishing between non-null types and nullable types. Types are non-null by default, and can be made nullable by adding a safe call ‘?’. E.g.

var a: String = "abc"
a = null                // compile error

var b: String? = "xyz"
b = null                // no problem


So after seeing, reading and migrating the code from Java to Kotlin, in my honest opinion, I do not see any reason to not choose Kotlin over Java. For instance, we need to write less code as compared to Java, we don't have to face the dreaded ‘NPE’ error anymore, interoperability with existing Java files, smart casts while declaring variables and many more. We've given the fair amount of our time to Java, but it's time to let it go and welcome our new friend Kotlin.

Happy Reading.

Dec 21 2018

Highlights of the XWiki 10.x Cycle

10.x cycle is defined by having an improved usability for on-boarding new users and administrators: from protection against refactoring operations, to editing inline macro content, to more auto-suggests, to a faster user interface. ...

Aug 23 2018

XWiki Feedback Survey Conclusions - 2018 Edition

At the beginning of the year the XWiki development team launched a new XWiki features survey. We had 31 community members filling in this survey. We looked at all the responses and we'd like to share the conclusions with you. ...

Aug 21 2018

Features Brainstoming during the XWiki SAS Seminar 2018

Findings of the Features Brainstorming session held during XWiki SAS Seminar 2018, covering 82 ideas from 35 people on 4 topic categories: what features to add, improve, remove or make paying. ...

Jan 05 2018

Highlights of the XWiki 9.x Cycle

The biggest highlights of the XWiki 9.x cycle were the support of multiple Flavors and the introduction of the Notifications feature. We managed to have 1003 issues fixed: 480 bugs, 254 improvements, 53 new features and more. Read our Top 10 features from 2017. ...

Sep 01 2017

Programming Rights Fixing Day #1

Yesterday we have our first XWiki Day related to trying to remove the need for pages to have Programming Rights(PR). The reason we wanted to fix this is because when users who don't have Programming Rights modifies a page that requires Programming Right to work, then the page becomes non-functional (it's a security protection). Of course, users then don't understand why their wiki broke and this becomes a pain point. ...

Aug 01 2017

Highlights of the XWiki 8.x Cycle

Some highlights of what done during the XWiki 8.x Cycle: 1461 issues closed, counting 745 bugs closed, 423 improvements, 66 new features and more (CKEditor by default, new homepage, tour for homepage, default templates, etc.)! XWiki 8.4.5 is our current LTS (Long Term Support) version and you can download it. ...

Jun 29 2017

XWiki Enterprise is dead, long live XWiki!

With the release of 9.5.1 we have dropped the XWiki Enterprise distribution and instead we exposed the Flavor mechanism. Now when you install or create a new wiki you will be able to choose the Flavor you want to use. We expect in the future that the community members will provide additional Flavors built on top of XWiki and you could select between them when customizing your wiki. ...


Get Connected