JAVA_HOME, -java-home and java binary incompatibilities about sbt-extras HOT 22 CLOSED

note the suggestion to look for a .java-home file on startup of sbt. Is this something you would consider supporting?

from sbt-extras.

We know it's running the right java binary, after that it's in sbt's hands. It's a bug in sbt if it doesn't use the javac which corresponds to the running java.

In principle I could modify the path when JAVA_HOME or -java-home is encountered, but I am leery that this may have unanticipated consequences and I don't want to have to wonder about it.

from sbt-extras.

See sbt/sbt#510 which indicates "If you specify javaHome explicitly (such as in your ~/.sbt/global.sbt configuration file), it will construct the path to the binary directly. I expect that would be a suitable workaround."

from sbt-extras.

I can maybe add the javaHome setting to the command line when -java-home is given.

from sbt-extras.

This is how I'm currently dealing with it, which is nice because I have project-specific java requirements (which can't be committed to SCM because of local paths) and I rarely remember to augment sbt with the correct -java-home anyway:

https://github.com/fommil/unix/blob/master/bin/sbt#L8

It would be awesome if you could take the same concept and put it in sbt-extras (no change to current behaviour if .javahome is not present).

I'll do a quick grep of sbt's sources to see where they might be calling javac without the path.

from sbt-extras.

If sbt/sbt#510 can be believed, they are intentionally calling javac without a path.

from sbt-extras.

That's awful

from sbt-extras.

My enthusiasm didn't extend all the way to writing a test, but as of 2e2280f this behaves as described. I verified the change in behavior.

from sbt-extras.

I'm reopening this because I won't pay the price of six lines of new noise every time I start sbt. So if we want this to stick around it would be great if someone would investigate how to shut it up for a while, then let it speak.

[info] Set current project to root (in build file:/mirror/forks/wartremover/)
[info] Defining {.}/*:javaHome
[info] The new value will be used by core/*:compilers, core/*:console::compilers and 24 others.
[info]  Run `last` for details.
[info] Reapplying settings...
[info] Set current project to root (in build file:/mirror/forks/wartremover/)

from sbt-extras.

A likely outcome is for me to only set javaHome when -java-home is given, but not based on JAVA_HOME.

from sbt-extras.

How about the necessary bash magic to only set javaHome from JAVA_HOME when java and JAVA_HOME/bin/java are not the same?

That way for you and me there's no spam and for people with JAVA_HOME's pointing to alternative java binaries to PATH it's consistent (same java & javac versions) and explicit.

from sbt-extras.

does this mean you've found out how to convince sbt to use the javaHome version of javac? Because if that is not the case, then setting PATH and JAVA_HOME is the only way to guarantee a good build (see my customisation to your script above which reads the java home from a project specific .javahome file)

from sbt-extras.

@fommil Setting javaHome is enough to convince sbt to use the javaHome version of javac, that's the point of the commit.

from sbt-extras.

Well can't do it via path, at least not for me on Mac OS X, as my java is /usr/bin/java, which through Mac voodoo is also my JAVA_HOME/bin/java.

Perhaps test -version results? I guess technically people could have different java installations, perhaps with JCE, or dropped in jars.. but I guess they can open tickets, or be explicit with -java-home.

from sbt-extras.

@dwijnand If you're up for investigating, forget about javaHome and consider the larger question: my script piles up a list of sbt settings which need to be run. What is the fastest and quietest way to accomplish that.

from sbt-extras.

I'm sure I know sbt much less than you.

However, I think the script should continue to have the sbt commands be temporary only, ie. not saving them to disk (which it currently only does for explicit sbt versions written to build.properties). So if you want to keep that, I don't see any other option for sbt commands in general.

--warn "set javaHome in ThisBuild := Some(blah)" --info doesn't work :(

from sbt-extras.

Ah, but you gave me the idea which does work.

java -jar ~/.sbt/launchers/0.13.5/sbt-launch.jar \
  '; -- error ;  set javaHome in ThisBuild := Some(file("/tmp/bippy")) ; -- info ; about '

from sbt-extras.

Aw yiss! Excellent. And as far as my test can tell me this doesn't interfere with setting -w/--warn or -d/--debug before or after that command chain.

from sbt-extras.

Oh no, it does :-/

  > java -jar ~/.sbt/launchers/0.13.5/sbt-launch.jar --warn \
"; -- warn ; set javaHome in ThisBuild := Some(file(\"/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home\")) ; -- info" shell
  root#test> show javaHome
  [info] root/*:javaHome
  [info]    Some(/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home)
  [info] test/*:javaHome
  [info]    Some(/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home)

from sbt-extras.

I am dealing with same problem. In my opinion,
the location of javac should be derived from value of the JAVA_HOME variable - if exists.
If JAVA_HOME variable doesn't exists, then location of javac should be derived from the path of used java executable.
If there is not derived value of javac (from java executable), then PATH may be used, but as last choice.

On linux, I am must use next workaround:
#!/usr/bin/env bash
export PATH=$JAVA_HOME/bin:$PATH
/opt/sbt/bin/sbt -java-home $JAVA_HOME "$@"

from sbt-extras.

any progress on this? I'm still using my .javahome hack in my custom sbt launcher.

from sbt-extras.

@fommil Do you mind seeing if my branch attached to #95 works for you?

from sbt-extras.