Develop Reference

Should I update aspectJ when migrating from java 6 to 8?

My AspectJ version is still on 1.6.8 running on a Java 6 Project.
Suppose I migrate to Java 8.
Should I update the AspectJ version? Is it mandatory?
If yes, are there things I have to be aware of?

This question was flagged as a duplicate before, but I voted to re-open it because the other question was about AspectJ Maven Plugin compatibility with Java 8 and the answers there do not explain anything explicitly in order to answer this question.
AspectJ 1.6.x was published for Java 6, just as AspectJ 1.7.x was for Java 7, 1.8.x for Java 8, 1.9.x for Java 9-13 at the date of writing this.
Having said that, you should consider the following:
If you would just use the Java 8 compiler but compile your Java 6 code with target 1.6, in theory you could continue using AspectJ 1.6.8 (e.g. runtime) too.
But as soon as you compile with target 1.8 and/or use Java 8 language features, you have to use AspectJ 1.8.x (I recommend the latest version) at least in order to make the AspectJ compiler and weaver understand those language features and the byte code at all.
I would even recommend to use the latest 1.9.x version, it is backward compatible and might have a few bug fixes missing in 1.8.x. But that is an optional choice. I always use the latest AspectJ version even in Java 8.

Does there exist a Babel like compiler for Java?

With javascript if we want to make sure that our code runs in all browser versions we can use Babel. Is there something like this for Java, where we could write our code in Java 9, but it will run in a Java 6 runtime?
For example can Kotlin target multiple JVM runtime versions?

I was hoping for something like Kotlin to target multiple JVM runtimes - I guess we just have to dream for now.
You can compile Kotlin code to JDK6, JDK7, JDK8, JDK9 or any JDK above JDK6. This is what meant by supporting Java 1.6 level byte code. All features of Kotlin will stay the same, except for libraries, which can require different JDK versions.
The byte code generated by Kotlin will generally stay the same independent of the target JVM version. An exception is if you set a compiler option jvmTarget = "1.8", then the compiler may (or may not) use some features of JDK8 as an optimization.
IMHO this question got all the minuses because of how unexpected it is. Tools like Babel are unique to JavaScript because in all other languages they are called compilers. Since JS decided it could do without a compiler, I has such problems with deployments. There are (very limited) back porting tools for Java, but they are just plugins to the compiler. Kotlin doesn't have any, because its development is independent of JDK and it has to support all previous JDK versions above 1.6.
To sum it up, if you use Kotlin for JVM or JS development, your dream have come true - you can use any version of Kotlin, with any JVM library, probably any JS library above ES5.1, and get consistent runtime representation.

There is an unofficial library retrolambda which compiles Java 8 feature lambda expression into Java 6(just like Babel).
I guess you will enjoy it, and here it is: https://github.com/orfjackal/retrolambda

You can check teaVM ! http://teavm.org/ also there is dukeScript

Java - Write code that older version ignore

I try to write my code compatible with older versions of java, so it will work everywhere.
on the other hand there is very powerful tools in the new version - java 8, and I want use them.
So I'm forced to choose between compatibility or richest code.
And I'm wondering if by any chance I can write some methods in java 8, and somehow prevent the compiler of older version to ignore these methods, so my class is compatible "partially" with older version.
Thanks.

You can write two classes and use some toll like ant, maven or gradle to chose which file use for compiling with concrete Java version.

You can set the java compiler to compile against an older jdk (ie jdk 1.5) even if you use jdk 1.8. see javac source and target options

I think the short and easy answer is no.
See this thread: Can Java 8 code be compiled to run on Java 7 jvm?
You can use the java reflection api to check if methods exist in the jvm the code runs on. This allows you to make your code fail-safe even when a method or class is unavailable in the jvm. Doing this is very cumbersome however and I'm pretty sure it's not what your're looking for.

Can scala code compiled with JDK 7 run on JVM 8?

I have a project using scala for several microservices. We are planning to move to Java 8, but due to the limitation of gradle's Scala plugin and the compatibility between scala and Java 8, those micro services will still be compiled on JDK 7. My question is will they run on JVM 8 without any modification or specific configurtion?

Scala 2.11 which is just released is not yet compatible with Java 8 bytecode. However JVM 8 is backward compatible, so as long as you are still compiling your Scala code on JDK 7 and you just drop it in JVM 8, everything will be working fine.
Might not be applicable to you, but latest Scala only works with JDK 6+, so nothing lower than JDK 6.

Yes, they will. So will those compiled on Java 6 or 5. I am not sure about earlier versions, but would still expect them to work.

Will programs written against "Java 8" JDK be compatible with "Java 7" JREs?

My question is if Java JDK and JREs have to be compatible to run?
I mean: will Java applications written using JDK version 8 in future work with current JRE's?

It is possible to use cross-compilation options when compiling. Do that and it will be possible to compile code with SDK 8 that is compatible with Java 1.1. It won't be very advanced code for 1.1, but it will run.

The short answer is No.
If you develop your application in JDK 8 and run it with JRE 7, you would get an UnsupportedClassVersionError.

This question is two part:
JDK vs JRE
forward / backward compatibility.
JRE is the acronym for Java Runtime Environment. JDK is the acronym for Java Development Kit: a set of tools which you use to develop Java programs. The JDK also contains a full JRE. In general there is no compatibility issue between the two. But you might want to take care not to use libraries which are only available in the JDK (for example code generation or the tools.jar)
Java itself is compiling to bytecode, which is forward compatible. That means you can use bytecode of any Java version and run it with any newer version. The other way around generally doesn't work and is checked by using the class file version ("java.lang.UnsupportedClassVersionError: Test : Unsupported major.minor version 51.0").
Then there are Java libraries, including the core libraries. So far there was never anything removed from them, so they are forward compatible. This is probably going to change with Java 9 where a very small usually unused library functions are removed.
Regarding to backwards compatibility, this is possible by setting the Java compiler to produce Bytecode of an older version. Up until Java 8, the compiler was always able to produce bytecode of the last two major versions as well. However, you might successfully compile a Java 8 source to Java 6, but not be able to run it. That is the case when you use libraries that are only available on a never Java. For such cases there is for example the maven animalsniffer plugin which will verify that when you compile against an older version, you actually only use libraries existing in said version.