I don't know this package very well but it seems like it was a bit of a messed up design from the beginning if it exposed methods which had a vector of opaque types meant only for internal use. How would an application ever be able to call them or subclass
them?  Amusingly perhaps the javadoc for both these methods actually mention
UndoPosRef by name.

The defining class, GapContent is never used anywhere in public API.
I imagine this to be one example of the many types exposed in Swing only because
there was no equivalent of C++ friends and it was needed in another package.
I found that apart from the swing.text package in which it is defined it is used
only once outside its own package, in the swing.text.html sub-package

So I am fairly sure that really the whole GapContent class is for internal use only
and the same follows for UndoPosRef, so I'd vote against making it public.
I'd actually remove reference to it from thepublic  javadoc and say its
an implementation private type.

-phil.



On 8/19/2014 9:16 AM, Anthony Petrov wrote:
In theory, I agree. However, these methods didn't declare the type of objects in the Vectors since they were introduced, and we didn't see any RFEs to expose the types, which means that nobody really uses the methods outside JDK.

I believe that the missing notice about internal usage of the first method is a mistake, it should have been there from the beginning.

Finally, even if you make UndoPosRef visible, it is still an opaque type: there's no way to create instances of it, and no any public methods or fields. It doesn't make much sense to simply expose the name of the type w/o giving developers any control over it (which, as we know, has never been requested by those developers yet).

So I'm still unconvinced whether those internal classes should be exposed.

--
best regards,
Anthony

On 8/19/2014 7:43 PM, Joe Darcy wrote:
Hi Anthony,

The methods where the UndoPosRef type is used in the generification are
protected methods and UndoPosRef occurs in the argument list; from
GapContent:

     protected Vector<UndoPosRef> getPositionsInRange(Vector<UndoPosRef>
v, int offset, int length)

     protected void updateUndoPositions(Vector<UndoPosRef> positions,
int offset, int length)

The second method includes the disclaimer

      "This is meant for internal usage, and is generally not of
interest to subclasses."

but the first method does not. As a protected method, either of these
can be called by subclasses. Therefore, it seems to me the subclasses
should be able to know the types of the objects in the vectors being
passed into or returned.

Thanks,

-Joe

On 08/19/2014 05:34 AM, Anthony Petrov wrote:
Hi Joe,

I'm not sure if exposing internal classes is a good idea. There's
absolutely no need for user code to even know about them. If the only
reason we have to make them protected is because they're exposed with
the generification fix, then perhaps we could just revert the
generifications (and add corresponding @SuppressWarning) for these
specific cases?

--
best regards,
Anthony

On 8/19/2014 5:33 AM, Joe Darcy wrote:
Hello,

Please review my proposed changes to address:

     JDK-8055059: JDK9b22 public API exposes package private classes
     http://cr.openjdk.java.net/~darcy/8055059.0/

Bug JDK-8055059 that the generification of swing added package-private
types to the signatures of several protected methods. The solution is to
the make the formerly package-private types also be protected.

Patch below.

Thanks,

-Joe

--- old/src/share/classes/javax/swing/text/GapContent.java 2014-08-18
18:27:50.000000000 -0700
+++ new/src/share/classes/javax/swing/text/GapContent.java 2014-08-18
18:27:49.000000000 -0700
@@ -826,7 +826,7 @@
       * Used to hold a reference to a Mark that is being reset as the
       * result of removing from the content.
       */
-    final class UndoPosRef {
+    protected final class UndoPosRef {
          UndoPosRef(MarkData rec) {
              this.rec = rec;
              this.undoLocation = rec.getOffset();
@@ -839,7 +839,7 @@
           * @param endOffset end location of inserted string.
           * @param g1 resulting end of gap.
           */
-        protected void resetLocation(int endOffset, int g1) {
+        void resetLocation(int endOffset, int g1) {
              if (undoLocation != endOffset) {
                  this.rec.index = undoLocation;
              }
@@ -849,9 +849,9 @@
          }

          /** Previous Offset of rec. */
-        protected int undoLocation;
+        private int undoLocation;
          /** Mark to reset offset. */
-        protected MarkData rec;
+        private MarkData rec;
      } // End of GapContent.UndoPosRef


--- old/src/share/classes/javax/swing/text/StringContent.java 2014-08-18
18:27:50.000000000 -0700
+++ new/src/share/classes/javax/swing/text/StringContent.java 2014-08-18
18:27:50.000000000 -0700
@@ -366,7 +366,7 @@
       * Used to hold a reference to a Position that is being reset
as the
       * result of removing from the content.
       */
-    final class UndoPosRef {
+    protected final class UndoPosRef {
          UndoPosRef(PosRec rec) {
              this.rec = rec;
              this.undoLocation = rec.offset;
@@ -376,14 +376,14 @@
* Resets the location of the Position to the offset when the
           * receiver was instantiated.
           */
-        protected void resetLocation() {
+        void resetLocation() {
              rec.offset = undoLocation;
          }

          /** Location to reset to when resetLocatino is invoked. */
-        protected int undoLocation;
+        private int undoLocation;
          /** Position to reset offset. */
-        protected PosRec rec;
+        private PosRec rec;
      }

      /**



Reply via email to