Usage of star imports

[Raul Kripalani]

Hello Igniters,

First of all, congrats to all the committers, former PPMC now PMC members
and mentors for the project's graduation! Great work, everybody!

I have a question about the Coding Guidelines. Why do they enforce star
imports?

It is considered a bad practice for several reasons:

1. It pollutes the local namespace, leading to unnecessary name clashes.

2. Unexpected errors can occur if a class is added the package of a
dependency we import. Of course, this would be detected at compile time and
would make the build fail. But it's worrisome that we allow this to occur
in the first place. Leads to unpredictable builds in case we have SNAPSHOT
dependencies.

3. It makes it absolutely necessary to use a fully-fledged IDE to browse
the source. People using simpler text editors like Sublime, vi or emacs
will have a hard time unless they use plugins that can process pom.xml and
add dependencies to classpaths (I haven't even installed these plugins –
and I use Sublime 45% of my working time, as an example).

4. As an example of the latter, I'm currently working on adding OSGi
support for ignite-core. I'm trying to figure out which classes require
package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
lightweight browsing. Found several hits, but because I'm not familiar with
the contents of the package by heart, I have absolutely no clue which
classes of that package are being used our source files.

If the reason/alleged benefit is simple convenience/brevity, I'm not quite
sure it outweighs all the negatives.

Thanks,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Raul Kripalani]

(Found out that org.jsr166 is an internal package in this case).

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Wed, Aug 19, 2015 at 10:23 PM, Raul Kripalani <[hidden email]> wrote:

> Hello Igniters,
>
> First of all, congrats to all the committers, former PPMC now PMC members
> and mentors for the project's graduation! Great work, everybody!
>
> I have a question about the Coding Guidelines. Why do they enforce star
> imports?
>
> It is considered a bad practice for several reasons:
>
> 1. It pollutes the local namespace, leading to unnecessary name clashes.
>
> 2. Unexpected errors can occur if a class is added the package of a
> dependency we import. Of course, this would be detected at compile time and
> would make the build fail. But it's worrisome that we allow this to occur
> in the first place. Leads to unpredictable builds in case we have SNAPSHOT
> dependencies.
>
> 3. It makes it absolutely necessary to use a fully-fledged IDE to browse
> the source. People using simpler text editors like Sublime, vi or emacs
> will have a hard time unless they use plugins that can process pom.xml and
> add dependencies to classpaths (I haven't even installed these plugins –
> and I use Sublime 45% of my working time, as an example).
>
> 4. As an example of the latter, I'm currently working on adding OSGi
> support for ignite-core. I'm trying to figure out which classes require
> package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
> lightweight browsing. Found several hits, but because I'm not familiar with
> the contents of the package by heart, I have absolutely no clue which
> classes of that package are being used our source files.
>
> If the reason/alleged benefit is simple convenience/brevity, I'm not quite
> sure it outweighs all the negatives.
>
> Thanks,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[Sergi]

Agree, I don't like current approach as well and prefer explicit imports.
Since they are automatically maintained by IDE it will be easy enough to
change this.

Sergi

2015-08-20 0:37 GMT+03:00 Raul Kripalani <[hidden email]>:

> (Found out that org.jsr166 is an internal package in this case).
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Wed, Aug 19, 2015 at 10:23 PM, Raul Kripalani <[hidden email]> wrote:
>
> > Hello Igniters,
> >
> > First of all, congrats to all the committers, former PPMC now PMC members
> > and mentors for the project's graduation! Great work, everybody!
> >
> > I have a question about the Coding Guidelines. Why do they enforce star
> > imports?
> >
> > It is considered a bad practice for several reasons:
> >
> > 1. It pollutes the local namespace, leading to unnecessary name clashes.
> >
> > 2. Unexpected errors can occur if a class is added the package of a
> > dependency we import. Of course, this would be detected at compile time
> and
> > would make the build fail. But it's worrisome that we allow this to occur
> > in the first place. Leads to unpredictable builds in case we have
> SNAPSHOT
> > dependencies.
> >
> > 3. It makes it absolutely necessary to use a fully-fledged IDE to browse
> > the source. People using simpler text editors like Sublime, vi or emacs
> > will have a hard time unless they use plugins that can process pom.xml
> and
> > add dependencies to classpaths (I haven't even installed these plugins –
> > and I use Sublime 45% of my working time, as an example).
> >
> > 4. As an example of the latter, I'm currently working on adding OSGi
> > support for ignite-core. I'm trying to figure out which classes require
> > package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
> > lightweight browsing. Found several hits, but because I'm not familiar
> with
> > the contents of the package by heart, I have absolutely no clue which
> > classes of that package are being used our source files.
> >
> > If the reason/alleged benefit is simple convenience/brevity, I'm not
> quite
> > sure it outweighs all the negatives.
> >
> > Thanks,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>

[Gianfranco Murador]

I was thinking about the same problem , I opened a ticket for a specific
problem of ambiguity in imports.
https://issues.apache.org/jira/browse/IGNITE-1253

2015-08-20 7:17 GMT+02:00 Sergi Vladykin <[hidden email]>:

> Agree, I don't like current approach as well and prefer explicit imports.
> Since they are automatically maintained by IDE it will be easy enough to
> change this.
>
> Sergi
>
> 2015-08-20 0:37 GMT+03:00 Raul Kripalani <[hidden email]>:
>
> > (Found out that org.jsr166 is an internal package in this case).
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Wed, Aug 19, 2015 at 10:23 PM, Raul Kripalani <[hidden email]>
> wrote:
> >
> > > Hello Igniters,
> > >
> > > First of all, congrats to all the committers, former PPMC now PMC
> members
> > > and mentors for the project's graduation! Great work, everybody!
> > >
> > > I have a question about the Coding Guidelines. Why do they enforce star
> > > imports?
> > >
> > > It is considered a bad practice for several reasons:
> > >
> > > 1. It pollutes the local namespace, leading to unnecessary name
> clashes.
> > >
> > > 2. Unexpected errors can occur if a class is added the package of a
> > > dependency we import. Of course, this would be detected at compile time
> > and
> > > would make the build fail. But it's worrisome that we allow this to
> occur
> > > in the first place. Leads to unpredictable builds in case we have
> > SNAPSHOT
> > > dependencies.
> > >
> > > 3. It makes it absolutely necessary to use a fully-fledged IDE to
> browse
> > > the source. People using simpler text editors like Sublime, vi or emacs
> > > will have a hard time unless they use plugins that can process pom.xml
> > and
> > > add dependencies to classpaths (I haven't even installed these plugins
> –
> > > and I use Sublime 45% of my working time, as an example).
> > >
> > > 4. As an example of the latter, I'm currently working on adding OSGi
> > > support for ignite-core. I'm trying to figure out which classes require
> > > package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
> > > lightweight browsing. Found several hits, but because I'm not familiar
> > with
> > > the contents of the package by heart, I have absolutely no clue which
> > > classes of that package are being used our source files.
> > >
> > > If the reason/alleged benefit is simple convenience/brevity, I'm not
> > quite
> > > sure it outweighs all the negatives.
> > >
> > > Thanks,
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> >
>

[dsetrakyan]

I am +1 on the proposed change.

However, I also want to mention that we should try to avoid changing coding
guidelines as much as possible.

D.



On Thu, Aug 20, 2015 at 1:26 AM, Gianfranco Murador <
[hidden email]> wrote:

> I was thinking about the same problem , I opened a ticket for a specific
> problem of ambiguity in imports.
> https://issues.apache.org/jira/browse/IGNITE-1253
>
> 2015-08-20 7:17 GMT+02:00 Sergi Vladykin <[hidden email]>:
>
> > Agree, I don't like current approach as well and prefer explicit imports.
> > Since they are automatically maintained by IDE it will be easy enough to
> > change this.
> >
> > Sergi
> >
> > 2015-08-20 0:37 GMT+03:00 Raul Kripalani <[hidden email]>:
> >
> > > (Found out that org.jsr166 is an internal package in this case).
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> > > On Wed, Aug 19, 2015 at 10:23 PM, Raul Kripalani <[hidden email]>
> > wrote:
> > >
> > > > Hello Igniters,
> > > >
> > > > First of all, congrats to all the committers, former PPMC now PMC
> > members
> > > > and mentors for the project's graduation! Great work, everybody!
> > > >
> > > > I have a question about the Coding Guidelines. Why do they enforce
> star
> > > > imports?
> > > >
> > > > It is considered a bad practice for several reasons:
> > > >
> > > > 1. It pollutes the local namespace, leading to unnecessary name
> > clashes.
> > > >
> > > > 2. Unexpected errors can occur if a class is added the package of a
> > > > dependency we import. Of course, this would be detected at compile
> time
> > > and
> > > > would make the build fail. But it's worrisome that we allow this to
> > occur
> > > > in the first place. Leads to unpredictable builds in case we have
> > > SNAPSHOT
> > > > dependencies.
> > > >
> > > > 3. It makes it absolutely necessary to use a fully-fledged IDE to
> > browse
> > > > the source. People using simpler text editors like Sublime, vi or
> emacs
> > > > will have a hard time unless they use plugins that can process
> pom.xml
> > > and
> > > > add dependencies to classpaths (I haven't even installed these
> plugins
> > –
> > > > and I use Sublime 45% of my working time, as an example).
> > > >
> > > > 4. As an example of the latter, I'm currently working on adding OSGi
> > > > support for ignite-core. I'm trying to figure out which classes
> require
> > > > package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
> > > > lightweight browsing. Found several hits, but because I'm not
> familiar
> > > with
> > > > the contents of the package by heart, I have absolutely no clue which
> > > > classes of that package are being used our source files.
> > > >
> > > > If the reason/alleged benefit is simple convenience/brevity, I'm not
> > > quite
> > > > sure it outweighs all the negatives.
> > > >
> > > > Thanks,
> > > >
> > > > *Raúl Kripalani*
> > > > Apache Camel PMC Member & Committer | Enterprise Architect, Open
> Source
> > > > Integration specialist
> > > > http://about.me/raulkripalani |
> > http://www.linkedin.com/in/raulkripalani
> > > > http://blog.raulkr.net | twitter: @raulvk
> > > >
> > >
> >
>