The current code is performing authentication calls on ExecutorService that it then cleans up in a finalize method. I suspect this is how the original C# code does it. However, finalize doesn't work in java the way it does in C# and as written the code will prevent the JVM from exiting unless at least two GC calls have occurred since an ADALClientWrapper has been constructed (create a simple main that does nothing but make an IntuneClient call to demonstrate this - the program will hang on exit). It also will keep allocating new OS threads between GC calls.
The library as written makes no use of the possible concurrency offered by adal4j's ExecutorService-based design, so I replaced the current ExecutorService with a "run on the current thread" version. It should be more efficient, will not hold onto the JVM and will not allocate unnecessary OS threads.
The current code is performing authentication calls on
ExecutorServicethat it then cleans up in afinalizemethod. I suspect this is how the original C# code does it. However,finalizedoesn't work in java the way it does in C# and as written the code will prevent the JVM from exiting unless at least two GC calls have occurred since an ADALClientWrapper has been constructed (create a simplemainthat does nothing but make an IntuneClient call to demonstrate this - the program will hang on exit). It also will keep allocating new OS threads between GC calls.The library as written makes no use of the possible concurrency offered by adal4j's
ExecutorService-based design, so I replaced the currentExecutorServicewith a "run on the current thread" version. It should be more efficient, will not hold onto the JVM and will not allocate unnecessary OS threads.