geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [Standard] Using public/static/abstract modifiers in interfaces
Date Thu, 14 Aug 2003 11:18:48 GMT
I agree. Most Java code uses public even though its redundant in 
interfaces. We're really splitting hairs if we worrying about this 
kinda thing. Lets focus on J2EE! :)

On Thursday, August 14, 2003, at 12:10  pm, Alex Blewitt wrote:

> On Thursday, Aug 14, 2003, at 12:01 Europe/London, Jason Dillon wrote:
>> Also, as I noted in the coding standards, public and public static 
>> are redundant in the context of interfaces and should not be used.
> I disagree. They should absolutely be there in interfaces, along with 
> the abstract keyword for methods.
> public interface GoodExample {
>   public static final int CONSTANT = 0;
>   public abstract void method();
> }
> pubic interface BadExample {
>   int CONSTANT = 0;
>   void method();
> }
> The reason for this is that if a developer cut-n-pastes a line from 
> the interface into a class, the only one that will keep the same 
> behaviour is the GoodExample. Missing out keywords leads to potential 
> problems.
> It also makes it trivial to change it from an interface to a class, or 
> to create a subclass by copying the interface and changing the top 
> line.
> There was a discussion in Eclipse re: generating methods w/o some of 
> the modifiers that got bounced to the top of the Eclipse PMC about 
> this. Their conclusion was that it didn't hurt to have the modifiers 
> in, and it actually avoided those problems outlined above.
> Since an IDE will put these in automatically in most cases, I can't 
> see any reason for wanting them taken out.
> I would say that the standard should read:
> You SHOULD put in public abstract for methods, and pubic static final 
> for constants, but it is not mandatory to do so.
> Alex.
> (It is also generally considered bad practice these days to define 
> constants in an interface and implement it just to gain access to 
> those components; this should probably be put in the standards as well 


View raw message