Develop Reference

Java Annotation processor check for full rebuild

I am creating an Annotation Processor in Java and I want to be able to check if the user triggers a full rebuild.
I want to be able distingush between a full rebuild and just building a few files.
Is this possible? Or are there any workarounds for this?
Edit1:
I am going to explain what I want to achieve. I have an annotation processor and 10 annotations. 8 of these Annotations generate a config file called plugin.yml. 3 of these annotations (one annotation is used in both processes) are used to generate a sourcefile called AutoRegister.java. This works like a charm when I trigger a full rebuild and all my annotations get processed. Now the problem arises when I only compile, lets say 3 of the 15 classes using my annotations. Then the plugin.yml and the AutoRegister.java get generated based on the Annotations of the 3 files, thus beeing incomplete.
My workaround is to create a cache file, which contains information about all the other classes, which need to be insertet to the two files plugin.yml and AutoRegister.java. This somewhat works but makes it impossible to remove data from the cache, for example when I remove an annotation from a class. So the only way to remove data from the cache is to remove the cache file and to trigger a full rebuild.

I don't think the term 'workaround' means what you think it means. If there was a way to distinguish, that would just be 'the answer', not 'the workaround'. If you elaborate on WHY you need this, perhaps a different solution is available, that is NOT directly detecting 'full rebuild' versus 'incremental build', which nevertheless is sufficient for your needs. That'd be a workaround, but you'd have to explain why you need it in order for us to try to help you out.
Here's the most common reason I can think of for why you need this:
Let's say your AP will scan all source files, and distill some sort of list from it. For example, all classes that implement com.derteufelqwe.MyAwesomeInterface. Then, it writes this list someplace. Say, META-INF/services/com.derteufelqwe.MyAwesomeInterface. The problem is: During incremental builds, you only see a subset of all sources, therefore the list is incomplete, then you write it where ever it needs to be written and now you have a broken list (as it is incomplete).
The fix for this is that you can ask the Filer for a source file or class file; even if it is not part of the compilation run it is still on the source path or class path and you get a result. Thus, IF you can read the existing list, and you can extract, per entry, the source or class file that is responsible for it (which in our hypothetical case where you are creating a services file, is trivial: The very entry is itself a fully qualified class name you can ask the Filer to find) you can then query the filer if that resource is still around. If yes, keep it, if not, delete it. Now you can update (instead of regenenerate and replace) your list.

java.util.Properties ignoring ${...} placeholders

Anyone happen to come come across a use case where one has to stick to java.util.Properties.load method to read all the key-value pairs from a .properties file but at the same time to be environment/profile specific, placeholders, ${...} are used?
I'm building a spring boot app. and have profile specific properties files and placeholders work fine in them. However, the app. is dependent on a relatively older app that reads a property file from java.util.Properties.load method and in doing so the placeholders are being ignored. Since this is an old app. and do not want to change at this point in time, anyone has any suggestions on how do I go about?

If you're using Maven, you can write a generic properties file as such:
prop.1=${val1}
prop.2=${val2}
...
Then using the Filtering feature of the Maven Resources Plugin, you can do the replace your placeholders depdending on your maven profile.

Generate a SQL script from Hibernate

I'm using Hibernate 4.3.5-Final for my Java Swing application and I do many UDPATE, INSERT and DELETE with it (in HQL or with Criteria).
Now, what I'm trying to do is to export a SQL script of all modifications done on my database but I don't know how to do that. This script need to contain only the modifications (and not the creation of the tables) and put them on a .sql file (exported file path will be chosen by the user)
Do you have any ideas that can solve my problem ?
Thank you in advance !
[Edit] : Some forums talk about p6spy, can it answer to my problem ?

