a program that fails only when run as a macOS bundled app

[Alan Snyder]

I’ve run into a strange situation, a tiny Java Swing program that works when 
run from the command line (java -jar) but fails when run as a macOS
bundled app created by the packager. I am using Java 10:

java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

The specific error appears to involve creating a window with an unsupported set 
of style bits. A similar error is described in JDK-8181476 [1].
NSWindow logs an assertion error. The problem does not arise in Java 8, 
probably because it uses a different set of style bits.

Does anyone have an idea why the behavior would be different for the bundled 
app vs the command line?

Anyone willing to take a look at it?

  Alan


[1] https://bugs.openjdk.java.net/browse/JDK-8181476 



package test;

import javax.swing.JFrame;
import javax.swing.SwingUtilities;

public class Test
{
 public Test()
 {
  // This frame is always displayed:
  JFrame fr1 = new JFrame("Test 1");
  fr1.getRootPane().putClientProperty("Window.style", "small");
  fr1.setResizable(false);
  fr1.setBounds(0, 0, 200, 200);
  fr1.setVisible(true);

  // This frame fails to display when run as a Java 10 bundled app:
  JFrame fr2 = new JFrame("Test 2");
  fr2.getRootPane().putClientProperty("Window.style", "small");
  fr2.setBounds(300, 0, 200, 200);
  fr2.setVisible(true);
 }

 public static void main(String[] args)
 {
  SwingUtilities.invokeLater(new Runnable()
  {
   public void run()
   {
new Test();
   }
  });
 }
}

Re: OS X commandline tools

[Alan Snyder]

Use “9” instead of “1.9”

> On Oct 28, 2017, at 7:12 AM, Michael Hall  wrote:
> 
> I think I may of raised this as an issue sometime earlier.
> 
> I filed a bug report through bug report.java
> We will review your report and have assigned it an internal review ID : 
> 9051382 .
> 
> But as I recall earlier it was indicated that this involved files owned by 
> Apple. For one thing I think they seem to symbolic link files in an apple 
> legacy java Framework.
> The solution as I remember it was for Mike Swingler to update the files. This 
> doesn’t seem like something you would want him to continue doing on an 
> ongoing basis.
> 
> For now I looked at it again because there seems to be nothing at all 
> pointing to the jlink command for me.
> 
> echo `which jdeps` is here
> /usr/bin/jdeps is here
> 
> echo `which jlink` is here
> is here
> 
> Nothing ‘is here’
> 
> What didn’t seem appropriate to the bug report is /usr/libexec/java_home. 
> This has been a useful platform specific command line tool for some time. 
> Currently it is somewhat broken. 
> This works…
> /usr/libexec/java_home
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> 
> This didn’t seem to work but now does seem to but with a incorrect(?) error 
> message.
> /usr/libexec/java_home -v 1.9 --exec java -version
> Unable to find any JVMs matching version "1.9".
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> 
> Is this supported? Did Apple contribute this to the port? Would anyone be 
> making changes to it or is it possible to get the source to change on your 
> own?
> 
> 

Re: Disallowing the dynamic loading of agents by default

[Alan Snyder]

> On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote:
> 
> In addition to future performance improvements, let's not forget about
> maintainability.  Improved integrity allows those of us who maintain the
> JDK to change internal implementation details without having to worry
> about breaking user code.  It allows users of the JDK to be confident
> that their code depends only on supported interfaces, so that they can
> more easily upgrade from one release to the next.  We've all too often,
> over the last twenty years, had to back out internal changes because
> some popular library depended upon those internals.
> 
> A common response to this concern is to say, "then don't use libraries
> that depend upon JDK internals!"  Would that it were that simple.  The
> hardest cases arise when some library A that depends on JDK internals is
> published, then it's used by library B, which in turn is used by library
> C, and that in turn is used by the immensely-popular library D, whose
> authors don't even know that library A depends on JDK internals.  (They
> might not even know that D ultimately depends on A!).  Then we fix a bug
> in the JDK that changes those internals, library D breaks, a large number
> of popular applications (or applications with important customers) stop
> working, and the cries and support escalations demanding that the change
> be reverted ensue.

Sounds to me like there are two different issues here.

One issue is the ability to create a library that breaks when “internal 
implementation details” of the JDK are changed. The other is the awareness of 
when one is depending upon such a library.

It should be clear that it is impossible to prevent libraries from depending 
upon internal implementation details and impossible to always be aware of when 
a library is so dependent. You will always have to worry about breaking user 
code, but maybe you can worry less.

A realistic goal would be to reduce the likelihood of a developer accidentally 
depending upon internal implementation details. Another would be to make it 
more likely that when a developer chooses to depend upon implementation details 
(sometimes necessary if the goal is to have code that works on already deployed 
platforms) that the dependence uses a mechanism that is detectable by static 
examination of the library. These goals may be related. Perhaps a developer 
would be less likely to create an avoidable dependence knowing that users would 
be aware of it.

