Develop Reference

JaamSim crashing on Start up under Eclipse

I am really new to this and trying to get the JaamSim Tool running within Eclipse to run a Simulation for my Bachelors Thesis.
When ever I try to run the config im getting an libc++abi.dylib: terminating with uncaught exception of type NSException. The JaamSim Loading Window always opens for a brief moment and then closes again with the note "GUIFrame was unexpectedly closed"
I tried for days new and im out of ideas... installed the newest jdk from adoptopenjdk, as well as apache ant and maven. Also linked everything within the .bash_profile
I would be really grateful if somebody could guide me to an solution.I added the terminal log form eclipse here1
Btw I am on Mac if that helps

The "exception" you are encountering is not a Java exception. It is a native Objective-C NSException. The "NS" stands for NeXTSTEP. It is a shibboleth of the old NeXTSTEP OS that is the ancestor of OS X and macOS. I can understand your confusion because both Objective-C and Java use the term "exception".
The logs you posted are, likewise, not a Java stack trace but an NSLog based thread dump from the native frameworks that your Java graphics depend on. You cut off the text of the actual exception in the image you linked. I'm guessing you didn't recognize the format and so didn't see the helpful message.
I'm going to guess that full text of the NSException message was "NSWindow drag regions should only be invalidated on the Main Thread!" If this is the case, then I think your problem is likely caused by changing some graphics from a background thread.
System graphics, such as windows, alerts, etc. are managed in macOS through a framework called "Cocoa". NSWindow is a Cocoa object. One of the important rules of Cocoa (and most UI frameworks) is that you should only alter Cocoa objects (like NSWindow) from the main thread. Probably, you are making some alterations to your GUI (specifically, invalidating drag regions) from a background thread. Java doesn't have any inherent problem with this, but Cocoa does. So you get a native error instead of a Java error.
TL;DR: Only work with your GUI from the main thread. You are getting this error because you are changing the GUI from a background thread.
EDIT: After doing a little research.
It appears that this particular issue occurs with certain Java OpenGL libraries, in particular lwjgl. You can see a very determined but ultimately fruitless effort to fix the problem here. I'm not sure what OpenGL Java interface is used in JaamSim, but they documented this same problem as far back as 2018, saying
The bug turns out to be a known problem with the JOGL software we use for 3d graphics. Unfortunately, it will take a while to get a fix in place.
The same JOGL bug was documented again in 2019. There, it seems to be resolved. Their report of the fix was
encapsulated both construction fully to run on the Main-Thread
I'm not sure how much control over this you have. Your best bet is to start by adding the -XstartOnFirstThread flag to your java command. I would also check if anyone in your class has been able to make this work on a Mac. Sometimes, it's nice to do a quick impossibility check before wasting time.

DDMS reporting incorrect memory usage?

I'm currently investigating one of our Android applications for memory leaks and I found something that completely baffles me.
The DDMS heap monitor reports that the application is using 13mb/20mb heap memory, but a report pulled directly from the device is reporting that the application is using nearly 700mb!
Is this an issue with the device? Is DDMS wrong? How do I find out what is going into that 700mb?

It is part of the system software
The first screenshot is the output of adb shell dumpsys meminfo. The second screenshot looks like it is from procrank, which isn't part of standard Android; leastways, I can't find it quickly on Android 6.0.
(in the future, when somebody asks you 'what exactly is this "report"', feel free to cite actual commands)
Is this an issue with the device?
Probably not, though that's tough to say, since we do not know what the device is, what the app is, or much of anything outside of two digital camera photos.
Is DDMS wrong?
Probably not. Java code, whether running in Dalvik or ART, has a heap limit, and that's going to be well under 700MB.
How do I find out what is going into that 700mb?
~600MB of that will be coming from native code (NDK libraries), most likely.
So, start by finding out what in your app is using native code. That could be your code, or it could come from third-party libraries (e.g., Fresco). Your choices then are:
Call (or implement) logic in those libraries to cap how much heap space they use, or
Get rid of them, or
See if there's a way of hooking up Valgrind or something else to NDK code to determine where and how those libraries are using so much system RAM

java api to receive notifications when a file system is mounted

