Javascript vs. Java

Javascript and Java are NOT the same

Over the last year, we’ve expanded into IT Staffing and Recruiting. In spinning that up, I’ve been doing a lot of interviews. I’ve been surprised at how many Automation Engineers and prospective SDETs apply for Javascript jobs and answer that they have X years of Javascript on the application, when they have used Java instead.

I’ve even gotten to the point of asking folks to talk about the difference between the two languages in order to help isolate this issue.

I’ve also met many technical folks who call Java programs, files or applications “java scripts”. This overloading of terms is likely the culprit of not a few mislearnings.

It’s also understandable that folks could look at code in java and javascript and see that they look similar. But they are not.

Javascript and Java are not the same. They’re VERY different languages. Here is what I hope is a comprehensive comparison of Java vs. Javascript.

Ownership

Java is owned and managed by Oracle Corporation (as of this writing, in 2021). It was created in the 1990s my James Gosling. It was originally called “Oak” among other names… you can learn more here.

Oracle gained the rights to Java with the acquisition of Sun Microsystems in 2010. If you don’t know who Sun is, well, you’re just too young. Get off my lawn!

Javascript, on the other hand, was originally created by Brendan Eich in the mid 1990s and owned by Netscape (if you don’t know who Netscape is, refer to above “lawn” comment). Netscape Navigator (one of the early graphical browsers) interpreted Javascript that was served up by web servers and embedded in web pages.

For many years, Internet Explorer worked on JScript instead of Javascript and made the development of cross-browser webpages a nightmare. JScript and Javascript were so similar, yet so different that coding for them both was barbaric. I’d venture to say as bad or worse than most cross platform C/C++ and their precompile directives.

Netscape originally called Javascript “Mocha”. If things weren’t confusing enough, now there is a unit testing framework in javascript with the name mocha. Apparently coffee was really important to software development in the 90s. 🙂

Eventually standardization came in the form of ECMAScript (or ES). This is the organization (ECMA) that standardized the language and works to develop new features of Javascript. Javascript is also referred to as ES6, ECMA6 and ECMAScript 6.

Design

Java was designed to “write once, run anywhere”. It uses a runtime environment to run machine code that is generated by a compiler. Because it is compiled into machine language it is not, strictly speaking, an interpreted language. Because it is interpreted on at runtime virtual machine, it is not, strictly speaking, a compiled language. For many years, people have referred to it as a “hybrid” language, having characteristics of both types of languages.

Javascript is interpreted. Originally, it was designed only for the browser and over time, each browser contained an interpreter. The ECMA standard helped browsers evolve to interpret javascript mostly the same today.

With the creation of Node.js, javascript was teleported from the browser and spawned on to any machine anywhere where node can run (Win, OS X, Linux, etc). Characterizations of Javascript being “client side” are no longer correct. In fact, many of the most modern enterprise applications (since about 2013) run on node and are written in Javascript using node.

Javascript can also be (pre)compiled into specific bundles compatible with different node versions. Additionally, Typescript can be “compiled” into Javascript, for definitions of “compile” as loose as javascript’s types. There are also “compilers” like Babel that enable writing javascript with more recent standard language features to scripts which are interpretable by interpreters written with earlier standards.

Frankly, any conversation about compiling javascript is beyond my comfort zone – so if you have more experience, please post in the comments with references and I’ll add if it is helpful.

Programming characteristics

Java is an Object-Oriented Programming language. The smallest compilable component of a java program is a class which defines the behaviors of an object at runtime.

Classes have strict access definitions (unless you cheat and use reflection to thwart them). Classes contain data, called members and functions called methods.

Java is strictly typed, meaning it has primitives (int, boolean, float, double, char, etc) and higher-level classes which define more complex types. All defined variables must have a type defined (or class). The exceptions to this are interfaces and abstract classes with basically give you malleable type and enable what we call “polymorphism”.

Java’s architecture allows for inheritance from one class to the next of members and methods.

Javascript on the other hand, is not object-oriented. It is more of a functional language, in that functions can be passed between functions and referenced. A function is the lowest level component of the language.

Variables in Javascript must be declared, but not necessarily typed or defined. Like other loosely-typed languages the interpreter is responsible for figuring out what to do with a variable and how to interact with it. For instance, zero could be a string, character, or number, but the language doesn’t care until it’s used for something. For some people, this makes the language “easier” to learn. For others who are used to the comfy confines of strongly typed languages (like me) it is vertigo-inducing.

Javascript allows for objects, but they are basically all just key-value pairings which can be worked with natively in JSON.

Uses

While Java was originally designed and targeted to work for client-based applications, it has become widely used on enterprise and service-side applications.

While javascript was originally designed for browsers it also being used (with node) on the enterprise/service side.

Syntax

To the untrained eye, the two languages look very similar, but as you work with each language some major differences become apparent.

For instance, in Java, objects passed to methods are said to (this is a bit of a lie, explained here: https://stackabuse.com/does-java-pass-by-reference-or-pass-by-value/) be passed by reference (primitives are by value). For almost all pragmatic programmers an understanding of java as passing objects by reference works.

Note: technically, java passes the value of a reference to an object, but that’s not really a distinction most people make, in practice its easier to conceptualize as passing by reference.

By contrast, in Javascript there are no first class objects and variables’ values are passed to functions.

Even the dot notation is different.

The concept of “this” is completely different between the languages.

Scope is different (if you’re a Java-native person, check out “hoisting” in Javascript if you want your mind blown).

Javascript in node runs asynchronously – meaning the return from a function doesn’t necessarily block running the next line of code. Instead, you manage that by hand, using something like async blocks or promises. To make things even more unsettling for those coming from Java – control flow of the language and even syntax in Javascript can be supplemented with libraries, like in the case of certain promise libraries.

Additionally Java has more native support to access system resources than Javascript, including filesystems, processes, and network resources. Some of those things can be done in Javascript, but not natively and sometimes not from the browser. This is another area outside of my comfort-zone, so please supplement or better illustrate in the comments.

Ecosystem (dependency management)

One of the most overlooked differences between programming languages is what I call “ecosystems”. Language ecosystems consist of the tooling near and around the development and deployment of applications built in a language. These tools can be dependency management tools, package managers, IDEs, runtime considerations and configuration, runtime environments (like web server applications), and common partnering applications in tech stacks. For brevity and by way of exemplifying how significant each type of tool can affect those using these languages, I’ll focus on dependency management tools.

In Javascript, dependencies in the browser are as simple as defining a location on the web where a client should go to find the dependency. The browser then requests that package and uses it as the code requires. Node provides a package manager called npm (node package manager). There are also other package management tools that can replace certain functionality of npm, but I’ll focus on npm. Node’s package manager uses a configuration file (usually package.json) to configure libraries and versions of libraries along with locations of those libraries. NPM uses a local cache of those files, built on first use of certain npm commands. The remote repository for those official libraries is generally findable on sites like npmjs.com. For example, the documentation mocha package (used for unit testing) is here. This page gives all the information you would need to configure package.json for your use, although usually you can just tell the npm program to install mocha for your dev environment and it would set up package.json for you.

Any dependency issues are found at runtime (by virtue of being an interpreted language). Runtime can be simulated, of course, in an IDE or other environments.

Java on the other hand, needs dependencies at “compile time”, when the machine code is generated. Two heavily used dependency management tools in Java are Gradle and Maven. Because my experience in maven is more rich, I’ll talk about it.

Maven is a program (mvn) that runs through a lifecycle related to code development. The actions associated with different phases of that lifecycle are defined in a file called pom.xml. On first running, like npm, maven uses the pom.xml file to find repositories on the internet (or network or local file system) that contain the dependencies defined in the pom.xml file. These are then compiled into the java application at compile time. Maven allows for the type of packaging that should be provided for the compiled code (war, jar, etc). It’s been quite some time since I’ve worked with maven deeply, please feel free to provide updates and references in the comments.

Finally

There are many more differences between these languages, but these are a few off the top of my head.

Often I ask candidates for SDET and test automation roles what the difference is between two languages like java and javascript. Their answers tell me a bit about the depth of their understanding of computer science, programming, their technical experience, the degree of interest in the subject matter, and ability to retain knowledge and communicate it. All of those abilities are required by most SDET and Test Automation roles.

The question sometimes helps me start a conversation. Sometimes it determines if the conversation should continue.

I can’t tell you how many times I have people google the answer to this question and read it to me in a phone screening. Do folks really think I can’t hear them typing? That I haven’t looked up the default answer on google? Bing? others? That I don’t recognize the answers or when I’m being read to?

While I hope you learned something from this post, or found a way to contribute to its betterment, I’m mostly writing it out of selfishness. I guess if I have to choose, I’d rather hear people parrot my writing back to me than duckduckgo the answer for me.

Let me know if this article helps you!

And if you’re an SDET looking to work in javascript or java, check our posts on indeed and on this site.