Rename annotations about hotswapagent

[edudant]

I agree, that your version looks more intuitive and it might be a good time to change it. However, few considerations:

@Transform was selected to match Java ClassFileTransformer API. If we split the annotation into two versions, there is a lot of associated behaviour (method parameter matching), which will be common for both versions.

@watch has several arguments, that will be common for both versions as well. Suffix "Updated" is a little bit misleading, because it is also Created/Deleted. @watch(filter = ".*.class") is regexp that uses only .class, but what if I want to catch only a single class or some class name prefix.

There are associated handlers with a name same as annotation. If an annotation is split to two, this logic must be changed as well.

@watch is probably not a good name.

[bthule]

"Alter", "Modify", "Change", "Update", "Transform", all have a similar connotation that it might not include adds and deletes. I personally think using "Update" is okay since when there is an add or delete, the class is updated in the ClassLoader. In my opinion, even simply changing @Transform to @OnTransform would make it more intuitive.

I expected @OnClassFileUpdated would use classNameRegexp. The point of showing the filter - ".*.class" was meant to only show that it was only relevant for class files. I personally really like this separation since the annotation could then drive the CtClass and any other class specific injected parameters.

[edudant]

Ok, what about:
@Transform => @OnClassLoaded. It should cover update event as well, because usually you will watch for both load and update. Properties onDefine and onReload will remain. There is different behaviour with static and non static class (see javadoc).

@OnClassFileEvent => instead of path and filter properites will contain classNameRegexp property (same as @OnClassLoaded).
@OnResourceFileEvent => same as @watch, CtClass and ClassPool parameters will not be available.

[bthule]

I really like the naming for @OnClassFileEvent and @OnResourceFileEvent. Smart.

Maybe do @OnClassLoadEvent (or shorter @OnClassEvent) for @Transform

Also, consistency of annotation params for @OnClassEvent and @on*FileEvent would be smart.

eg.

• @OnClassLoadEvent(onDefine=true, onReload=true)
• @OnClassFileEvent(onCreate=true, onModify=true, onDelete=true)

or

• @OnClassLoadEvent(events = {LoadEvent.Define, LoadEvent.Reload})
• @OnClassFileEvent(events={FileEvent.CREATE, FileEvent.MODIFY, FileEvent.DELETE})

But thinking about this more, I suggest @OnClassEvent(events = {ClassEvent.LOAD, ClassEvent.RELOAD, ClassEvent.FILE_ADDED, ClassEvent.FILE_MODIFIED, ClassEvent.FILE_DELETED}). I know this is a bigger change, but it keeps all the class events together, which seems correct for consistency. It allows documenting how the ClassEvents differ from each other more easily. There would naturally be an @OnResourceEvent with ResourceEvent.FILE_ADDED, ResourceEvent.FILE_MODIFIED, and ResourceEvent.FILE_DELETED. This is what I would like to see, but I feel like I'm suggesting too big of a change.

[edudant]

This looks good to me:
@OnClassLoadEvent(events = {LoadEvent.Define, LoadEvent.Reload})
@OnClassFileEvent(events={FileEvent.CREATE, FileEvent.MODIFY, FileEvent.DELETE})
@OnResourceFileEvent(events={FileEvent.CREATE, FileEvent.MODIFY, FileEvent.DELETE})

About merging @OnClassLoadEvent and @OnClassFileEvent. What we solve here is an edge case, where you need to reload a class when it is not known to Java classloader (file annotations are scanned by different mechanism). When you listen for both ClassEvent.RELOAD and ClassEvent.FILE_MODIFIED, the method will be triggered twice in normal case. This is something you need to be aware of and is explicitly declared by:

@OnClassLoadEvent
@OnClassFileEvent
public void myMethod() {}

[bthule]

Looks great to me!

The merge concept would be too difficult to implement perfectly since hotswap and watcher events occur at different times. FYI, if they were merged, I was thinking that the RELOAD and FILE_MODIFIED would not get triggered for the same file change.

Just a note, for plugins, using static imports will make these annotations more readable:

import static org.hotswap.agent.event.LoadEvent.*;
import static org.hotswap.agent.event.FileEvent.*;

@OnClassLoadEvent(events={DEFINE})
public static void onDefine( ... ) { ... }

@OnClassFileEvent(events={CREATE})
public static void onFileCreate( ... ) { ... }

@OnClassFileEvent(events={MODIFY, DELETE})
public static void onFileModifyAndDelete( ... ) { ... }

[edudant]

Implemented. Please have a look. Btw. any ideas about names of configuration properties inside hotswap-agent.properties? :-)

[bthule]

Looks great! I think the configuration properties in hotswap-agent.properties are fine. Some could be renamed to be clearer, but the example file documents them so the naming isn't as important, imo. But, here are some thoughts: extraClasspath would likely be better named as preferredClasspath. watchResources is well named.