4 ms·

I didn't know you could use Java SecurityManager to implement a similar system. That's cool. Do you know anyone who does that in their test suite? I'd love t

I didn't know you could use Java SecurityManager to implement a similar system. That's cool. Do you know anyone who does that in their test suite? I'd love to chat with them. The imvujs test framework for JavaScript tries to achieve the same effect by disabling known common sources of test intermittency: https://github.com/imvu/imvujs/blob/master/src/imvujstest/testglobals.js#L24 https://github.com/imvu/imvujs/blob/master/src/imvujstest/te... Sadly, this technique, like any blacklist, doesn't work for types of IO that can't be prevented, like mutations to document.location. The technique described in the article is effectively a named whitelist of IO operations (called World) that, say, all HTTP request handlers are restricted to.

Peaker 11y ago
Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. Also, perhaps some non determinism is allowed for the tests. Then runtime safety isn't equivalent to compile time safety.
- pron 11y ago
  > Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. True. We do that in Java, too. The idea is that you don't want to let methods use any "global" IO access (like System.out or new FileOutputStream) -- only IO streams that are passed in as arguments (which can then be mocked) -- so you use an annotation processor[1] to prohibit any such use; it's automatically picked up, loaded and used by all IDEs to mark any use of "prohibited operations" as errors while you type. Square/Google's Dagger DI library uses the same approach to make sure -- at compile time, with IDE support -- that all dependencies are satisfied. Again, this works without requiring any use of new/non-standard APIs. [1]: It's a class that gets run during one of the compilation phases, like a poor-man's pattern macros.
pron 11y ago
> Do you know anyone who does that in their test suite? I'd love to chat with them. I do. Not often, as I don't have a lot of IO in my tests, but I've found the security manager useful for that purpose from time to time. I also use it to help our users enforce global contracts, such as prohibit IO or any blocking code in fork-join computations.
- chadaustin 11y ago
  That's cool. I chatted with a friend about this too and they said they've used SecurityManager in this way. But one thing they said is that SecurityManager can't be used to restrict things like accessing the current time. Do you know if that's true or not?
  - pron 11y ago
    That's true -- out of the box. As with all things JVM, this, too is very pliable. You can create a new permission -- "access clock" -- and then it is quite easy to use an agent to inject a call for the security manager to check for this permission whenever the clock is accessed. In fact, since we started this discussion, I've written a small library that uses an agent to fake all clock accesses on the JVM with a user-supplied virtual clock, that can be set globally or per-thread. Injecting s security check is even easier.

Peaker 11y ago

Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. Also, perhaps some non determinism is allowed for the tests. Then runtime safety isn't equivalent to compile time safety.

pron 11y ago
> Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. True. We do that in Java, too. The idea is that you don't want to let methods use any "global" IO access (like System.out or new FileOutputStream) -- only IO streams that are passed in as arguments (which can then be mocked) -- so you use an annotation processor[1] to prohibit any such use; it's automatically picked up, loaded and used by all IDEs to mark any use of "prohibited operations" as errors while you type. Square/Google's Dagger DI library uses the same approach to make sure -- at compile time, with IDE support -- that all dependencies are satisfied. Again, this works without requiring any use of new/non-standard APIs. [1]: It's a class that gets run during one of the compilation phases, like a poor-man's pattern macros.

pron 11y ago

> Do you know anyone who does that in their test suite? I'd love to chat with them. I do. Not often, as I don't have a lot of IO in my tests, but I've found the security manager useful for that purpose from time to time. I also use it to help our users enforce global contracts, such as prohibit IO or any blocking code in fork-join computations.

chadaustin 11y ago
That's cool. I chatted with a friend about this too and they said they've used SecurityManager in this way. But one thing they said is that SecurityManager can't be used to restrict things like accessing the current time. Do you know if that's true or not?
- pron 11y ago
  That's true -- out of the box. As with all things JVM, this, too is very pliable. You can create a new permission -- "access clock" -- and then it is quite easy to use an agent to inject a call for the security manager to check for this permission whenever the clock is accessed. In fact, since we started this discussion, I've written a small library that uses an agent to fake all clock accesses on the JVM with a user-supplied virtual clock, that can be set globally or per-thread. Injecting s security check is even easier.