Tim Holloway

Saloon Keeper
+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Linux
Forum Moderator
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
80
In last 30 days
3
Total given
9
Likes
Total received
1240
Received in last 30 days
21
Total given
39
Given in last 30 days
3
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Tim Holloway

Are my ears burning?

I've been on record as saying that you should remove deprecated resources and methods from your code after a decent interval (say 6 months or so), but one of the most famous deprecations of all is the java.util.Date(m, d, y) constructor. This has been deprecated since about Java 2, and yet it's still around.

It was deprecated because A) it's locale-ignorant and B) assumes that the natural way of stating a date is US form.

However, it's also a quick and dirty way to build a date constant. And it's been used in enough places that if it was actually removed, half the Internet would probably break, not to mention innumerable services and applications. So deprecated or not, I'm not expecting to see it get yanked. Still, you do get put on notice that you're being sloppy.

So while I recommend pulling deprecated stuff between major versions of in-house stuff (and a lot of the external 3d party libraries), I have to confess that best practices are a little different when you are the Supreme Ultimate source for Java.
2 days ago
StackOverflow, in its defense, is not nearly as bad about flaming people as, say, traditional Usenet forums were. But they are excessively pedantic much of the time, and I say that as someone who's notoriously pedantic myself.

I can respect their attempts to keep topics non-redundant and on-point, but a lot of times they do more harm than good. People are routinely chastised for asking questions that only look like they're the same as other, not-quite-related questions, for volunteering information and opinions considered outside the discussion, and other trivialities. This makes it look unfriendly and the sheer quantity of moderator chatter is a distraction.

Moral of story: if you want to ask an innocent question, you're better off asking at the CodeRanch. We don't care (much! ) if you're asking the same question as 97 other people did or if it's a "stupid" question. We don't call ourselves the Friendly Placeā„¢* for nothing.

---
* No, we didn't really trademark "Friendly Place". Although maybe we should.
2 days ago
You can deduce my approach to question #1 from my earlier digression. Here's the other 2 answers:

#2 - I don't mind hearing from people via LinkedIn. I'm generally not going to "friend" recruiters casually, though. I prefer that my links reflect people who I actually have a fairly strong relationship with. And in fact, one of the flaws to me in LinkedIn is that it doesn't allow for distinguishing people I know from people I interact with on a regular basis. While I've gotten my fair share of offers to work at a warehouse assembling/testing parts for $15/hr, I'm not sure I could say that LinkedIn is any worse source for such clueless "efforts" than anywhere else.

#3 - Anything regarding relocation doesn't interest me. I know I could be a lot wealthier if I joined the ranks of migrant workers, but I like where I live just fine and I've already paid off my mortgage. And frankly I've gotten sick of commuting through city traffic. These days I work for people all over the world from my home office. This "offshore talent" thing isn't all one-way.

Stuff that offers opportunities for new and shiny tech can appeal to me although I've never stinted at doing workhorse stuff (and occasionally adding new and shiny technology to it.) Flexible work environments are a major consideration. I don't want foosball tables and tat, I want reasonable working hours and conditions and reasonable management.

A lot of what I look for isn't so much "pros", since I'm fairly easygoing once the basics are assured. What gets more attention are the red lights:

2 days ago
I never had problems with it myself. But then my favorite way of crashing Eclipse has always involved editing XML files.

If the Maven plugin only ran Maven, that would be good. But it also permits keeping multiple run profiles with differing goals, POM profiles, command-line options, etc. So you can quickly yank them off a menu and run them over and over again.

Plus it's good about incorporating dependencies into the project (both source and class) without requiring manual addition.

I'll admit that sometimes it seems to be mysterious about what it takes to make the light bulb go on, but mostly I think that has to do with the fact that Eclipse project facets are pretty gnarly to begin with.
3 days ago

ras oscar wrote:when I was doing C++ many years ago, it seemed that the Microsoft IDE was invoking bat files in the background to build the application. I remember I got compiler errors and link errors. Does java not have an internal linker to resolve external dependencies?



One of the biggest differences between C/C++ and Java is how they form programs.

In C (or C++), you compile your source files, link in external libraries, and get a (more or less) stand-alone executable file that can be directly loaded and run by the OS loader.

