We Keep Coding

Why arraycopy() does not obey the lowerCamelCase convention? [duplicate]

While studying the standard Java library and its classes, i couldn't help noticing that some of those classes have methods that, in my opinion, have next to no relevance to those classes' cause.
The methods i'm talking about are, for example, Integer#getInteger, which retrieves a value of some "system property", or System#arraycopy, whose purpose is well-defined by its name.
Still, both of these methods seem kinda out of place, especially the first one, which for some reason binds working with system resources to a primitive type wrapper class.
From my current point of view, such method placement policy looks like a violation of a fundamental OOP design principle: that each class must be dedicated to solving its particular set of problems and not turn itself into a Swiss army knife.
But since i don't think that Java designers are idiots, i assume that there's some logic behind a decision to place those methods right where they are. So i'd be grateful if someone could explain what that logic really is.
Thanks!
Update
A few people have hinted at the fact that Java does have its illogical things that are simply remnants of a turbulent past. I reformulate my question then: why is Java so unwilling to mark its architectural flaws as deprecated, since it's not like that the existing deprecated features are likely to be discontinued in any observable future, and making things deprecated really helps refraining from using them in newly created code?

This is a good thing to wonder about. I know about more recent features (such as generics, lambda's etc) there are several blogs and posts on mailing lists that explain the choices made by the library makers. These are very interesting to read.
In your case I expect the answer isn't too exiting. The reason they were made is hard to tell. But both classes exist since JDK1.0. In those days the quality of programming in general (and also Java and OO in particular) was perhaps lower (meaning there were fewer common practices, library makers had to invent many paradigms themselves). Also there were other constraints in those times, such as Object creation being expensive.
Many of those awkwardly designed methods and classes now have a better alternative. (See Date and the package java.time)
The arraycopy you would expect to be added to the Arrays class, but unfortunately it is not there.
Ideally the original method would be deprecated for a while and then removed. Many libraries follow this strategy. Java however is very conservative about this and only deprecates things that really should not be used (such as Thread.stop(). I don't think a method has ever been removed in Java due to deprecation. This means it is fairly easy to upgrade your software to a newer version of Java, but it comes at the cost of leaving some clutter in the libraries.
The fact that java is so conservative about keeping the new JDK/JRE versions compatible with older source code and binaries is loved and hated. For your hobby project, or a small actively developed project upgrading to a new JVM that removes deprecated functions after a few years is not too difficult. But don't forget that many projects are not actively developed or the developers have a hard time making changes securely, for instance because they lack a proper regression test. In these projects changes in APIs cost a lot of time to comply to, and run the risk of introducing bugs.
Also libraries often try to support older versions of Java as well as newer version, they will have a problem doing so when methods have been deleted.

The Integer-example is probably just a design decision. If you want to implicitly interpret a property as Integer use java.lang.Integer. Otherwise you would have to provide a getter method for each java.lang-Type. Something like:
System.getPropertyAsBoolean(String)
System.getPropertyAsByte(String)
System.getPropertyAsInteger(String)
...
And for each data type, you'd require one additional method for the default:
- System.getPropertyAsBoolean(String, boolean)
- System.getPropertyAsByte(String, byte)
...
Since java.lang-Types already have some cast abilities (Integer.valueOf(String)), I am not too surprised to find a getProperty method here. Convenience in trade for breaking principles a tiny bit.
For the System.arraycopy, I guess it is an operation that depends on the operating system. You probably copy memory from one location to another in a very efficient way. If I would want to copy an array like that, I'd look for it in java.lang.System

"I assume that there's some logic behind a decision to place those
methods right where they are."
While that is often true, I have found that when somethings off, this assumption is typically where you are mislead.
A language is in constant development, from the day someone proposes a new language to the day it is antiquated. In between those extremes are some phases that the language, go through. Especially if someone is spending money on it and wants people to use it, a very peculiar phase often occurs, just before or after the first release:
The "we need this to work yesterday" phase.
This is where stuff like this happens, you have an almost complete language, but the programmers need to do something to to show what the language can do, or a specific application needs a feature that was not designed into the language.
So where do we add this feature?
- well, where it makes most sense to that particular programmer who's task it is to "make it work yesterday".
The logic may be that, this is where the function makes the most sense, since it doesn't belong anywhere else, and it doesn't deserve a class of its own. It could also be something like: so far, we have never done an array copy, without using system.. lets put arraycopy in there, and save everyone an extra include..
in the next generation of the language, people will not move the feature, since some experienced programmers will complain. So the feature may be duplicated, and found in a place where it makes more sense.
much later, it will be marked as deprecated, and deleted, if anyone cares to clean it up..

C/C++ exposure of functions / methods vs Java

The world of Minecraft Modding has made me curious about differences in mechanisms between Java and C/C++ libraries to allow methods / functions in the libraries to be invoked externally.
My understanding is that Minecraft Modding came about due to the ability to decompile / reflect over Java in order to reverse engineer classes and methods that can be invoked from the library. I believe that the Java class specification includes quite a lot of metadata about the structure of classes allowing code to be used in ways other than intended.
There are some obfuscation tools around that try to make it harder to reverse engineer Java but overall it seems to be quite difficult to prevent.
I don't have the depth of knowledge in C/C++ to know to what degree the same can be done there.
For C/C++ code is compiled natively ahead of time. The end result is an assembly of machine code specific for that platform. C/C++ has the notion of externalising functions so that they can be exposed from outside the library or executable. Some libraries also have an entry point.
Typically when connecting to external functions there is a header file to list what functions are available to code against from the library.
I would assume there would need to be a mechanism to map an exposed function to the address within the library / executable machine code assembly so the function calls get made in the right place.
Typically connecting the function calls together with the address is the job of the linker. The linker still needs to somehow know where to find these functions.
This makes me wonder if it is fundamentally possible to invoke non exported functions. If so would this require the ability to locate their address and understand their parameter format?
function calls in C/C++ as I understand it is typically done by assigning the parameters to registers for simple functions or to an argument array for more complex functions.
I don't know if the practice of invoking non-public API's in native code is common
or if the inherent difficulty in doing so makes native code pretty safe from this kind of use.

First of all, there are tools (of varying quality and capabilities) to reverse engineer compiled machine-code back to the original language [or another language, for that matter]. The biggest problem when doing this is that languages such as C and C++, the names of members in a structure don't have names, and often become "flat", so what is originally:
struct user
{
std::string name;
int age;
int score;
};
will become:
struct s0
{
char *f0;
char *f1;
int f2;
int f3;
};
[Note of course that std::string may be implemented in a dozen different ways, and the "two pointers" is just one plausible variant]
Of course, if there is a header file describing how the library works, you can use the data structures in that to get better type information. Likewise, if there is debug information in the file, it can be used to form data structures and variable names in a much better way. But someone who wants to keep these things private will (most often) not ship the code with debug symbols, and only publish the actual necessary parts to call the public functionality.
But if you understand how these are used [or read some code that for example displayed a "user", you can figure out what is the name, the age and what is the score.
Understanding what is an array and what is separate fields can also be difficult. Which is it:
struct
{
int x, y, z;
};
or
int arr[3];
Several years ago, I started on a patience card game (Similar to "Solitaire"). To do that, I needed a way to display cards on the screen. So I thought "well, there's one for the existing Solitaire on Windows, I bet I can figure out how to use that", and indeed, I did. I could draw the Queen of Clubs or Two of Spades, as I wished. I never finished the actual game-play part, but I certainly managed to load the card-drawing functionality from a non-public shared library. Not rocket science by any means (there are people who do this for commercial games with thousands of functions and really complex data structures - this had two or three functions that you needed to call), but I didn't spend much time on it either, a couple of hours if I remember right, from coming up with the idea to having something that "works".
But for the second part of your question, plugin-interfaces (such as filter plugins to Photoshop, or transitions in video editors), are very often implemented as "shared libraries" (aka "dynamic link libraries", DLLs).
There are functions in the OS to load a shared library into memory, and to query for functions by their name. The interface of these functions is (typically) pre-defined, so a function pointer prototype in a header-file can be used to form the actual call.
As long as the compiler for the shared library and the application code are using the the same ABI (application binary interface), all should work out when it comes to how arguments are passed from the caller to the function - it's not like the compiler just randomly uses whatever register it fancies, the parameters are passed in a well-defined order and which register is used for what is defined by the ABI specification for a given processor architecture. [It gets further more complicated if you have to know the contents of data structures, and there are different versions of such structures - say for example someone has a std::string that contains two pointers (start and end), and for whatever reason, the design is changed to be one pointer and a length - both the application code and the shared library need to be compiled with the same version of std::string, or bad things will happen!]
Non-public API functions CAN be called, but they wouldn't be discoverable by calling the query for finding a function by name - you'd have to figure out some other way - for example by knowing that "this function is 132 bytes on from the function XYZ", and of course, you wouldn't have the function prototype either.
There is of course the added complication where Java Bytecode is portable for many different processor architectures, machine code only works on a defined set of processors - code for x86 works on Intel and AMD processors (and maybe a few others), code for ARM processors work in chips developed with the ARM instruction set, and so on. You have to compile the C or C++ code for the given process.

How to use Deelang conditionals with operators?

Am making a simple game (another one that will probably never be published) in libGdx and I want to evaluate 'events' for the game characters. Each event should have a 'condition' block and an 'execute' block, that executes if the 'condition' returns true. The language has to support order of operations as well as the following logical operators or their equivalents;
==
!=
<=
>=
||
&&
I also need to be able to pass instances of various objects to the script, so that I might access variables and call methods similar to this;
if(game.hasFlag("here_be_my_flag")) then
game.alertAllPlayers("Here be my flag!");
Where game is the instance of class Game of my game and hasFlag and alertAllPlayers are methods of game implemented in java.
The problem comes when I need two dozen scripts evaluating for each "character" (between 100 and 500) in the game. It was quite simple to set Mozilla's Rhinoscript Javascript interpreter up for this, but this slows my FPS down from 50 to the 25 to 30 range, an unacceptable loss of performance. This is because Rhino was designed to run on an actual JVM, something Android lacks. Android instead runs on a DVM which executes bytecode in a different format from JVM bytecode. Rhino can compile to Java bytecode, but not Dalvik.
This problem is present in many of the different languages. Most were designed to work on desktop computers. I stumbled upon Deelang, a small scripting language that compiles into Dalvik bytecode. Deelang has good performance relative to Rhino on Android devices.
Unfortunately, it seems that most languages with good documentation do not have this ability and are bound to be slower than those that do (there are probably exceptions). So, I looked at the two basic examples of Deelang code on Github and there is absolutely nothing on boolean comparisons. I learned of Deelang while reading a few questions on scripting languages in java. There is little to no documentation on the Github Wiki regarding this, so, does anyone with experience in this minilanguage know anything regarding the use of operators and conditionals?
Note that I have poked around in the code for comments that might possible give me an idea as to how to do this.

Is Java.awt.geom suitable for discrete calculations?

The package java.awt.geom allows testing if a point lies within a rectangle and similar questions. In particular I need to know if a rectangle is intersected by a line. All involved values are integers.
However, it appears we cannot have those calculations use integers instead of floating point. As I need a completely consistent and reproducible result (its factual accuracy is not as important, actually), I am worried this might be a bad approach. The program will be deployed on Windows, Linux and Android platform, and I do not have full control over the machines.
I have implemented the required algorithm myself (using pure integer arithmetic), and it suffices all my needs. Yet, if possible, I would like to use the preprovided package. Is there some sort of guarantee on its consistency?

Yet, if possible, I would like to use the preprovided package.
It is unlikely the J2SE classes will be available in Android, so stick with your own custom rolled solution.

Do calculus in java

I am trying to implement a neural network in java (small one) and I'm using back propogation for the learning algorithm. This requires to find general derivatives. How do I find general derivatives in java?

Try Helmut Dersch's Jasymca 2 http://webuser.hs-furtwangen.de/~dersch/jasymca2/. It's a Java API providing GNU Octave/Matlab-like capabilities. It includes symbolic math.
Jasymca has been recently worked on. The documentation is from March 2009 and it requires Java 1.5+.
CAVEAT: Jasymca is GPL so consult a lawyer before using it in a commercial product.

Depends on whether you have continuous or discrete data. I'm guessing that you have discrete data, since we're talking about neural nets.
Finite differences are one way to approximate derivatives. Another approach might be to do a fit of some kind and differentiate the fitting function, assuming that it's a well-known function with an easy-to-calculate derivative (e.g., polynomials).
How many independent variables for your data? Functions of one variable are easy; two or more are harder because you need partial derivatives.

You should try to hardcode it
double derivative = (f(x+h) - f(x-h)) / (2*h);

I'm pretty certain java does not have built in library for calculus functionality. However, it could range anywhere from trivial to quite challenging to implement differentiation by yourself.
If you already have the ability to store and analyze functions, then getting derivatives is as simple as programming the (quite limited) number of differentiation rules.
However if you are looking at differentiation based on DATAsets (not abstract functions), then you can use various approximation techniques, such as simpsons rule.

If you can make HTTP requests to the world wide web, you can create a SaturnAPI integration script.
Disclosure: I worked on SaturnAPI

If it comes to java, look at the DMelt math program. It free. In the manual, you can find how to take the derivations.

Okay, if you are doing neural networks most likely you will NOT need to take just a general derivative of some arbitrary function. Which is what you would need a general Calculus library for. Backprop requires you to use the derivative of your activation function. USUALLY, your activation function is going to be the sigmoid function or the hyperbolic tan function. Both of which you can just get the derivative of from Wikipedia and simply provide that function to your neural network training. You do not need to actually solve the derivative each time.
There are other common activation functions, but there is really only a handful that is actually used. Just look up the derivative and make use of which one you want. Most neural network frameworks just build the regular activation function and derivative into some sort of a base class you use. Here are some of the most common ones:
https://web.archive.org/web/20101105231126/http://www.heatonresearch.com/online/programming-neural-networks-encog-java/chapter-3/page2.html