https://kotlinlang.org logo
Join Slack
Powered by
Okay, finally got a valid output. Looks like I'm r...
# getting-started
w
Okay, finally got a valid output. Looks like I'm running Gradle 6.8
z
that would be the issue then, simply upgrade it to 7.0 or newer and it should work fine
w
Gotcha. Okay so since I posted that, I figured that was the case... I'm currently googling like crazy trying to figure out how exactly to do that.
Haha! I did it. looks like I'm on 7 now in the project.
I updated the distributionURL line in gradle-wrapper.properties from 6.8 to 7.0 then ran the wrapper task.... now when I check version it shows as 7
And now, where before it would sometimes run and sometimes error out with that bug, it now appears to be running every time.
So one last question, any time I spin up a new project, it appears to come up as gradle 6.8 instead of 7. Is there a way I can fix that for every new project?
z
I believe the wrapper is built into intellij
so updating intellij should fix it, I think
(provided their gradle version is 7.0+)
w
Gotcha, sounds like I have to wait then and just do it manually if I'm using JDK16 then, my intellij is running latest version
So with that, if all I'm doing is writing Kotlin applications targeting a JVM, is there a recommended JDK to be using?
I have no particular reason to use 16, aside from that was what showed up in my install.
z
No idea tbh, I only use Kotlin/Gradle for Android development, although I think there's the recommended/supported versions listed somewhere on the page
w
Gotcha, I'll go on a hunt for it. I'm normally in Android Studio and I've been blessed enough to not run into this problem until today. I took a pause from my Udemy Android App Course to really get into Kotlin and programming in it, as a result it's easier to just do it in intellij than try to force AS to run them like that.
Thanks again for all the help. It's definitely got me going on the right track.
z
no problem
c
If you can use any version, I think it's better to use at least JDK 8 (the lambda implementation is much better, default methods etc).
z
well, 16 is a lot newer than 8 🙂
and since 1.5.0 kotlin also supports JVM records and sealed classes I believe on JDK 16
w
Makes sense
c
Definitely, but JDK 8 bytecode for Kotlin is potentially much better, and takes less space. Support for JVM records and sealed class is only useful if you want Java interop, for a pure Kotlin project I don't think it makes any difference.
w
Interesting, so the older version would be better because of more compatibility?
c
To be fair though, the real answer is “use the most recent version your company/whatever allows you to use”, there's never been any case where a previous version was better than a later one
w
gotcha.
c
Exactly: if you use JDK 16, your users need to have JRE 16.
Note that I'm talking about the target JDK (the one in your build.gradle). The one you locally have installed doesn't make a difference.
w
Even if I target JVM 1.8 in my kotlin complier?
z
@CLOVIS I'm not familiar with how kotlin generates the bytecode, is there a regression when targetting newer JDKs? as far as I'm aware JDK didn't add any impediments for this
c
(essentially any JDK is able to compile for older JDKs, so if your clients have JRE 8, you can target 8 in your gradle and have whatever version you prefer installed yourself, as long as it's at least 8)
z
I would probably suggest 11 over 8, as it's the latest "LTS", afaik JDK 8 no longer receives public updates, does it?
w
I dont think it does. Wasn't that the first version after the licensing change?
z
well, every 3 years oracle supports a JDK (if you pay for it), latest is 11, and will be superceeded by 17 in september
c
JDK 8 doesn't receive updates, but if you have clients that still run it you might want to compile for it still (Again, that's the target JRE, you can target 8 but run 11 on your machine without issues)
w
Gotcha
Good lord, Java and it's versioning can be a bit intimidating for someone new to programming
c
So two questions I guess: • which JVM version do you target: the highest that you're sure your clients have installed • which JDK version do you install: the most recent one you have access to
w
Gotcha, that makes sense.
c
Or you could just target whatever and tell them to update their Java 🤷
w
XD
That does work as well
Sort of (saying that as a profession SysAdmin, people just LOVE when you force an update across the board)
z
yeah, depends entirely on your use case, if you're working on BE, and you handle deployment it's great having all the latest stuff like the new GCs
c
It really depends what you're making, if you're creating a backend it's probably fine to require a really recent version, if you create an app for technically-illiterate people, having it ‘just work' with their install is probably better Tbf many recent projects just bundle the JVM version they want into their binary, and boom. (See jpackage)
z
yeah, minecraft recently bumped it to 16
w
Oh dang, it did?
c
And well, your app will most likely be faster in a more recent JVM, so if your client can afford to update, it's better for everyone
z
yup
w
@CLOVIS Definately
c
But when it comes to Kotlin, if you don't need Java interop, anything after 8 probably doesn't make much difference at all
w
Right
z
well, the GCs are nice, but if you're not doing lots of allocations it probably wouldn't make much difference
w
Yeah, to be honest, for now this is purely a personal educational adventure, most of what I make will be run on my own machine as I learn Kotlin itself, and I will wind up migrating into Android Studio for app development. I've been taking a Udemy course and just recently got to a point that I felt that I really needed to build my Kotlin fundamentals prior to proceeding with it.
c
I mean, the GCs are in the version the client runs, not the version the developer targets You could target 8, run it on 17 and use all the shiny tools (just not the new APIs)
z
yeah, true
w
What are GCs?
z
garbage collectors
w
AH, gotcha
z
the thing that frees memory after you're done using the object
w
yep, I remember going over it a bit on android apps and recycler views
c
There are many different implementations that are good for different things, but to be fair it's an advanced subject and almost all projects don't even both trying out others than the default (to be fair, it is pretty good)
w
Yeah, that's what I've been gleaning from this whole thing, lol
z
yeah, by the time it becomes relevant for you you'll learn about it anyway
w
Yeeeep
Ight fellas, it's 2 in the mornin' here, time to grab some shuteye, but I'm happy that I can continue with this Kotlin book and not have to deal with that weird bug thanks to an old gradle build
Thanks again @Zan Skamljic for the help
c
Good luck 😅
z
no problem at all
2 Views
Open in Slack
PreviousNext
Powered by