Chris Janicki

Greenhorn
+ Follow
since Aug 30, 2006
Chris likes ...
Mac OS X Netbeans IDE Tomcat Server
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Janicki

Ritchie, thanks for the critical eye!  I edited my post to remove the controversial parts.  Apparently I was wrong about the floating point representation... I had just looked it up on a generic (non-Java) site, and/or maybe I misunderstood something too.  Casting to int may still be trivial for the JVM (masking/shifting some number of bits in the mantissa?), but I don't know that yet.  And regarding the cast being "native" I should review/quote the Java Specification for clarity on that.  My thought/assumption was that cast is(?) implemented by the JVM--not hardware or the operating system--and therefore you could rely on its consistent operation to "chop off" fractional parts, like Math.floor().

I still prefer to avoid functions calls whenever possible.  My "mission-critical" (24x7x365) commercial app runs sometimes 10x faster than competitors that dive deep into frameworks and functions, and I don't think I've ever had a "gotcha" bug due to using low(er)-level code.  And even it there was an occasional bug to squash, it would be worth it, to me.  But that doesn't pertain to the original question, so I removed that part too, and we can quietly disagree on the pros/cons.  ;-)
1 year ago
I think Phoebe was right on target regarding the intent of the exercise (not to cover extreme conditions), and her approaches.  The test function can be simply:  For extra credit, Marvin might print some "try again" message if any parameter is too big/small.

I prefer the (int) cast over Math.floor() mentioned previously for two reasons: 1) A floating point number is stores the integer part separately from the fractional part, so the casting is a trivial operation for the JVM; and 2) any function call is going to run slower in comparison, so it's always(?) best to avoid functions/methods when you have native alternatives.  Also, the sign is preserved in the cast, so that's not a concern that needs to be tested separately.

Regarding Marvin's attempt to convert the numbers to strings, that would have worked fine (although less efficiently), but he assumed that the strings would always contain a decimal point.  He just needed to code for the possibility that indexOf(".") would find nothing, returning -1.  He may have been unaware that passing the parameter 0.0 is still just zero, so it will convert to the string "0" with no decimal point to be found.  And 1.0 is just "1", etc.
1 year ago
Old thread, but just for the record: It's not really fair to compare skipping with DataInputStream vs. RandomAccessFile.  The RandomAccessFile has knowledge of it's underlying stream... It knows it's talking to a filesystem, so it can take the shortcut of doing a "seek" with the underlying filesystem API.  FileInputStream's skip() has the same advantage.  However, DataInputStream, and any other general-purpose input streams, don't know that their source is a file, so they can't take any low-level shortcuts. Their only way to implement skip() is to read the bytes, which is certainly slower that telling a filesystem to "seek" to a new file position.
7 years ago
Late reply, but I ran into the same problem, so hopefully this will clarify the issue for other readers... The Attributes.get() method takes a constant object argument: an instance of the inner "Attributes.Name" class, not a String.  The Attributes.getValue() alternative takes a String, as you discovered.  So for example:


7 years ago
Yes, that's basically it. Note that the file descriptor is a resource in the operating system, not Java. Calling close() on the BufferedReader releases it. (More precisely, the close() call bubbles all the way up to your FileInputStream, which then tells the O/S to release the descriptor)

In all versions of Java, your orphaned BufferedReader object instances (and the associated hierarchy of I/O classes you instantiated, all the way up to FileInputStream) will eventually be garbage collected. But only the latest versions of Java automatically call close() for you during the garbage collection. I think that feature appears in Java 7. But regardless, the garbage collector only runs every so often. So even if the garbage collector does close things for you, your loop still might quickly use up all the descriptors before garbage collection starts. The best practice is to explicitly call close(). Even if programmers can start getting "lazy" with Java 7, you'll still need to be wary of files opened quickly in loops of unlimited size.

Note that the same goes for opening/closing sockets… the same pool of file descriptors are used for those.
11 years ago
Yes, you need to close it each time. Sure, the old BufferedReader objects may eventually get garbage collected (which may automatically close them in some recent version of java, I think?) , but until they are closed, they hold "file descriptors" on your operating system. On Unix at least, each user id only gets to open 1024 (varies per system), then no more files can be opened. If your list.size() > 1024, then the tight for-loop may open all the descriptors before any are reclaimed, and your app will fail with an exception (sometimes with a rather unclear explanatory text).
11 years ago
I'm not sure what's wrong, but you might try adding the 'v' (verbose) option to the command line to see if anything useful is printed.

Also, my hunch at why unzipping/re-jarring doesn't work is because of the manifest. Unless you include the 'm' option to include the old manifest, it would create a new manifest from scratch. That's not necessarily bad, but your original manifest may contain extra properties that your app needs, but a fresh jar doesn't include. (For example, executable jars add extra properties that the jar command-line tool wouldn't include on its own.) You might try comparing (diff'ing) the original and regenerated MANIFEST.MF files to see if there are indeed differences.
11 years ago
I believe the only way to control a browser that way is via javascript. The only alternative I can think of is to open a Java-based browser window (i.e. there are a few Swing-based widgets capable of rendering HTML), but they often have limited support for the latest HTML/Javascript/plug-ins. If you're controlling what's supposed to appear in the pop-up, that may be a way to go. If you're just showing something from a third-party web site, then that would be a fragile solution.
11 years ago
You need to read the exception. It says the error occurred in your code at line #91 of Client.java. You're doing an RMI lookup() there, and the thing you are looking up is not found. You probably have the wrong name for the remote object. Find out what name the remote object used when it registered itself, and verify that it actually does so.
11 years ago
Well, your client app has to call an RMI method on the server app. It looks like you've set up an add() method for that purpose. So after the client grabs the server reference (you've already done that), then call rmiServer.add(). Of course you still have some work to do… that add() method needs to be expanded to accept some parameters (the stuff you want to add), and the method signature line needs to throw RemoteException, since that's what your interface declares (and required for RMI methods).
11 years ago
That's such a generic question… You're best off just looking up each in wikipedia or elsewhere.
11 years ago
I think you'll have to maintain an index of which IDs belong to which hosts/IPs. You could manually create a properties file (see java.util.Properties). It would be fancier to have a centralized directory that was automatically updated (e.g. as users login), but I don't know if Windows already offers such services built-in. You could build a central directory system yourself, but that's a bigger client/server project.
I'm not too familiar with the HEAD request, but it looks like the web server is simply closing your socket, probably because it's not happy with your interaction. I found this example of a HEAD interaction… Notice that the client is sending more info than you are. My guess is that your target server times out waiting for that additional info.
Java 7 seems to add tools for links/shortcuts. See createLink() in the java.nio.file.Files class, new in Java 7. There's a short tutorial here: Dr. Dobbs
11 years ago
1. You didn't provide enough info to definitively respond.

2. Threads are funny things. They are not guaranteed to immediately start just because you call start(). You should search for some tutorials on "concurrency" in java for techniques to schedule/coordinate threads in a deterministic manner.
12 years ago