Tim Holloway

Don't be sad. Many years ago I was called on to write a C++ compiler and in C++, ambiguities were not fatal.

At the time, they were also not - so far as I could see - predictable. So that shot down that project.

Terrance Samson wrote:Thanks for clarifying that line.  And I've heard all about Java working the same in all circumstances (I guess as long as you're not relying on DLLs compiled in C or something), but I don't think I've ever seen it before, so that will be interesting.  Anyway, thanks again!

Java's biggest claim to fame is indeed "write-once/run-anywhere". Avoiding DLLs and other native-code classes is essential to make that happen, yes, but there are other considerations.

For example the filename paths and locations vary with the OS. That's something that can be reduced, though, since Java accepts a "universal" file path format based on Unix (so you can code "C:\\Program Files\\jre-1.23.4\\bin\\java.exe" as "C:/Program Files/jre-1.23.4/bin/java.exe", for example, and break up the path-construction logic so as to allow the OS-dependent parts to be isolated and made reconfigurable. For example:
final String javaExe = "java.exe"; final File javaDir = new File("C:/Progam Files/jre-1.23.4"); final File javaBinDir = new File(javaDir, "bin"); File javaExecutable =new File(javaBinDir, javaExe);

Ports to Linux just by changing the values of javaExe and javaBinDir - which can be read from a properties file or supplied as command-line options. Do note that filenames are case-sensitive in Unix and Linux, so don't be sloppy there. Even in Windows Java will potentially get annoyed if you're not consistent with upper/lower case in filenames and paths.

An "executable" JAR is not an executable program and therefore no OS file permissions settings will do any good.\

You cannot execute a JAR without a Java runtime program (JVM). An "executable" JAR is one where you can say:
java -classpath myExcutable.jar
and Java will find a Main-Class entry in the JAR's META-INF/manifest.mf file that tells which class within the JAR contains the public void Main(String []args) method for the JVM to execute

You would typically see this message when the called class was compiled for a newer version of Java than the calling class was. In your case, that would seem to indicate that the version of WebSphere you're using is too old to use that particular Oracle JDBC Driver library.

Right-mouse (context) menu: "Compare With/Local History..."

Note that this menu mixes itself with VCS history menu if you have a version control system active for the project.

I don't run critical Internet services on Windows and have not for a very, very, very long time. Actually, I haven't run Windows on anything for a very long time.

But a quick check on the Tomcatw.exe documentation at tomcat.apache.org indicates that you can set an execution parameter for tomcayt9w to point its JAVA_HOME to any JDK installed on the machine's filesystem.

However, Tomcatw is apparently designed to be run as a Windows Service, so I'm thinking that you'll actually need to execute the Service Manager control panel snap-in to configure it and that would require that you either have sysadmin provileges or be empowered to direct someone who does.

It's good practice to keep your project source under source version control. The git version control system is very good for that, since you can simply "git init" the project directory and have a per-project archive. Which you can then export to a git server if you like at any time in the future. Eclipse has git menus that can help go it all from within the IDE.

But even without a VCS like git, Eclipse itself keeps a history of changes. Several days worth, in fact. You can list them by their save time/date and "diff" compare/merge different versions. It's a feature that has saved my skin many times.

I can tell you one thing. That POM seems to have an awful lot of explicit file directory references. Maven doesn't like that and it reduces the chance that one of Maven's major strengths can be exploited.  An ideal Maven project can be cleaned, ZIPped and sent to a completely new system on the other side of the planet then rebuilt exactly with only an installed JDK and copy of Maven. It should not require or assume any files or directories external to the project itself. Maven should be allowed to build into its standard build areas (in the target directory) without being told via symbolic substitution. Maven isn't Ant and works very differently than Ant.

Beyond that, this appears to be a multi-language build. For that, I'd recommend something more like Gradle, which, unlike Maven is not as focused on Java and Java alone.

