Develop Reference

"jar:file" vs. only "file:" reference when retrieving resources in Java

This question is related to my question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
And how is that influenced by the operating system ran under?
E. g. using this resource reference in Jetty webserver, in Windows with Oracle JDK 17, files are found as resources and parsed by Jetty webserver:
file:///D:/Projects/verdi_2/target/classes/static/,AVAILABLE}{file:/D:/Projects/verdi_2/target/classes/static}
Using this resource reference in Jetty webserver, in Ubuntu Linux 20.04 LTS with Oracle JDK 17, NO files are found and nothing can be parsed by Jetty webserver:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
Is there a difference in how a Linux version of JDK interprets "jar:file" vs. how a Windows version of the JDK interprets "jar:file"?
EDIT: The related issue is the Jetty webserver apparently can no longer serve resources directly out of a JAR file it is itself embedded in. This is now a GitHub bug ticket at https://github.com/eclipse/jetty.project/issues/8549

file: is the beginning of a general file url. jar:file: is that for a jar file particularly, with a view to referring (usually) to a particular entry in a jar. Here's an example you can run (obviously with your own jar url) where you can save an entry as a file (given by the parameter to the app)
import java.nio.file.Paths;
import java.nio.file.Files;
import java.net.URL;
public class JarUrl {
public static void main(String[] args) {
try {
URL url = new URL("jar:file:root.jar!/root/a/b.txt");
Files.copy(url.openStream(), Paths.get(args[0]));
}
catch(Throwable t) {
t.printStackTrace();
}
}
}

What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
You're mischaracterising the URL a little bit. The string until the first : decides the 'scheme' of a URL, so, the pertinent question is: How does jar: work. The file: part is a smaller aspect of a sub-part of the jar bit.
How does jar: work
The format is jar:(URL-of-jar)!(path-inside-jar)
Where URL-of-jar is itself a valid URL (and file: is just one way to do that. So is http, for that matter), and path-inside-jar is not a URL but a path.
The meaning is: First, resolve the 'URL-of-jar' URL. This gets you a jar file. Then, open the jar file, and retrieve the resource at the stated path.
So, to pull this one apart:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
The jar is located at URL file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar and the resource it is referring to is the /static resource inside the jar found at the given URL.
How does file: work
That's not java-specific; file: is a generally available URL scheme. You can even type it in a web browser. The more general URL formatting scheme is scheme://server/resource, but with file:, server doesn't apply (it is by definition local to the system you are on), so usually its put as file:///foo, i.e. - an empty 'server' part. Because 3 slashes is a drag to type, I guess, file:/resource is allowed by some 'URL parsers', including java's in this regard, so, file:/usr/... simply maps straight to a local folder: /usr/src/verdi/verdi-12-JDK-etc, as in, if you type ls /usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar on the command line on your system, it would show a result (and if it does not, this URL would fail to find anything).
And how is that influenced by the operating system ran under?
It isn't. file URLs are a general concept that work on any platform. Of course, /usr/src/verdi/etc is never going to work correctly on a windows platform. Or on anybody else's machine. The problem isn't "Oh no! This won't run on another OS!". The problem with file URLs, especially absolute ones, is "Oh no! This will not run on any machine other than this one!".
file:///D:/Projects
I've explained the triple slashes earlier. This is the standard windows 'scheme' for how to stick paths in file URLs: Always forward slashes (even though windows normally uses backslashes), and treat the disk letter as if it is a 'drive' in the 'root': /D:/Project is URL-ese for:
D:
cd \Project
There is no difference in OS at all - file: URLs are handled by 'interpret this file URL the way any file URL would be interpreted on this machine'.

The answer to the related question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
which prompted this post is in the long series of posts beneath this GitHub issue for jetty:
https://github.com/eclipse/jetty.project/issues/8549
In essence, eventually I had to first clean up my Maven pom.xml (see this thread for the discussion and for links to a pom.xml example that is compliant with Maven Shade plugin and Jetty 11.0.11 requirements and standards) then at the end of the day hardcode a link to the JAR file to find the HTML, JS, etc. resources Jetty was to serve out as a webpage. Also put in a conditional where, on compiling, I need to specify if the code will run "in-IDE" (in my case, Netbeans 14) or "in-JAR" - e. g. in a detached JRE elsewhere than the Netbeans 14 IDE.
Also dropped using the Jetty WebAppContext class and started rendering web content out of a normal ServletContextHandler.
Hopefully this may help someone upgrading Jetty from Jetty 9.xxx to 11 and finding that it all falls apart.
For details as to why they changed so much, see the GitHub link (the last few entries are apropos.)
The github discussion also contains full working source code (startJettyc method) that solved the issue of getting a 404 in a detached, non-IDE modality where the JAR was being run in an JRE separate from an IDE.
Stefan

To which file path should I set my JAVA_HOME path?