These goals can be accomplished by erecting barriers but also providing well 
defined and statically visible bypasses, of which there are several long 
standing examples. Perhaps more control of these bypasses is needed. Perhaps 
some kind of module permission scheme would help. If I release a version of a 
library that bypasses a barrier (for reasons that are hopefully temporary), I 
should be willing to statically declare my need to do so (just as “apps” 
declare their need to access the network, etc.). If I release a runtime tool 
that needs to bypass a barrier, perhaps my users should be willing to use a 
security manager that allows my tool to do what it needs. (I understand the 
desire for a solution that does not require a security manager, but I’m less 
clear on why one should not allow a security manager to participate in the 
solution.)

In this regard, I find “integrity” as a concept or goal to be misleading or 
even meaningless. By erecting more barriers are you actually “improving 
integrity”? I don’t think so. The ability to write implementation-dependent 
code remains and always will remain. A barrier can have a benefit: reducing 
accidental or hidden implementation dependencies. But a barrier can also have a 
cost, which, ironically, is to cause existing code to break in the new JDK! So, 
worry is conserved, at least temporarily.

Re: Disallowing the dynamic loading of agents by default

[Alan Snyder]

> On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote:
> 
>> The sort of thing I am thinking about is, say, a module-wide
>> global analysis in the JIT guaranteeing that a call argument will only
>> ever be non-NULL, a positive int, or some such invariant that can fed
>> into an optimization phase. I can understand how a switch to disable
>> dynamic agent loading might be needed to underline that sort of guarantee.
> 
> That's exactly the kind of thing we want to enable, long-term, and one
> reason why integrity is worth improving aside from any considerations
> of security -- and why suggestions by others to "just use a security
> manager" if you care about such things are beside the point.

There has always been a conflict between optimization and the ability to make 
changes to the program at runtime. I don’t see this as an “integrity” issue or 
related to modules. If a program (including a JDK) has been built with a 
certain level of optimization, then certain runtime changes either cannot be 
performed or will not have the intended effect. If, as an example that has been 
previously suggested, some agent needs to create a subclass of a final class, 
then the vendor of that agent needs to instruct their customers on how to 
ensure that their JDK/application can support this behavior.

Re: Better tools for adjusting to strong encapsulation

[Alan Snyder]

OK, so the configuration idea does not work.

How about the idea of using the console log instead of System.err for these 
messages, on systems that have such a thing?


> On Mar 23, 2017, at 12:04 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 23/03/2017 18:44, Alan Snyder wrote:
> 
>> If I understand JEP 264 correctly, it should be possible to direct platform 
>> generated error messages to locations other than the standard error stream 
>> (System.err).
>> 
>> Is that correct?
>> 
>> If so, would it not make sense for the default to be the (platform 
>> dependent) console log rather than System.err, which is used by applications 
>> for their own error messages?
> System.Logger can be configured to send log messages to whatever logging 
> library you are using. However, is is not appropriate here, ditto for several 
> other areas where you don't want arbitrary code to execute.
> 
> -Alan

Re: testing for a class having been loaded

[Alan Snyder]

JDK-8170834

> On Nov 30, 2016, at 11:13 AM, Alan Snyder <javali...@cbfiddle.com> wrote:
> 
> By the way, I had no trouble finding examples on the web of using 
> findLoadedClass() via reflection. I listed the first 11 below.
> 
> Obviously, this hack is known, of interest, and used.
> 
> I think it deserves to be an issue.
> 
>> As I said, this change will not be popular but please bear with it until the 
>> extent of the issues uncovered is more widely understood. We need all the 
>> help we can get to identify issues and get them reported (and hopefully 
>> fixed) by the libraries and tools with the technical debt (and we expect a 
>> lot of it will be technical debt). For those working on OpenJDK and the JDK 
>> 9 project then it's very possible that some of these issues will redirect to 
>> the JDK as requests for new APIs or hooks (and I assume will need to be 
>> looked at on a case-by-case basis).
>> 
>> Any help reporting issues to popular tools and libraries would be 
>> appreciated.
> 
> 
> 
> https://github.com/HotswapProjects/HotswapAgent/blob/master/hotswap-agent-core/src/main/java/org/hotswap/agent/util/classloader/ClassLoaderHelper.java
> 
> http://stackoverflow.com/questions/482633/in-java-is-it-possible-to-know-whether-a-class-has-already-been-loaded
> 
> http://stackoverflow.com/questions/12093271/how-do-i-determine-class-loading-order-when-i-inject-them-into-the-systemclasslo
> 
> https://dzone.com/articles/classloaderlocal-how-avoid
> 
> http://snacktrace.com/artifacts/net.bytebuddy/byte-buddy-dep/1.3.20/net.bytebuddy.dynamic.loading.ClassInjector
> 
> https://fossies.org/linux/yacy/source/net/yacy/document/parser/pdfParser.java
> 
> http://lists.jboss.org/pipermail/jboss-cvs-commits/2010-May/120099.html
> 
> https://devops.ands.org.au/browse/VT-BUILD-55/artifact/JOB1/Javadoc/src-html/au/org/ands/vocabs/toolkit/utils/ApplicationContextListener.html
> 
> http://visualvm.sourcearchive.com/documentation/1.2.1-0ubuntu1/ClassLoaderManager_8java-source.html
> 
> http://code.taobao.org/svn/QLExpress/trunk/src/main/java/com/ql/util/express/ExpressClassLoader.java
> 
> http://svn.rifers.org/rife/tags/release-1.4/src/framework/com/uwyn/rife/engine/EngineClassLoader.java
> 
> 

