1. A description of the suggestion

ClassLoader loader = ClassLoader.getSystemClassLoader();
loader.setDefaultAssertionStatus(true);

We can't do it in scripts because our access to the class loader is blocked by the security manager

 

2. How will this suggestion impact scripters and/or botters? They can use assert statements to write nicer code

3. Post any examples such as code or pictures to supplement your description (optional)

if (!inventory.isEmpty()) 
    assert bank.depositAll();
bank.close();
// because if 1 action fails there is no point in executing the others

I really don't think there's a chance we're going to allow ClassLoader. Zach could probably speak more to it, but I would be surprised if he said yes even with the allow permission. 

I really don't think there's a chance we're going to allow ClassLoader. Zach could probably speak more to it, but I would be surprised if he said yes even with the allow permission. 

I didn't mean to request access to the ClassLoader, I mean't enable assertions in the client code because we can't access it in scripts, if you enable it then we will be able to use assertions in scripts too since they run on the same JVM. It should also work by starting the client with -ea or -enableassertion flags but that's not a general solution because not all users will do it, unlike enabling it programatically using those 2 lines, which should work for all users.

Edited September 23, 20169 yr by Token

Ah sorry, I jumped the gun as soon as I saw ClassLoader. In regards to assertions/JUnit/testing, we would probably only want it for local scripts/local testing. I'll ask around for you. 

Edit: Just double checking, I'm not a security guru so I don't know if there are any crazy loopholes. 

Ah sorry, I jumped the gun as soon as I saw ClassLoader. In regards to assertions/JUnit/testing, we would probably only want it for local scripts/local testing. I'll ask around for you. 

Edit: Just double checking, I'm not a security guru so I don't know if there are any crazy loopholes. 

Nah there is nothing security related, it simply enables the assert statement but it should be done in the client code preferably before instantiating the Script, as every change on the ClassLoader will affect only future instances.

I looked into a little bit, but I couldn't readily find a way to disable assertions from compiling in Java (for the SDN). In C++ there is the assert Macro which can be disabled using #define NDBEUG. Looking into allowing it for local scripts.