-
Notifications
You must be signed in to change notification settings - Fork 298
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bundle the jvm with the installer via jpackage #248
Comments
Hi gdoenlen, Thanks for pointing out jpackage tool. Data Loader requires a commercial/open source JRE 11 or later, not specifically OpenJDK 11. The installation/launch messages and documentation can be improved to state this requirement clearly. |
Data Loader requires a commercial/open source JRE 11 or later
Yes which is why you should bundle it with the installer and not make users
install it into their system on their own.
not specifically OpenJDK 11.
Which is why you specify the `--runtime-image` flag on jpackage to point it
to your custom JVM.
…On Tue, Jan 26, 2021, 12:00 AM ashitsalesforce ***@***.***> wrote:
Hi gdoenlen,
Thanks for pointing out jpackage tool. Data Loader requires a
commercial/open source JRE 11 or later, not specifically OpenJDK 11. The
installation/launch messages and documentation can be improved to state
this requirement clearly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#248 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AED7AOVFOJQ3BZ6WJRG6CQ3S3ZD77ANCNFSM4WSDJUAQ>
.
|
Hi gdoenlen, Perhaps I am missing something but bundling the JVM would have the side-effect that a customer wanting to use their own org-specific JVM won't be able to do so. |
I just never met anyone that ever wants to do this. 100% of the users I know don't want to have to configure a JVM for a desktop program. Regardless these aren't mutually exclusive things, you can produce a build without it bundled and with it bundled so you can improve the UX for non-technical users like admins. 🤷♀️ Just a suggestion. |
100% agree with @gdoenlen here. To illustrate why, an anecdote: I happen to have an ancient version of Java on my Mac, one that was too old to run Data Loader. So I tried installing the suggested ZuluJDK, which didn't work. So I installed OpenJDK and that worked. Next, I needed to change the startup script to use the correct JDK path. Now I happen to be technical enough to understand what I'm trying to do here, but my colleagues have no clue what they're supposed to do. They just want to download Data Loader and have it run without a hitch. Please consider releasing Data Loader as a self-contained Java application. |
I fully agree with the comments from @gdoenlen and @Raptor399. Our customers also want to rely on the newest Data Loader but they expect the installation process to be as simple as possible. And because free dataloader.io is very limited when it comes to the number of records, we need to ensure that Data Loader is hassle-free :). |
I agree with this. End users don't care what JRE is used, or what it even is, just so long as it works. It is a bit risky sending users on a mission to download a JRE. They might find a fake one with malware. They won't keep it up to date to keep it secure. The standalone version will be installed system wide and therefore a much greater attack surface for malware rather than living dormantly in a folder. Any power user wanting a specific JRE for some strange reason I can't think of should be proficient enough to delete the included JRE and use their own. It is also better for you, because the user environment will be more predictable for troubleshooting. |
@ashitsalesforce, can we please revisit this suggestion? |
Hi @pgumiela , point noted. |
For macOS please use at lest Java 17 And this is actually pretty important since we do not install java anymore for security reasons. |
Hi @MaxG-Enpal , you can use a JRE v11 or later including Java 17 for data loader. So, if the preinstalled JRE on your system is JRE 17, it should work with data loader. |
I mean if Salesforce is gonna add a prepackaged version it would be great if you would use Java 17 for macOS since it has wonderful M1 and Metal support that reduces the battery consumption. |
Hi @MaxG-Enpal , that's a good point. Will keep it in mind when planning for a prepackaged version. |
@ashitsalesforce, can we close the issue when it's really done? Because, otherwise, people will create other issues on the same topic because nobody knows Data Laoder's roadmap. |
good point @pgumiela. Will reopen. |
Just a thought - nix machines with sdkman & on windows machine with scoop, setup the dependencies with a script as pre-requisite. |
Thanks for these suggestions. Here is a bat script:
Here is a .command (or a .sh) script:
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
If you're going to require a specific JVM (zulu) to be used by users you should be using jpackage to bundle said JVM into the installer.
The text was updated successfully, but these errors were encountered: