Java Textio file addition [duplicate] - java

This question already exists:
how to add new class(textio.java) in jdk 12.0.1
Closed 3 years ago.
Where to put the textio.java and its classes. I am using jdk 12.0.1. it is the error cmd is showing on comipiling file that uses textio class.
Please tell me the correct directory where to put textio class file in jdk 12.0.1 folder.

There are numerous ways to add third party libraries to your runtime. Without more information, the lowest energy way you're looking for isn't quite clear.
I believe the CLASSPATH environment variable is what you want. If it's not defined, you may define one by whatever process matches your operating system.
CLASSPATH is one way for your machine to tell your java installation which folders jars and other jvm bytecode are located in so that your java runtime can load them when your program starts. This can be anywhere, but depending on your operating system, there are standard locations that are often good to follow.
In linux/unix/OSX, you may run echo $CLASSPATH, and a non-empty result means that it's set. If it doesn't exist, then you may run this command to create it pointing to the folder you choose. export CLASSPATH=/path/to/jars. Just keep in mind that without some extra steps, this will be reset on next reboot.
If you're using an IDE such as eclipse or idea, then there are project-specific solutions that can be done as configuration options within your IDE, which will keep things you don't want globally available on your machine from being loaded up every time.

Related

VS Code runs .java files without the producing .class files

I have some basic java knowledge and i decided to switch from Intellij to VS Code. I know how to compile and run a java file (which may use other imported .java files) from the terminal, but i want to run a java program using the run icon inside vs code.
I'm not a 100% sure, but i think that in order to run a java program inside vs code you need a extension. For this reason i downloaded the Java extension pack. Note that i already have installed the latest jdk on my computer.
After i installed the plugin, i could run the program using the "run without debugging"/clicking in the run icon. However, no .class files are produced. I control+h but there isnt any hidden folder that vs code may drop the .class files.
How does the program run in the first place?
How can i config vs code in order to compile the java files before running the one that has the main function?
Basically, when you run a java file normally, you compile it with javac and then run it with java (or something along those lines, there are many different variations of possible ways to do it). If you go ahead and try, it is possible to run java filename.java and skip the normal javac step. In the case of VSCode, it will differ based on what extensions you have, but some may run the code with a simple java filename.java and others may have different settings set. If you take a look at your extension preferences as well as your preferences for java by searching your settings, there may be an option, such as "Java Source Paths" enabled which changed where compiled files are saved by VSCode.
If your project is a folder containing Java source files. And no build tools(Maven/Gradle) are used.
If that is the case, you can trigger the command Java: Configure Classpath, then find the section output and then set a relative path to your workspace.
The output files are by default stored inside the workspace storage.
If after triggering the command, what you see is the native vs code setting page. Then try to search java.project.outputPath and then set a relative path to it.

“no sigar-winnt.dll in java.library.path” error when using SIGAR

I'm very new to java. I'm developing a tool that checks if your PC meets some set of specifications. This included writing and executing a separate batch file and including an API (SIGAR) for the model of the CPU.
My problem is that when I tried exporting it to Runnable JAR in eclipse, and I ran the resulting JAR from command line, it gave me lots of 'DLL not included in build path' Exceptions. After including the folder that contains the API DLL in the build path, I got similar exceptions. The thing that fixed it was adding the folder containing the DLL to environment variables (PATH) in Advanced System Settings.
Questions:
The JAR now works fine on my computer, but what about the users who download the JAR? Will they also need to add the DLL to environment variables? If so is there a way the JAR can do that for them?
My JAR won't run with a double-click, but will run from command line. Is there any way around this that will carry over to users who download the JAR too?
If the user downloads the tool and can't run it because they don't have the right version of the JRE, will the tool notify them? If not, is there a way around the user having to update JRE or will wrapping as an EXE suffice?
Thanks in advance, much appreciated. Lots of questions.
Q1: The JAR now works fine on my computer, but what about the users
who download the JAR? Will they also need to add the DLL to
environment variables? If so is there a way the JAR can do that for
them?
You can put a DLL inside a JAR file:
How to make a JAR file that includes DLL files? (Hint: read both answers ... completely.)
However, when you distribute a JAR containing a DLL, you then have the problem that different platforms require different DLLs (or whatever). Even with Windows you have the problem of 32 bit versus 64 bit DLLs.
Q2: My JAR won't run with a double-click, but will run from command
line. Is there any way around this that will carry over to users who
download the JAR too?
You cannot address that problem in a JAR file. The "double-click to run" functionality is implemented by the OS. The best way to provide this kind of functionality is using (platform specific) wrapper scripts that are double-clickable.
Q3: If the user downloads the tool and can't run it because they don't
have the right version of the JRE, will the tool notify them? If not,
is there a way around the user having to update JRE or will wrapping
as an EXE suffice?
Unless you have a JRE installed, the JAR file is just a passive blob of data. (A ZIP file, actually).
If the user has a JRE that is too old, then either the JRE will be unable to load any classes in the JAR (because the classfile version number is wrong), or you will get errors because of missing (system) classes.
The only hope would to do something like providing a wrapper script to launch your application that checked the JRE version before attempting to launch the JAR.
As a general rule, if you want to do fancy stuff like this you need to distribute your program in an installer, not as a bare JAR file.

