Swift for Beans – Java Developers view on Swift

swift-ogA large open source community has grown around Swift, since Apple open sourced it along with a Linux Port back in Dezember 2015.

Certain parallels can be drawn between the evolution of Java and Swift. Java was first a portable platform independent client-side technology that slowly found its way to the server side. A similar pattern can now be seen when looking at the Swift ecosystem. Starting out as a client side technology for developing IOS and OS X applications. The release of Swift as an open source community driven language, along with the Linux port, have given rise to an array of frameworks, utility libraries and server projects.

Currently there are three major active web server projects:

For an overview of the Swift ecosystem visit IBM Swift Package Catalog.

So why is Swift more than “yet another language”? Its still a third generation language, so there are no major advantages or productivity boosts as opposed to any of the other major contenders.

Memory Footprint

Java and other languages that compile to Java byte code run on the JVM. In a world of Docker containers the JVM is just YET ANOTHER LAYER eating up resources. The claim “write once run any where” is just as true for a Swift applications packaged into a Docker container as for a Java Application running on top of a JVM.

Running an application in JVM, that is running in a Docker container, that is running on a virtual host seems rather ludicrous. Swift compiling to native machine code, has the advantage of a rather small memory footprint. When running hundreds or thousands of instances, as many tech companies do, even saving a couple of MB on memory footprint generates real business incentive.

Ian Partridge compiled N-Body Benchmark results from Debian Benchmark Game for his presentation “Swift: the mobile language that’s coming to the cloud” (you can view the full presentation here).

Java even managed to outperform Swift ever so slightly 22.53s vs. 23.53s in the N-Body Benchmark.

When looking at the other benchmark results the picture is rather mixed. Swift leading by significant margins for mandelbrot, binary-trees and fankuch-redux. Whilst Java has the lead in pidigits, k-nucleotide and regex-dna benchmarks. Most notably Java has a significant lead in regex-dna (4.56s vs. 102.57s). This will undoubtedly improve as Swift and its API’s mature.

More importantly is the amount of memory used, Java uses 28,212 KB vs Swifts 4,348 KB, depending on the benchmark the memory advantage varies but Swift still beats Java by significant margins in all benchmarks.

Memory Management

Garbage collection has eased memory management for developers, delegating the nitty gritty business of memory management to the JVM. Swift, just like Objective-C, utilizes automatic reference counting (ARC), admittedly its not as hassle free as garbage collection, especially when dealing with cyclic references. Swift however provides decent ARC API for dealing with these issues (see ARC and Memory Management in Swift). Claiming that memory leaks are unheard of in Java applications also belongs in the realms of legends.

Also garbage collection comes at a high cost. Employing concurrent mark and sweep algorithms, it still requires more memory and CPU cycles then immediately assigning and releasing memory as needed.

Developer availability

A major consideration point when adopting a technological stack is the availability of skilled developers. Swift has been around since 2014 and has become the primary language for IOS and OS X development, garnering a substantial crowd of capable developers who are all to eager to also develop the server sided code to their applications.


Tooling is another important factor when considering technological stacks. Java has a very mature tooling stack, supported by three major IDE (Eclipse, Netbeans and Intellij) and a large supporting ecosystem around it.

As for Swift, the tooling is still fairly limited. The obvious choice is XCode which limits it’s use to OS X. If you want to develop on Linux or any other platform you are faced with a choice of “code editors” which are mostly limited to syntax highlighting. JetBrains CLion being the one exception, providing Swift 3 support via an AppCode based Swift 3 plugin.


For “traditional enterprise” applications, the load is usually fairly low, dealing with a tens maybe hundreds of concurrent users. Having one or four servers running doesn’t have any real cost impact in the grand scheme of enterprise applications. However, when considering tech companies that operate with hundreds, thousands, if not 10s of thousands of instances this becomes an entirely different story.

Considering that the main driving force for Javas ecosystem usually comes from the tech companies rather than traditional enterprises, there may be a movement towards Swift. This may in turn drain resources away from the Java ecosystem.

Its important to note that Java is in its prime years, and with all the active development on and around Java, it is far from declining or dead. However there is a new kid on the block and it has more to offer than just “syntactic sugar”, it has a real business “value proposition”.


I would like to thank Björn Sonntag and Robert Meyer for reviewing my posts.

16 thoughts on “Swift for Beans – Java Developers view on Swift”

    1. Also ARC doesn’t save CPU cycles in comparison to other garbage collection schemes – it can actually be slower, especially in a multithreaded environment.

    2. It’s a little more complicated than that; value types are inlined if possible but more complex ones are actually stored on the heap, but it all happens under the hood and the most important thing is the copy on write mechanism.

  1. » More importantly is the amount of memory used … Swift still beats Java by significant margins in all benchmarks. «

    The difference between Swift memory usage and JVM default memory allocation in 100-line toy benchmark programs really isn’t important.

  2. » Java even managed to outperform Swift ever so slightly 23.53s vs. 22.53s in the N-Body Benchmark. «

    The “N-Body Benchmark Duration” chart is kind-of misleading 😉

  3. As for me, the possibility to drop the JVM can only be an advantage, so I’m looking forward to see how Swift will evolve, in particular on the server’s side.

  4. I don’t think garbage collection is the main cause of Swift’s lower than Java memory usage. Go which is garbage collected as well was lower than everything but C++.

Leave a Reply

Your email address will not be published. Required fields are marked *