Re: testing for a class having been loaded

[Alan Snyder]

By the way, I had no trouble finding examples on the web of using 
findLoadedClass() via reflection. I listed the first 11 below.

Obviously, this hack is known, of interest, and used.

I think it deserves to be an issue.

> As I said, this change will not be popular but please bear with it until the 
> extent of the issues uncovered is more widely understood. We need all the 
> help we can get to identify issues and get them reported (and hopefully 
> fixed) by the libraries and tools with the technical debt (and we expect a 
> lot of it will be technical debt). For those working on OpenJDK and the JDK 9 
> project then it's very possible that some of these issues will redirect to 
> the JDK as requests for new APIs or hooks (and I assume will need to be 
> looked at on a case-by-case basis).
> 
> Any help reporting issues to popular tools and libraries would be appreciated.



https://github.com/HotswapProjects/HotswapAgent/blob/master/hotswap-agent-core/src/main/java/org/hotswap/agent/util/classloader/ClassLoaderHelper.java

http://stackoverflow.com/questions/482633/in-java-is-it-possible-to-know-whether-a-class-has-already-been-loaded

http://stackoverflow.com/questions/12093271/how-do-i-determine-class-loading-order-when-i-inject-them-into-the-systemclasslo

https://dzone.com/articles/classloaderlocal-how-avoid

http://snacktrace.com/artifacts/net.bytebuddy/byte-buddy-dep/1.3.20/net.bytebuddy.dynamic.loading.ClassInjector

https://fossies.org/linux/yacy/source/net/yacy/document/parser/pdfParser.java

http://lists.jboss.org/pipermail/jboss-cvs-commits/2010-May/120099.html

https://devops.ands.org.au/browse/VT-BUILD-55/artifact/JOB1/Javadoc/src-html/au/org/ands/vocabs/toolkit/utils/ApplicationContextListener.html

http://visualvm.sourcearchive.com/documentation/1.2.1-0ubuntu1/ClassLoaderManager_8java-source.html

http://code.taobao.org/svn/QLExpress/trunk/src/main/java/com/ql/util/express/ExpressClassLoader.java

http://svn.rifers.org/rife/tags/release-1.4/src/framework/com/uwyn/rife/engine/EngineClassLoader.java

Re: testing for a class having been loaded

[Alan Snyder]

Why separately packaged? The goal would be loose coupling allowing smaller 
images. Same goal as Jigsaw…

Your solution uses Class.forName(), which will load classes. Perhaps it works, 
but doesn’t it rely on implementation specific behavior for nested static 
classes?

  Alan