Program uses outdated (not current) env variable value

I've got a C++ program that internally uses java (via my C++ dll that wrapps the WebLogic jsmc.dll that internally uses jvm.dll).
When I set CLASSPATH before running my program, all JAR libraries are found and the program works properly.
When I do not set the CLASSPATH before running my program, the JARs are not found, which of course is expected.
Now, when I set the CLASSPATH before running my program, but clear this CLASSPATH environment variable inside the program code before loading my dll that uses java, a strange thing happens: all JARs are still found and the program works as if everything was OK. I have verified by several ways that the CLASSPATH is really deleted from the env variables (e.g. by using ProcessExplorer or by printing its value).
QUESTION:
Can you explain this behaviour to me? I'm not wondering why java ignores the CLASSPATH I set, but how is it possible that java sees the old CLASSPATH value, not the current one? I emphasize that it isn't possible for java to store the old CLASSPATH value somehow because java was not loaded at the the time the old value was available.
How can I make the java to respect the changes in the process env variables?
DETAILS:
The problem above is just a simplification I've made to explore my real problem. I'm trying to set the CLASSPATH from within the program and avoid to have it set externally. But the java uses the externally set CLASSPATH, not the one I set inside the program.
I read and set the env variables values using the Windows API (GetEnvironmentVariableA, SetEnvironmentVariableA). I have verified that the program process environment variables really change after setting them this way. I even printed the CLASSPATH value from the dll that uses java, before calling any java method. I checked using the ProcessMonitor that jvm.dll is really loaded after the CLASSPATH is deleted. I also tried to exclude the possibility that the CLASSPATH is read from the parent process. Now I'm pretty sure that at the time jvm.dll is being loaded, the CLASSPATH is already deleted from the process environment.
I have tried both a Visual C++ 2010 testing program and the HP LoadRunner C-compiler (mmdrv.exe) vuser script, with the same result. LoadRunner is the main reason why I need to solve this problem.
The problem was caused by that the C-runtime somehow caches the environment variables. While I was trying to modify the CLASSPATH using the system function SetEnvironmentVariableA(), jmsc.dll read CLASSPATH from the C-runtime cache. The C-runtime tries to synchronize its cache with the real values in the process environment, but evidently not very successfully. It was necessary for me to replace the system call to SetEnvironmentVariableA() with the call to _putenv() from the C-runtime in order to change the CLASSPATH.
But there was another problem. There were various versions of C-runtime used by my code, each having its own environment cache. My VC code was linked against msvcr100.dll, while jmsc.dll (that instantiates the Java VM) uses msvcrt.dll. The solution was to link my code to msvcrt.dll too, so that my code sets CLASSPATH using _putenv() from the same C-runtime that jmsc.dll reads.
Thanks to Harry Johnston for the crucial hint, and Peter Cetinski for valuable information.
You should not rely upon the CLASSPATH environment variable when invoking a new JVM process from C++. The JNI interface provides a mechanism to specify the classpath of the JVM upon startup.
See http://java.sun.com/docs/books/jni/html/invoke.html#28719

How should I bundle Java with my Windows application?