Stephan van Hulst wrote:If your applications already run on Java 9, they will likely also run on Java 11.

A reason to use Java 8 might be if you were using Tomcat 6 or something like that.

Please don't, though. I don't think Tomcat 6 has been supported for several years itself. What benefit using a supported JDK version for an unsupported server version?

Let me add a few odds and ends. Since I only have limited screen space, it's hard to keep track of all the questions and suggestions, but I'll address the ones that I found most noteworthy.

7zip is an archiver like ZIP, but the ZIP standard doesn't support files larger than 4GB and 7zip does. it's a completely different program than the gzip and zip utility programs and since installation packages (fortunately! so far!) don't require large file support, tarballs remain the accepted standard. Except I think in Slackware, where bzip was popular when I worked there. So many standards! So I wouldn't mess with 7zip here. It's almost never in the standard OS install, so you'd have to install it manually and that's just one more step for no immediate benefit. Actually, zip/unzip are themselves often not in the basic OS install, although gzip and tar usually are.

About the dash on the command line. There is no absolute standard on command line option syntax, although conventionally a dash is used. Except on the ps command, where it's disdained. And on dd, which ahas its own charming syntax form. And... The original Unix command line format called for option switche flags to be single letters and/or digits and the convention has been that you can stack them all behind a single switch indicator. That is "tar -t -v -z -f filename.tgz " is also valid as "tar -tvzf filename.tgz". The order of the switch flags is mostly arbitrary except for flags that have operands. That is "tar tvfz filename.tgz" would be mis-interpreted, since the filename must immediately follow the "f" flag. And on some utilities, "tar -tvzffilename.tgz" will work. Haven't checked tar on that one. It's too hard to read and too easy to screw up.


You don't need a JDK to run apps, no, much less an IDE like NetBeans.

Regarding Campell's recommendations, setting options in /etc/profile.d would be appropriate for default systemwide settings, like for multi-user timeshare servers  but I never use it for Java myself. I use .bashrc settings:
export JAVA_HOME=/usr/java/latest export PATH=$JAVA_HOME/bin:$PATH

Yes, expanding PATH like that does make it longer, but it's only done when the environment is constructed (when I login) so it's not like it gets longer and longer forever.

JAVA_HOME, incidentally, is not an official part of the Java spec. but a lot of Java apps look for and use it. The Eclipse IDE, however, does not, for example. A given command shell instance can (re)define JAVA_HOME and it will not affect any other command shell's environment. Likewise, redefining JAVA_HOME will not update the PATH, since $JAVA_HOME/bin:$PATH is evaluated at the time it is set and not dynamically. If you want a different Java bin in your PATH, you have to re-define the command shell's PATH.

Welcome to the Ranch!

I would not expect a larger max-post-size to affect the response time, no. Although the bigger the POST payload, obviously the longer it's going to take to transmit and parse it.

The primary use of the max-post-size limit is to defend against malicious attacks or sloppy/runaway clients. Knowing the maximum size that a legitimate POST can be allows blocking Denial-of-Service attacks that would attempt to tie up the server and possibly cause failure due to excessive storage requirements. Such failures might then be exploited to invade the JBoss/WildFly server and possibly its containing OS.

