groovy
  1. groovy
  2. GROOVY-3963

GroovyConsole windows should be their own process

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.7.0
    • Fix Version/s: None
    • Component/s: Groovy Console
    • Labels:
      None
    • Environment:
      Tested on Windows XP
    • Number of attachments :
      0

      Description

      The output is shared between GroovyConsole windows created from the same process, since requesting a new window doesn't create a new process.

      Steps to reproduce:
      1. Open a new console window (ctrl + shift + n)
      2. Cause some output to be generated
      3. Observe output in original window

      The output of that script will be displayed on all console windows created in the (ctrl + shift + n) way but not when it is launched as a new process. I believe the latter behavior to be preferable.

        Issue Links

          Activity

          Hide
          blackdrag blackdrag added a comment -

          this one is a bit difficult to implement, since it is a normal swing application we are talking here about. Normally Java processes don't create other Java processes. It would require native code, or a library that provides that. Any idea on that?

          Show
          blackdrag blackdrag added a comment - this one is a bit difficult to implement, since it is a normal swing application we are talking here about. Normally Java processes don't create other Java processes. It would require native code, or a library that provides that. Any idea on that?
          Hide
          Keegan Witt added a comment - - edited

          I'm no expert on this, but couldn't you use Runtime.exec("groovyConsole")? I would think that would work as long as the Groovy bin folder is on the path, or you could pass a string array of environment variables into exec as the second argument and set it yourself (maybe using GROOVY_HOME?). Another possibility, if the Java were directly accessed would be to use ProcessBuilder with javap, but I don't think that will work here.

          Show
          Keegan Witt added a comment - - edited I'm no expert on this, but couldn't you use Runtime.exec("groovyConsole")? I would think that would work as long as the Groovy bin folder is on the path, or you could pass a string array of environment variables into exec as the second argument and set it yourself (maybe using GROOVY_HOME?). Another possibility, if the Java were directly accessed would be to use ProcessBuilder with javap, but I don't think that will work here.
          Hide
          blackdrag blackdrag added a comment -

          I will try to explain a bit... native code can clone or fork the process. That action includes all the settings made for the process. Java does not offer this, so native code is reuqired to achieve it.

          But the problem to solve here is more delegating System.out and System.err. From different Threads into different output windows without really knowing which Thread belongs to which output window.

          Show
          blackdrag blackdrag added a comment - I will try to explain a bit... native code can clone or fork the process. That action includes all the settings made for the process. Java does not offer this, so native code is reuqired to achieve it. But the problem to solve here is more delegating System.out and System.err. From different Threads into different output windows without really knowing which Thread belongs to which output window.
          Hide
          Keegan Witt added a comment -

          I guess my question would be why do you need to fork the process? What variables do you need from the original process? The way I use GroovyConsole, creating a new process with nothing carried over from the original would work fine. I would think this should be the case for anyone using it as a standalone swing app. For those using it as an embedded component, I wouldn't think they would need to call the fileNewWindow method (or if they did they would override it to work with the embedding app). Could you explain the thought process behind the current behavior?

          Show
          Keegan Witt added a comment - I guess my question would be why do you need to fork the process? What variables do you need from the original process? The way I use GroovyConsole, creating a new process with nothing carried over from the original would work fine. I would think this should be the case for anyone using it as a standalone swing app. For those using it as an embedded component, I wouldn't think they would need to call the fileNewWindow method (or if they did they would override it to work with the embedding app). Could you explain the thought process behind the current behavior?
          Hide
          blackdrag blackdrag added a comment -

          What would I need? Well the classloader setup for example. A new process is most probably good enough... I guess a look at ant and how they the "forking" would be a good idea... or reusing the ant stuff even.

          Show
          blackdrag blackdrag added a comment - What would I need? Well the classloader setup for example. A new process is most probably good enough... I guess a look at ant and how they the "forking" would be a good idea... or reusing the ant stuff even.

            People

            • Assignee:
              Unassigned
              Reporter:
              Keegan Witt
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: