Here is a code example:
import com.my.package.util.fun1
import com.my.package.util.fun2
import com.my.package.util.fun3
import com.my.package.util.fun4
import com.my.package.util.fun5
import com.my.package.util.fun6
import com.my.package.util.fun7
Why not to remove repeating characters like this:
import {fun1, fun2, fun3, fun4, fun5, fun6, fun7} from com.my.package.util
This syntax is used in ES6/TypeScript and looks very compact and readable.
You can use import com.my.package.util.*
BTW, these import is supported from the IDE. I don’t see any problem when we import each package individually
There are some people in this world that just like using Notepad 
Our position is that, if you’re doing anything with imports manually, you’re doing it wrong. The correct way to deal with imports is to use auto-import and “optimize imports on the fly” features in the IDE. Because of that, making imports compact and readable is a non-goal - you’re not supposed to ever read them.
Statements like this put JetBrains at real risk of disenfranchising programmers (including myself) who prefer to program outside of a rich IDE.
Just use wildcard imports. That’s what I usually do. You run into conflicts so infrequently that it’s not worth worrying about until you do and then most of the time a simple alias will fix the problem. I don’t get why this isn’t the default anyways
Appreciate it!
The common Kotlin code cannot be read without an IDE anyway. There are so many context switches through extension functions that you often cannot see in the code where a called function is coming from.
I don’t mean this in a negative way. I strongly believe that the future of programming will rely heavily on IDEs and I hope Kotlin will go further into this direction.
Fair points, thanks for sharing that.
Certainly believe in a rich IDE being necessarily idiomatic for Kotlin. In addition, remaining accessible to vim/emacs/notepad development seems vital to it one day overtaking Java as the general-purpose JVM language of choice.
I can’t believe I just read that from somebody from JetBrains team. That’s an unfortunate answer.
Positions may change, right? 
I think there’s potential here for a more delightful developer experience for newer developers in particular—new to Kotlin, and new to the entire Java ecosystem. Figuring out “where stuff is declared” has typically been a challenge for me personally, especially when I began picking up Rust (and now I’m picking up Kotlin).
It would be nice to have a syntax like Rust’s use declarations
use std::option::Option::{Some, None};
use std::collections::hash_map::{self, HashMap};
… or ES6 imports…
import { useEffect, useState } from "react";
Reasoning is:
import io.javalin.*
import io.javalin.Javalin
import io.javalin.apibuilder.ApiBuilder.get
import io.javalin.apibuilder.ApiBuilder.post
import io.javalin.{Javalin, apiBuilder.ApiBuilder.{get, post}}
…maybe that looks silly. 
Just my 2 cents.
So as far as I understand it, the request is motivated by at least two things:
1) I want to see all imports (to know where things come from and what’s being used)
2) I want the import statement to be compact
Personally, I don’t mind if the import statements aren’t compact but instead if it’s readable and easy to see what is being used. So I’d add #3 as “I want the import statement to be readable”.
IMO, all of these cases are covered by the current system.
If you want compact import statements (#2) then wildcard is available.
If you want to see all of the imports (#1), you can write them out per line.
But for making the import statement readable (#3), I find the line-per import much more readable than ES6 style. Here’s the two for comparison (same example shown in your post:
import io.javalin.{Javalin, apiBuilder.ApiBuilder.{get, post}}
import io.javalin.Javalin
import io.javalin.apibuilder.ApiBuilder.get
import io.javalin.apibuilder.ApiBuilder.post
For very few imports it’s easy to see what is included in the ES6 style. But once you get a longer list of imports, being able to easily scan a sorted and column aligned list is much quicker for me. I don’t have to scan every line for nested lists of lists like the ES6 example.
Maybe I’m missing some of the advantages of ES6 style imports, or maybe there’s a third style that is even better–Still, even if it turns out to be better to use ES6 style, I suspect the gains may not be worth enough to get past the minus 100 point rule.
The current system is not a widespread or a high impact pain point.
EDIT:
The Kotlin/Java ecosystem is deeeeeply tooled–to the point where you might go months or years without manually typing or deleting an import statement. The IDE makes import management and insight so effortless that some of us have forgotten import statements even exist
Your position is to compromise on mediocrity, which is not the way of future programming.
Programming is a philosophy, an art. our thought and design come to life at scale of millions. our best effort is to make everything more readable and with minimum code. it should be extraordinary.
programming is our magical connection between machines, electric atoms, and the human mind.
sometimes, it appears as one of the greatest achievements of the human race.
anyone who does not think like that, shouldn’t lead this industry.
I agree… in 2022. The mindset should be if making imports more concise improves the language and if it does then at what cost? Arguing the IDE can hide that section and automatically handle imports does not fix/improve things at the language level. Turning the IDE into a transpiler to auto-magically do things like hiding imports just complicates the IDE and adds baggage (in this case i know it was necessary because java needs it). To add to the languages already mentioned, Scala and Python also support it.