I have two files in my 'usr/lib/jvm/' path namely "/usr/lib/jvm/java-1.8.0-openjdk-amd64" and "/usr/lib/jvm/java-8-openjdk-amd64". The icon on the "/usr/lib/jvm/java-1.8.0-openjdk-amd64" file is a folder with a black downward curving arrow. When I look at the properties of the "/usrlib/jvm/java-1.8.0-openjdk-amd64" file it says its 'Link target' is "/usr/lib/jvm/java-8-openjdk-amd64". What does that mean?
The reason I am asking is because I want to try to solve the KeyError: 'JAVA_HOME' I receive when importing jnius, which means I have to try the solution given at https://github.com/kivy/pyjnius/issues/209. The solution is to set the right path for 'JAVA_HOME'.
Tried
I noticed when I checked the -version of java in the terminal it only gave "/usrlib/jvm/java-1.8.0-openjdk-amd64". Does that mean that the 'JAVA_HOME' is this path or the other.
Which of the two file paths above is 'JAVA_HOME'?

You have found a symbolic link, which is usually shortened to "symlink".
If you're familiar with Windows, it's equivalent to a "shortcut". It's a tiny file that simply points to another file or directory.
You can run man ln in a terminal to read more about links (both symlinks and hard links).
Regarding your final question: they should be functionally equivalent at this point. I would recommend the shorter one (the symlink). That way, you won't have to update your environment variable if you install another jdk8 version (e.g. upgrade to 1.8.1, or choose another implementation with update-java-alternatives) in the future.

How many Classpath can be specified on Java command line?

I have to run a java task, with a very large number of classpath (1000, totaling 150k characters if concatenated).
The problem is that java returns an error when I try to execute this class:
/jdk/JAVA8/bin/java: Argument list too long
The error code is 7
I've tried to put the classpaths using "export CLASSPATH=CLASSPATH:....." and so I shouldn't specify them through the -cp java parameter, but it returned the same error.
I'm pretty sure that the problem revolves round a classpath's limit, because if I delete some of the classpath, the error disappears (but then I will have logical errors in the execution, because I need all the classpaths)

You could use classpath wildcards. Especially if many of your jars/class files are in the same directory, this would help a lot.
It could be environment variable size limit or command-line size limit as well rather than javac classpath arg limit.
javac takes arguments from file input as well. You can add all your arguments to this file and pass this file argument to command. Refer this for more.

You didn’t hit a java-specific limitation, but a system dependent limit. This is best illustrated by the fact, that the attempt to set the CLASSPATH variable fails as well, but setting an environment variable via export name=value in the shell isn’t related to Java.
As said by others, you could try to use wildcards for jar files within the same directory, but you have to care that Java does the expansion rather than the shell, as in the latter case, it would again yield a too long command line. So you have to escape the * character to ensure it will not be processed by the shell.
javac supports reading the command line arguments from an external file specified via #filename, but unfortunately, the java launcher doesn’t support this option.
An alternative would be to create symbolic links pointing to the jar files, having shorter paths and specifying these. You could even combine the approaches by creating one directory full of symbolic links and specifying that/directory/* as class path.
But there seems to be a logical error in the requirement. In a comment, you are mentioning “code analysis” and an analyzing tool should not require having the code to analyze in its own application class path. You can access class files via ordinary I/O, if you want to read and parse them. In case you want to load them, e.g. for using the builtin Reflection, you can create new ClassLoader instances pointing to the locations. So the tool doesn’t depend on the application class path and could read the locations from a configuration file, for example.
Using distinct class loaders has the additional advantage that you can close them when you’re done.

JVM does not limit classpath length. However, there is a hard OS limit on command line length and environment variables size.
On Linux check getconf ARG_MAX to see the limit.
On older kernel versions it is only 128KB. On newer kernels it is somewhere around 2MB.
If you want to set really long classpaths, you may need a JAR-Manifest trick. See this question for details.

How to change font size for JMeter?

I am using JMeter with 2.13 version.
I want to increase font size for JMeter.
I have tried following question jmeter test plan navigation pane font size. However for 2.13 version doesn't have src folder.
Here is a picture, how it looks now:
How to change font size for JMeter test plan section.

Since JMeter 3.2, use Menu:
Options > Zoom In
Options > Zoom Out
See this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=59995
JMeter 3.0 (released 2 weeks ago) has improved regarding the icons and tables but does not yet support full HiDPI mode:
See this particular bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58426
https://bz.apache.org/bugzilla/show_bug.cgi?id=59168
To set properties, see:
https://jmeter.apache.org/usermanual/hints_and_tips.html#hidpi
Now for fonts, you can use Swing mechanism. To do that, add to jmeter.sh or jmeter.bat the JVM System property:
-Dswing.plaf.metal.controlFont=Dialog-20
And ensure you use the Cross Platform LAF

JMeter 4.0 update :
Before any update of Jmeter setting
After the update of Jmeter setting
JMeter 4.0 update using Windows 10 :
1. Go here : C:\apache-jmeter-4.0\bin
2. Open to edit this : jmeter.properties
3. Over here you need to update all required fields for you
This is what I changed and it looks good to me :
jmeter.loggerpanel.display=true
jmeter.loggerpanel.enable_when_closed=true
jmeter.loggerpanel.maxlength=1000
jmeter.gui.refresh_period=500
jmeter.hidpi.mode=true
jmeter.hidpi.scale.factor=2.0
jmeter.toolbar.icons=org/apache/jmeter/images/toolbar/icons-toolbar.properties
jmeter.toolbar=new,open,close,save,save_as_testplan,|,cut,copy,paste,|,expand,collapse,toggle,|,test_start,test_stop,test_shutdown,|,test_start_remote_all,test_stop_remote_all,test_shutdown_remote_all,|,test_clear,test_clear_all,|,search,search_reset,|,function_helper,help
jmeter.toolbar.icons.size=48x48
jmeter.icons=org/apache/jmeter/images/icon_1.properties
jmeter.tree.icons.size=48x48
save_automatically_before_run=true
onload.expandtree=true
jsyntaxtextarea.wrapstyleword=true
jsyntaxtextarea.linewrap=true
jsyntaxtextarea.codefolding=true
jsyntaxtextarea.maxundos=50
jsyntaxtextarea.font.family=Hack
jsyntaxtextarea.font.size=28
loggerpanel.usejsyntaxtext=true
view.results.tree.max_size=10485760
please refer : https://jmeter.apache.org/usermanual/hints_and_tips.html

In order to get src folder you need to download JMeter source code separately, i.e. from here. Unpack the folder and make required changes
You will need Apache Ant to build JMeter. Install it and make sure that %ANT_HOME%/bin folder is added to your system PATH variable
Build JMeter using next 2 commands:
ant download_jars
ant package
Now your should be able to run JMeter with increased font from apache-jmeter-2.13/bin folder like:
jmeter -Djmeter.dialog.font=20 .....
or ir you want to make font size change permanent add the next line to system.properties file (located in JMeter's "bin" folder)
jmeter.dialog.font=20
JMeter restart will be required to pick the property up. See Apache JMeter Properties Customization Guide for more information regarding JMeter properties usage.
If you trust me and Bitbucket hosting you can take the risk and get compiled binary with aforementioned change from
https://bitbucket.org/glinius/jmeter-font-increase/downloads/ApacheJMeter_core.jar
and dropping it to /lib/ext folder of your JMeter installation, however downloading binaries of unknown origin is not recommended (your PC can become a member of a botnet or someone's bitcoin mining farm) so it's better to take above 4 steps.

Using Jmeter 3.2
Options > Zoom In
Zoomed some panes but not others.
However modifying apache-jmeter-3.2\bin\jmeter.properties works. Tested with Win 10.
#jmeter.hidpi.mode=false
# To enable pseudo-hidpi mode change to true
jmeter.hidpi.mode=true
# HiDPI scale factor
#jmeter.hidpi.scale.factor=1.0
# Suggested value for HiDPI
jmeter.hidpi.scale.factor=2.0

In Jmeter 3.1 and 3.2, uncomment below lines in jmeter.properties file, and restart the Jmeter. It worked and the font size increased for all the icons and components
jmeter.hidpi.mode=true
jmeter.hidpi.scale.factor=2.0

After setting the following properties in bin\jmeter.properties it looks better
jmeter.hidpi.mode=true
jmeter.hidpi.scale.factor=2.0
jmeter.toolbar.icons.size=32x32
jmeter.tree.icons.size=24x24
jsyntaxtextarea.font.family=Hack
jsyntaxtextarea.font.size=28
ref: https://jmeter.apache.org/usermanual/hints_and_tips.html

How to open file with default application in SWT?

I have for example .pdf file (path to that file). How to open this file in default application (probably Acrobat Reader) from SWT application (for example on Button click) ?

You should be able to use:
Program.launch(file);
to open the file (using the default application or creator). From the javadoc:
Launches the operating system executable associated with the file or URL (http:// or https://). If the file is an executable then the executable is launched. Note that a Display must already exist to guarantee that this method returns an appropriate result.
Note that there are some peculiarities in Program.launch() (or at least there were, though these may have been fixed in more recent versions of the runtime.) I don't really remember the specifics of the bugs, but we do some checks to work around some issues:
If you're on a Unix platform, and you're specifying an absolute path, there may be trouble opening that file. We prefix absolute paths with /. - so that /tmp/foo would be translated to /./tmp/foo - although I don't really remember the specifics of this bug any more than that.
On Windows, if you're trying to open a UNC path - for example \\server\bar - you need to wrap the string in double-quotes. For example: Program.open("\"\\server\bar\"");

Try Desktop.open:
Desktop.getDesktop().open(file);

Maybe this can help to find a decision: we ran into PermGen space trouble upon call Desktop.open() - which is in AWTpackage - out of our SWT application.
So I would prefer Program.launch() over Desktop.open() in a SWT-environment.