"yml" is the common filename suffix for files in the YAML (YAML Ain't Markup Language) format.

YAML is a structured notation that supports hierarchical data and collections. Its popular relatives include XML and JSON.

Unlike XML, but like JSON, there is no meta-data support to codify structure or content-type for the data elements. However the syntax is simpler for YAML than for JSON, so it's very easy to parse. JSON elements must be valid JavaScript expressions, but YAML elements are just name/value pairs and lists.

Because of this simplicity, the amount of data required to transmit over a network or store in a file is very small. Even better, it's very easy to edit YAML, as you don't have to fiddle around with angle brackets, braces, and other structural stuff. As in PYTHON, most of the structural information is conveyed by simple indentation.

A very quick look at the project you pointed to seems to have only one file (my eyes aren't what they used to be, though) and that's a Travis configuration File. I believe that Travis is a test framework, so to be complete you should keep that file even if you never run Travis yourself.

Yes, you really should learn YAML. Basic YAML is quite simple, but very powerful and you can expect to run across a lot of it these days.

The main page for the YAML project is an outline that is itself in YAML form: https://yaml.org/ Note that it lists several Java YAML tools. Just about every major and some minor programming languages have YAML support.

A description of how YAML is constructed (the YAML spec) is here: https://yaml.org/spec/1.2/spec.html

We think that you have a major confusion between what is blanking a line and deleting a line.

To blank a line on paper, you could simply erase what is written. To delete a line on paper, you would have to take scissors, cut out the part of the page with the deleted line on it and paste the page back together with the lines above and below the deleted line touching.

Computer memory and text display does not work that way.

OK. I guess life could be more fun if you have no direct Internet connection. I have to assume some sort of indirect connection though, if you have anything more than an install DVD or thumb drive (in whiich case you should find the OpenJDK package there, if not the latest one).

A tar,gz file is what happens when you run a set of files through the tar utility and then uze gzip to compress them.

The Tape Archive (tar) utility is hardly ever used ti make tape files anymore, but it's a serializing utility - designed to take a set of files/directories and reduce them to a single file. It's similar to ZIP, then, except that ZIP attempts to compress data unless told not to and tar has no compression capabilities. The gzip (GNU ZIP) utility, on the other hand takes a file and compresses/decompresses it (gzip/gunzip). Unlike ZIP, it takes exactly one and only one file (or more accurately data stream). Why are these functions separate instead of all-in-one like in ZIP? Well, for one thing, I think that tar was being used before compression became common, for another, it kept progams small and simple (the original Unix philosophy prefers chaining simple programs together instead of making one big program). And finally, gzip uses Lempel-Zev compression, which was developed more recently. In older times, it was common for Unix to use a utility called compress, but the algorithm used with compress is less powerful than Lempel-Zev.

In modern Linux, yes, you can explode a compressed tarball with a single command. Use the tar options "tvzf", where "t" means "extract", "v" is for "verbose" (optional), "z" for compress/decompress amd "f" indicates that the name of the tarball file will be next on the command line.

Both ".tar.gz" and ".tgz" are used to indicate compressed tarballs. It's mostly preference. Other options include the bzip utility, which was once used as a more efficient alternative to ZIP (file extension is ".bz2"), but tarballs are the standard.

And yes, if you wanted to, you could double-click on a GUI desktop icon and browse, expand or edit tgz files if your desktop has a GUI explorer such as File Roller mapped to the file extension in question. Although if you intend to unpack the file and use it, you might as well be at a command prompt, because you'll need it for the next steps.

I'm afraid your screen dumps didn't make the trip.

Although parts of what you're describing sound like how the original MacOS handled title bars - which differed from other GUIs - I think your real problem is not really MacOS related.

A Java application does not truly terminate - that is, the JVM does not exit - until all threads in the JVM have terminated. As long as even one thread lives, the JVM shutdown will hang.

There are quite a few threads running in your average JVM, but most of them (stuff like the garbage collector) understand when shutdown has been signalled and they then terminate themselves. That includes, in the case of a GUI system like Swing, the rendering and UI threads.

So killing just one window by brute force might not be enough. Ideally you should have an "Exit" command action (tied to things like the File/Exit menu) that will initiate a clean shutdown, but if you should kill processes relating to just one window, for example, then something like what you seem to be describing would apply - the remaining threads would hang the JVM shutdown process.

Note that doing an OS-level termination ("Force close/quit" for desktops that support it or a "kill" from command line) terminate the JVM by raw brute force, and in such cases no hooks would be able to run. However if you can trap the OS signal (for example SIGKILL) then you can fire the "Exit" command action and (we hope) shut down properly.