> On Nov 30, 2016, at 9:52 AM, Peter Levart <peter.lev...@gmail.com> wrote:
> 
> Hi Alan,
> 
> On 11/29/2016 10:14 PM, Alan Snyder wrote:
>> Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader 
>> whether a class with a given name had been loaded without actually forcing 
>> it to be loaded.
>> 
>> This hack will not work in JDK9, so I am wondering if there is a way to do 
>> this?
>> 
>> If not, can someone explain why it would be a bad thing to be able to do 
>> this?
>> 
>> Here is my use case:
>> 
>> I have two classes, A and B, that have been designed to be aware of each 
>> other, but are packaged in separate JAR files or modules that can be loaded 
>> independently. My goal is for these classes to make a runtime connection 
>> with each other, but only if both have been loaded by the application.
>> 
>> If each class can at load (initialization) time test whether the other has 
>> been loaded, then they can use reflection to make that connection.
>> 
>> All of the other solutions I have thought of require yet a third 
>> class/interface C that is separately packaged and loaded by both A and B. 
>> This is feasible, but seems unnecessary.
> 
> Why separately packaged? You could do something like the following:
> 
> 
> package pkga;
> 
> public class ClassA {
> 
>public static final class Loaded {
>private static boolean loaded;
>public static boolean isLoaded() { return loaded; }
>}
> 
>static {
>try {
>Class bLoadedClass = Class.forName("pkgb.ClassB$Loaded");
> ClassA.class.getModule().addReads(bLoadedClass.getModule());
>java.lang.reflect.Method bLoadedMethod = 
> bLoadedClass.getMethod("isLoaded");
>synchronized (ClassA.Loaded.class) {
>ClassA.Loaded.loaded = true;
>boolean bLoaded = (Boolean) bLoadedMethod.invoke(null);
>if (bLoaded) {
>connect();
>}
>}
>} catch (ReflectiveOperationException ignore) {
>// ClassB.Loaded not visible
>}
>}
> 
>private static void connect() {
>System.out.println("Connecting from A -> B");
>}
> 
>public static void use() {
>System.out.println("A used.");
>}
> }
> 
> 
> package pkgb;
> 
> public class ClassB {
> 
>public static final class Loaded {
>private static boolean loaded;
>public static boolean isLoaded() { return loaded; }
>}
> 
>static {
>try {
>Class aLoadedClass = Class.forName("pkga.ClassA$Loaded");
> ClassB.class.getModule().addReads(aLoadedClass.getModule());
>java.lang.reflect.Method aLoadedMethod = 
> aLoadedClass.getMethod("isLoaded");
>synchronized (aLoadedClass) {
>ClassB.Loaded.loaded = true;
>boolean aLoaded = (Boolean) aLoadedMethod.invoke(null);
>if (aLoaded) {
>connect();
>}
>}
>} catch (ReflectiveOperationException ignore) {
>// ClassA.Loaded not visible
>}
>}
> 
>private static void connect() {
>System.out.println("Connecting from B -> A");
>}
> 
>public static void use() {
>System.out.println("B used.");
>}
> }
> 
> 
> 
> 
> Regards, Peter

Re: testing for a class having been loaded

[Alan Snyder]

All questions are worthy of some study, but I’m not getting why you question 
the sanity of asking for the status of classes but have no problem with asking 
for the status of packages.

Do you have some vague sense of possible problems?

  Alan



> On Nov 30, 2016, at 8:45 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 30/11/2016 15:51, Alan Snyder wrote:
> 
>> :
>> As Michael said, the hack is using reflection with setAccessible() to call 
>> the protected method ClassLoader::findLoadedClass().
>> 
>> Is there some conceptual or security reason to not provide this 
>> functionality in a public API?
> It's protected because it's for use in class loader implementations. It is 
> final so it could potentially be changed to public but would require a lot of 
> consideration before going that road. To be honest, the scenario is a bit 
> odd, there must be a saner solution that doesn't involve checking if classes 
> are loaded.
> 
> -Alan

Re: testing for a class having been loaded

[Alan Snyder]

> On Nov 30, 2016, at 1:46 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 29/11/2016 21:14, Alan Snyder wrote:
> 
>> Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader 
>> whether a class with a given name had been loaded without actually forcing 
>> it to be loaded.
>> 
>> This hack will not work in JDK9, so I am wondering if there is a way to do 
>> this?
>> 
>> If not, can someone explain why it would be a bad thing to be able to do 
>> this?
> I can't quite tell what the hack is, is it reading the private `classes` 
> field?
> 


As Michael said, the hack is using reflection with setAccessible() to call the 
protected method ClassLoader::findLoadedClass().

Is there some conceptual or security reason to not provide this functionality 
in a public API?


>> 
>> Here is my use case:
>> 
>> I have two classes, A and B, that have been designed to be aware of each 
>> other, but are packaged in separate JAR files or modules that can be loaded 
>> independently. My goal is for these classes to make a runtime connection 
>> with each other, but only if both have been loaded by the application.
>> 
>> If each class can at load (initialization) time test whether the other has 
>> been loaded, then they can use reflection to make that connection.
>> 
>> All of the other solutions I have thought of require yet a third 
>> class/interface C that is separately packaged and loaded by both A and B. 
>> This is feasible, but seems unnecessary.
>> 
> The scenario sounds like it needs a broker but without specifics then it's 
> hard to make suggestions.
> 
> One question: Are A and B in different packages? If A is p.A and B is q.B 
> when would it be enough to know if any p.* or q.* types have been loaded? If 
> so then ClassLoader::getDefinedPackage might be useful.

ClassLoader::getDefinedPackage might be useful in a new design, especially one 
using modules, as split packages are not allowed.

However, I’m not sure of the implications of this method not searching ancestor 
class loaders. Might there be circumstances where the result is not consistent 
with findLoadedClass()?

  Alan

testing for a class having been loaded

