Closed aknuds1 closed 10 years ago
Looking real good! :) Still seem to fail on compile because of missing generic type info - perhaps better to specify type params either way?
Strange that it should fail to compile, it must be because I'm compiling with a newer Java? Can I make JDK 8 compile as if it were JDK 6?
Do we need to support old JDKs btw??
I think it the <> notation is new in Java 7. We should support back to JDK/JVM 6. There are build tools that have to support it and I would argue that the overhead of adding the type parameters is not large enough to merit not supporting it. Might be wrong though.
I can definitely see that we should support older JRE's, but what are the scenarios where old compilers must be supported in building Adept?
Should we compile with JDK 6 locally then? Can JDK 8 be configured to compile as if it were version 6?
It is possible to build to a older target and I have tried to setup the build file to this (search for jvmTarget) but I am not sure it works (I believe there is an issue on this). Before releasing I am compiling with JDK 6, but normally in dev mode use JDK 8 (these days) because it is faster. You are right that we could just compile to an older target in theory though.
I have had a couple of glasses of wine, so I think I have to review this tomorrow again though. It is looking very good though! :) Just want to check if there are more tips for you in there (I am assuming you want these ;) )
It is a bit of a pain to not know if one breaks the build or not while developing, so it would be best to try to find a solution. Either compile with new compiler targeting old JVM, or maybe compile with old compiler if need be.
Compiling against JRE 6 with JDK 8 is possible, but one needs to set the bootclasspath to point at the runtime libraries of JDK6. Something like this: https://github.com/ngs-doo/dsl-client-java/blob/master/code/project/DSLBuild.scala (althought you usually need just rt.jar). Your best bet would always be to compile by using the older JDK, but using the bootclasspath seems to be the preferred option when creating libraries (smarter javac, I guess)
I've changed build.sbt to provide options -target:1.6 and -source:1.6 to javac, as per this StackOverflow discussion. It seems to catch the language incompabilities as I was hoping, so that should be good enough. We can compile release builds with JDK 6 anyway.
This PR looks perfect now! Thank you so much! :)
Just make sure to test adept-lockfile, as I haven't been able to :)
Yep, writing a small test for it.
Have consolidated around Jackson streaming API for JSON serialization and deserialization. All tests pass, but it seems that adept-lockfile doesn't get tested, as known bugs aren't detected. I've scoured the code, but it would probably be wise to test adept-lockfile to verify that it still works. The Java code is also pretty dirty, since writing functional style in this language turned out to be pretty hard :(
Solve #37.