I'm seeing count of unloaded classes increasing over the time.
From what I read, the classes will only be unloaded, if underlying classloader is garbage collected. So, does it mean that my jetty-based application is creating and destroying classloaders frequently?
This legacy application is using rhino js engine. And according to this thread, default mode is to "generate classes", and in turn classloader for each request.
https://dev-tech-js-engine.mozilla.narkive.com/Aly49IOz/memory-leak-with-rhino-class-loader
https://bugzilla.mozilla.org/show_bug.cgi?id=64397
The solution seems to change the optimization level for interpretive mode.
Related
Why file.bufferedReader() is giving me NullPointerException here?
val file = mock<File>()
when(file.bufferedReader()).thenThrow(IOException::class.java)
According to this thread Unable to mock BufferedWriter class in junit
You can mock Java IO classes (including their constructors, so future
instances also get mocked) with the JMockit library, though you will
likely face difficulties such as a NullPointerException from the
Writer() constructor (depending on how the mocking was done, and which
IO classes were mocked).
However, note that the Java IO API contains many interacting classes
and deep inheritance hierarchies. In your example, the FileWriter
class would also probably need to be mocked, otherwise an actual file
would get created.
Also, usage of IO classes in application code is usually just an
implementation detail, which can easily be changed. You could switch
from IO streams to writers, from regular IO to NIO, or use the new
Java 8 utilities, for example. Or use a 3rd-party IO library.
Bottom line, it's just a terribly bad idea to try and mock IO classes.
It's even worse if (as suggested in another answer) you change the
client code to have Writers, etc. injected into the SUT. Dependency
injection is just not for this kind of thing.
Instead, use real files in the local file system, preferably from a
test directory which can be deleted after the test, and/or use fixed
resource files when only reading. Local files are fast and reliable,
and lead to more useful tests. Certain developers will say that "a
test is not a unit test if it touches the file system", but that's
just dogmatic advice.
In Tapestry(5.0) when ever I try to recompile my changes in java class i get a popup saying
Hot Swap Failed
abc.xyz : hierarchy changes not implemented
abc.xyz : Operation not supported by the VM
AFAIK this should be working and because of this I end up restarting the debug session which takes quite a bit of time.
Any help with this ?
You see this warning, because IntelliJ is failing to hot swap the classes, because, as the message says: VM doesn't support this operation for your changes.
What Tapestry is doing is actually not a hot swap, it's called "Live Class Reloading".
In short: instead of updating existing classes and objects inside VM (what hot swap is doing), Tapestry throws old classes away with all their state, and loads/initialises them again using a custom class loader. It can only do this for its managed classes: page/component/mixin classes and IoC service implementations that are registered using service interface. Everything else can only be reloaded with a hot swap if it's implemented by a VM.
You can read more details about Live Class Reloading in official documentation .
I'm implementing a C++ library that wraps a COM library (IMAPI) to more easily provide the functionality throughout our applications.
It contains wrapper classes for the various interfaces of IMAPI. These are instantiated in the GUI thread of a client application to get information about the drives and their current medium. However, these objects also have functions to e.g. write data to a medium, which is a blocking function call.
Usually I would simply put this blocking function call onto another thread and execute it asynchronous to avoid blocking the GUI. However, since the COM objects were created in the GUI thread, which is initialized with COINIT_APARTMENTTHREADED (STA), this is not possible.
How do I best handle this in my shared library so that its clients do not have to worry about these details? Is the best thing to do to create a thread that belongs to my library that is initialized with COINIT_MULTITHREADED and is responsible for the creation of the COM objects?
I am curious about when the class side initialize messages are sent in Smalltalk (Pharo and Squeak particularly). Is there any specified order? Is it at least safe to assume all other classes packaged with it have already been loaded and compiled, or does the system eagerly initialize (send initialize before even finishing loading and compiling the other classes)?
The class-side initialize is never sent by the system. During development you do it manually (which is why many of these methods have a "self initialize" comment.
When exporting code of a class into a changeset, the exporter puts a send of initialize at the very end, so it gets executed when the class is loaded into another system.
This behavior is mimicked by Monticello. When loading a class for the first time, or when the code of the initialize method was changed, it is executed. That is because conceptually MC builds a changeset on-the-fly containing the difference of what is in the image already and what the package to be loaded contains. If that diff includes a class-side initialize method, it will be executed when loading that package version.
As you asked about loading and compiling, I'm assuming you mean when loading code...
When loading a package or changeset, class-side #initialize methods are called after all code is installed (1). While you can not count on a specific order, you can assume that all classes and methods from that package are loaded.
As Bert pointed out, if you were not loading but implementing class-side #initialize, you'd have to send the message yourself.
One way to know for sure, is to test it yourself. Smalltalk systems make this kind of thing a little more approachable than many other systems. Just define a your own MyTestClass, and then implement your own class side (that's important) initialize message so that you can discover for yourself when it fires, how often it fires, etc.
initialize
Transcript show: 'i have been INITIALIZED!!! Muwahahahah!!!'
Make sure it works by opening a Transcript and running
MyTestClass initialize
from a Workspace. Now you can play with filing it out and back in, Monticello loading, whatever and when it runs.
I am porting a regular C++ app to metro in C++ using WRL. I have an existing thread pool and that some point I need to update the UI from one of these threads.
Touching directly the UI objects gives the expected RPC_E_WRONG_THREAD so I need somehow to execute in the right thread. Looking in MSDN I discovered that the metro dispatcher (CoreDispatcher) has a RunAsync method.
Larry Osterman sort-of answers the question of how to use it here:
Run code on UI thread in WinRT
But what is not clear is if I can do that from a non-winrt thread, that is from a thread which has not called RoInitialize.
I guess to be more precise I fear that the dispatcher might belong to an STA and I would need to somehow marshal the interface so it would be safe to call from my other thread.
Note that the main() function of my app following the msdn samples calls RoInitialize(RO_INIT_MULTITHREADED).
You should be ok calling CoreDispatcher::RunAsync from a non UI thread. But there are a couple of caveats:
1) You need to be in a metro style app (this should go without saying). The reason is that the application object creates an MTA that lives for the life of the application. There's this nifty feature of COM called the implicit MTA - if the MTA exists in your process any threads are considered to be a part of that MTA even if they've not called CoInitialize.
That means that when you access CoreDispatcher::RunAsync, even if you need to proxy objects, the MTA is active so the marshaling should succeed.
Note that there is a period of time during app startup where it's possible that the application object hasn't yet been created - you should refrain from doing anything until your application's code has been executed.
2) You need to capture the CoreDispatcher object on the UI thread you want to use. This is made easier by the fact that the Xaml infrastructure already captures the dispatcher in DependencyObject. So if you already have a Xaml UI element, you can just call .Dispatcher.RunAsync().
PS: The UI thread is on an ASTA (application STA, a new kind of apartment added in Win8) but the dispatcher is thread agile. Note that while the dispatcher is agile, the CoreWindow should not be considered agile.