[Alan Snyder]

Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader 
whether a class with a given name had been loaded without actually forcing it 
to be loaded.

This hack will not work in JDK9, so I am wondering if there is a way to do this?

If not, can someone explain why it would be a bad thing to be able to do this?

Here is my use case:

I have two classes, A and B, that have been designed to be aware of each other, 
but are packaged in separate JAR files or modules that can be loaded 
independently. My goal is for these classes to make a runtime connection with 
each other, but only if both have been loaded by the application.

If each class can at load (initialization) time test whether the other has been 
loaded, then they can use reflection to make that connection.

All of the other solutions I have thought of require yet a third 
class/interface C that is separately packaged and loaded by both A and B. This 
is feasible, but seems unnecessary.

  Alan

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

[Alan Snyder]

A somewhat peripheral comment on:
> To ensure the integrity of the platform we expect that all the modules of
> the JDK itself will be normal modules and that very few, if any, packages
> will be opened.
I’m wondering if it would be possible to open the package(s) used by Swing Look 
and Feels, to better support custom look and feels.

The most obvious candidates are the packages containing the Portable Look and 
Feel. The PLAF design is somewhat schizophrenic. It is clearly designed for 
reuse, yet it has encapsulations that sometimes get in the way of reuse. (You 
can see examples in the Aqua LAF, originally coded by Apple, where there are 
workarounds with comments like “bad Sun”.)

Other candidates are AWT support packages, which I have found useful in 
implementing a custom platform-specific look and feel.

The basic issue for my look and feel is whether I will need to include 
instructions for developers on special command line arguments to allow the code 
to run in JDK 9. Obviously, I would rather not have to do this.

What is not clear to me is whether the goal of protecting the integrity of the 
platform is layered in some way, with some parts of the platform more critical 
than others.

  Alan










> On Oct 27, 2016, at 9:07 AM, mark.reinh...@oracle.com wrote:
> 
> Thanks to everyone who commented on the weak-modules proposal.  I've
> just posted a third proposal for #ReflectiveAccessToNonExportedTypes,
> along with an analysis of the proposals presented thus far:
> 
>  
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
>  
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000431.html
> 
> Further comments most welcome, as usual!
> 
> - Mark

Re: Privileged module idea

[Alan Snyder]

I find this idea appealing because it places the burden of special declarations 
on a small number of developers (the framework developers) who can reasonably 
be expected to acquire the necessary expertise, rather than on the many 
developers of clients of the frameworks who have better things to do than to 
master a complex module system.

I also believe that the developers building or configuring applications should 
be able to do whatever they want, even at the risk of shooting themselves in 
the foot in a variety of ways. The need for emergency workarounds is not going 
away.

The security issue, I would imagine, is to make sure that the power given to 
builders and configurers is not accessible to rogue code at runtime. This gets 
back to the question (was it ever answered?) of identifying the security 
threats that the module system is trying to prevent. I have this intuitive fear 
that with the current module system Java will get much more complex but not 
actually more secure.

  Alan





> On Oct 14, 2016, at 2:39 AM, Oliver Gierke  wrote:
> 
> Hi,
> 
> I like the idea. Especially the aspect that it allows you to identify which 
> of the modules have privileged access at runtime.
> 
> Also I guess it might even allow only certain modules of e.g. Spring to 
> actually require that access, i.e. only the ones that perform bean 
> instantiation etc. Not sure about the breadth of that effect but at first 
> glance it sounds like it might be worthwhile fleshing out the details of your 
> suggestion (how do modules declare they want to be privileged ones? etc.)
> 
> Cheers,
> Ollie
> 
>> Am 14.10.2016 um 04:27 schrieb Nikita Lipsky :
>> 
>> Hi all,
>> 
>> 
>> 
>> Recently I have described an idea of "privileged module" --
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009636.ht
>> ml
>> > tml>  :
>> 
>> 
>> 
>> "privileged module" may reflect on any unexported (and exported) type of
>> other resolved modules of a layer that it belongs to.
>> 
>> DI/JPA frameworks are subjects for "privileged modules".
>> 
>> 
>> 
>> "Privileged module" moves responsibility of weakened strong
>> encapsulation from user modules (via weak module or dynamic export
>> concepts) to framework modules.
>> 
>> 
>> 
>> I would greatly appreciate if someone could give me any feedback on it.
>> 
>> 
>> 
>> Regards,
>> 
>> Nikita
>> 
>> 
> 
> --
> /**
> * @author Oliver Gierke - Senior Software Engineer
> *
> * @param email ogie...@pivotal.io
> * @param phone +49-151-50465477
> * @param fax   +49-351-418898439
> * @param skype einsdreizehn
> * @see http://www.olivergierke.de
> */
> 

Re: Exporting - the wrong default?

