If a java project compiled with jdk 5 talks to another project which is compiled with jdk 6, whether it leads to any compilation issue(s)?. In simple, can a lower version of java talks to higher version of java give any compilation error? Any clarifications would be appreciable.
Thanks,
Marshal.
It works fine. Go right ahead. We all depend on it every day.
Related
I'm relatively new to Kotlin.
I did create a test project, just the Hello World for now.
Compile/Package OK, then when I try to run the main.kt :
Kotlin: API version 1.1 is no longer supported; please, use version 1.2 or greater.
Is driving me nuts.
Ok, here some info and things I did :
Ubuntu 18.04
IntelliJ Idea Ultimate 2020.3 - all plugins/libraries updated
Kotlin project created from Project --> Kotlin --> Console Application --> SDK 1.8 --> Maven (need to simulate another environment that has similar settings)
On Settings/Build/Kotlin Compiler I selected Language version 1.4
When building I have only some warnings and I did notice this one :
[WARNING] Runtime JAR files in the classpath should have the same version. These files were found in the classpath:
/home/steve/.m2/repository/org/jetbrains/kotlin/kotlin-stdlib/1.1.1/kotlin-stdlib-1.1.1.jar (version 1.1)
/home/steve/.m2/repository/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.4.31/kotlin-stdlib-jdk8-1.4.31.jar (version 1.4)
/home/steve/.m2/repository/org/jetbrains/kotlin/kotlin-stdlib-jdk7/1.4.31/kotlin-stdlib-jdk7-1.4.31.jar (version 1.4)
So it seems is still importing a stdlib 1.1.1, I did try to remove manually it but without success, is always there.
The POM only has this from jetbrains :
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib-jdk8</artifactId>
<version>1.4.31</version>
</dependency>
Can anybody please give me some suggestions about how to fix this kind of problem ?
Thanks
STeve
Ok, I did restart from scratch many times trying to identify the problem and I think I did it, i.e. I identified the problem but I don't have a solution.
Starting from scratch everything is working, however I need to add to the project some classes I created in other projects in order to test them.
One of the class imported uses a library called khttp.
Well the moment I add this library as dependence in the project, even without adding any code that use it, screw up everything and I end up with the error :
Kotlin: API version 1.0 is no longer supported; please, use version 1.3 or greater.
The ONLY way I found so far to solve the problem is to remove from the POM the dependency of the library.
So I guess that the problem is IN the library.
If I can't find a solution I guess I need to don't use khttp.
Thanks
Go to
Intellij Preferences -> Build, Execution, Deployment -> Compiler -> Kotlin Compiler. Update Language version
and Api version to the one you wish.
**Click run again it should work fine.
for me it worked like this: right click on project and go to
project settings -> modules -> Kotlin
there I set the API Version to 1.5
I update the Kotlin dependencies version in pom.xml from 1.3.61 to 1.5.10 and it's ok for me
Project Structure>Modules>General
When you go there you gonna see 2 sections right side. Language version and API version. Update these 1.5 and problem will solve easily.
I am having difficulties understanding HOW maven compiler plugin works under the hood post java 8 (i.e. JDK 11).
(I know how to operate it to work with JDK 11 (using <release> element), but I am interesting (and confused) as to HOW it works behind the scenes)
When working with pure JDK 11 javac, I can give it the --classpath argument and have all the jars listed there be treated as Unknown module.
I can also give javac the --module-path argument, and have all the (non modular) jars appearing there to be treated as Automatic module(s).
But, when working with maven project, using the maven-compiler-plugin with JDK 11, how does it compile my code ? are all the dependencies are in the classpath ? or in the module-path ? perhaps both ? what maven uses to distinguish between them ?
I have read the maven-compiler-plugin documentation, that referred me to the plexus compiler project (and could not find there much to be honest). I expected to be able, eventually, see the actual command line that maven compiler plugin uses when invoking javac for me and its various used arguments. I tried to invoked it with verbose=true and did not get anything useful as well..
All in all, I could not find anything useful on that stuff ; All references explains how to operate compiler plugin as a black box, nothing about how it actually works internally. :(
Anyone knows or has a good reference to a proper documentation\explanation on the above ?
Update:
Following #khmarbaise comment, -X shows a lot of debug information, among it a detailed list of what jars\classes are used in the class-path and which are in the module path.
One strange thing remains though:
I am compiling maven module A which is a java module as well (it has module-info.java file). It seems that A's classes (...\A\target\classes folder) is given to the class-path argument. Any idea why ?
We have a system which runs on Java 6 and uses Ant. I want to migrate the system to Java 13 and Maven.
What are the things that I need to consider when performing this migration? I understand that some third party libraries may cause issues but I'm hoping that all the Java libraries will work smoothly as before.
What is the easiest way to follow in doing this? Is there a plugin in an IDE which can perform the Ant to Maven migration easily?
Thanks in advance.
First migration is a manual process
Change the directory to follow Maven conventions
Create one/more pom files which fill your needs. Do you have multiple modules?
Try to build with maven
Are you within a company? Yes start with a repository manager
Make configuration (settings.xml).
Start to build with JDK 8 first (expect issues with libraries)
Try to build with JDK 11 (expect some issue with libraries)
Finally JDK 13
I have some projects in Java 6 and Spring on app server. Because of limitations in my infrastructure and governance planninng I cannot migrate to newer Java 7 or 8.
I think i could add Kotlin in those projects to use features like functional programming.
It this approach a good way to go?
Thanks
In my opinion Kotlin is a great language because it addresses all the pain points from Java in terms of boiler plate code and adds all of this plus functional programming to Java 6 (your target Java version)
So go ahead and give it a try.
If you use IntelliJ you can convert Java files to Kotlin and vice versa.
For kotlin, I don't know. But I think there is a lambda library, developed by Mario Fusco, an italian "Java Champion" (the only italian Java champion as far as I know), which is named lambdaj.
I google it for you and I found this. I suggest you to google it a bit more, I remember that long time ago it was available in a jar for ant build.
I hope it helps.
Java 9 is scheduled to be released soon (July 27). Are there any plans to release a Java 9 compliant version of Spring projects that will be modular (Java 9 project Jigsaw)?
Spring 5, the next major version of Spring, won't be modular. However you can use Spring 5 jars/artifacts as automatic modules in your module-info files. See official blogpost and What's new annoucement.
Conserning module-info.java see Declare Spring modules with JDK 9 module metadata issue last commit:
This issue is marked as "General Backlog", indicating that we won't deal with it for 5.1 (otherwise it'd be marked for 5.1 GA still) and probably not in subsequent 5.x releases either (otherwise it'd be marked as "5.x Backlog").
Specifically, we can't ship module-info files quite yet since we'd need stable module names for all of our optional dependencies... and many of those don't declare stable module names at this point (that is, they don't even include an Automatic-Module-Name manifest entry in their jar). Also, we'd need to build the entire framework on JDK 9+ for the compiler to understand the module-info.java format which is not entirely trivial either, even if the framework itself is known to work fine with JDK 9/10/11 at runtime.
All in all, my prediction about module-info files for 5.1 turned out to be too ambitious. Our current focus is on general JDK 11 compatibility (SPR-16391) on the classpath and as automatic modules on the module path, as well as GraalVM compatibility (SPR-16991). The use of jlink requires manual addition of module-info.class files to the framework jars for the time being... which might stay that way for several years still until we ship a JDK 11 baselined Spring Framework 6.0 against a new generation of dependencies.
Update For 11/3/2022
from Juergen Hoeller in #18079
Our strategic alignment with the module system has been in competition with our AOT and GraalVM native image efforts in 6.0, so we unfortunately had no chance to experiment with a build migration to full module descriptors yet. There have been very few requests for it even in the course of this year, so we wonder whether there is much practical value to be uncovered here for the time being anyway. Looking forward, the use of jlink's module-bounded approach for application/framework-level modules might get superseded by runtime images based on GraalVM-style individual reachability analysis in the long run.
That said, OpenJDK's Project Leyden aims to reuse module system concepts and tools for its standardized static image approach, so deeper module system alignment remains part of our long-term technology strategy for the Spring Framework 6.x generation.