This sounds like you are trying to shoehorn asynchronous kotlin code into synchronous Java code. Which would be doing it wrong. The problem is trying to make asynchronous code synchronous: don't do that. The whole point of asynchronous is to do it end to end and isolate the remaining synchronous bits and pieces that you have on separate threads so they don't end up blocking all the asynchronous bits and pieces that you have.
Use a proper asynchronous framework and then the only thing you need to worry about is avoiding calling synchronous code on your main thread (i.e. dispatch it to some thread pool backed co-routine context). Not that hard. And you can get rid of a lot of that stuff by gradually switching to non blocking versions of whatever you are using.
If you are exposing class properties without accessors in Java, that's not necessarily a great thing. Especially if your state is non final (i.e. mutable). In Kotlin, you'd use vals (or vars if you really have to) and by default they just behave like they have getters/setters. But you don't have to spell it out. And you can override the getters and setters. Just like you would in Java. It's just the distinction is not there. It's basically a less hacky Lombok.
The weirdly positioned text that your IDE adds are called hints and you can turn them on or off as you please. They are there to help you. Type inference is a nice thing: it means you can read the hints without having to spell out what is what. Java has type inference too but it's a bit more limited and more verbose. There is no uncertainty about what the type of anything is in either language: exactly what you specified (but just once in Kotlin's case).
Use a proper asynchronous framework and then the only thing you need to worry about is avoiding calling synchronous code on your main thread (i.e. dispatch it to some thread pool backed co-routine context). Not that hard. And you can get rid of a lot of that stuff by gradually switching to non blocking versions of whatever you are using.
If you are exposing class properties without accessors in Java, that's not necessarily a great thing. Especially if your state is non final (i.e. mutable). In Kotlin, you'd use vals (or vars if you really have to) and by default they just behave like they have getters/setters. But you don't have to spell it out. And you can override the getters and setters. Just like you would in Java. It's just the distinction is not there. It's basically a less hacky Lombok.
The weirdly positioned text that your IDE adds are called hints and you can turn them on or off as you please. They are there to help you. Type inference is a nice thing: it means you can read the hints without having to spell out what is what. Java has type inference too but it's a bit more limited and more verbose. There is no uncertainty about what the type of anything is in either language: exactly what you specified (but just once in Kotlin's case).