Tim Holloway

Bartender
+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Linux
Forum Moderator
Tim Holloway currently moderates these forums:
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.
Jacksonville, Florida USA
Cows and Likes
Cows
Total received
85
In last 30 days
4
Total given
11
Likes
Total received
1287
Received in last 30 days
28
Total given
40
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tim Holloway

Java assumes/requires directory structures for source and class files. That is true. Maven assumes additional structures for project organization, which helps both it and humans figure out where to find resources when editing or compiling. For example, most Java projects have a src/main/java and a src/test/java so that test code doesn't end up in the production output but is still available for Maven to run junit (or other) tests with.

Junit 5 is built with gradle, which has among its primary distinctions support for languages not limited to Java. The site itself is built by their Jenkins server. I didn't see a ready-made junit5 JAR available anyplace obvious - the implication seemed to be build your own and the build will install the junit5 jar in your local Maven repository. I'm not actually sure if Junit 5 is intended for prime time yet or not.
8 hours ago
I am not so sanguine. IBM has systems that have created recipes, composed music and even written fiction. While it's still a far step from there to intuiting what users were hallucinating when they wrote up the system specs, it's still an indication that such things may eventually be possible.

And it won't be for lack of hardware. Yesterday alone I read of how to wire a handful of ESP-32 chips to produce a supercomputer, although I suspect that in terms of raw speed and parallelism, a lot of the bitcoin-mining GPUs can easily surpass that (though at a much higher price). Western Digital also announced a 14TB disk drive. Somewhere around the year 2000, I was working in one of the largest mainframe shops in town and the entire mainframe DASD farm was 14TB. Although my department had another 1.4TB aggregated in their workstation hard drives.

And as long as I'm expressing attitudes, I'm rather eagerly awaiting the AI CEOs. Unlike humans, they won't have any reason to demand obscene salaries and likewise wouldn't have any internal incentive to ruin the company for short-term personal gain. Although I take no responsibility for any cybernetic humanoids they start creating.
9 hours ago
Job security aside, once computers start writing their own systems, we're into Skynet territory and it's time to run!

It's also been a major complaint about many cheap programmers - that they don't think, they merely follow orders by rote, and so basically they're doing the same thing as computers - doing what you tell them to do instead of what you want them to do. Computers because they're too stupid to do otherwise, people because in many cases they came from a culture where questioning orders could have dire consequences.

The whole idea that you can take untrained, non-creative (and low-paid) people, dump an IDE on them and expect the IDE to make up for the properties that the people lack is contemptible to me. As you can probably tell.
13 hours ago
Glad we could help.

Sorry if I seemed like I was ignoring some of your examples, but what I was really trying to do was assert the facts and thus re-inforce what you'd done right. Plus sometimes you tried different things, so I wanted to make it certain what the right alternative was among the various examples you gave.

I think by now you can see why Maven is so popular, though.

And I'll admit I started out doing things the hard way (including with Windows batch files), had worked my way up to Ant, and initially resisted Maven because in Ant you could see what the build rules were, but Maven did things by "magic". But gradually I warmed up to it. Having it maintain all those dependencies helped a lot, as did having a standard project structure that could be shipped out and understood (and compiled!) anywhere.
14 hours ago
You still have to import org.junit.Test if you extend TestCase. With the @Test annotation, you need the junit jar on your compile and execution classpaths. And, of course, if you're going to use Junit assertions, import org.junit.Assert.

When you get a ClassNotFoundException, one of 3 things has happened:

1. You misspelled the classname.

