# Wednesday, 22 October 2003
« Ghosts | Main | PDC »
Private Super Classes

While trying to get Stuart Ballard's Japitools to work on a netexp generated export of IKVM's classpath.dll, I encountered java.awt.BufferCapabilities.FlipContents. This public (inner) class has non-public base class (java.awt.AttributeValue). What kind of a bizarre design is that?

I had never realised that the Java language allowed this. Fortunately, the C# designers didn't make the same mistake.

Note that a similar issue exists for fields (and method arguments). In Java it is legal to have a public field of a non-public type, or a public method that takes an argument of a non-public type. C# prohibits both of these.

I fixed netexp to export non-public base classes (and I should do the same for interfaces, fields and method arguments/return type).

Wednesday, 22 October 2003 18:36:30 (W. Europe Daylight Time, UTC+02:00)  #    Comments [4]
Wednesday, 22 October 2003 19:53:10 (W. Europe Daylight Time, UTC+02:00)
It's interesting the things that C# prohibits but the CLR allows. If I read your comment right, you're saying that C# prohibits this situation, but the CLR allows it, so you can actually compile Java code that has this design without having to correct for it, and it will run ok, so the only problem is making sure netexp exports a coherent hierarchy back to Java.

I'd have expected the CLR to prohibit it, in which case you'd have more complex issues - you'd have to make the base class public but somehow indicate by attributes that it's supposed not to be, so that Java code couldn't use it.

Either that, or I'm confused :)
Wednesday, 22 October 2003 23:16:04 (W. Europe Daylight Time, UTC+02:00)
You're absolutely right. I'm lucky that the CLR allows it, if it didn't I'd have to jump through (even) more hoops to compile the Java classes.
It is not surprising that the CLR allows things that are bad from an OO design perspective. Its job is not to promote writing "good" code.
As an aside, it can actually be surprisingly difficult to figure out what is reasonable for the CLR to accept or not. Microsoft did a good job, but I certainly don't agree with all their decisions.
Thursday, 23 October 2003 18:31:39 (W. Europe Daylight Time, UTC+02:00)
Would you agree that a public class implementing a non-public interface is actually legit? It may be that internal code needs it to implement the interface even though external code doesn't care.

Does C# allow this?
Sunday, 26 October 2003 17:59:07 (W. Europe Standard Time, UTC+01:00)
Implementing private interface is definitely legit. C# allows it and it is even more powerful than in Java, because the interface implementation methods don't have to be public.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview