• Post Reply Bookmark Topic Watch Topic
  • New Topic

why don't interfaces don't allow static blocks?  RSS feed

 
Amit Singla
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interfaces do not allow static blocks but do allow public final static member.
If someone wants to initialize the variable based on some logic, it is not possible in interfaces but possible in classes.

I am trying to figure out the logical reson why java language does not allow it? though it allows to define inner classes in interface.
 
Campbell Ritchie
Marshal
Posts: 56533
172
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The idea of an interface is not to supply implementation. A block would constitute implementation.

That is obviously what they thought when they designed that feature.
 
Amit Singla
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought of the same reaons but then at the same time they do allow inner classes in interface though i have never seen this feature in use.
 
Campbell Ritchie
Marshal
Posts: 56533
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can't help any more, I am afraid.

Anybody else?
 
pardeepkumar devgon
Greenhorn
Posts: 8
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because interface are not supposed to have any code, that what abstract classes are for. Also interface is not a part of object hierarchy
 
Wilhelm Vogt
Greenhorn
Posts: 10
Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interfaces do not allow static blocks but do allow public final static member.
If someone wants to initialize the variable based on some logic, it is not possible in interfaces but possible in classes.

It is not necessary to have a static block to initialize the variables based on some logic, as the variable initializer may contain a method call.


This might be useful to initialize some variables according to the current environment.

As to why static blocks are not allowed, there are some good reasons in the previous answers, but to really know we would need some documentation from the original developers.
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could this be one another way to put it? Just my reasoning - if you think it's incorrect, please point out.

First we only have instance method declarations in an interface for obvious reasons - implementation is deferred to an implementing class that declares to keep the contract.
Static methods aren't for overriding. So they don't apply.

A static block is generally used to initialize variables that should be initialized only once or to call a static method. The latter does not apply. For the former, in an interface the static variables are already also final variables.
The following two styles must be functionally equivalent ( not really sure on this one - not sure if inlining works with both, but it must be an implementation detail ) though the first one must be more concise and readable.





I think we can safely say that because of the above, the static blocks are not required in an interface. Having them could only mean more work for the compiler?

Chan.
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Didn't have Wilhelm Vogt's response when I started typing mine. Good timing :-)
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Order of execution of the initializers is one of the things to consider here. Here is an extract from the JLS3 - Sec 12.4.1

The intent here is that a class or interface type has a set of initializers that put it in a consistent state, and that this state is the first state that is observed by other classes. The static initializers and class variable initializers are executed in textual order, and may not refer to class variables declared in the class whose declarations appear textually after the use, even though these class variables are in scope (§8.3.2.3). This restriction is designed to detect, at compile time, most circular or otherwise malformed initializations.

As shown in an example in §8.3.2.3, the fact that initialization code is unrestricted allows examples to be constructed where the value of a class variable can be observed when it still has its initial default value, before its initializing expression is evaluated, but such examples are rare in practice. (Such examples can be also constructed for instance variable initialization; see the example at the end of §12.5). The full power of the language is available in these initializers; programmers must exercise some care. This power places an extra burden on code generators, but this burden would arise in any case because the language is concurrent
(§12.4.3).
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!