why is modularity changing the rules of inheritance?

[Gregg Wonderly]

This is pretty much what was lamented about on the list as the project proceeded.  In the end, the restrictions you see are because all the system classes in the Java VM implementation need to be protected in this way to provide the opportunity for evolution of the implementations underlying the JVM.  Rather than implementing some customization of visibility “into” specific system classes, we all get to deal with having visibility changes that break existing code which uses introspection for IoC etc.

Practically, Jigsaw feels like too little too late for Java improvement over all.   It’s way past the time when people would be satisfied to see Java fixed in places where underlying APIs were not sufficient and so introspection based fixes ended up being made, or base JVM classes replaced with bootclasspath.

There seems to be an honest effort to try and fix things in the base of Java by this work, but the cloud environment is being overrun by .Net, just because of the number of developers being trained there, vs the J2EE disaster.  .Net is not an attractive solution for stability reasons however.  

Additionally, the desktop environment is so overrun by other platforms due to the lack of focus on media support and fixes to Swing/AWT problems, that Java on the desktop is probably not as interesting as it once was.

Swift, Go, .Net and a few other platforms have much more productivity for creating usable applications, and are being taught and used much more prolifically than Java.  Apple pulled away from Java completely as Swift came flying into view.  That was a pretty good number of nails into the coffin.

Oracle has a bad name in many places because of “Android”, “Jenkins”, “MySQL” and other Oracle things around open source arguments.   People are standing at a distance from anything that Oracle is doing because they tire of the argumentative and restrictive control that is constantly changing for the worse.

It’s really a sad state of affairs given the opportunity for unification of programming language/platform that Java once offered…

Gregg

> On Mar 13, 2018, at 4:23 AM, Bernard Amade <bear.amade at gmail.com> wrote:
> 
> Hello all (OOps! wrote "Hell all" )
> 
> just curious to read about the rationale behind this behaviour:
> if you have a code in moduleB that inherits from code in moduleA, modularity wise the inherited methods behave as if they were invoked from moduleA (not from moduleB). see an example at the end of this post.
> Naïvely found this behaviour *very bad* but I suppose that if it were not the case then the situation could be worse... so I would like to read the rationale behind this. 
> 
> thanks
> 
> code of a service definition in moduleA:
> -----------------------------------------------
> public abstract class  PropertiesProvider {
>        public Properties get(String domain) {
>            Class clazz =this.getClass();
>            System.out.println(" CLASS " +clazz);
>            try {
>                Object obj = clazz.getConstructor().newInstance();
>                System.out.println("Object " + obj);
> 
>            } catch (Exception exc) {
>                exc.printStackTrace();
>            }
>            InputStream is = clazz.getResourceAsStream(domain) ;
>            if (is != null) {
>                Properties props = new Properties();
>                try {
>                    props.load(is);
>                    return props;
>                } catch (IOException e) {
>                    System.getLogger("").log(System.Logger.Level.WARNING,e) ;
>                }
> 
>            }
> and so on ...
> now if in module B you just create a Service by inheriting from this class:
> - the className is correct (an instance of the class has been created for the service)
> - you can't invoke newInstance from that very class!(if the class is not opened or exported)
> - you can't get the Resource (or other files) unless they are explicilty opened.
> if you copy this code in the class implementing the service everything just works fine
> so there is a difference between the same code being explicitly in the class or inherited!
> (got a headache trying to find something to say for people learning Java)