This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Assuming the following scenario: 1. "Run" target is invoked on some Java Card project 2. After successful completion Default Device is still active in Services tab ("Stop" item in context menu is active). 3. Open dialog Tools|Java Platforms|Bundled Java Card 3.0.2|Manage Devices and change any parameter, e.g. Contacted Protocol or HTTP Port. 4. After saving these properties IDE shows that Default Device is stopped ("Start" and "Resume" context menu items are active). 5. When we try to start Default Device the following error message is displayed: "ALERT: Can not create file mapping. May be another instance of cjcre is using the same e2pfile. Specify different e2pfile using -e2pfile option (or) terminate the currently running cjcre. " The problem is that cjcre.exe isn't actually terminated after modifying Default Device properties, but detached from IDE, so we can't stop or start it from IDE. We should close the process in Task Manager and only then we can start Default Device within IDE.
This is tricky. There may be so many issues if we just stop the service. For example it may be in the middle of debug session, or few application are in progress and so on. One solution could be, DO NOT let any changes if a device is in running state. So, to make any changes to the device configuration, one has to stop it first and then change any settings. We have to warn that "resume" will be an issue. Resume always takes whatever was saved earlier. So resume becomes invalid. Solution: I would say, DO NOT make any device editable after it got created. Think it as a chip came out of factory. NOT allowed to change the memory for that chip. It only can happen at manufacturing time. If changes are required users can create a new device with new configuration.
The IDE should still have a handle on the cjcre.exe process if it started it (it tracks them to ensure they are terminated on shutdown - look for a call to Runtime.getRuntime().addShutdownHook() in source). So I'd suggest: - Allow user to modify the device - it's easy to decide you need to change memory limits, etc., so we should not make this hard or non-obvious - This could definitely make a mess if the user has the card in a known state and is using it (debug session, whatever) - If the device is running (you can get the status - just get the device instance from the node and check its state), then offer the options "Stop emulator and apply changes" or "Discard changes"
Reassigning a bunch of bugs still assigned to me - I haven't worked for Oracle in almost a year.
Uy... I *am* the default assignee for javacard...
changing owner