Re: [off-topic] stop bashing!
Uncle George wrote:
>
> u really r stupid.
No, actually, I'm not.
> The topic was porting issues, and ur notion that the .java jdk/source code cannot be
>altered to fit the port. Do i really need to say more.
> gat
I only said the platform-independent portions of the jdk source code
cannot be modified to fit the port. Java's int data type is considered
platform-independent, and therefore, you may not modify it. I admit I
spoke too hastily in my initial post that "none of the .java files may
be altered"; nonetheless, I spoke in response to your complaints about
having to change the size of Java's int data type from 32-bit to 64-bit.
Section 4.2 of the Java Language Specification, which I quoted earlier,
specifies int as being 32-bits. Not 64-bits. Not 8-bits. 32-bits.
Changing the size of the data types is changing the core of the
language. Deviations from the JLS are *not permitted*. Yet you say you
have to change the size of int for your port to Alpha. You also refuse
to explain *why*. The size of int is *not* considered
"platform-dependent", it is, in fact, part of the core of the Java
language. To be sure I wasn't blowing hot air on this, I asked Mr.
Austin about it. Here is what he told me:
"They are allowed to change 4 packages that are shared which includes
java.lang where the object definition is, but not where int is."
^
(emphasis mine)
I'd say that is pretty definitive, since it came from Sun.
Let's take a look at your sample code for a minute, and the explanatory
comments you included after the code:
"5) In the land of alpha longs are 64bits as well as
address pointers =>
.java
intlets_store_a_32_bit_address;
private nativeint wheres_my_window();
lets_store_a_32_bit_address = wheres_my_window();
..
Native .c
intwheres_my_window(blah*,blah ){
longaddr;
addr = (Window) w;
return(addr);
}
"This particular example results in the truncation of a returned 64 bit
'c' address, into a 32bit '.java' variable/storage. u can of course
change the 'c' routine to return all 64bits, but that will be,
eventually, truncated by the jvm to 32bits. In the Land of "OSF/true64"
for the Dec Alpha, u can convince the compiler to produce 32bit pointer
arithemetic, where long == 32bits. But the currently available
linux/alpha compilers a long==pointer==64bits."
Well, as I've been saying all along, in the world of Java, long==64bits,
just like Alpha long==64bits, which is why your example is flawed. So,
your example could be rewritten like so:
NativeCExample.java:
public class NativeCExample {
static {
System.loadLibrary("native_c_example");
}
public NativeCExample() {
long addr = wheresMyWindow();
System.out.println(addr);
}
public static void main(String[] args) {
NativeCExample example = new NativeCExample();
}
private native long wheresMyWindow();
}
...
native.c:
#include
#include "NativeCExample.h"
#include
JNIEXPORT jlong JNICALL Java_NativeCExample_wheresMyWindow (JNIEnv *env,
jobject
obj)
{
jlong addr;
addr = 9223372036854775807L;
return addr;
}
Note that the value I'm assigning 'addr' here is the maximum value of
the Java long range. Also, 'addr' could have its value assigned to it
from any function which returns a 64-bit value.
Here's the output:
[jgalyan@talisman Jeff]$ java NativeCExample
9223372036854775807
Now everyone's happy. Your platform's native typedef for jlong can be
found in /include/linux/jni_md.h -- and jlong is defined as 64-bit
on Intel platforms, too, by the way. I'm attaching the actual source
files I used for this so you can see I haven't changed them for the
post. Another thing - all the .java files which call native methods use
JNI, which means the appropriate types are being used (jlong, jint,
etc.).
You can see that you really don't have to change the size of int.
--Jeff
>
> Jeff Galyan wrote:
>
> > Why do you insist you *must* store the pointer in an int? Why can't you
> > use a long? If it's your application code, you *are* free to do as you
> > please, you know.
> >
> > However, the point remains that you are not legally permitted to change
> > the size of Java's int data type, as it is defined in the Java Language
> > Specification as 32-bits.
> >
> > --Jeff
> >
> > Uncle George wrote:
> > >
> > > Please return a long/64 bits Window address. Lemme know what gets stored in in
>the java int valiable "lets_store_a_32_bit_address", which has the capacity to store
>32 bits. I'm sorry, I thought a fairly simply program sample would demonstrate it
>best.
> > >
> > > While ur pondering this porting delima, may u can figure out the othe
Re: [off-topic] stop bashing!
I'm sorry, but u appear to be angry Calvin Austin wrote: > Well you have totally missed that point, I was talking about choice of OS > NT/Solaris/Linux for users, eg I am aware of what I call "intel centrism". When some one says we ported to NT, the intel part is always silent. When someone says linux, that intel part is also silent. So whenever I hear of a great port, I ask "does it run on the alpha ( alpha/nt, alpha/linux )". The usual answer is, well, no. So to talk of OS without architecture is an 'intel centrism'. to Say Nt/alpha, Nt/intel, Linux/ppc,linux/intel,linux/alpha would be much clearer > > When you want to buy your next alpha chip machine from your compaq > reseller do you want them to say. > > "Yes Mr Baeslack, we have a great deal for you, NT comes pre-installed > and only costs $150. You want Linux?, oh we can't do that, not enough > demand. No you cannot have a rebate for the pre-installed software" I think u are a little outta date. Compaq appears to be on the way of dropping Alpha/NT. I also got tired of asking various vendors what other packages are avail that can run on the alpha . u just cant imagine how hard it is to get 'nt' device drivers that will work on the alpha. Its exceedingly hard to obtain a copy of the MSc++ on the open market. This is not ur fault, or problem. BTW, u'll find the alpha resellers to be a little more realistic, and savy when it comes to selling alpha computers. I (usually) find them more intellegent, than most of the 'intel centric' vendors. > > I did forward your question to our legal department, posting to blackdown-linux > won't make it go any faster. You can read the terms of the scsl license > without accepting it, that answers some of your other questions in the > meantime. Public aliases are not generally the place to discuss licenses > and contracts terms, although I would suggest you read both licenses carefully. Can I take this as some form of threat? Cant understand Y it is posted to the "legal" department. Does the legal dept run Sun ? shudda have been answerable by any executive. Public places are the best places to talk, and to discuss things that affects that public. It has in the past when it came to discussing the non-commercial licenses. It has been a forum where one ( and all ) can discuss the document. Other forums, that might be more appropriate, are closed to the general public. or for licensee's eyes only. For myself, there doesn't appear to be any reason to accept a license, where one does not allow for the 'USE' of the port. For me the "USE" would be to have it ( the JDK ) distributable to the linux community. gat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
jni for linux
Hi & a congradulations for your wonderful outcome. Is there jni support available on linux. If yes please inform from where could I avail the same. Thanks, Regards, subash. mailing address: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Japanese data under Apache JServ
Hello all, I tested my servlet under Apache JServ with redhat Linux 5.2 and Apache 1.3.4. But all Japanese data is not handled and displayed correctly. Java application under XFree86 can handle Japanese characters correctly with LANG=ja setting. Please let me know how to set JServ setting if I use Japanese characters. Best regards. Daiju Kato e-mail:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK1.2 on Slackware3.5 problems.
Juergen thanks for following up on this: > > Sergio Antoy writes: > > Sergio> Here is a trace of what happens on my machine > > Sergio> gray:/tmp[501] export PATH=/home/antoy/java2/jdk1.2/bin:$PATH > Sergio> gray:/tmp[502] export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH > Sergio> gray:/tmp[503] ls -lt /usr/lib/libc.so.6 > Sergio> lrwxrwxrwx 1 root root 14 Jun 16 14:40 >/usr/lib/libc.so.6 -> /lib/libc.so.6 > Sergio> gray:/tmp[504] javac Animator.java > Sergio> /home/antoy/java2/jdk1.2/jre/bin/realpath: >/home/antoy/java2/jdk1.2/jre/bin/i386/realpath: No such file or directory > Sergio> /home/antoy/java2/jdk1.2/jre/bin/realpath: >/home/antoy/java2/jdk1.2/jre/bin/i386/realpath: No such file or directory > Sergio> /home/antoy/java2/jdk1.2/bin/javac: >/home/antoy/java2/jdk1.2/bin/i386/native_threads/javac: No such file or directory > Sergio> /home/antoy/java2/jdk1.2/bin/javac: >/home/antoy/java2/jdk1.2/bin/i386/native_threads/javac: No such file or directory > Sergio> gray:/tmp[505] > > Sergio> Is this correct? > > Try > $ ldd /home/antoy/java2/jdk1.2/jre/bin/i386/realpath > > the result should be something like > > libc.so.6 => /lib/libc.so.6 (0x40014000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) No, this is what I get gray:~[504] export PATH=/home/antoy/java2/jdk1.2/bin:$PATH gray:~[505] export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH gray:~[506] ldd /home/antoy/java2/jdk1.2/jre/bin/i386/realpath ldd: can't execute /home/antoy/java2/jdk1.2/jre/bin/i386/realpath (No such file or directory) gray:~[507] ls -lt /home/antoy/java2/jdk1.2/jre/bin/i386/realpath -rwxr-xr-x 1 antoyusers 11862 Jun 3 17:43 /home/antoy/java2/jdk1.2/jre/bin/i386/realpath gray:~[508] ls -lt /usr/lib/libc.so.6 lrwxrwxrwx 1 root root 14 Jun 16 14:40 /usr/lib/libc.so.6 -> /lib/libc.so.6 gray:~[509] ls -lt /lib/libc.so.6 -rw-r--r-- 1 antoyusers 4009308 Jun 16 14:32 /lib/libc.so.6 I could not find trace of /lib/ld-linux.so.2 Thanks again, Sergio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
action command
hi all, i got some code where the event handling is done using the command action and when i compile it it says that the method is depreciated. What is the alternative method or way to do event handling. Any help would be of great help. bye, MUTHU. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: action command
It is? Our code uses action command fairly extensively and the 1.2 compiler doesn't seem to complain. Can you show a sample output of javac with the -deprication option on? -rchit R MUTHUSWAMY wrote: > > hi all, > > i got some code where the event handling is done using the command > action and when i compile it it says that the method is depreciated. What > is the alternative method or way to do event handling. > > Any help would be of great help. > > bye, > MUTHU. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK1.2 on Slackware3.5 problems.
Sergio Antoy wrote: > > Juergen thanks for following up on this: > > > > Sergio Antoy writes: > > > > Sergio> Here is a trace of what happens on my machine > > > > Sergio> gray:/tmp[501] export PATH=/home/antoy/java2/jdk1.2/bin:$PATH > > Sergio> gray:/tmp[502] export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH > > Sergio> gray:/tmp[503] ls -lt /usr/lib/libc.so.6 > > Sergio> lrwxrwxrwx 1 root root 14 Jun 16 14:40 >/usr/lib/libc.so.6 -> /lib/libc.so.6 > > Sergio> gray:/tmp[504] javac Animator.java > > Sergio> /home/antoy/java2/jdk1.2/jre/bin/realpath: >/home/antoy/java2/jdk1.2/jre/bin/i386/realpath: No such file or directory > > Sergio> /home/antoy/java2/jdk1.2/jre/bin/realpath: >/home/antoy/java2/jdk1.2/jre/bin/i386/realpath: No such file or directory > > Sergio> /home/antoy/java2/jdk1.2/bin/javac: >/home/antoy/java2/jdk1.2/bin/i386/native_threads/javac: No such file or directory > > Sergio> /home/antoy/java2/jdk1.2/bin/javac: >/home/antoy/java2/jdk1.2/bin/i386/native_threads/javac: No such file or directory > > Sergio> gray:/tmp[505] > > > > Sergio> Is this correct? > > > > Try > > $ ldd /home/antoy/java2/jdk1.2/jre/bin/i386/realpath > > > > the result should be something like > > > > libc.so.6 => /lib/libc.so.6 (0x40014000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) > > No, this is what I get > > gray:~[504] export PATH=/home/antoy/java2/jdk1.2/bin:$PATH > gray:~[505] export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH > gray:~[506] ldd /home/antoy/java2/jdk1.2/jre/bin/i386/realpath > ldd: can't execute /home/antoy/java2/jdk1.2/jre/bin/i386/realpath (No such file or >directory) > gray:~[507] ls -lt /home/antoy/java2/jdk1.2/jre/bin/i386/realpath > -rwxr-xr-x 1 antoyusers 11862 Jun 3 17:43 >/home/antoy/java2/jdk1.2/jre/bin/i386/realpath > gray:~[508] ls -lt /usr/lib/libc.so.6 > lrwxrwxrwx 1 root root 14 Jun 16 14:40 /usr/lib/libc.so.6 -> >/lib/libc.so.6 > gray:~[509] ls -lt /lib/libc.so.6 > -rw-r--r-- 1 antoyusers 4009308 Jun 16 14:32 /lib/libc.so.6 > > I could not find trace of /lib/ld-linux.so.2 I don't know how Slackware does it, but I'm accustomed (on Red Hat) to seeing libc.so.6 be a symlink to libc-2.. From the size, it *looks* like you've got a glibc2.1. The missing ld-linux.so.2 seems significant... that file is very closely associated with glibc. I'm inclined to suspect that you don't have a complete glibc installation. Do you know how that /lib/libc.so.6 got installed on your system? Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Installation of glibc (was: JDK1.2 on Slackware3.5 problems)
The difficulty with the JDK1.2/Slackware installation turned out to be a very incomplete installation of glibc: libc.so.6 had been installed by copying, but none of the other hundreds of related libraries and support files was there. If anyone has some good words of wisdom on putting glibc on a libc5 system, I'm sure some of the viewers would find the info useful. I know of some old, detailed instructions to install glibc from source (http://metalab.unc.edu/LDP/HOWTO/Glibc2-HOWTO.html), but I don't really know the story for glibc packages. Is it safe to drop in a glibc RPM or .deb -- does the installation successfully avoid breaking the system? How well do the distribution upgrades handle the migration to a new glibc? Anyone here have some relevant experience? Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic] stop bashing!
> I think u are a little outta date. Compaq appears to be on the way of dropping > Alpha/NT. I also got tired of asking various vendors what other packages are avail > that can run on the alpha . u just cant imagine how hard it is to get 'nt' device > drivers that will work on the alpha. Its exceedingly hard to obtain a copy of the > MSc++ on the open market. This is not ur fault, or problem. > BTW, u'll find the alpha resellers to be a little more realistic, and savy when it > comes to selling alpha computers. I (usually) find them more intellegent, than most > of the 'intel centric' vendors. As a software R&D manager at a Fortune 50 company that is buying Alpha boxes at an amazing rate (we are probably Compaq/Digital's largest Alpha VAR), I can tell you authoritatively that Compaq is NOT going to be dropping either Alpha or Alpha/NT. I met with the Alpha team at JavaOne and am comfortable with what they are doing and where they are going. Their stated goal for the Alpha ports of 1.2 is to have the very fastest Java available on any platform. In talking to them about their porting strategy and the tricks they are using, I think they will meet their goals. Just thought I would fill you in from the point of view of someone leading a significant Alpha/NT based effort. Peace, Ron Braithwaite -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What's so platform dependent with Java2 source?
First, no I haven't read the source; my views are based on my thoughts. Why has it been so difficult to port Sun's Java2 source to Linux? I was under the impression that a) Sun isolated their platform-dependent parts, b) all the rest of the code is in portable, standard C, and c) the source code is fairly well-organized. I would also tend to believe that Sun would probably use POSIX and/or de-facto system calls for system-related tasks such as threads and I/O. The current "release" is still labelled a pre-release, suggesting that it should definitely not be used to do real work. Even the porting team says that one should use it only if you are "willing to take some risk". So what are the major problems in porting this thing and why has it taken so many months without the end in sight? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Other ports
Besides the Blackdown 1.1.x/1.2 ports and the IBM 1.1.6 port, are there any other ports (as opposed to actual implementation like Kaffe) underway to provide a useable Java implementation for Linux? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What's so platform dependent with Java2 source?
Gerald wrote: > > Why has it been so difficult to port Sun's Java2 source to Linux? I > was under the impression that > > a) Sun isolated their platform-dependent parts, > b) all the rest of the code is in portable, standard C, and > c) the source code is fairly well-organized. > > I would also tend to believe that Sun would probably use POSIX and/or > de-facto system calls for system-related tasks such as threads and > I/O. > (Keep in mind that I'm not part of the Blackdown team; I'm just another licensee, so I'm not speaking on their behalf) Part of what makes porting so difficult is that even though the porting team get a (very) little bit of a break in that they can start with the Solaris sources, there are still a lot of files they have to touch to do a port. One of the problems they have to face is adapting code written for 64-bit Solaris/SPARC to run on 32-bit Intel x86-based systems. Solaris and Linux have many differences in their low-level system calls. As much as we all like to believe in "de facto" system calls, there isn't an OS around that I've ever seen that implements *all* of the POSIX specifications (unfortunately). Now, none of the porting tasks are particularly difficult *if* you have a team of engineers dedicated to nothing but porting Java over. The Blackdown team are working on this in their spare time, for no pay, just because they believe in Java and Linux. Half the time, they don't even get any kind of thanks or support from their users. Frankly, I'm extremely impressed that they've come as far as they have already, and with the quality that they've achieved (even for a pre-release). -- Jeff Galyan http://www.anamorphic.com http://www.sun.com jeffrey dot galyan at sun dot com talisman at anamorphic dot com Sun Certified Java(TM) Programmer == Linus Torvalds on Microsoft and software development: "... if it's a hobby for me and a job for you, why are you doing such a shoddy job of it?" The views expressed herein do not necessarily reflect those of my employer. Sun Microsystems, Inc., has no connection to my involvement with the Mozilla Organization. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JSP Examples in Jetty
Does anyone have any comments or pointers to documentation on getting the Java Server Pages examples up and running in Jetty? All comments welcome. john -- E-Mail: John N. Alegre <[EMAIL PROTECTED]> Date: 26-Jun-99 Time: 20:18:38 This message was sent by XFMail -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
