Tim Holloway

Saloon Keeper
+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Tomcat Server Redhat Java Linux
Merit badge: grant badges
Biography
Long-time moderator for the Tomcat and JavaServer Faces forums. Designer and manager for the mousetech.com enterprise server farm, which runs VMs, a private cloud and a whole raft of Docker containers.
These days, doing a lot of IoT stuff with Arduinos and Raspberry Pi's.
For More
Jacksonville, Florida USA
Cows and Likes
Cows
Total received
196
In last 30 days
0
Total given
40
Likes
Total received
3152
Received in last 30 days
17
Total given
375
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tim Holloway

Very frequently a large old project has been implemented using technology that is itself outdated. For example, don't even think of doing a simple code upgrade to a CORBA-based system. Even something SOAP-based would be questionable. Often code used originally could be replaced with something simple/cleaner/more powerful.

The beauty of Java is that you can keep old stuff running almost forever, unlike Microsoft-based systems, of which I've known a few whose functionality was literally measured in weeks. But regardless, the longer you let it run, the more expensive it will be to sort out all of the accumulated cruft and make it clean again.

As for recent experience along those lines, I can present the CodeRanch JForum, which I undertook to upgrade several years back, as the very operating system it runs under is long past end-of-life and thus subject to potential shutdown without warning. Here are some things I encountered:

1. The build was done in Ant. No problem as such. So is Tomcat. But vanilla Ant isn't good at tracking library versions, and like most major JEE apps, JForum uses a ton of external libraries. I could have added Ivy to the Ant build to better deal with that, but we're not doing something so elaborate that Maven can't do it just as well, so I Mavenized it. So I had to track down the latest versions of all of the external libraries and plug those version numbers into my POM. A few libraries aren't in the standard Maven archives and had to be manually defined to Maven. Also, in some cases, the package ownership had changed, meaning that the library's base name often also changed.

2. I ran the build and noted the things that didn't compile clean (if at all). These were generally due to package path changes, but sometimes also due to changes in the APIs that the libraries presented. Those had to be fixed. Also, because the current source builds under Java 8 and Java 9 and up have significant differences regarding introspection, I wanted to at least minimise the whining. Note that I never even considered moving from javax EE to jakarta EE. There's a limit to how much mayhem even I am willing to introduce at one time. The project's target would be Tomcat 9.

3. Once I had something resembling a clean build, I started running the unit tests. A lot of testing was done using Mockito and that uncovered 2 problems. First, since Mockito uses a LOT of introspection the bump from Java 8 to Java 17 wrought havoc with the compile-and-test process, so I had to clean that up. Secondly, the older version of Mockito was less stern about how you coded certain cases, so that in addition to having to upgrade test code to appease Mockito, there had been tests that weren't actually doing what the original authors thought they were doing that had to be fixed.

That brings me to the point where it's ready to be beta-tested. But there's more.

4. To be fully up-to-date, the javax stuff needs to be changed to Jakarta. For a smaller project I was able to do most of that using an app someone had written to scan and change source code while being aware that not every javax actually became jarkarta. It did most of the job, but some manual tweaking was still needed.

5. There are, alas, several characteristics of the current jforum that violate what we tell others is good practice. I think I could probably repair that without a whole lot of trouble, but, again, that's too much for the first stages of upgrade.

6. And, of course, in addition to the app itself, changes have to be made regarding the automated build and test processes, deployment and OS integration.
8 hours ago
There is a utility that can take a Java source tree and  intelligently convert javax to jakarta. It's not 100% tuned to which is which - I had to change some JSF stuff manually - but it takes care of about 90% of the job automatically.

I used it to upgrade my Spring Boot Recipe Manager project.
1 day ago
Welcome to the Ranch, Arron!

Actually, I believe that Mockito has been able to mock statics for several years now (before that, extra help was needed).

But I wouldn't be using mocks there in any event.

There is a JUnit test capability that specifically tests database logic and it doesn't need mocks to do that. That's my preferred method.

In fact, mocks are my test of last resort. Mockito mocks in particular can be more trouble than they are worth, especially when you're attempting to get data from a mocked object.