I have a Windows application based on Java, that I should like to install with Java bundled. The installation framework is NSIS. The application executable should be guaranteed to invoke the bundled Java, so there's no clash with other Javas installed in the system.
What's the best way to achieve my goal? I haven't tried to solve this kind of problem before, and have little experience with Java, so I don't know which solutions are out there. I think I'd prefer Java to be embedded in the application's executable, if feasible, otherwise I guess Java could be installed along with it (with the executable pointing to said Java).
Edit:
This project already generates an executable (.exe), via NSIS. The executable will by default use the system Java, but apparently it'll prefer a JRE in the same directory (i.e. bundled) if present.
Edit 2:
The scenario that made me want to bundle Java with this application was that I received an executable for it built with 32-bit Java, which failed (silently) on my system which has 64-bit Java.
Are you absolutely sure you don't want to use the computer JRE? In most cases it's preferable.
You can see here (and the included link) some examples with installers that check JRE number and install it (globally) if necessary.
If you really prefer to include your own JRE in the installer and always use it - what prevents you from doing it? It's just a matter of your main program point having some way of konwing the JRE location and forcing to use it. That depends on how you pack/invoke your Java program. Normally, it would be feasible, perhaps with a simple .bat file - perhaps to be created at installation time.
The solution we used(A few years ago, but still I think the best way).
Find a program which can generate an exe file from a jar file(Google is your friend, I can't remember the name). Note that this .exe file will still need a jre. It is just a smart way to make an exe which contain your .jar file, and which start the java process automatic. (This also allows you to set a custom icon on your .exe file).
The java sdk which you use to develop/compile your java application, also contains a folder called jre, which contain a copy of the jre.
Include this folder with the installer, so the jre folder is located in the same folder as the .exe file. Then the .exe file will use the included jre, and the jre will not be installed on the computer, so you prevent any problems.
Well one extremely simple solution that works actually quite nice if you don't have to get an executable, is just using a simple Windows Batch file that starts the jar and having a shortcut to it so you get your preferred icon on it. For the average user there's no real difference - after all the default is to suppress known extensions on Windows (horrible default but well) - and for people who do know what an exe is, the solution should be quite apparent anyways.
That way you can also easily start the included java or better yet offer both versions and just change a variable in an ini file, which really is much nicer - nobody wants or needs X different JRE versions that are outdated and are nothing more than security problems. Still can't harm to offer a version that includes the JRE for people without a java install to make it as simple as possible for them.
One example for this behavior would be weka..
launch4j seems to offer to bundle an embedded JRE.

Installing Java manually on Windows? [duplicate]

This question already has answers here:
How can I get the latest JRE / JDK as a zip file rather than EXE or MSI installer? [closed]
(30 answers)
Closed 8 years ago.
I have seen many products bundeled with JDK, I wonder if there is a way where one can install JDK by simply unzipping contents to a directory, so there is no icon created in add/remove programs, no registry entries etc.
Also in this case:
How can we configure Java plugin for browsers?
And how can we configure settings as seen via Control Panel entry for Java?
According to this, I created a batch script to build jdk archives automatically.
The essential parts of the link are:
Create working JDK directory ("C:\JDK" in this case)
Download latest version of JDK from oracle (for example "jdk-7u7-windows-i586.exe")
Download and install 7-zip (or download 7-zip portable version if you are not administrator)
With 7-zip extract all the files from "jdk-[6-7]u?-windows-i586.exe" in directory "C:\JDK"
In command shell (cmd.exe) do the following:
change directory to directory C:\JDK.rsrc\JAVA_CAB10
execute command: extrac32 111
Unpack C:\JDK.rsrc\JAVA_CAB10\tools.zip with 7-zip
In command shell (cmd.exe) do the following:
change directory to C:\JDK.rsrc\JAVA_CAB10\tools\
execute command: for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar" (this will convert all pack files into jar)
Copy whole directory and all subdir of c:\JDK.rsrc\JAVA_CAB10\tools" where you want your JDK to be and setup manually JAVA_HOME and PATH to point to your JDK dir and its BIN subdir.
Yes, you can create a zipped up JDK, unzip it on the target machine and run java, javac, etc. from that directory to your heart's content.
The easiest way to create such a zip file is to install the JDK on a machine and then zip up the contents of the JDK directory. We do this in certain circumstances where we need to control exactly what configuration of Java will be used in our deployments. In that case, our scripts just point JAVA_HOME (or the equivalent) to our internally bundled JDK instead of relying on a sysadmin to install exactly what we need prior to arrival.
In terms of integrating with the browsers, that can be a bit more problematic. The short answer is no, you can't integrate directly with the browser without some sort of installer.
You could use SysInternals RegMon and FileMon (now owned and dist by MS) to see exactly what is modified by the Java installer. I believe there will be a number of reg entries that you will want to create. Products like WISE installer, for example, also use this sort of approach under the hood to repackage product installations (e.g. as MSI).
Please be careful since there are also some dynamic decisions made by the installer which may affect what gets installed (e.g. on XP v.s. W2K3 server). I was bitten by this once regarding installed codepages. I do not recall the precise details, but the effect was that a codepage file was missing in my embedded JRE + JDK (legally redistributable portion only). This caused a very bizarre and seemingly nonsensical runtime error in my code. It goes without saying that the same applies to Server v.s. client JVM DLLs.
Really, no, at least if you want to use it from Windows and not from, say, cygwin. Windows depends too much on the registry; you could simulate the registry updates necessary, but software that moves the files to the right place and updates the registry is called "an installer"; you'd just be reinventing the installer.
I believe this at least used to be feasible to a limited extent with earlier versions of Java - I don't know if it still is.
Most of the registry entries are used for things like browser plugins, as you mentioned in the question. If you just want to be able to run Java (e.g. from a batch file), that's one thing - but really installing it is a different matter. Even if you're just wanting to run it, you'll need to be careful to always explicitly use the one you intend, rather than using the installed one accidentally for part of your application.
What's your actual use case? Do you actually need a browser plugin? What aspect of the configuration are you interested in? A lot of the control panel configuration is to do with updates and browser integration. Many other aspects can be controlled using command line options to set specific system properties.
If you just want to provide a JVM with your application is fine, but more than that I would not recommend.
If you just want to have the JDK (JRE) files, you can run the installer within sandboxie. Once installed in the sandbox, just copy the files from c:\sandbox and you are done.
I'm using this to compile and run legacy java applications which cannot be migrated easily to a newer version of java. I can point Eclispe to this JDKs and tell it to be compliant to Java 1.3.
Just down load the Windows server version of Java from the Oracle downloads page. Setup JAVA_HOME and PATH variables on your own.

Categories

Resources