Clan x86
Technical (Development, Security, etc.) => General Programming => Topic started by: Hdx on May 24, 2006, 02:16:15 am
-
Well, does anyone have any clue how to get platform imforation with Java?
Basic information, Country, Operating system, Archatecture (CPU), and anything else.
My crappy first idea was simply checking the current directory, seeing if there was a drive letter, if not :P
Anyways, anyone got any ideas?
~-~(HDX)~-~
-
You can get a few things with System.getProperty(), but not everything you're after. See my Version Plugin (http://www.javaop.com/javaop2/src/Version/src/PluginMain.java) for JavaOp2:
String osName = System.getProperty("os.name");
String osArch = System.getProperty("os.arch");
String osVersion = System.getProperty("os.version");
There's also more, you can find them on Java's api page.
-
I like how the JDK is entirely object-oriented plus the System class. It's like the JDK creators were sitting around one night...
"Hey man, I've still got a bunch of functions to add, that don't really go anywhere else. I mean I could add them somewhere else."
"What do you mean?"
"Well, I guess the array copying function could go into an Array class. But we don't have one in the lang package, and you know that if we were to make one, they would want even more functionality from it than just 'copy.'"
"Yeah you're right."
"And the same thing goes for information about the execution environment, console I/O streams, and garbage collector. I mean, I'm sure we could implement classes for each of those. Or we could just stick them all in the System class."
"Yeah I think we go with that. Seems like a lot more fun. Then in fifteen years some self-righteous Microsoft fanboy can make fun of us for making such an apparrent design flaw!"
-
Incidentally, System is a class.
-
Incidentally, System is a class.
Yes, System is a class (which is why I said "plus the System class"), but it's not object-oriented. It's as I described, an amalgamation of methods and fields.
System.in, System.out, and the standard error field violate OOP because they're not encapsulated with a method. Suppose Java changes the stream implementation and needs to change them later. It can't do so without breaking code. At the very least they could have made a getter method, or even better, made a class that deals with standard I/O. Arguably, Java is littered with these kinds of issues; I just bring up System because it's more or less the bastard child of Java.
Functions that deal with garbage collection and runtime-loadable libraries should be in a class that deals with the execution environment. Java already has the Runtime class, which of course has a gc() method which I'm sure the System class's gc() is just a stub for.
It also has .arraycopy(), which should be part of an Array class rather than the System utility class.
There are a couple things that the System class is good to have for, but in principle, it violates OOP, *and* it violates the small-library-toolkit approach used by Unix.
-
Incidentally, System is a class.
Yes, System is a class (which is why I said "plus the System class"), but it's not object-oriented. It's as I described, an amalgamation of methods and fields.
System.in, System.out, and the standard error field violate OOP because they're not encapsulated with a method. Suppose Java changes the stream implementation and needs to change them later. It can't do so without breaking code. At the very least they could have made a getter method, or even better, made a class that deals with standard I/O. Arguably, Java is littered with these kinds of issues; I just bring up System because it's more or less the bastard child of Java.
Functions that deal with garbage collection and runtime-loadable libraries should be in a class that deals with the execution environment. Java already has the Runtime class, which of course has a gc() method which I'm sure the System class's gc() is just a stub for.
It also has .arraycopy(), which should be part of an Array class rather than the System utility class.
There are a couple things that the System class is good to have for, but in principle, it violates OOP, *and* it violates the small-library-toolkit approach used by Unix.
System.out and System.in return an abstract type. I'd prefer having them over System.getOutputStream().println(). System.out.println() is long enough.
System is designed for native methods. Those methods include the execution environment and arrayCopy(). The Array class is a normal class and can't have native methods (easily), but System has native methods. That's why arrayCopy() is in System.
-
Well, I got info from .getProperty()
And i've added a crapload to my game server. And then I decided a good way to store accounts was in a Hashtable.
But I haven't used those much and I get this warning when I compile:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type java.util.HashtableAnyone know how to stop this warning (besides ignoring it)
~-~(HDX)~-~
-
Well, I got info from .getProperty()
And i've added a crapload to my game server. And then I decided a good way to store accounts was in a Hashtable.
But I haven't used those much and I get this warning when I compile:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type java.util.HashtableAnyone know how to stop this warning (besides ignoring it)
~-~(HDX)~-~
If you're using Java 1.5, then you should use templates. Templates ensure that you don't have to worry about checking types or casting types. For example:
Hashtable <String, Integer> a = new Hashtable<String, Integer>();
a.put("one", 1);
a.put("two", 2);
Hashtable <String, String> b = new Hashtable<String, String>();
b.put("one", "1");
b.put("two", "2");
I'm pretty sure that's why you get the warning. Templates in Java are used (but not defined) the same way as C++, I think.
-
Thanks that was it, I was useing the type template (what ever you call them) when creating the hash table, just not when declairing it., so it wasnt working. But alls good now thanks man.
~-~(HDX)~-~