p6spy should help here.
In general, following should do the job for you:
enable p6spy in your app (see official docs: http://p6spy.github.io/p6spy/)
afterwards you have basically 2 options:
use provided: BatchFileLogger, enabling it via: appender=com.p6spy.engine.spy.appender.BatchFileLogger in spy.properties (it's however undocumented yet, see: https://github.com/p6spy/p6spy/issues/119)
OR
implement custom com.p6spy.engine.spy.appender.MessageFormattingStrategy, that would be returning sql only (see: https://stackoverflow.com/a/23521623/1581069 for idea on implementation) and configure it in spy.properties via: logMessageFormat=FooFormat
set sqlexpression to match the queries you need - restricting CREATE/ALTER/... TABLE/SEQUENCE/... (see official docs: http://p6spy.github.io/p6spy/2.0/configandusage.html)
still there are some tricky points, like:
databaseDialectDateFormat property (to be able to kind of replay the output without modifications). For inspiration for some of the common databases, see the unit tests of p6spy itself: https://github.com/p6spy/p6spy/tree/master/src/test/resources/com/p6spy/engine/spy

What should be the strategy to migrate configuration files to new version?

I understand this is question is completely implementation dependent, but would like to know the general strategy used to migrate the configuration files.
We have a product that reads some configurations from properties/XML files. Some default values are configured in the properties file. Customer can change the properties as per his needs. Now suppose we change/add some properties in the file and customer migrates to newer version. How should we merge the customer specific configuration with newly added/updated properties? One way is to write a utility to merge the files, but dont want to do it for every release.
Thanks in advance

We have a configuration inheritance schema. Within development we have:
BaseSetup <- Setup <- DevelopmentSetup <-- StagingSystemSetup
|- DeveloperMikeSetup
|- DeveloperSusySetup
So the demonstration server runs with the setup StagingSystemSetup which inherits from the general DevelopmentSetup, etc. Also each developer has its own configuration/setup, which is also checked in. This means everybody can change its configuration as needed, without interfering others.
On production/customer just the setup is used without specialication, but that is the setup provided by the customer, which inherits from the basic setup.
If we introduce and enable a new feature we only need to modify the base setup. Ideally, forced setup changes by the customer should not happen.

I'd say it's all documentation. I won't bother with a migration tool. You surely have documentation of your software. Include the configuration changes in that documentation. It's the responsibility of your customer to read the change log and apply those configuration changes. If a missing new configuration is essential and has no reasonable default value the error message should clearly point the customer to the missing configuration. OTH if the missing configuration has a default value a warning in the log might be helpful.

Is it possible to add custom metadata to .class files?

We have used liquibase at our company for a while, and we've had a continuous integration environment set up for the database migrations that would break a job when a patch had an error.
An interesting "feature" of that CI environment is that the breakage had a "likely culprit", because all patches need to have an "author", and the error message shows the author name.
If you don't know what liquibase is, that's ok, its not the point.
The point is: having a person name attached to a error is really good to the software development proccess: problems get addressed way faster.
So I was thinking: Is that possible for Java stacktraces?
Could we possibly had a stacktrace with peoples names along with line numbers like the one below?
java.lang.NullPointerException
at org.hibernate.tuple.AbstractEntityTuplizer.createProxy(AbstractEntityTuplizer.java:372:john)
at org.hibernate.persister.entity.AbstractEntityPersister.createProxy(AbstractEntityPersister.java:3121:mike)
at org.hibernate.event.def.DefaultLoadEventListener.createProxyIfNecessary(DefaultLoadEventListener.java:232:bob)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:173:bob)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87:bob)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862:john)
That kind of information would have to be pulled out from a SCM system (like performing "svn blame" for each source file).
Now, forget about trashing the compilation time for a minute: Would that be even possible?
To add metadata to class files like that?

In principle you can add custom information to .class files (there's and attribute section where you can add stuff). You will have to write your own compiler/compiler extension to do so. There is no way to add something to your source code that then will show up in the class file.
You will also have major problems in practice:
The way stack-traces a built/printed is not aware of anything you add to the class file. So if you want this stuff printed like you show above, you have to hack some core JDK classes.
How much detail do you want? The last person who committed any change to a given file? That's not precise enough in practice, unless files are owned by a single developer.
Adding "last-committed-by" information at a finer granularity, say per method, or even worse, per line will quickly bloat your class file (and class files are limited in size to 64K)
As a side note, whether or not blaming people for bugs helps getting bugs fixed faster strongly depends on the culture of the development organization. Make sure you work in one where this helps before you spend a lot of time developing something like this.

Normally such feature can be implemented on top of the version control system. You need to know revision of your file in your version control system, then you can call blame/annotate command to get information on who has changed each individual line. You don't need to store this info into the class file, as long as you can identify revision of each class you deploy (e.g. you only deploy certain tag or label).
If you don't want to go into the version control when investigating stack trace, you could store line annotation info into the class file, e.g. using class post processor during your build that can add a custom annotation at the class level (this is relatively trivial to implement using ASM). Then logger that prints stack trace could read this annotation at runtime, similarly to showing jar versions.

One way to add add custom information to your class files using annotations in the source code. I don't know how you would put that information reliably in the stack trace, but you could create a tool to retrieve it.

As #theglauber correctly pointed out , you can use annotations to add custom metadata. Althougth i am not really sure you if you cant retrieve that information from your database implementing beans and decorating your custom exceptions manager.