[SUGGESTION]: Define aliases when importing multiple classes with same classname

Mario Torre neugens at redhat.com
Fri Oct 10 07:38:45 UTC 2014

On Fri, 2014-10-10 at 06:50 +0200, CHAUVET Guillaume wrote:
> Dear OpenJDK community,

Hello Guillaume,

First of all welcome and thanks for this proposal.

> I would like to submit you a potential new Java feature already existing 
> in Eiffel language : renaming classes/interfaces when importing them. 
> The goal is to improve the clashnames resolution when importing some 
> classes with the same classname but provided from different packages by 
> adding a classname alias mechanism. Below, a simple use case that 
> display how this potential new syntax :
> Snippet class
> ==================
> import javax.management.Query;
> import javax.persistence.Query as PersistenceQuery;
> import org.apache.lucene.search.Query as LucentQuery;
> public class Snippet {
>   private javax.persistence.Query q1;	// Direct classname resolution
>   private PersistenceQuery q2;		// Using alias classname of 
> javax.persistence.Query
>   private Query q3;			// Using default imported class : 
> javax.management.Query
>   private LucentQuery q4;		// Using alias classname of 
> org.apache.lucene.search.Query
>   public PersistenceQuery getPersistence() {
>    return q2;
>   }
> }
> Caller class
> ==================
> Snippet s = new Snippet();
> s.getPersistence(); // return javax.persistence.Query, not the internal 
> alias used in class definition

Not sure, it seems really confusing. You declare a type internally and
make public API return that type, but then the method returns something
else (which is really the same, but nobody knows!). Yes, JavaDoc may do
the right thing, but people reading the code would be lost.

I think preserving clarity of the language is the first goal of any
addition so this change isn't likely to get traction, but you can try :)

> I'm ready to involved to implement this new feature by contributing to 
> the OpenJDK development effort.

Best thing is to start discussing here like you did, then if enough
people like the idea or you don't get enough feedback but have a general
impression that it's worth it, you could go ahead with a JEP. If it's
accepted, you'll get all the tools needed to experiment and allow us to
keep track of the work. At that point, depending on the specific
changes, you may need to involve the JCP to get the changes part of the
Java specification.

If you join the adoption-discuss you can find people to help with all
those steps, but as I said, the discussion should go on here first.


More information about the discuss mailing list