However, this link seems to be addressing your problem using mocks: https://dzone.com/articles/mockito-basic-example-using-jdbc
"Help with" isn't the same thing as "Please provide a completed solution". We're always happy to help with, and welcome to the Ranch! But we don't provide completed solutions. So if you can supply us with some XSLT that you've been working on, we'll be happy to help you make it work right.

Also, while you've managed not to have your XML samples get mangled by our message editing system, a better presentation would be to wrap the XML samples with Code tags (see the "Code" button on the editor). Code tags allow sample Java code, XML, SQL, and other pre-formatted text to display without being damaged by the typesetting algorithms that our main text editor applies.
Both Swing and CSS are based on the premise that areas of interest are laid out in rectangular areas, where some rectangular areas may also serve as containers for other rectangular areas. I don't use the word "rectangle" because while a given component is always contained within a bounding rectangle, there are times where the area of interest/rendered area may not itself be a rectangle. And also note that in some cases, "area of interest" may differ from "rendered area", such as when a rectangular area contains, say, a map of the continental United States, but you can click on sub-rectangles or aggregates of sub-rectangles to indicate a particular state.

The default layout for CSS is simple box packing, but you can also have stuff like floating and relative DIVs. Swing, on the other hand, offers a number of layout algorithms which can be selected at both top and containing component levels. The two display sysstems are more alike than they are different and for the most part, you can get the same layouts from either, though it might be a bit kludgier to do so using CSS.

Of course, as Carey pointed out, Swing is a complete GUI framework, based on MVC whereas CSS is View-only and requires additional frameworks to attend to the Model and Controller aspects.
4 days ago
You can call me a cynic, but I'd wager that a primary reason that your incoming data is such a mess is that it was produced using only "core" Java instead of tested publicly-available Java resources.
1 week ago
If by "core java" you mean that you are limited to only classes that come with the JDK, your employer is doing themselves a serious disservice. Not to mention locked themselves out of any meaningful Internet development, or, for that matter, the JDBC database drivers.

I started out long ago when we had to write everything in assembly language for the mainframe. It was an excruciatingly slow process, but we had no choice. since none of the higher-level programming languages such as COBOL or Fortran could be used at the system level where we were working. I suppose in that sense, we were "more core than core". My boss hated it, we hated it. We had to create every single sort, search and what-have-you algorithm from scratch and the only thing that justified it was that when a mainframe costs $1 million (last-century) dollars, having the most expensive talent in the shop constantly re-inventing the wheel was justifiable economically, even if not in terms of productivity.

Java's true utility comes from its trusted extensions. Java EE, for example, isn't "core" Java and never was even when Sun owned it. And now it's property of the Apache Foundation. Which brings you such venerable projects as the Tomcat webapp server, innumerable support libraries, including the Apache Commons CSV parser, and much more. Many of those libraries, in fact, form components of other Apache components. For example, Tomcat is built using the Apache Digester, Commons pooling, and probaby a lot of the JNDI support. Big-name commercial products like WebLogic server and Jira even though proprietary are laced with "non-core" products like the ANTLR parser.

The alternative to using ready-made is to re-invent it all yourself. Which requires more manpower, more time to develop, maintain, and support. All of which suck resources out of your core business projects.

While it's certainly not safe to just pick up libraries off the street, there are certain resources that have major weight behind them, sources like the Apache Foundation, IBM Red Hat/hibernate and others. These projects have serious support behing them and can be readily obtained from secure sources like the Maven Repository.

There's being prudent and then there's being penny-wise and pound-foolish. While it would be wise to keep a review team meeting occasionally to vet the safety and in some cases licensing issues before approving library use, throwing out the baby, bathwater and tub is a good way to end up at the mercy of the competition at best.

Having said all that, I'm reminded of a major corporation that provides downloadable financial information in CSV form. Their algorithm is an abomination and having downloaded the file, the first thing I can do before feeding it to a spreadsheet or database is run it through a custom cleanup program to repair all the mis-uses of quotes and commas in what it supposed to be a simple data file format. The data at the head of this thread is a lot like that.
1 week ago
The first thing I do when I encounter an issue like this is to see if the project in question has been re-homed. Meaning that a more up-to-date version lives under a different website/package tree.

