Win a copy of Spring Boot in Practice this week in the Spring forum!

Guido Sautter

Ranch Hand
+ Follow
since Dec 22, 2004
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
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Guido Sautter

Hi Campbell,

you probably mean "bonne chance" ... "merde" means something you might be tempted to say if things go finally wrong ... like "m***** f***in' shit"
13 years ago
Using the System.setOut() and System.setErr() methods does not do any harm at all. In fact, that's sort of the way Eclipse get the output of a program started via its Run button into its own console window ... you can even temporarily change the System.out and System.err streams, store references to the original ones in some variables and change them back to original again later. This is somewhat useful for sending, say, the console output of a specific method to some file, while not sending there the output of the whole program.
13 years ago
The JarFile class is pretty useful, yes, but only once you got a File object pointing to the jar file ... The problem in your task is to get the addresses of the jar files on the class path ... or did you find a way of doing this?
13 years ago
Hi Todd,

what just came to my mind: For finding at least the jar files on the class path, you might use ClassLoader.getResources("MANIFEST.MF"), which returns an Enumeration of URL objects. In particular, this should give you the URLs of all the manifest files in any of the jars, which you can use to parse the jars' URLs from, then use the ZipInputStream/ZipEntry technique.

Forget about it, you'll need the manifest's full name, including the path, which, in turn, includes the jar's path ... stupid me

Hope that helps,
Guido
[ September 23, 2008: Message edited by: Guido Sautter ]
13 years ago
Hi Thomas,

didn't know about the Package.getPackages() method, but a look a the JavaDocs reveils that a Package has no method for obtaining the classes is contains ...

So I guess Packages are of little use here, other than trying all the package names available with a simple class name appended. But this would be pretty exhaustive ...
13 years ago
System.getProperty("os.name") will tell you which OS your're dealing with, so you can implement both ways and the choose the appropriate one at runtime.
13 years ago
Eclipse is probably indexing the fully qualified names of all the classes on a project's class path by their short names ... I hardly guess you want to do something similar, for going through all the jars is pretty much of an effort to achieve what you intend to do ...

If you want to do it, however, keep in mind that jar files a nothing but zip files containing class entries. So for listing the classes in a given jar, take a look at the ZipInputStream and ZipEntry classes, and try listing the content of a given jar file. A look at the list might give you a hint how to achieve your goal.
13 years ago
How about a custom ClassLoader, which reads the new jar and invokes defineClass() again with the new byte code? Check out the following custom ClassLoader from the GATE NLP framework:
13 years ago
I'll have to test this particular one, but have generally pretty bad experiance with leading '.*' parts in regular expressions ... therefore, I've found it better to make them reluctant ...
13 years ago

Originally posted by Henry Wong:
The matches method matches the whole string -- it doesn't do partial matches like "string contains xxx". To do that, either use the find() method, or modify the regex to match around what you are looking for like... string.matches(".*\\w+.*").

Henry



You actually need string.matches(".*?\\w+.*"), the other won't work. In general, it's a good idea to make leading "match-all" parts reluctant, for otherwise they might match some part of your input you're aiming at with some later part ...
13 years ago
Try out printing the value of i within the loop with both variants, ad see what you get ... Hint:
- i++ is a post-increment
- ++i is a pre-increment
13 years ago
Hi 'bappa',

please read the JavaRanch naming policy, which specifies that your display name has to consist of a full first name and last name. Take a second to change your display name accordingly.

In addition, just asking for code to solve a problem described in text form is not the way JavaRanch works, especially if it clearly sounds like a homework assignment. (a) JavaRanch is not a code mill, and (b) do your own homework. People are out here to give you hints on how to solve problems, or to fix bugs in code you've written.

For your particular problem, try a for loop and the String.length() method.

All the best,
Guido
13 years ago
Hi Rob,

Originally posted by Rob Prime:

And Calendar.SUNDAY = 1

It doesn't really matter what value you give them; you could start at 481 if you like. That's what you are naming them for.

I'd start at 1 in this case.



surely vou can sart at 481, but then you would have to do adjustment computations in order to use the constants as array indices ... that's why I proposed starting with Card.ACE = 0 ... Otherwise, you'd hav to subtract Card.ACE all the time, and still asume that the card rank constants are subsequent, distinct integers of which Card.ACE is the smalest ...
13 years ago
Hi Chris,

a more general way of doing this would be to group the cards by rank. I assume that you have constants for the ranks, like Card.ACE = 0, Card.TWO = 1, Card.THREE = 2, ..., Card.KING = 12. I know the numbers are a little un-intuitive, but it's the (zero-based) way Java is, just as with Calendar.JANUARY = 0 ... Now let's group the cards:
13 years ago
Maybe it's not real Java, but is there another way? If there is none, it's maybe not real Java, but the only way to achieve the goal at all ...
13 years ago