From JS to Java: A JavaScript Dev's Journey (Part 2)

Well, I realized after my first post that I'd already forgotten something I wanted to bring up. As developers, we know different languages have different syntax. It shouldn't drive me nuts but I wish the Java lambda expression arrow operator (->) matched the JavaScript's fat arrow (=>). That one is going to take some getting used to. From my research, it looks like the Java arrow was introduced in Java 8 which was released on March 18, 2014. JavaScript’s fat arrow came a bit later in ES6, released in June 2015. Interestingly, it seems the decision to use -> in Java was made as far back as 2011, as noted by this email from Brian Goetz. The TL;DR from the email: -> had already proven successful in C# and Scala so why fix what isn't broken? Maybe it should drive me nuts that JavaScript chose to go with =>, rather than it being the other way around. Topics covered in this session: Loops Methods Consistency Rant Methods (cont.) Overloaded Methods Variable Scope Other Closing Loops Disclaimer: This next statement isn’t meant to be a reflection of the course itself, only the material presented - loops were boring. While, do-while, and for loops were essentially the same as JavaScript. I could’ve skipped that, but hey, you don’t know what you don’t know! There was actually a moment where Angie was discussing nested loops and the convention of using "i" and "j" as counter variable names within for loops. She mentioned we usually start at "i" and just proceed through the alphabet ("i", "j", "k", etc.). She then said: "But you should rethink life if you get three loops in." I was thinking it, but I loved that she said it. I got a good chuckle out of that one. Methods Now it feels like we're really sinking our teeth into something. The first line of a Method declaration is called the "Method Header". Method Header syntax: access-modifier | non-access-modifier | return-type | method-name | parameters Note: The access modifier and non-access modifier are optional. If no access modifier is supplied, it defaults to "protected" which means only other classes within the package can use it. There is no default for the non-access modifier, the method just won't have any non-access behavior. This is definitely different from JavaScript where we would basically just have: function-name | parameters I think most will have made this assumption due to Java being a statically typed language but we also have to specify the datatype of each parameter in the method definition. This is more work but I appreciate taking the guesswork out of it for yourself or other developers later. Detour Consistency is one of the things I love about programming. With consistent inputs, you should be able to expect consistent outputs. With a language like JavaScript, how can you be sure your input is consistent if you're not explicit giving it a type? I'm sure fellow JavaScript devs following along are thinking "Well you are mentally giving it a type when you create it." Right... but how does that scale? I’ve definitely encountered code where sometimes you get back a number formatted as a string, and other times it’s an actual number. Tracking down every instance of that variable to figure out where the type was being flip-flopped is not fun - especially when the variable is used heavily throughout a file. Note: I know TypeScript is a thing and that's fantastic. I probably should have mentioned earlier, for sake of this series - we're talking plain JavaScript. Methods (cont.) While learning about Methods, someone asked one of the same questions that I did in Part 1! The question I'm referencing boiled down to "Why do we pass the parameters String[] args to main"? Ladies and gentlemen, we have an answer: The main method can expect to take in flags or an array of strings! To use strings from this array, you’d just index into args. Simple enough! I thought I had deduced the “array of strings” part just from reading TypeScript here and there, but I don’t like making assumptions. Overloaded Methods So this is an interesting one to wrap my mind around. Methods are uniquely identified by their "signature". A signature consists of the method's name and parameter list. There can be multiple methods with the same name but they must have unique parameter lists. The variable name is irrelevant, the parameters for each method must accept different data types. My Brain: So Java just knows which method to use by reading the data type of the input passed...? Answer: Yes! I have to give ChatGPT credit where credit is due here. It seems that's exactly how it works. ChatGPT: "The Java compiler determines at compile time which method to call based on the arguments you pass in." Code example given in response: public class Example { void print(String s) { System.out.println("String: " + s); } void print(int i) { S

Apr 9, 2025 - 06:26

From JS to Java: A JavaScript Dev's Journey (Part 2)

Well, I realized after my first post that I'd already forgotten something I wanted to bring up. As developers, we know different languages have different syntax. It shouldn't drive me nuts but I wish the Java lambda expression arrow operator (->) matched the JavaScript's fat arrow (=>). That one is going to take some getting used to.

From my research, it looks like the Java arrow was introduced in Java 8 which was released on March 18, 2014. JavaScript’s fat arrow came a bit later in ES6, released in June 2015. Interestingly, it seems the decision to use -> in Java was made as far back as 2011, as noted by this email from Brian Goetz. The TL;DR from the email: -> had already proven successful in C# and Scala so why fix what isn't broken?

Maybe it should drive me nuts that JavaScript chose to go with =>, rather than it being the other way around.

Topics covered in this session:

Loops
Methods
- Consistency Rant
Methods (cont.)
Overloaded Methods
Variable Scope
Other
Closing

Loops

Disclaimer: This next statement isn’t meant to be a reflection of the course itself, only the material presented - loops were boring.
While, do-while, and for loops were essentially the same as JavaScript. I could’ve skipped that, but hey, you don’t know what you don’t know!

