United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4456057 package access for interface methods
4456057 : package access for interface methods

Details
Type:
Enhancement
Submit Date:
2001-05-08
Status:
Closed
Updated Date:
2011-10-31
Project Name:
JDK
Resolved Date:
2011-10-31
Component:
specification
OS:
generic,windows_xp
Sub-Component:
language
CPU:
x86,generic
Priority:
P5
Resolution:
Won't Fix
Affected Versions:
1.2.0,1.3.0,7
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description

Name: krC82822			Date: 05/08/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

Interfaces are very useful, but I often want to write methods that have package
(default) access instead of public access.

For example, I have a viewer class that can place any one of many custom
components in its main view.  The viewer then asks this newly-added component
which menu items should be enabled. This provides a simple, powerful
implementation of context-sensitive menus. I do this through an interface, which
all the components implement. For example, the interface could look like this:

package com.myfirm.mywidget.ui;
import java.awt.Component;

interface MenuStates // interface has package access
{
  Component getViewer();   // I want these methods to have package access, too
  boolean isViewEnabled();
  boolean isCopyEnabled();
  boolean isSortEnabled();
  ...
}

Any class that implements this can provide a viewer for my main window. However,
there is no reason why any of these methods need to be visible outside the
current package. I want to encapsulate them inside the package, and I especially
want to hide the getViewer method. The current specification for Java doesn't
allow this.

I can't achieve this through an abstract class, as the evaluator of 4144491
suggests, because the classes that implement MenuStates all extend other AWT
classes. These methods need to be in an interface.

Please don't close this as a duplicate of 4144491. That was asking for protected
access, which is clearly not a good idea. Package access is different. It's
essentially a limited version of public access. Methods should only be allowed
to have package access if the interface itself has package access. A public
interface should certainly require public methods. But right now, I can write an
interface with package access, but I'm forced to give its methods public access.
This makes no sense.
(Review ID: 124020) 
======================================================================

                                    

Comments
EVALUATION

Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot).

All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1.

This specific request to change the Java programming language is related to the work of OpenJDK Project Lambda. It will be considered further by that project, not here.

The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.
                                     
2008-07-24
EVALUATION

There is a logic to this proposal, but it has downsides as well.
1. Package access is in fact quite problematic in some ways, and extending
its reach is not really that attractive.
2. This isn't easy to fix. It requires VM support in order to work.

I am certain that this can be worked around in various ways, which may 
require changing the design a bit.  

We should take this under consideration.

gilad.bracha@eng 2001-05-08
                                     
2001-05-08



Hardware and Software, Engineered to Work Together