FRIHOST FORUMS SEARCH FAQ TOS BLOGS COMPETITIONS
You are invited to Log in or Register a free Frihost Account!


I hate Java but I have a question





davidv
Does Java have an API similar to Python's string module?

http://docs.python.org/library/string.html
Fire Boar
The Apache Commons Lang package is a must for any large-ish project. It provides many helpful APIs including a StringUtils library which contains many static methods for working with the String class.
davidv
I've downloaded the .jar file however I'm having a bit of trouble installing it, help? Confused
jcreus
davidv wrote:
I've downloaded the .jar file however I'm having a bit of trouble installing it, help? Confused

If using eclipse:
- Project > Properties > Java Build Path > Libraries > Add External JARs.

Then point to the downloaded JARfile.

Everything should by fine then.
davidv
jcreus wrote:
davidv wrote:
I've downloaded the .jar file however I'm having a bit of trouble installing it, help? Confused

If using eclipse:
- Project > Properties > Java Build Path > Libraries > Add External JARs.

Then point to the downloaded JARfile.

Everything should by fine then.


Oh wow, sorry I didn't realize until now that there was an additional response to this thread. I don't use IDEs. Just plain ol' unarguably awesome vim Smile
Fire Boar
In that case, use the -classpath option when invoking javac to add the commons-lang-x.y.jar file. For example, suppose your directory structure looks like this:

Code:
bin/                     # Target for your compiled .class files.
lib/
lib/commons-lang-2.6.jar
src/                     # Root of your source package, containing all your .java files.
src/Main.java            # Java file containing your main() method, say.


Then you can compile like this:

Code:
javac -classpath lib/* -sourcepath src -d bin src/Main.java


You may want to put that in a Makefile or something, so you can just shorten that to

Code:
make
saberlivre
Why do you hate Java? Laughing
inuyasha
saberlivre wrote:
Why do you hate Java? Laughing

I suppose the topic starter thought Java is just too wordy~ Laughing
davidv
inuyasha wrote:
saberlivre wrote:
Why do you hate Java? Laughing

I suppose the topic starter thought Java is just too wordy~ Laughing


Haha yes. It's an ugly verbose language. Also, the generics is fake. That said, it's a great OO language.
jcreus
davidv wrote:
inuyasha wrote:
saberlivre wrote:
Why do you hate Java? Laughing

I suppose the topic starter thought Java is just too wordy~ Laughing


Haha yes. It's an ugly verbose language. Also, the generics is fake. That said, it's a great OO language.

Maybe it could be a nice language, IMHO, but the problem is that Python exists. And it beats it all!

EDIT: Frihost seems to have a problem when adding tags that have been closed?
Fire Boar
While we're on the topic of Java pros and cons, I do think that Java's verbosity makes it easy to understand the code written for it. I'd much rather explicitly define types and know exactly what each function/method is expecting than wait for the inevitable runtime error.

The single biggest problem with Java in my opinion is the complete lack of overloaded operators. There's no way to write a class that knows what to do when someone tries to add two objects of said class together, for instance. Or, perhaps more usefully, x == y is generally much nicer than x.equals(y), yet the former can only be used on non-primitives to check if x and y reference the exact same object, which is often not very helpful, particularly for immutable objects. To give an example of this, I present the classic bug that every Java programmer will encounter in their code at some point or another: that the check "x" == "x" returns false.
Peterssidan
Fire Boar, there are cases when you want to check if two variables reference the same object so if you could overload operator== there need to be another way to check that. Java makes big difference between primitive types and user defined types. You can't create methods that works for both so there is no functional need to allow overloaded operators. It would make the use of some classes, like BigInteger, much nicer though.
davidv
Comparators used with objects and primitives isn't really something that I've ever had problems with. You get a sense of when to use == and .equals() when comparing objects after a while and it becomes second nature.

What you can never get use to is shit like this:

Code:
public class TwoThreeTree<K extends Comparable<? super K>, V> implements TwoThreeDictionary<K,V>


or worse when you have to pass generic objects holding more generic objects along with specifying a return type and access type. Method signature just becomes an ugly mess. I think I once had to pass in 3 objects of type ThreeNode<Entry<K,V>> x and then a collection LinkedList<ThreeNode<Entry<K,V>>> y and then something else, I don't quite recall but man was that hideous.
Fire Boar
Peterssidan wrote:
Fire Boar, there are cases when you want to check if two variables reference the same object so if you could overload operator== there need to be another way to check that. Java makes big difference between primitive types and user defined types. You can't create methods that works for both so there is no functional need to allow overloaded operators. It would make the use of some classes, like BigInteger, much nicer though.


True, but for immutables, there is pretty much no reason you would ever want to do that. Immutable classes include, for instance, BigInteger, String, Rectangle, etc... basically anything that can't be modified after creation. However, Java also has no "immutable" keyword or similar, only "final" properties which are similar but a bit different in that they can refer to mutable objects. So mutability really depends on the design of your class. And if you design a class to be immutable, surely one should at least have the option of redefining == to mean "the state of these objects is the same".

EDIT: If you really want the behaviour of == without actually using the object's own ==, how about this:

Code:
public boolean isSameAs(Object other)
{
  return System.identityHashCode(this) == System.identityHashCode(other);
}
davidv
Fire Boar wrote:
Peterssidan wrote:
Fire Boar, there are cases when you want to check if two variables reference the same object so if you could overload operator== there need to be another way to check that. Java makes big difference between primitive types and user defined types. You can't create methods that works for both so there is no functional need to allow overloaded operators. It would make the use of some classes, like BigInteger, much nicer though.


True, but for immutables, there is pretty much no reason you would ever want to do that. Immutable classes include, for instance, BigInteger, String, Rectangle, etc... basically anything that can't be modified after creation. However, Java also has no "immutable" keyword or similar, only "final" properties which are similar but a bit different in that they can refer to mutable objects. So mutability really depends on the design of your class. And if you design a class to be immutable, surely one should at least have the option of redefining == to mean "the state of these objects is the same".

EDIT: If you really want the behaviour of == without actually using the object's own ==, how about this:

Code:
public boolean isSameAs(Object other)
{
  return System.identityHashCode(this) == System.identityHashCode(other);
}


After some thought, I'm going to have to agree with Fire boar. I can't think of a reason why you would want to compare two variables that point to an immutable object. It can never change and thus .equals() is enough.
Fire Boar
I think it's like how when comparing numbers, you're interested in "is 3 equal to 3" and not "are this 3 and this other 3 the same object". Immutables share this "only the state matters" property.

While we're on the subject of immutable objects (wow, this did deviate a bit from the original post!) it's interesting that most immutable objects actually do change internally during their lifetime. Specifically, caching a hash code. Hash codes are typically a little expensive to compute, so it's generally more efficient to keep a variable to store the hash code, then set it when you compute the hash code for the first time.
Related topics
Java download question
Where to find Java Scripts
I need a php upload script, NEEDED BADLY
Java Has Failed!
HTML/Java Question
Whos is the FUTURE.... JAVA or .NET
.NET or JAVA
is taking bachelor of science in Computer Science hard?
N00b Java Question
Java Support
java help
aatiis
java question
Recursive functions in java
Reply to topic    Frihost Forum Index -> Scripting -> Others

FRIHOST HOME | FAQ | TOS | ABOUT US | CONTACT US | SITE MAP
© 2005-2011 Frihost, forums powered by phpBB.