In Java, what's executed is the Java Virtual Machine (JVM), which is supplied with classes to execute. The classes may be loose (in a directory tree) and/or in Java Archive (JAR) files, which are actually just ZIP files full of classes plus one or more files of interest to Java (the META-INF directory). Incidentally, a JAR inside another JAR is not normally accessible to the Java class loader. Although some specialized run environments have exceptions to that rule.

While some JARs contain complete executable applications, Java often requires additional class resources. The totality of all the classes is the core classes in the JVM (stuff like java.lang.Object and java.lang.String) plus what's in your classpath. The classpath is like the PATH for executables except that the OS program loader knows nothing about it - it's used ONLY by the JVM to locate and load classes and class resources. The classpath locates the JVM internal classes plus additionally-specified class directory trees and/or JARs containing class resources. Actually, it's a concatenation of paths in most cases and in some systems there may be more than one classpath. For example webapp servers have a distinct classpath for each webapp, plus one or more for the internal processes of the webapp server (which is usually a Java Application).

You also need a classpath when compiling Java code, since unlike C (I'll assume this includes C++ for brevity going forward), there are no separate header and code files in Java. The "header" comes from referencing the compiled class itself. Note that at this level a Java Interface is itself a class, just in case you thought it was a header file.

So you have to have access to both your own source code and the compiled code of external class resources that your code needs. These are provided to the javac compiler via the classpath specified when you run javac (or when a tool such as Maven or Ant runs javac).

One of the reasons why Maven became popular was that instead of having to assemble all your external class references manually, you can indicate what classes you need in your Maven project's POM file. Maven will then go to the Internet and pull them from public repositories and cache them in a per-user local directory - which means that the slower network access is only done once. This cache is then available to all Maven compiles done for that user account, eliminating duplication of common resources and, incidentally ensuring that Maven-managed code is "write-once/compile anywhere". Ant doesn't normally do this, but the Ant Ivy extension does.
3 days ago

Campbell Ritchie wrote:

salvin francis wrote:. . . the OP is manually compiling it with javac.

In which case the behaviour may differ depending on whether the two classes are in the same package or not.



Very definitely. And once you start compiling multi-package projects, a simple javac command or batch script doesn't really do the trick anymore. At that point, it's better to use a Java-specific build tool such as Ant, Maven, Gradle, or the like.
4 days ago

Bear Bibeault wrote:

Tim Holloway wrote:the challenge for Developer Management is usually less about motivating people than it is about not de-motivating them.


Well-said. This memo needs to be sent to almost all my past managers.



I didn't invent it. I'm fairly sure I've read it more than once over the years and probably at least once in something by Ed Yourdon - I had a lot of his books.

Now if you want a quote you can credit me with, it's this:

Tim Holloway wrote:
The deadliest words in Information Technology are "All You Have To Do Is..."

Tim Cooke wrote:Conversely, I distrust any IDE to perform Maven and Git tasks reliably. As such I do all my Maven executions from the terminal.



I have that opinion of the J2EE version of Eclipse and its built-in Tomcat execution. But that's the fault of its WTP plugin. The sysdeo/mongrel plugin can run Tomcat properly.

The m2e plugin doesn't "perform maven tasks". It runs maven itself. It provides a profile template in the Run menu that facilitates Maven command-line options, such as selecting a goal, but Maven is a Java application and the plugin runs it as a Java application. It's quite straightforward. It doesn't screw around with Maven's run environment like the J2EE WTP plugin does with Tomcat.

The same, incidentally, is also true with Ant. git isn't a Java app, and I have found it a bit confusing at times, but then I find often git more than a bit confusing IDE or not.

Maven, in turn loves Eclipse. You can make a Maven project into an eclipse project just by running the command "mvn eclipse:eclipse" and then instructing Eclipse to add it to a workspace. If you're an IntelliJ fan, there's a goal for that as well.
4 days ago

Knute Snortum wrote:

Stephan van Hulst wrote:I found that Eclipse has such poor Maven support.


Even with the M2E plugin?


I'm puzzled about this assertion as well. I work with M2E all the time and it suits me. It even can look into the Maven cache for source code.
4 days ago

Rob Spoor wrote:You can also configure Apache to proxy to Tomcat, using mod_proxy_http or mod_proxy_ajp.



Or mod_jk, although I prefer mod_proxy myself.

Actually, it's really not a good idea to have clients directly accessing Tomcat itself anyway. Tomcat's default http port is 8080, and that requires explicit notation in client URLs - DNS only resolves IP addresses, not port numbers and the universal default port (well-known port) for http is 80, just as the well-known port for https is 443.

Nor is it a good idea to run Tomcat listening to port 80. Even if you don't have something like Apache already usurping id, port numbers lower than 4096 can only be opened by processes with administrator/root privileges, which means that if someone can access Tomcat directly via port 80 and manages to exploit the server, the entire JVM is available for exploit. Servers such as Apache and Nginx have mechanisms that keep them safe, but such mechanisms are not available to Java, since they're OS-specific.
4 days ago
BTW, a commentary on two items of the Agile Manifesto that I found notables:

Agile Manifesto wrote:
Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.



1. I don't really agree with "daily", since a lot of what I do can take more than one day to fully realize. "Often" works better for me.

2. I think it's pretty clear from what you've said that Management (implied here, since it says "give") isn't giving you the environment and support you need, isn't keeping you motivated, and definitely doesn't seem to trust you.

It's been said more than once that in software development, the challenge for Developer Management is usually less about motivating people than it is about not de-motivating them. Software professionals can usually motivate themselves or else they simply drop out of the field altogether. It's not the kind of a career that many of us can simply take or leave.

Well you cannot instantiate a COM interface, only discover it. The Java equivalent (more or less) is the Factory design pattern. When you're explicitly constructing something, you generally have requirements in mind beyond the interface itself. To take an example near and dear to my own heart, I recommend that people developing JavaServer Faces webapps back their table Views with a JSF DataModel object (which adds context to the underlying raw data). DataModel is an Interface, but it's implemented by many classes. For example, there's an ArrayListModel if you're fronting a simple array of rows, A ListDataModel if you're fronting an object that implements the java.util.List interface (which in turn can be an array, linked list, Stack, Vector, etc., a ScalarDataModel (never actually used this one), and so forth.

One of the key benefits of Java is that well-designed Java components have been run through the JavaDoc utility and therefore you have a reference. And one of the items that JavaDoc generates is the "Implemented by" line that shows what classes a given Interface implements (and hyperlinks to their documentation). It's not a cure-all, since it cannot discover classes that weren't fed to the JavaDoc utility, but it's very helpful.
4 days ago
Well it, is Management's fault when it's used to destroy morale. Agile is supposed to be a positive force and a guide, not a bludgeon. The Agile Manifesto makes this abundantly clear. No overpriced tools, no overpriced consultants, just a commitment to quality by realizing that it's better to release a product in imperfect stages with feedback than to delay results forever, then deliver something that people will despise the first time they use it. Agile is at heart a philosophy, not a product.

Speaking of the Manifesto, as I recall it neither mentions Scrum nor "lean" - which locally at least has no direct bearing on whether you're using Agile or even developing software and is in fact simply Management's trademark for making too few people do too many things and you'd bloody well like it or else. There's more than one way for Management to be abusive, after all.

Another thing not part of the Manifesto is not documenting things. Documentation to me is critical regardless of the methodology used. I would consider it essential to Agile because if you're going to have what is effectively a fluid contract between users and developers, that contract had better well exist in concrete form and be maintained as the process shapes itself. It's both protection against abuse and a reminder of what the goals and priorities are.

Is everybody in your area abusing Agile this badly, or is this just one really bad Dilbert company that's traumatized you?
I really can't say for certain relative to your location. In the USA, you wouldn't be considered as "entry level" if you'd worked more than 2 years full-time and part-time really isn't an option at that level. And they'd be expecting you to be constantly improving yourself. The idea of a "temporary career" in IT doesn't fly well. I've had people whine at me just for applying for jobs that I was over-qualified for because they didn't want to consider someone who might leave the first time that I got a better option. Ironic considering the lack of loyalty that companies have these days, but that's how it goes.

Traditionally you'd have a better chance part-time as a computer operator. A lot of programmers worked hanging tapes, loading printers and doing other stuff in the data center while putting themselves through school so that they could then become junior programmers. But that's another option mostly destroyed since these days the data center is likely to be an Amazon cloud or something.
5 days ago