[Alan Snyder]

As a lurker to this discussion, I would like to express a casual opinion. I do 
not claim any original ideas here, nor do I claim to understand the details of 
the discussion.

I am skeptical of solutions that are motivated by security and yet are not 
secure. Echoing a previous comment, I would not want to lose functionality for 
something like that.

Is it considered irrelevant for security that native code can bypass all of 
these barriers?



I am wondering whether agreement could be reached on this general approach:

  1. modules that need unrestricted reflection (as in JDK 8) should declare 
that desire in some static form (e.g. module info)

  2. a deployment time feature (e.g. command line argument) can be used to 
grant unrestricted reflection privileges to specific modules (but only to those 
known at deployment time)

  3. build tools can offer the convenience of using #1 and #2 to give 
unrestricted reflection privileges to every module known at deployment time 
that requests it


An implication is that modules that use unrestricted reflection should be 
carefully written so that malicious code could not hijack their reflective 
abilities to cause trouble. (The same would be the case for modules that use 
native code.)

  Alan




> On Jul 27, 2016, at 9:13 AM, David M. Lloyd  wrote:
> 
> On 07/27/2016 10:26 AM, Remi Forax wrote:
>> - Mail original -
>>> De: "dalibor topic" 
>>> À: jigsaw-dev@openjdk.java.net
>>> Envoyé: Mercredi 27 Juillet 2016 14:39:05
>>> Objet: Re: Exporting - the wrong default?
>> 
>>> On 26.07.2016 18:42, Stephen Colebourne wrote:
 In many projects
 packages change names frequently during development, everything is
 open and locking stuff down is the last thing on peoples minds. While
 this of course leads to slightly less secure software, it does achieve
 *business value*.
>>> 
>>> I would recommend Cristina Cifuentes presentation "Are We Ready for
>>> Secure Languages?" from the recent Curry On conference, of which a
>>> recording is available at https://www.youtube.com/watch?v=-fC975HLhyc
>>> for some less anecdotal thoughts on the business value of slightly more
>>> secure software.
>>> 
>>> It even touches briefly on the utility of modules in JDK 9.
>> 
>> Interesting talk !
>> 
>> to get back to our issue,
>> there are 4 possibilities when exporting a package, for a public type,
>> (1) don't see it at compile time, don't see it at runtime (can't reflect on 
>> it)
>> (2) don't see it at compile time, see it at runtime (this is the OSGI/JBoss 
>> model for not exported)
>> (3) see it at compile time, may not exist at runtime (so be prepared to get 
>> an exception then)
>> (4) see it at compile time and see it at runtime
>> 
>> The default can not be (3) because it's a corner case, it can not be (4) 
>> because in that case we lost the 'strong encapsulation' that a module should 
>> provide by default, so the default can be either (1), either (2) or to force 
>> the user to choose between (1) and (2) when declaring a module.
>> 
>> The problem with (1) is that:
>> - it makes most of the code that use reflection not working (and as Stephen 
>> said, at lot of codes use reflection (or bytecode generation)),
>> - it will slow down the adoption of jigsaw (not jdk9 which will be run with 
>> a -classpth) but the modularization of the already existing jars, so we will 
>> end up with a module system which will be not used or worst, some jars will 
>> be modularized, some will not and we will be in the same sad state of Python 
>> now with 2 mostly compatible worlds *.
>> 
>> The problem of letting users to choose is that the hope to educate them by 
>> forcing them to make their own choices will be destroyed because in practice 
>> IDEs will chose for them (e.printStackTrace() anyone ?)
>> 
>> So the only valid choice seem to be (2), which
>> - still enable JDK and application server implementation modules to not 
>> export some types at runtime, so the security will improve and by example, 
>> it will avoid most of the access control bugs Christina talk about.
>> - the default behavior will make the move to convert their jars to 
>> modularized jars easier because people will not conflate the problem of the 
>> modularization itself with the problem of the access control at runtime.
>> - everybody will be happy and we will not see angry ponies on slides about 
>> Java 9.
> 
> This is all rearranging deck chairs.  The critical problem here, lest we 
> forget, is that none of these solutions allow reflection to work on modules 
> without an export, even for public types, thus breaking *everything* 
> eventually.  Any valid choice IMO must allow public types to remain public 
> and thus globally accessible.
> 
> Since everyone seems to concede that the migration to any more secure form 
> for users must be incremental, there is nothing left to be gained by the 
> existing Jigsaw public access 

Re: getting a basic class loader

[Alan Snyder]

> On Dec 7, 2015, at 12:37 AM, Alan Bateman  wrote:
> 
> To your question, then there is an argument for a 
> ClassLoader::getPlatformClassLoader or some such method that you have 
> visibility to all platform/Java SE types.

OK, how will this happen?

  Alan