I am looking for a Java API that will allow registering for file system mount events, i.e. when a file system is mounted or dismounted. Specifically I want to know when a file system on removable USB devices is available, and also know exactly what type of USB device it was.
The udev subsystem provides notifications on USB plug and unplug events by default but not specifically when the file system on the device is available. It is possible to create udev rules that can do this in pieces, e.g. create a directory and execute a program when devices are added and removed. But my experience with udev rules is that the syntax is arcane and they are fragile and not simple to debug.
I've installed usbmount per this post:
https://serverfault.com/questions/414120/how-to-get-usb-devices-to-automount-in-ubuntu-12-04-server
though I believe the devices were automouting by default.
As an alternative I constructed a JDK 7 WatcherService on /media which can detect changes in /etc/mtab. This works but I have seen cases where the file systems on some USB devices are still not ready - meaning that attempts to read the directory throw an Exception - even after the entry in /etc/mtab is made. I added a timer to sleep for a configurable number of milliseconds and in most cases a 100ms wait time works but not 100% of the time. What this means is that increasing this wait time is not an absolute guarantee nor deterministic.
Clearly at some low level the mount event is being generated because the Nautilus pop-up window gets displayed. I had a case of one flash drive that would put the Nautilus icon in the launch pad menu but it would not mount until the icon was clicked open.
I've also looked at these options:
tailing /var/log/syslog; this may be the next best option. I see lines like the following:
:Dec 2 08:58:07 fred-Inspiron-530 udisksd[1759]: Mounted /dev/sdk1 at /media/fred/USB DISK1 on behalf of uid 1000
I am going to try a WatcherService here to see if the same timing issue exists, i.e. is the directory readable once this message is written.
jlibudev [ github.com/nigelb/jlibudev ] Much better Java API to udev subsystem than writing rules but it still falls short in that you still have to piece a number of different events together. NB: jlibudev depends on JNA [https://github.com/twall/jna] and purejavacomm [ github.com/nyholku/purejavacomm, sparetimelabs.com/purejavacomm/purejavacomm.php] both of which are pretty useful in their own right.
lsusb provides details on the usb device but nothing about where it is mounted.
Ideally I would like a simple API that would allow registering for file system mount/unmount events using the standard Java event listening pattern. I want to believe that such an API exists or is at least possible given that at a macro-level the net effect is occurring. I am still scouring the JDK 7 and JDK 8 APIs for other options.
Any and all pointers and assistance would be greatly appreciated.

Since there's no OS-agnostic way to deal with mounting filesystems, there's definitely no JDK API for this. I'm guessing this problem is not dealt with much (not a lot of programs deal with mounting filesystems directly), so it's unlikely that there's any prebuilt library out there waiting for you.
Of the approaches you mentioned, they all sound roughly equal in terms of how platform-specific they are (all Linux-only), so that just leaves performance and ease of coding as open questions. Regarding performance, running lsusb more than once a second is (a) a giant hack :-) and (b) fork+exec is slow compared to running something in-process, and tailing the event log will create a lot of (unpredictable) work for your program that is not related to USB mounts as well as making your implementation more fragile (what if the message strings change when you upgrade your OS?). Regarding ease of programming, either using jna or JNI to call into libudev or a WatcherService on /media sound about equal -- using libudev seems like the most portable option across Linux distros / user configurations (I'm guessing that's what Nautilus uses).
However, for simplicity of implementation that will work for 99% of users, it's hard to do better than a WatcherService on /media. To help ensure that the filesystem is available before use, I would just use a loop with some kind of randomized exponential backoff in the amount of time to wait between attempts to read the directory -- that way you never wait way longer than necessary for the filesystem to mount, you aren't burning tons of CPU waking up and trying to read, and you don't have to pick a single timeout number that won't work everywhere. If you care enough to ensure you don't tie down a single thread sleeping forever, I'd use a ScheduledExecutorService to issue Runnables that try to access the filesystem, and if it's not available schedule themselves to run again in a bit, otherwise alert your main thread that a new filesystem is available for use using a queue of some kind.
Edit: I just learned that you could also watch for updates to the /proc/mounts file. Hopefully since the kernel is responsible for updating this file things only show up when they're fully mounted, although I don't know for certain. For more details, How to interpret /proc/mounts? and the Red Hat docs were useful.

How come it is possible to "interact" with my app's process in DDMS even after I "exit" my app?

Now, I am aware that there is no such thing as "exiting" an app in Android. By this I mean that the process corresponding to an app is kept in memory even after all the activities in that app are destroyed. (For sake of simplicity, let's keep services and such out of the picture). The process is only killed when the system decides to do so in order to reclaim memory.
However, once all my activities have been destroyed, I would assume that the process corresponding to my app is no longer "active". By this I mean that since my app is not doing any work, I assume the process no longer performs allocations. Is this assumption correct?
I used the simple default HelloWorld example that Eclipse ADT gives me via the New Android Project Wizard and saw that this is not the case. Even after I close the app, I can still track allocations in DDMS. Can anyone explain the reason for this?

Allocation tracker has hints for you: columns Thread Id and Allocated in.
Watch these, and you'll learn which object and method did the allocation.
My inactive app shows allocations in DdmServer, which indicates that memory is used for DDMS service to work.
If you get other kind of allocations, check if your app has some outstanding threads, or other tasks that may be still running in background. If this is the case, make sure to do cleanup in Activity.onDestroy.

There is code running within the process because DDMS is attached to it. That code is the "remote" part of the remote debugging facility. Since there is code running there, that code will allocate memory and you will see those allocations.
If the debugger wasn't attached to the process, the OS could destroy the process if it wanted or needed to. However, because the debugger is attached, the process won't go away while you are watching it.
This is an example of the Observer effect, where you get unexpected results just because you are watching ;-)

Java applet white screen

I'm trying to get to the bottom of a problem with our Java applet based program. It quite regularly seizes up with an unresponsive GUI (or a white screen). This of course only happens when deployed at a customer site :-(. They are running a version of the Sun JVM in 1.5 series (not sure the exact release).
We have a theory that it's to do with the applet running out of heap space - does that sound plausible? The other thing that I have set up on my machine is disabling direct draw, but that was mainly to avoid weird artefacts on other applications.
They are seeing the problem on Citrix and on regular PCs, but obviously there is a limit to what the users on Citrix can do.
Any suggestions?

Running out of heap space should cause an OutOfMemoryError to be thrown. This case sounds like a typical deadlock. To find where that is you want a stack dump of all the threads. IIRC< you can do it through the console, or from IIRC 1.6 the JDK includes jps and jstack.

First of all ensure the customer uses the latest release of the JVM they are using, and make them enable the Java console inside their browser (this requires some research from you).
Then when it happens again, tell them to look at the console window and cut-paste the contents in a mail to you.

In order to solve the problem, you must first be able to reproduce the problem. You will need an identical system in order to troubleshoot this, making one change at a time while keeping everything else equal to determine the cause(s).

Just to add to this answer (to build the knowledge base as I'm currently looking into this).
There's (at least) 2 distinct white screens related to applets.
Deadlock (as mentioned by Tom) - area will not refresh when you drag a window in front of it, so you get the strange tails left effect.
VM crash - area will become white, Java VM closes (search for hs_err_pid*.log, location dependent on browser)