Unfortunately, there's nothing for DWR. In fact, the DWR homepage itself is no longer online. That counts as unsupported technology to me. Often a technology becomes unsupported because a better alternative has come along.

A quick check seems to indicate that jQuery plus a JSON library would be one alternative (which, incidentally, I've used without ever knowing of DWR). Note that if you're using JavaServer Faces, jQuery is already inside, although you may wish to override the default version, which tends to be fairly old.

Wholesale shuttling of Java objects between client and server for its own sake is something I don't encourage. It lends itself to easy hacking, so I'd be limiting the properties being transmitted to only what is essential.

One source recommended YAML. I'm a big YAML fan because of all the popular web service data formats (XML, JSON and YAML), it's the easiest to type, and like XML and JSON, you can source it from a JSP template. But I'm not sure I'd prefer it to JSON when used with AJAX or in JavaScript in general.
1 week ago

Campbell Ritchie wrote:Please avoid abbreviations like, “w.r.t.,” which may confuse non‑native‑English speakers, and certainly confuses Google Translate.


I don't even think it's that obvious to Americans. More of a British/South Asia phrase.

A better usage here would be to use the simple word "regarding".
Welcome to the Ranch, Sai!

You can start your own message thread if you prefer. This one's nearly 16 years old and things have changed. For example, Class.forName() is no longer required.

Java operates on classpaths. To find a class, you have to place it in your Java app's classpath. You can do that using the -classpath option on the java runtime command.

Classpath  elements are directory trees and/or JARs. So, for example, to run a Java app named "Foo" that uses Derby, your command line might look something similar to this:

There are two elements in the classpath of this command: ".", which refers to your current directory, and "C:\Java\XXXXX\org\apache\derby.jar", which refers to your JAR. Note that you don't have to use such an elaborate location scheme for the JAR, though, as its package structure is contained within the JAR itself. You could have simply said

And put the Derby JAR in C:\usr\me\javalibs.
If you have a webapp, then a Connection Pool should definitely be used and the best way to use one is to define it to the webapp server as part of the webapp's Deployment Descriptor. Then you can use JNDI to obtain a reference to the Connection Pool and that reference can be safely stored globally in the webapp so you don't have to look it up each time you need access to the pool. While the webapp server will come with a standard Connection Pool implementation built in, it's usually plug-replaceable if you find a different Connection Pool implementation that's more suited for your needs.

Similar options may be available for other frameworks, but you can also write stand-alone Java apps that create and use their own Connection Pools. Please note that DriverManager.getConnection() is NOT connection pool-based, though. It's what connection pools invoke to build their pools and it has a LOT more overhead itself than simply getting a Connection from a Connection Pool does.

Some other important things to note is that in order to use a Connection Pool most efficiently, you should not obtain the Connection until you actually need it and to close() the Connection as soon as you are done with it. And absolutely never cache and hold a Connection between requests in a webapp!
What you're dealing with is a type of Packing Problem. Packing is mathematically a sub-species of Topology.

I did a similar project a while back, but in my case, I was trying to take a set of backup files and figure out how to pack them into the smallest number of 4.3GB DVDs I could in order to be able to better manage disaster recovery. Ny solution turned out as a surprisingly small Python program.

This is also the sort of thing that was meat-and-potatoes to the ACM back in its heyday when sorting, searching and optimal list processing were still being explored at their most basic levels.

So expect to find quite a bit of existing literature on the subject.

Without looking, though, I'd probably break the geometry down to the point where every rectangle was an integral collection of atomically-sized squares, if I could. You could then know if a problem was solvable at all if the sums of the number of squares in each rectangle was less than or equal to the squares in the bounding box. If so, then the fun begins, testing if there was at least one packing that would cram them all in.
2 weeks ago
Welcome to the Ranch, Palak!

The first thing to realize is that JSPs are not like time-sharing terminal displays. The only way to get a JSP to update is if the client sends a new request to the server so that the server can send back a new JSP (or whatever).

You can get around that by putting an auto-refresh option in the HTML that your JSP generates. In ancient times, it was common to use a special META tag to do that. These days we often use AJAX, since that allows updating only part of a page instead of replacing the whole page on the client side.

HTTP servers likewise don't run "programs". Instead they provide services that are run when a request comes in and those services must then provide the response back to the client. So there's nothing to sit around and get updated from the database. Instead the request processor has to read from the database on each request.

In JEE, reqest processors are servlets. For JSPs, the JSP compiler generates a servlet by turning the JSP source into Java code, then compiling the Java code into a class. That's all automatically done for you,
2 weeks ago
JSP
Just because I'm chatty online or even one-on-one doesn't mean that I enjoy going out randomly and meeting people. And, alas, the last time I encountered someone from my own town on the CodeRanch, it was an old office-mate who'd retired and was trying to learn Java for the fun of it. I used to be somewhat of a presence in other forums, such as LinuxQuestions and StackExchange, but I gave them up years ago, as well as the more generally social places such as Slashdot and reddit.

In fact, it worries me that unless external demands require it, I can spend the entire day no more than 10 feet from my house. Even the back garden is more unvisited than not now.

It's not that I'm especially unpleasant like I was when I was much younger and didn't have much optimism, hadn't been introduced to appropriate medications and hadn't yet learned that my daily dosage of tea was what was making me 1 short step from diving under the furniture at the slightest noise. I'm just a very solid embodiment of the stereotypical software person, but with better spelling abilities (most of what I mis-type is sloppy fingers).

While in the past, I was always treated for depression, in actuality, what really seems to have ruled me was more a mix of obsession over minor hurts and generalized anxiety disorder (which wasn't a Thing until fairly recently). The mental health sciences have progressed considerably over the decades, and I'm glad to have missed out on the icepick-lobotomy fads and most of the drug-them-until-they're-comatose ones, but we're a long way still from precision diagnosis and treatment.

The first effective treatment I encountered was a tri-cyclic anti-depressant and it's what clued me into the obsessive component of my affliction because it messed with my short-term memory and you can't properly obsess if you keep forgetting what you're obsessing about. It was fairly brutal, and it caused major tooth decay, but I still got messed up when I had to move to get a new job and couldn't carry the prescription over.

Ironically, I get a lot of benefits these days from a blood-pressure medication that works by slowing heartbeat. Since one of the symptons of "fight-or-flight" is accelerated heart rate, applying the principle in reverse makes me feel less on the edge of panic all the time.

But in the end, I still don't like to socialize. It's like the "you can make yourself be happy!" approach to depression. You can fake it, but you cannot make it, because it's like treading water. No matter how long you tread, it's an effort that someone more buoyant wouldn't have to make and eventually the effort will exhaust you and you go under. You simply are not going to be able to build up the level of muscle tone required to go indefinitely no matter how much you exercise. Quite a few people have tried to become software developers and ended up abandoning it. Some skills can be learned, but that doesn't mean that they can be enjoyed by everyone.

OK. The Twitter reference was a dig at people who are naturally sociable, and can end up being worshipped even as they take a $75 million company and turn it into a $30 million one. Or whatever it's worth these days. Failing upwards because they were brought up to be connected and had the ability to use those connections. I have had neither. In fact, to paraphrase Terry Pratchett, when I die, the sum total of persuadeability of the population of Earth will fractionally increase.

But, as to seniority, I basically started my career in senior positions. I was the system administrator for the minicomputer in college, did yeoman-level assignments on my first actual job, and shortly moved up into OS support. It's one reason why generic recruiting doesn't work for me. When you need me, a grunt-level person won't do, and grunt-level screening will cut me out of the process.

Not to worry. As I said, I'm essentially retired now. After all, I'm "too old to learn new technologies". And I'm tired of meeting my boss in the hall and learning that he was just laid off and my exit interview comes next. No more. I quit.

2 weeks ago
The principal reason why Java isn't suited for system-level tasks is its "write-once/run-anywhere" design. For example, Windows security attributes cannot be accessed by Java, because Windows security is totally different to the various security systems on Linux (standard file ownership rights. selinux rules, and so forth). So there's simply no Java API to hook into. You'd have to create a native-code glue module for that. In the end, it's simply not worth the trouble. Just write the whole app in native code.