getting a basic class loader

[Alan Snyder]

I have been told [1] that doing something like String.class.getClassLoader() is 
a good way to get a value that can specified as the parent of a custom class 
loader when my goal for the custom class loader is to exclude 
application-specific classes (e.g. from the classpath).

Is this the best way to accomplish that goal, and does the answer change in JDK 
9 with jigsaw?

I am skeptical because I don’t see any reason to believe that the class loader 
for any given JDK class is necessarily a complete class loader that knows about 
all JDK runtime classes. In fact, in JDK 8 it is clearly not the case because 
the extensions class loader is not included.

  Alan

[1] 
http://stackoverflow.com/questions/34101259/need-a-java-system-only-class-loader
 

Re: Feature complete?

[Alan Snyder]

Good point. The command line solution might work in a local context, but its 
viral nature means it will propagate to environments where often the best you 
can expect is for people to follow instructions mindlessly or to use an 
automated solution. So much for the idea that application developers will 
carefully consider the (supposed) risk of any library that depends upon 
internal APIs before deciding whether or not to use it (or to upgrade to a new 
version).


> On Dec 4, 2015, at 8:07 AM, Stephen Felts  wrote:
> 
> I have come to a similar concern about command line options.
> 
> First, it won't be acceptable for customers to change their scripts that say 
> 'java myjavacommand'.
> The best that I have come up with so far is to hide JDK9 command line options 
> in _JAVA_OPTIONS (it's likely that things will still need to work with JDK8). 
>  One problem with that approach is that all of the commands use this single 
> environment variable (there's not a _JAVA_OPTIONS and _JAVAC_OPTIONS).  There 
> is a problem with javac/jimage complaining about options that only work with 
> java.  Let's ignore that for a minute.
> 
> In my project, I have two module path modules, two upgrade path modules, 13 
> export packages, and almost 900 classes in the XPatch directory.  I can't 
> expect to tell customers how to handle all of that so the best that I can do 
> is generate an argument file on installation (with full pathnames burned in 
> since environment variables don't work) and tell them to put the 
> @/full-pathname-to-argumentfile into _JAVA_OPTIONS everywhere in their 
> environment.
> 
> Let's assume I buy into that and it's fine for my project.  It's quite likely 
> that my project will have "3rd party" projects and they might have decided to 
> do the same thing, assuming they have done the JDK9 migration.
> 
> Now my customer will need to manage putting all of this stuff into 
> _JAVA_OPTIONS.  That's a pain and it's not clear that the modules, exports, 
> and patches from other projects won't interfere with mine.
> So we have moved from difficulties managing jars to command line option 
> difficulties.
> 
> 
> -Original Message-
> From: Reinier Zwitserloot [mailto:rein...@zwitserloot.com] 
> Sent: Friday, December 04, 2015 8:50 AM
> To: jigsaw-dev
> Subject: Re: Feature complete?
> 
> On Tue, Dec 1, 2015 at 2:24 PM, Alan Bateman 
> wrote:
> 
>> This seems a bit pessimistic. One thing that would be helpful is to 
>> get more help testing of these libraries with the EA builds. If there 
>> are libraries and applications on the class path today that are using 
>> core reflection then they should continue to work as they do in JDK 8. 
>> The
>> *only* issue *starting out* should be where core reflection is being 
>> used to get at JDK internal types, in which case a command-line option 
>> might be needed to keep those deployments working.
> 
> 
> Emphasis mine: "only"?
> 
> "Just add some command line switches" is not exactly a nice solution. From 
> personal experience, the vast majority of java users do not know how to add 
> configure command line switches to the various compile and build VMs being 
> started by their build tools of choice, for example. Also, not something Alan 
> mentioned here: Adding the command line switches is currently the _ONLY_ 
> solution, so tools that are aware of the issue can't even fix it, other than 
> by mangling modules (bad idea, I think we all agree on that I assume), or 
> advising the userbase not to actually USE any of the modularity features and, 
> preferably, to avoid switching to JDK9 altogether.
> 
> Emphasis mine: "starting out"?
> 
> This gets back to an earlier issue I raised on this mailing list: Okay, 
> starting out this isn't an issue, but by having no way to opt out of 
> export-based access control, it's a bit like switching from driving on the 
> left side of the road to the right: Unless the entire greater java community 
> switches in the same instant, we're all going to have a bad time.
> A way to opt out needs to exist, and the fact that the discussion is still 
> going, and no plans have even been stated yet, means in my opinion that 
> jigsaw is not fully baked yet.
> 
> --Reinier Zwitserloot

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> On Dec 3, 2015, at 2:49 PM, mark.reinh...@oracle.com wrote:
> 
>> I would be happier with a solution that documents specific
>> penetrations of encapsulation in a way that can be interrogated by a
>> tool. Then application developers can choose whether to run the tool,
>> rather than getting random run time access errors or buggy behavior
>> when the penetration is rejected.
> 
> Something like that might work for simple static references to internal
> APIs, such as your workaround scenario.  It's infeasible, however, for
> other use cases in which encapsulation must be broken in a more dynamic
> fashion, e.g., frameworks that use reflection to inspect the internals
> of classes in modules not known when the framework is compiled.

There is no reason to believe that single mechanism will solve all use cases.

However, if having a single mechanism is important, then it sounds like 
removing the restrictions on reflection would be a good choice.

  Alan

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

Alan,

It seems you have completely misunderstood my message. It’s not about any 
specific JDK bug. I have already sent mail to the AWT mailing list about the 
bug.

My message is about how jigsaw supports or prevents workarounds that require 
access to “private” JDK APIs.

I’ll repeat the questions here, for convenience:

>> Is it the position of the jigsaw team that I should not do this? [the 
>> workaround]
>> 
>> Is it the position of the jigsaw team that it is acceptable for someone in 
>> my position to somehow inform and convince every application developer who 
>> knowingly or unknowingly uses a library to change the command line arguments 
>> in their build configuration so that this workaround will run? (And later, 
>> presumably, get them all to remove the command line argument when the 
>> workaround is no longer needed?)


  Alan





> On Dec 1, 2015, at 12:26 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> 
> On 01/12/2015 18:26, Alan Snyder wrote:
>> The following is a workaround that I recently added to my code:
>> 
>> OGLRenderQueue rq = OGLRenderQueue.getInstance();
>> rq.lock();
>> 
>> try {
>> // my code here
>> } finally {
>> rq.unlock();
>> }
>> It is a workaround for a lack of synchronization in the AWT, a bug that was 
>> reported 18 months ago.
>> 
>> Is it the position of the jigsaw team that I should not do this?
>> 
>> Is it the position of the jigsaw team that it is acceptable for someone in 
>> my position to somehow inform and convince every application developer who 
>> knowingly or unknowingly uses a library to change the command line arguments 
>> in their build configuration so that this workaround will run? (And later, 
>> presumably, get them all to remove the command line argument when the 
>> workaround is no longer needed?)
>> 
>> I would appreciate learning where people stand on this issue.
> All I can suggest is start a discussion on the 2d-dev mailing list on this 
> topic. Small test cases that reproduce an issue easily are always welcome. If 
> you know this area then maybe you have a candidate patch to get the 
> discussion going.
> 
> -Alan.

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> On Nov 23, 2015, at 4:24 PM, Alex Buckley  wrote:
> 
> I know there is considerable effort going into replacement public APIs for 
> JavaFX -- see http://openjdk.java.net/jeps/253 
>  from May and the openjfx-dev thread 
> "Understanding the com.sun.* APIs being (ab)used by the community" from June 
> -- you could inquire about equivalents on swing-dev.

Yes, I have already proposed some and some are under development. I have not 
proposed low level ones yet.

  Alan

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> There are rather a lot of libraries out there that access private
> members via reflection. I posit that almost all such libraries break
> without an easy way to fix the problem, if there is no way to use
> reflection to access non-exported members.

I agree with Reinier that there are situations where it makes sense to bypass 
module encapsulation and the existing access rules. Encapsulation is a good 
thing, but unless it is needed for security, Java should not be totally rigid 
about it.

My use case is a platform specific Swing look and feel. To work, it needs 
access to platform specific features of the AWT. I’m trying not to be 
pessimistic or cynical, but I cannot assume that Oracle/OpenJDK will be 
motivated to create a public API for all of the platform specific features that 
I need, or if they do, that the API will be available in a timely manner. I 
understand that my library will have dependencies on specific JDK versions as 
it does on specific platform versions.

I was unpleasantly surprised to learn (via the recent Java One talks) that the 
module encapsulation rules apply to reflection, as I had understood that they 
did not.

Using command line arguments as an escape mechanism is not a good fit for this 
use. The main reason is that it places a burden on all users of the library, 
both direct and indirect. Every application in which this library is used must 
define the appropriate command line arguments. The other reason is that the 
command line argument solution is too broad. Using reflection, each specific 
need to penetrate encapsulation is identified. Using the command line argument, 
entire packages are opened up.

Which brings me to a question... How is native code access to classes and 
methods via JNI affected by module encapsulation?

  Alan

internal API usage: sun.awt.CausedFocusEvent

[Alan Snyder]

I have been using sun.awt.CausedFocusEvent to implement special behavior in 
response to an explicit user-initiated focus traversal to a component. The main 
point is that I want to inhibit this behavior for all other kinds of focus 
gained events.

Will there be some way of doing this in JDK9?