Develop Reference

Weka Experimenter mod : Problem creating experiment copy to run

In the experimenter mod in weka I have this configuration :
Results destination : Ex1_1.arff
Experiment type : cross-validation | number of folds : 10 | Classification
Dataset : soybean.arff.gz
Iteration Control : Number of repetitions : 10 | Data sets first
Algorithms : J48 -C 0.25 -M 2
This experience is saved as Ex1_1.xml (saving with .exp give the following error : Couldn't save experiment file : Ex1_1.exp Reason : java.awt.Component$AccessibleAWTComponent$AccessibleAWTComponentHandler)
And when I try to run this experience I have the following error : Problem creating experiment copy to run: java.awt.Component$AccessibleAWTComponent$AccessibleAWTComponentHandler
So it seem I have a problem with something like AWT in java... Do somebody have an idea ?
Thank you !

Modify core java libraries of Android source for use in apps

I want to make a little modification to the Android source to meet my requirement. Here is the requirement:
I want index all the objects in an Android app by adding one more public int field to the java.lang.Object class. Therefore, all the classes can inherit the newly added field because all of them are the subclasses of the Object class.
What I have done so far is modify the java.lang.Object class under <Android_source>/libcore/libart/src/main/java/java/lang folder and recompile the source.
I want to ask if I am doing the right thing. Can my Android app recognize this change (e.g. can a String object access the newly added field)?
Edit
After around 3 weeks try and error, I finally got the complete answer. I want to share this experience with others if anybody else want to modify the core java libraries of Android source (e.g., modifying Object.java and String.java etc.). Again, as mentioned by Michael, please note that such a modification may only be suitable for research or testing purpose.
The key challenge in making a successful modification (here 'successful' means the modified Android source can be built and run on emulators or real devices without any problem) is that some of the classes in the core java library have their C++ mirrors (located in <Android_source>/art/runtime/mirrors/). When modifying these java classes, you should also make the same modifications to their C++ mirrors. Otherwise, you could fail the build process because there are a bunch of checkings that you need to pass. Since I only add a new field to the Object.java, I will list some checkings (or requirements) I encountered below:
1.The size of an object instance = the size of its C++ mirror. For example, if I add a long field into Object.java, I should also add a uint64_t field to its C++ mirror to make their size equal.
2.Try to make the size of an object instance be the power of 2 (e.g., 2, 4, 8, 16, ...). For example, the size of the original Object.java is 8, therefore I add a long field to increase the size to 16. If I add an int field, the size becomes 12 and it can fail many checkings. I don't figure out the exact reason but I guess it has something to do with memory alignment.
3.Try to put primitive-type fields after non-primitive-type fields and primitive-type fields should be ordered by size. This means you should put reference-type fields in the front, followed by 8-byte-primitive-type fields, then 4-byte-primitive-type fields, then 2-byte-primitive-type fields, then 1-byte-primitive-type fields. Again, I guess the reason is memory alignment
That's all I done to meet my requirements. I am open to any discussions if you have any ideas about the purpose of these checkings (especially the 2ed and 3rd one)
New edit
More specifically, I did the following things:
Add a new field (e.g., public long tag;) in Object.java
Change static constexpr uint32_t kObjectHeaderSize = kUseBrooksReadBarrier ? 16 : 8; to static constexpr uint32_t kObjectHeaderSize = kUseBrooksReadBarrier ? 24 : 16; in Object.h
Add the following method in Object.h (Only on Android 7)
static MemberOffset TagOffset() {
return OFFSET_OF_OBJECT_MEMBER(Object, tag);
}
Add a new public field public: uint64_t tag; in Object.h
Change
#define MIRROR_OBJECT_CLASS_OFFSET 0
ADD_TEST_EQ(MIRROR_OBJECT_CLASS_OFFSET, art::mirror::Object::ClassOffset().Int32Value())
#define MIRROR_OBJECT_LOCK_WORD_OFFSET 4
ADD_TEST_EQ(MIRROR_OBJECT_LOCK_WORD_OFFSET, art::mirror::Object::MonitorOffset().Int32Value())
#if defined(USE_BROOKS_READ_BARRIER)
#define MIRROR_OBJECT_HEADER_SIZE 16
#else
#define MIRROR_OBJECT_HEADER_SIZE 8
to
#define MIRROR_OBJECT_CLASS_OFFSET 0
ADD_TEST_EQ(MIRROR_OBJECT_CLASS_OFFSET, art::mirror::Object::ClassOffset().Int32Value())
#define MIRROR_OBJECT_LOCK_WORD_OFFSET 4
ADD_TEST_EQ(MIRROR_OBJECT_LOCK_WORD_OFFSET, art::mirror::Object::MonitorOffset().Int32Value())
#define MIRROR_OBJECT_CLASS_TAG 8
ADD_TEST_EQ(MIRROR_OBJECT_CLASS_TAG, art::mirror::Object::TagOffset().Int32Value())
#if defined(USE_BROOKS_READ_BARRIER)
#define MIRROR_OBJECT_HEADER_SIZE 24
#else
#define MIRROR_OBJECT_HEADER_SIZE 16
in asm_support.h (Only on Android 7)
Add addOffset(OFFSETOF_MEMBER(mirror::Object, tag), "tag"); in class_linker_test.cc
Change
static_assert(kObjectHeaderSize == sizeof(mirror::HeapReference<mirror::Class>) +
sizeof(LockWord),
to
static_assert(kObjectHeaderSize == sizeof(mirror::HeapReference<mirror::Class>) +
sizeof(LockWord) + 8,
in art/runtime/gc/collector/concurrent_copying.cc
8 Change static constexpr size_t kFirstElementOffset = 12u; to static constexpr size_t kFirstElementOffset = 20u; in array.h
9 Change static constexpr size_t kObjectAlignmentShift = 3; to static constexpr size_t kObjectAlignmentShift = 4; in runtime_globals.h (Not done yet)
10 Change
static_assert(kObjectAlignment == 8, "Alignment check");
class PACKED(8) ImageHeader {
to
static_assert(kObjectAlignment == 16, "Alignment check");
class PACKED(16) ImageHeader {
in image.h (Not done yet)
11 Change static constexpr size_t kAlignment = 8; to static constexpr size_t kAlignment = 16; in gc::space::BumpPointerSpace (Not done yet)
12 Change #!/usr/bin/python to #!/usr/local/bin/python in device/generic/goldfish/tools/mk_combined_img.py (The value depends on your /bin/env python)(Only on Android 10)
13 Change
#define DCHECK_ALIGNED_PARAM(value, alignment) \
DCHECK(::art::IsAlignedParam(value, alignment)) << reinterpret_cast<const void*>(value)
to
#define DCHECK_ALIGNED_PARAM(value, alignment) \
DCHECK(::art::IsAlignedParam(value, alignment)) << reinterpret_cast<const void*>(value) << "," << alignment
in art/libartbase/base/bit_utils.h (for debug purpose)(Only for Android 11)
14 Change
DCHECK_ALIGNED_PARAM(remaining_space, object_class->GetObjectSize());
Object* end = dst + remaining_space / object_class->GetObjectSize();
to
DCHECK_ALIGNED_PARAM(remaining_space, kObjectAlignment);
Object* end = dst + remaining_space / kObjectAlignment;
in art/dex2oat/linker/image_writer.cc (Only for Android 11)
Change
memcpy(reinterpret_cast<uint8_t*>(to_ref) + kObjectHeaderSize,
reinterpret_cast<const uint8_t*>(from_ref) + kObjectHeaderSize,
obj_size - kObjectHeaderSize);
to
memcpy(reinterpret_cast<uint8_t*>(to_ref) + kObjectHeaderSize - 8,
reinterpret_cast<const uint8_t*>(from_ref) + kObjectHeaderSize - 8,
obj_size - kObjectHeaderSize + 8);
in concurrent_copying.cc (on Android 10)(reference)

Firstly, I'd like to state that I don't think this is a good idea and is probably overkill outside of research purposes. If you are modifying AOSP then the code you write will be dependent on the target device running that customised build of AOSP. However, it is still possible.
I'm assuming you already know how to compile and flash a custom AOSP build to a device. In order to write code that makes use of your new functionality, you'll also need to compile a custom SDK. This is so that Android Studio will know that your new method exists within Object, and can compile correctly against it. The full documentation can be found here, but essentially it boils down to:
. build/envsetup.sh
lunch sdk-eng
make sdk
When you have your SDK zip file, you'll need to unzip it to your SDK's platforms directory - it should now show up checked in your SDK manager. If you have given your SDK a custom platform ID then you should be able to use that in your build.gradle files.
Disclaimer: This advice is purely from memory, it's a lengthy process so I've not had time to double-check, and chances are there may be a couple of minor things I've missed. This should get you most of the way towards where you want to be though.

Value of IPC_CREAT when used in JNA

I need to communicate a java application and a c process via posix message queue, and I am using JNA in java application.
In C process, when create message queue I am using:
key_t key = 112233;
int msgflg = IPC_CREAT | 0666;
msqid = msgget(key, msgflg )
What is the value of IPC_CREAT to use in Java application?
I found in ipc.h :
/usr/include/sys/ipc.h:#define IPC_CREAT 0001000 /* create entry if key doesn't exist */
May I safety assume that I can use 512? (decimal) ?
Thanks.

I would suggest you use 950, because
final int IPC_CREAT = 0001000;
int msgflg = IPC_CREAT | 0666;
System.out.println(msgflg);
outputs
950
I may not understand your question, because
printf("%i\n", 0001000 | 0666);
also outputs
950
Edit
Yes.
final int IPC_CREAT = 0001000;
System.out.printf("%d%n", IPC_CREAT);
Output is 512. And,
printf("%i\n", 0001000);
Output is 512. So you could use decimal 512. Or the binary version like C.

BCrypt very slow in app engine application

I'm developing a GWT/app engine application, using Eclipse. The below problem occurred after upgrading to app engine 1.6.4 from 1.6.3. After the upgrade, I my application would not work at all. Unfortunately, I had deleted my old app engine plugins, so I was unable to rollback to 1.6.3. After 2 hours of banging my head against the wall, I decided to recreate my Eclipse project. The project worked again, except for the following anomaly:
I'm using BCrypt to implement one-way hash encoding of passwords. Before yesterday, this worked fine, with password encodes and checks occurring very fast -- probably in a few milliseconds. Now these operations take on the order of 2 minutes! Using the debugger, I paused the application to see if I could figure out what was going on. Each time I pause, I get a stack trace such as the following:
Thread [798744730#qtp-2080190228-3] (Suspended)
Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method]
Class<T>.forName(String) line: 186
RuntimeHelper.checkRestricted(boolean, String, String, String) line: 63
Runtime.checkRestricted(boolean, String, String, String) line: 63
BCrypt.encipher(int[], int) line: 496
BCrypt.key(byte[]) line: 558
BCrypt.crypt_raw(byte[], byte[], int) line: 622
BCrypt.hashpw(String, String) line: 681
BCrypt.checkpw(String, String) line: 749
BCrypt.encipher() is as follows: (line 496 is shown below in a line comment)
private final void encipher(int lr[], int off) {
int i, n, l = lr[off], r = lr[off + 1];
l ^= P[0];
for (i = 0; i <= BLOWFISH_NUM_ROUNDS - 2;) {
// Feistel substitution on left word
n = S[(l >> 24) & 0xff];
n += S[0x100 | ((l >> 16) & 0xff)];
n ^= S[0x200 | ((l >> 8) & 0xff)];
n += S[0x300 | (l & 0xff)];
r ^= n ^ P[++i]; //*** LINE 496 *****
// Feistel substitution on right word
n = S[(r >> 24) & 0xff];
n += S[0x100 | ((r >> 16) & 0xff)];
n ^= S[0x200 | ((r >> 8) & 0xff)];
n += S[0x300 | (r & 0xff)];
l ^= n ^ P[++i];
}
lr[off] = r ^ P[BLOWFISH_NUM_ROUNDS + 1];
lr[off + 1] = l;
}
Depending on when I pause the debugger, different lines in BCrypt are the caller to Runtime.checkRestricted(), but it appears that Runtime.checkRestricted() is called continuously. Since this is called in embedded loops, I'm thinking that this is the cause. I then went on a hunt as to how to avoid this checkRestricted() call from happening. No luck.
I have a somewhat complicated application structure that contains three Google web applications (Eclipse projects). I'll call them:
Base
Store
App
where Store depends upon Base, and App depends upon both Store and Base. I use an Ant task to build the Base and Store projects into JAR files and copy them to the App/war/WEB-INF/lib folder.
Originally, I had BCrypt in its own Eclipse project and my ANT task would also JAR this and copy it to App/war/WEB-INF/lib. This was working fine for the past few months until now. To try to work around the current problem, I tried moving the BCrypt class (it contains only 1 class) directly into the Base project, with the same result, then into the Store project, again with the same result. Since my app currently calls BCrypt methods only from the Store project, I figured either of this might work. They did, functionally, but still taking 2 minutes to complete an encipher() call.
From the stack trace, Runtime or RuntimeHelper return Source Not Found when I click on them, and I can find nothing about them in Google searches.
Questions:
Why is every line in BCrypt subjected to a checkRestricted() call? This doesn't seem normal.
More importantly, any idea on how to fix this problem?
I don't know what to look at next. Any ideas would be very welcome, even if you don't know the ultimate solution.
Thanks very much.
Rick

I just created a ticket at the GAE code project: http://code.google.com/p/googleappengine/issues/detail?id=7277&thanks=7277&ts=1333530915
Maybe, we get an answer there as using BCrypt is also provided by an official tutorial: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
Google fixed the bug and released a new version (1.6.4.1) today:
http://code.google.com/p/googleappengine/downloads/detail?name=appengine-java-sdk-1.6.4.1.zip

Yes. There is a regression in 1.6.4
See Is google app engine 1.6.4 slower in local? Comments there by Googlers working on the GAE SDK.

J2ME error - the method nextInt() in the type Random is not applicable for the arguments (int)

I just started to learn J2ME and right from the bat I got this error when using Random class. Arg, it's so frustrating. Anyone got the same problem before? I already tried to restart Eclipse, write only the code for the random generator to isolate it but to no avail.
I'm using CLDC 1.1 and MIDP 2.1 by the way.

Seems you are pointing out the wrong CLDC and MIDP libraries. new Random().nextInt(x) exists in CLDC 1.1.
If you are using CLDC 1.0 you can create your own implementation of nextInt(int):
public static int random(Random r, int n) {
if ((n & -n) == n) // i.e., n is a power of 2
return (int)((n * (long)r.nextInt()) >> 31);
int bits, val;
do {
bits = r.nextInt();
val = bits % n;
} while(bits - val + (n-1) < 0);
return val;
}
(Same implementation as nextInt(int) in the CLDC 1.1.)

nextInt(int) is only available since CLDC 1.1, so you have to specify CLDC 1.1 instead of 1.0
if you specified cldc 1.1 an still get this error its most likely an error of eclipse. took me hours to find:
in Eclipse go to Windows -> Preferences -> Java ME -> Device Management -> choose your Default Device -> Edit -> Libraries -> There you have to remove the cldc_1.0.jar

I had the same problem in netbeans, and solved it.
Right click on your project, go to properties.
Go To Libraries & Resources under build
Add Library
scroll for JMUnit for CLDC11
click OK
and build. all problems solved.
I just left JMUnit for CLDC11 there. not really sure if I need it. maybe I'll test without it once I have made up for lost time.