Should I just switch to Java?

[ctbe]

The answers I look on this question would be answers that would be mostly based on opinion. But if you have predictable facts, that would be awesome.

 

Yesterday I found out my project didn't compile and had to use Scorg to be able to compile it. I was thinking of re-writing it from scratch, but this time using Java because of fear that Scorg may stop being available in the future. I have been using Scala because I had many immutable collections which were providing me a slightly better performance although that wasn't always the case. In order to perform some operations, sometimes I had to make conversions from Scala collections to Java collections and those little pieces of code reduced my performance a little as well. Other times it was simply impossible to use some features of Forge due to the requirement of the use of static variables and/or classes which require you to do a little of workaround to get an equivalent in Scala. For example, I was unable to use the new @Config system with Scala. I had to use Java because no workaround got me a working config menu for my mod. Maybe if I had fiddled a little more with the code I could have gotten something working, but it was growing too ugly for the Scala style so I decided to use Java and combine it in the project. Previously I also had problems when using IProperty due to boxing concepts. I can't use Enums, but instead use objects that extends Enumeration. I cringe everytime I have to use equivalents to statics, but at the end have no options because of the way minecraft and forge were made.

 

Something tells me I should just use Java which is what minecraft and forge were made with and save me all the workarounds and pain simply because I like the Scala style more and it offers me just a slight performance in some specific cases (in ocassions a cleaner look of code too).

 

At this point I am trying to decide what to do. Simply use Java or stick to Scala and risk having to do many workarounds in the future to compile my project in case Scorg becomes unavailable or other kinds of workarounds to be able to use some features of Forge. What are your opinions, what would you do?

[ctbe]

  On 9/1/2017 at 6:57 PM, diesieben07 said:

I assume you used Scala because you did not want to write Java, because nobody really likes writing Java, right?

Expand  

Oh no, it wasn't because I didn't want to write Java. I was okay with it . I was expecting to make a mod which when I finished planning it, it required me to use a lot of Collections, and with that expectation, I knew I could use Scala (from previous experience) to my advantage and their immutable collections for a little bit of additional performance if I were to program it correctly. But after writing a good amount of code for my mod in Scala I was like "Ugh, going back to Java". 

 

Right now yes, though I'm okay with it, I'm reluctant to use Java, but at first no.

  On 9/1/2017 at 6:57 PM, diesieben07 said:

I mean, most of the time it's ok, but really, you have better ways to spend your time than to write 20 getters and setters every day.

Expand  

This is very true .

 

Thanks for the Kotlin suggestion. I'll look into it. Because my mod is still small, I might as well re-write it in Java before it grows further and use the default language most of the community uses. That way I'm more in sync whenever I have a doubt.

 

Thanks for the feedback, much appreciated.

[CosmicDan]

A lot of the complaints about Java are sourced from it's verbosity - as diesieben07 mentioned. But that verbosity is also the reason why Java is so popular in the enterprise sector - it makes large projects and collaboration MUCH easier. While it's of course a good idea to write lots of inline comments, Java's main benefit is that it's self-documenting. But again, others might consider it as "too verbose".

 

If you plan on making an opensource mod and like collaboration, I think you really should stick with Java. To save time on the verbosity and repetition, use Project Lombok (it's essential for me these days). Also if you use Eclipse, switch to IntelliJ IDEA - I was resistant to switch for a long time, but after a few days of configuring and learning I am VERY glad I swallowed my pride and took the time to switch and learn.

 

I know Kotlin is gaining ground, and is even now an officially supported Android development language, but sticking to relatively obscure languages will keep your contribution level similarly obscure. I tried to get into Kotlin but I honestly didn't see the point in partitioning my language focus for it's minor benefits. No companies out there will expect you to know it.

 

I personally don't care much for Kotlin. The null-phobia is a reactionary one that is yet-another level of abstraction that isn't necessary IMO and doesn't always provide NPE safety much anyway. But I'm the kind of guy who has my IDE warn me on fields that aren't explicitly declared to null Also it got rid of the ternary operator, and various other little things that just seem counter-productive. But I have a C++ background so yeah. It's obviously loved by a lot of people but it just isn't for me.

 

Java gets a lot of hate, and I've had my fair share of annoyances with it (I started working with C# a while ago and it's really a fantastic language) but I always come back to Java mostly because of the massive community, availability of resources and the volume of capable programmers. It's very easy for any programmer to grasp any Java that even loosely follows the standards and conventions (which is exactly why some criticize it as being too verbose).

 

