Make jenv for Windows have same commandline options and logic as https://www.jenv.be/

[tech-consortium]

There is already a very popular Jenv for linux and Windows. If you want to get good adoption of this project I'd make the logic match https://www.jenv.be/ as much as possible.

[tech-consortium]

I'd also publish it to Chocolate package manager and other once you have the equivalent functionality as https://www.jenv.be/

[kid1412621]

I agree, at least use jenv global xxx instead of jenv change xxx, and jenv shell xxx instead of jenv use xxx.

[row49382]

Is there anyway to add the behavior of 'enable-plugin maven/gradle' that jenv has?

I run multiple maven projects all in different java versions at work. It would be great to be able to run the mvn commands at different jdk levels that were set by jenv local from cmd line without needing to reset the JAVA_HOME value.

[FelixSelter]

If I understand you correctly we can easily create this. Currently jenv removes any java from your path and creates an own executable(batch file) named java or javac etc that ensures the correct version is used. We could create an mvn.bat file that calls maven and passes the correct version as an argument.

Alternatively you can just run jenv once after opening the terminal in that directiory. This should update your java home automatically.

Is this what you are looking for? I might need to look at the code if the second version is still working.

[row49382]

You understand it correctly.

To help clarify, here's a concrete example: say I want java 17 globally and 8 locally. This is what happens currently:

• install java 8,17
• jenv add jdk8, jdk17
• jenv change jdk17
• cd "java_8_project_with_maven"
• jenv local jdk8
• mvn clean install -> fails because requires target of java 8

Alternatively you can just run jenv once after opening the terminal in that directiory. This should update your java home automatically.

Ah ok, so after swapping to "java_8_project_with_maven" and running jenv, then the version is registered correctly with maven and I am able to run install successfully.

It's probably not worth the work to save the extra step, though It would help usability by not needing to remember to call jenv each time I switch projects -- After some more usage, removing the need to call jenv each time would be a great help if you can instead just call the mvn bat once.

Perhaps though, it is worth a callout in the README? I'll let you decide :) Thank you for the quick response!

[FelixSelter]

I will implement this in the full rewrite. at least once I have time. I am currently quite busy :(. I will add a note to the readme though

[rcsilva83]

@FelixSelter, do you think jEnv and jEnv projects could merge to make one multiplatform jEnv? I've been thinking about the duplicate effort and, now that I know you're thinking about a full rewrite, I wonder if you and the jEnv team would be interested in this... Of course, this new jEnv shouldn't be written in PowerShell nor Shell Script...

[FelixSelter]

I actually had something completely different in mind. My goal was indeed a multiplatform approach. But a few compromises will need to be made.

I was thinking about something similar like pythons virtual environment. In this case we would have a single executable thats cross platform and provides all major functionality. We would then have multiple activation shell scripts. One for powershell, one for cmd, one for bash etc.
Their purpose will be to call the main executable which will provide information on how the path needs to be changed and whats the correct java home etc.

The disadvantage would be that any local environment needs to be activated once. The advantage would be, that its more clear when something will work and when not.

We could also create a hybrid approach. In this case we would move towards a cross platform solution but keep our "poisonous" shell files. But Im currently rooting for the activation so it will be more clear. In this case we might create a hook for shell open and the cd command that could automatically run the activation script.

I would also like to get rid of powershell and use a different language for the rewrite.

What do you think about this?

If we want to unite our efforts with the other jenv team we need to implement all their major features first. After that we could try to convince them

[rcsilva83]

I'm not familiar with Python Virtual Environments but, if I understood right, in your solution the user would need to execute some kind of setup command once jEnv is installed, is it? I'd be something like volta setup from Volta? I like this approach very much as it would make jEnv's faster and more predictable.

Nevertheless, my main point was the "multiplatform" aproach that you are into too, so I think we're on the same page :)

About uniting the efforts with the jenv team, let me ask them if they're interested. If not, I think it would be better a new name for the software, right? "jEnv for Windows" wouldn't work anymore.

[FelixSelter]

Sure. I was thinking about jvenv if we adapt the code to fit pythons virtual environment.

The catch is that the setup command must be ran whenever we open a terminal and not just once after the installation.

But lets push towards cross platform compatibility first and then decide if its an essential feature that needs to be added back.

[rcsilva83]

@FelixSelter , the jenv team answered they are open for a full rewrite to make a multiplatform tool. They asked which language do we plan to do it. What do you have in mind? As jEnv is a Java-related tool, I think a Java-related language (Java, Kotlin etc) would be appropriate, what do you think?

[FelixSelter]

The problem with a java related language is that it is compiled for a specific jvm version. Our tool changes the jvm version thus could break the executable.

Personally I would use rust for cross platform support, security and speed. But writing a full scale application takes more time than with other languages. Maybe another language should be used then. I would like to avoid that users need to install any other runtime like python to run the code. I would prefer a statically typed language. Do you know any other language thats secure, supports cross platform and does not depend on an additional runtime?
If we decide to use a jvm language and risk that the runtime is moved or deleted I would prefer scala.

I actually created a prototype in rust already. If you would give me a couple more days I could improve documentation and create a repo?

[FelixSelter]

@rcsilva83 I created a super basic repository. https://github.com/FelixSelter/JVenv/ It currently contains a very basic cli application that allows for cli option parsing and manages a cross platform config. The rust code may be replaced by any other programming language we may use. I just figured I leave it there until we decided. The main goal of the repository is to collect information in the readme of what needs to be implemented and how this could be achieved.

[rcsilva83]

The problem with a java related language is that it is compiled for a specific jvm version.

We could create a native image with GraalVM or bundle a mini-JVM created with jlink.

I like Rust very much but I think it can be a barrier for contributors.

[rcsilva83]

I opened an issue with some points we've discussed here: FelixSelter/JVenv#1