2. You mis-identified the package path (either it's not in that package or you mis-spelled the path).

3. You didn't include the directory or jar that contains the class in your classpath.

These 3 rules apply in both compiling and in runtime.
15 hours ago
I don't see an import statement for the junit TestCase class in your test class source code.
15 hours ago

Matt Wong wrote:If I understand correctly, you want to lock the connection so only your client can talk to the server.
Why bother implementing this yourself? Use TLS. I posted a thread about using client certificates (wich are a bit better now, I could share my code).



That falls under my "You can only limit by user ID in the sense that the listening application can choose who to converse with." In this case, the client certificate is indicating the user ID. The catch is that your listening app does have to support client-side certificates. And the certificate is bound to a specific client machine, so if the same user gets on another machine (or their primary machine goes in for repairs), they'd have to have a client cert assigned for their new/alternate machine. And dialing in from public machines, of course, would be unthinkable.
Whoops. Let's not get the compile (javac) and runtime (java) commands confused here. As I am getting. I really hate having a short, fat screen thanks to HDTV warping the market for computer monitors. Can't read everything without going to portrait mode, which is worse.

Anyway. the classpath ALWAYS points to compiled classes (and JARs of compiled classes, but not JARs within JARs). So to compile in a single command from source, you have to indicate BOTH main and test source files. Or compile the independent class separately and include it in the classpath to the compiler.

The "-d" option on my initial example was to indicate what directory to put the compiled classes in regardless of their source.

When you run, you are executing classes, so the classpath must either be the default (local directory) or explicitly indicated via the -classpath option. And you always execute the fully-qualified classname (package name incuded). The classpath points to the root(s) of the classes, and assumes the standard Java directory structure for packages. That is, it's not valid to put "com.coderanch.messages.MessageEditor" directly in the classes directory - you have to structure it as classes/com/coderanch/messages/MessageEditor.class. Feel free to interpret that with backslashes on Windows machines.
17 hours ago
In other words, don't "cd" to the directory containing the file. Instead, cd to the root of the output classes directory and reference the main class by its fully-qualified name:

OR

Which avoids the need to "cd". Also "-classpath" can be shortened to "-cp" if you prefer.
18 hours ago

Norm Radder wrote:

got this error: 


Can you post the command line that you are using?  The classpath needs to point to the folder holding the com folder on the path to the BasicTest class.



He did and it didn't reference both source trees. Hence the failure.
18 hours ago
What do you mean "It doesn't work"?

It looks like you're doing a cross-product join, so the code could be just fine and time out because the data set you're pulling is enormous (number of rows in products times number of rows in suborders).

You probably want an inner or outer join. Cross-product joins are almost never required, but unfortunately, they're easier to code than the more reasonable joins and it's not intuitively obvious what you're going to get back.
The GUI frameworks are a little complicated. To make it easier for GUI apps to deal with the slicing and dicing of the rendered images as you drag around and cover/uncover windows on the screen, they split the drawing into 2 parts.

The first part is the painting part. It's the program responsible for the drawing. But the painting part is separate from the application part. In most cases it's not even in the same thread as the application part.

The painting part is often called automatically since otherwise the application code would have to spend a lot of time worrying about screen activities external to the application. So you basically "set it and forget it".

So what happens if you change your layout? Well, in that case, you "invalidate" the parts of the graphics that have changed, create a new painting sequence, then invoke "repaint" on the application thread to tell the renderer to redraw the changed areas.

If that doesn't make much sense, don't worry. This is a very sophisticated mechanism and I'm not really good enough to explain it well in the small amount of space we have here. Your better bet would be to find a good text on Java's graphics system. Just remember, your application mainline code doesn't paint, it schedules a different part of the application to do the painting.
18 hours ago
Read what I said right before your response. Yes, the classes are both in the same package. But the compiler has to be able to see both of those classes in their respective source directories. It cannot intuit the location of one source directory tree from the other directory tree. So you either have to explicitly indicate both source paths, or compile the non-dependent class first and then include its compiled classfile in the javac classpath.
19 hours ago
Welcome to the Ranch, Soumitra!

1. Solve it? I can't even read it! The "Code" button on our message editor allows you to insert tags that will keep code and data/xml samples from getting scrambled like that.

2. Class.forName for database drivers has been obsolete for a very, very long time now.

3. You shouldn't be using the DriverManager in web code. Web servers support database connection pools. It's much more efficient for multi-user webapps.

4. You also shouldn't be coding logic on a JSP page. That also is a long-obsoleted practice. The JSP should be a template populated by a servlet. The servlet is where your database code should go.
22 hours ago
I worked with C++ from shortly after it was released by AT&T and I can tell you that one of the most annoying things about C++ was multiple base classes (multiple inheritance) with overlapping functions and/or variables. The authors of Java felt the same way, so interfaces are a sort of kludge where a class can have only one base class yet still promise things as though it had multiple base classes.

The "default" mechanism is an additional kludge. As I said earlier, it's a good way to add features to new classes while keeping the all-important backwards compatibility that is a hallmark of Java. But since it is a back-door version of multiple inheritance, it also allows some of the same problems that multiple inheritance has.