There was actually a moment where Angie was discussing nested loops and the convention of using "i" and "j" as counter variable names within for loops. She mentioned we usually start at "i" and just proceed through the alphabet ("i", "j", "k", etc.).

She then said:

"But you should rethink life if you get three loops in."

I was thinking it, but I loved that she said it. I got a good chuckle out of that one.

Methods

Now it feels like we're really sinking our teeth into something. The first line of a Method declaration is called the "Method Header".
Method Header syntax:
access-modifier | non-access-modifier | return-type | method-name | parameters

Note: The access modifier and non-access modifier are optional. If no access modifier is supplied, it defaults to "protected" which means only other classes within the package can use it. There is no default for the non-access modifier, the method just won't have any non-access behavior.

This is definitely different from JavaScript where we would basically just have:
function-name | parameters

I think most will have made this assumption due to Java being a statically typed language but we also have to specify the datatype of each parameter in the method definition. This is more work but I appreciate taking the guesswork out of it for yourself or other developers later.

Detour

Consistency is one of the things I love about programming. With consistent inputs, you should be able to expect consistent outputs. With a language like JavaScript, how can you be sure your input is consistent if you're not explicit giving it a type?

I'm sure fellow JavaScript devs following along are thinking "Well you are mentally giving it a type when you create it."

Right... but how does that scale?

I’ve definitely encountered code where sometimes you get back a number formatted as a string, and other times it’s an actual number. Tracking down every instance of that variable to figure out where the type was being flip-flopped is not fun - especially when the variable is used heavily throughout a file.

Note: I know TypeScript is a thing and that's fantastic. I probably should have mentioned earlier, for sake of this series - we're talking plain JavaScript.

Methods (cont.)

While learning about Methods, someone asked one of the same questions that I did in Part 1! The question I'm referencing boiled down to "Why do we pass the parameters String[] args to main"?
Ladies and gentlemen, we have an answer: The main method can expect to take in flags or an array of strings! To use strings from this array, you’d just index into args. Simple enough!

I thought I had deduced the “array of strings” part just from reading TypeScript here and there, but I don’t like making assumptions.

Overloaded Methods

So this is an interesting one to wrap my mind around. Methods are uniquely identified by their "signature". A signature consists of the method's name and parameter list. There can be multiple methods with the same name but they must have unique parameter lists. The variable name is irrelevant, the parameters for each method must accept different data types.

My Brain: So Java just knows which method to use by reading the data type of the input passed...?
Answer: Yes!
I have to give ChatGPT credit where credit is due here. It seems that's exactly how it works.

ChatGPT: "The Java compiler determines at compile time which method to call based on the arguments you pass in."

Code example given in response:

public class Example {
    void print(String s) {
        System.out.println("String: " + s);
    }

    void print(int i) {
        System.out.println("Int: " + i);
    }

    void print(double d) {
        System.out.println("Double: " + d);
    }

    public static void main(String[] args) {
        Example ex = new Example();
        ex.print("Hello");   // calls print(String)
        ex.print(10);        // calls print(int)
        ex.print(10.5);      // calls print(double)
    }
}

I feel like I should mention this: I originally intended for these posts to spend more time directly comparing JavaScript and Java. I suppose I’m discovering why they’re two distinctly different languages. That said, I do expect to find more overlaps or comparable patterns soon. Let's press on!

Variable Scope

In keeping with my statement just above, now comes a great subject for comparison!

For the most part, variable scoping is basically the same in JavaScript and Java. If you're a JS-dev post-var (using let and const instead), you can probably just move on. If you want to nerd out, feel free to read on for a quick discussion surrounding hoisting.

In JavaScript, var is hoisted to the top of its scope but without it's value (undefined). let and const are scope-hoisted too but they are in the temporal dead zone. If you try to access a let or const variable before initialization, you'll get a ReferenceError instead of undefined.

In Java, there is no hoisting. You must declare and initialize variables before you use them.

I had to dig a little deeper here. In the little bit of Java I've written now, I'm definitely calling methods within main even though they are defined below.

Java uses a full compilation step. The entire file is read top to bottom before the program runs. Every variable, class, method, and import is resolved, checked, and compiled.

If you read that and went "...that kinda still sounds like hoisting..." - hoisting is a runtime behavior for JavaScript. In Java, everything is parsed and validated at compile-time. I'm sure there are other things that differentiate them but this is enough for me at the moment.

This would maybe make for a good, tricky interview question but we probably don't care much in our day-to-day.

Other

Quick tip: You can call a method you haven't created yet, passing it the arguments you would after it exists. IntelliJ will go "I gotchu!" and just straight up create the method using the data types of the arguments you passed when you called it. Am I way too hype over this? That's so sick.

Closing

My impression still remains the same as it did initially — not so bad! The reasons Java is considered a “stricter” language than JavaScript are actually the things I appreciate most about it so far.

It all seems to come back to the consistency I ranted about earlier.

Thanks so much for following along and I hope to see you in the next one!

P.S. At this rate, we might end up with 10+ parts in this series. How do you feel about the length? Should I try to pack more in per post, or does the pacing feel good to you?