Is there a true need for a Portable Utility to download and install the Java JDK? I know I wish there had been when I was looking to no avail. Did find a Powershell script that did the trick with a little tweaking.
My question is; would I be wasting my time by creating a PortableApp Utility for distribution to install the Java JDK in the CommonFiles folder? The JDK would not be included in the distribution. The Utility would download the Windows installer then strip out the JDK and install it.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
It's fairly easy to do an online installer for it with the PA.c Installer, it's just that we don't have any official apps that require it. If folks are interested for the few dev tests we have that use it, I can put together an official one and have the platform start auto-updating it.
Sometimes, the impossible can become possible, if you're awesome!
Was thinking the JDKs would be good for development. Been working on a portable development system for myself. Have the JREs & JDKs (32 & 64 bit) in the CommonFiles folder. Now for a good portable IDE for Java.
Just got the portable (PAF) versions of MinGW, MSYS, Console, and Code::Blocks working together. So can use the GUI or CLI to program Windows apps in C++.
These are all aged a bit. Need to be updated. Guess I could fork them.
Dan "FloriDan" Carroll
Just an old hacker having fun.
Wihtout a portable version of JDK, i have to "install/update JDK compiler" .exe file installer from java.sun.com website.
At my side, i need a portable version.
P.S. i have made some Freewares Java softwares and games.
John, if you could put the JDK online, I'll commit to putting up an IDE for it. How do you feel about NetBeans?
Dan "FloriDan" Carroll
Just an old hacker having fun.
John if you have some time could you make a JDK Portable with launcher integration?
The current installer for the JDK doesn't allow for extraction as a live installer and the EULA does not permit repackaging.
Sometimes, the impossible can become possible, if you're awesome!
The 32-bit JDK version can easily be extracted. As with the 64-bit you are right.
jdkPortable is now available here: https://portableapps.com/apps/utilities/jdkportable
It's 32-bit only right now due to licensing and technical reasons. If you're working on a JDK-based app, please set it up to expect the JDK to exist at PortableApps\CommonFiles\JDK as discussed previously.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for making jdkPortable.
You should still be able to extract the files from the installer for the 64-bit jdk, it would however require a triple extract function with the first step needing a path set.
Btw, the path to get to the tools.zip in the 64-bit installer is:
.rsrc\1033\JAVA_CAB10\111with 111 being the .cab file that contains tools.zip
The 64-bit installer seems to be an encrypted MSI package, so it couldn't be extracted with 7-Zip. Which 64-bit JDK installer are you looking at?
Sometimes, the impossible can become possible, if you're awesome!
Using the path provided by richo above on jdk-8-u-131-windows-x64.exe, the 64 bit jdk appears to be entirely extractable.
See here: http://imgur.com/a/8qLm4
It's just the standard 64-bit installer package.
It isn't really any different from the 32-bit installer package, it's just that 7-Zip doesn't seem to open up into the first cab like it does with the 32-bit installer.
Both architecture installers are packaged exactly the same: An MSI with accompanying .cab files packaged into the resources section of a wrapper .exe, which is then also packaged into the resources section of another wrapper executable.
It really is just a bug with how 7-Zip opens the first archive format that it finds. If it for some reason doesn't find one, it then treats the PE format as an archive, though not all PE format files can be opened this way.
EDIT: Also, following is a tree-view of the resource layout of both installers. (Minus things that aren't needed for jdkPortable)
jdk-8u131-windows-i586.exe \ + .rsrc \ + RCDATA \ + 100 \ + .rsrc \ + 1033 \ + JAVA_CAB9 \ + 110 \ src.zip + JAVA_CAB10 \ + 111 \ tools.zip + JAVA_CAB11 \ + 112 \ COPYRIGHT jdk-8u131-windows-x64.exe \ + .rsrc \ + RCDATA \ + 100 \ + .rsrc \ + 1033 \ + JAVA_CAB9 \ + 110 \ src.zip + JAVA_CAB10 \ + 111 \ tools.zip + JAVA_CAB11 \ + 112 \ COPYRIGHTAh, quite right. I put together a few lines of custom code and it appears to be working as expected. I'll push this out as well, then.
Do we have apps that require 32-bit vs 64-bit JDK?
Sometimes, the impossible can become possible, if you're awesome!
I'm not sure about any apps that require 32-bit vs 64-bit, but once the Java IDE's start coming out as portables it'll be best if both are available. While not as common anymore, there are still some 32-bit PC's out there... though, it usually is just that the OS has been installed as the 32-bit version for one reason or another. I'm sure there are some other reasons to have both too, but I can't think of them.
EDIT: I should also note that the src.zip will need to be copied (not extracted) into the root folder of jdkPortable, as this file is required for any Java IDE's to function correctly. (Haven't tried many, but I know that NetBeans can't browse function definitions correctly without it)
About the 7-Zip bug I mentioned previously... While the first part of
the bug is what is happening afaik, the second part is probably just
that 7-Zip is doing the same thing as if it had been given the -t*
switch, with -t*:r being the default behaviour.
Knowing this, the jdk would need some TripleExtract settings in the
DownloadFiles section of the installer.ini, with the same stuff as
AdvancedExtract and DoubleExtract, but with the following new
settings:
with the values for Filter2 being the same as what can be
set for Filter in AdvancedExtract and DoubleExtract.
Name2 is the same thing as Name, but for Filter2.
Type2 is the same thing as Type, but again, for Filter2.
The values for Type can be the same as what 7-Zip's -t switch expects,
with *:r being what gets used if nothing is provided.
This new Type setting could be useful for both AdvancedExtract and
DoubleExtract as well.
Also, if there was a DownloadCookie setting, we could do an online
installer that downloads from Oracle's servers by using the following
line in the ini:
The call to inetc to download the file would need the following added:
/header "Cookie: ${DownloadCookie}"which would end up like this:
The description of DownloadCookie in the PAF could be:
Or something that is better understood.
I updated the way it works with today's release and added a new capability in the PA.c Installer allowing custom code to use 7-Zip. I'll likely refine it later with some more of the concepts above.
Sometimes, the impossible can become possible, if you're awesome!
Any chance there can be a version of this for an older jdk, or give the ability to select java versions?
I tried to use this with eclipse, only to find out that to compile the thing i want to with eclipse, i have to install the 1.7 jdk instead of the 1.8 jdk.
I wish portable java to stop the auto updater from uninstalling older versions.
It's unlikely at this exact moment, though we'll be introducing the ability for users to pause or disable updates for a given app. That would allow you to manually install 7 and prevent the updater from automatically updating it.
Sometimes, the impossible can become possible, if you're awesome!