In summary: I suggest Java with Project Lombok if you want to be community-friendly and keep your commercial-level programming well practiced. Almost all of the major issues people have with Java are solved with Lombok and Java 8's new functional programming additions (i.e. lambda's and method references).

Edited September 21, 2017 by CosmicDan

[CosmicDan]

  On 9/21/2017 at 11:23 AM, diesieben07 said:

Sorry, but I have to disagree with this. A lot.

There is nothing "self-documenting" about this:

public class StupidPojo {
    
    private final String foo;

    public StupidPojo(String foo) {
        this.foo = foo;
    }

    public String getFoo() {
        return foo;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        StupidPojo that = (StupidPojo) o;

        return foo != null ? foo.equals(that.foo) : that.foo == null;
    }

    @Override
    public int hashCode() {
        return foo != null ? foo.hashCode() : 0;
    }
}

 

It's noisy as hell, difficult to maintain and you don't want to read it, do you? Oh and worst of all, this is as simple as it gets.

Compare that to Kotlin:

data class StupidPojo(val foo: String)

If you ask me which of those two is better at self-documentation, I would pick the Kotlin version. You can clearly see "this is a class that has a property foo". Where as in the Java version your brain has to first get rid of all that noise.

 

Lombok is a terrible hack based on unsupported Compiler (and IDE, at least in Eclipse) internals. It's also abusing Annotations in terrible ways. I personally would not want to base my big "enterprise-y" application on such a sandy ground.

 

It's not necessary a phobia. null is a great tool, especially in Kotlin (more so there than in Java!). Kotlin makes null what Java's (stupid and clunky) Optional should have been. Fact is, you have "there is nothing here" values all over the place, and dealing with those properly is just great.

 

myObject?.owner?.name?.toLowerCase() ?: "no owner"

Try writing that in Java without losing your mind and still getting the point across.

 

The "problem" with Kotlin is that you look at the language for a few minutes and go "Oh, yeah, neat. But I can do that in Java, too". You really don't notice the tremendous benefits it brings to your code until you've written in it for like 2-3 weeks. Then you just look at your code and go "how did I ever live without this?".

But of course, to each their own.

Expand  

Lombok *is* used in the enterprise, is very mature (been around longer than Kotlin) and is endorsed by Oracle themselves. Of course, JetBrain's Kotlin is a direct competitor to Oracle's Java so it's not all surprising you've picked a side here. But if I were with a company that, for whatever strange reason, had a policy against Lombok, then I wouldn't be too fond of Java either.

 

I did write out more but decided to snip it - I don't really have strong opinions about this. Just stating that I don't see the point in learning Kotlin *personally* because it has no professional application yet. I'm not in love with Java but it's benefits outweigh the flaws in my use case.

EDIT: I want to iterate that I wasn't so much touting Java as technically superior to Kotlin, but rather (with Lombok) it's not THAT bad, and you can be sure to get much more support for it. Technical superiority isn't *everything*. I do find Kotlin interesting, though to me it seems not worth the time investment nor dealing with relatively obscurity, if outside of Android and maybe RAD. At least for the moment. I'll be keeping an eye on it. Java is pretty old fashioned and it doesn't look like it'll stop dominating market share any time soon but titans do fall.

 

EDIT2: I've been reading some more *recent* stuff about Kotlin and it seems it might be time I take another look at it.

Edited September 21, 2017 by CosmicDan

[CosmicDan]

  On 9/21/2017 at 1:18 PM, diesieben07 said:

???

Expand  

What do you recommend as a first foray into Kotlin? Or would diving straight in with Forge be OK for someone who already knows Java well? If so, how is that done - with this Forgelin thing?

[CosmicDan]

Fair enough, thanks for the info.

 

I just discovered that Kotlin/Native can now compile for Win32 and also seems to support calling the WinAPI natively, which is... whoa. Kotlin might just be going places afterall!

[LexManos]

Minecraft is Java. So mods should be Java. End of story.

No more language arguments here.