XML and java on Linux
Hi all, I am kind of a newbie to Linux. Could somebody suggest a good place to learn/read/research developing XML / java applications for Linux? I need to know: Which Linux-browsers support XML? How do I setup Java development environment on Linux? Is jdk1.2.x ported to Linux? Can I use Sun's JVM for runtime? Which IDE would you recommend? I Appreciate any input . Thanks.. Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 R&D Informix Software
Re: error in compilation
Are you sure it's an error? It might have been a warning. Additionally, you get this when the interface from that API has been replaced by another better interface. But the old interface is supported for backward compatibility. At 10:59 AM 04/14/2000 -0700, Luz Lopez wrote: >Hi > >I am compiling an applet but send me the following error: > >uses or overrides a deprecated API. Recompile with "-depreca >tion" for details. > >When appear this type of error? > >thanks in advanced, > >Regards, > > >__ >Get Your Private, Free Email at http://www.hotmail.com > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 R&D Informix Software
RE: Java security question
This would require a self-coded lock or something, I presume. It's always good to have obfuscation on the java class code. Like Zack mentions once its in somebody's hands, they could make changes. If obfuscation is really as good as it sounds, wouldn't it be possible to limit the applet that has been installed once to make sure it cannot be copied onto another location? I mean, say your applet has been been installed on machine A. The applet is signed and has access to installed m/c. Applet during installation, creates a lock that identifies this machine uniquely. Person P is able to make a small change say to logo and sells it to Party Q. Party Q runs applet install. Install knows it's being dumped on another m/c. Install spews scary legalise at Q and fails to install? If the applet is being used like normal applets, it would have access to m/c that is serving it, right? Does this sound even remotely fair to do? At 02:05 PM 04/19/2000 -0400, Gayathri Viswanathan wrote: >Zack, > >I have already signed my Java applet with a certificate from Thawte. But I >thought that >this means that Thawte certifies that noone has changed the jar file. But >what if after >accepting the certificate, some malicious user wishes to change the contents >of the jar file >by say changing some image files (used for displaying logo) and then signing >it again and then >selling it ? Would obfuscation help in this ? Can obfuscation be used on >applets ? >Is there any other alternative ? > >Thanks. > >-- Gayathri > >-Original Message- >From: Zack Grossbart [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 19, 2000 1:30 PM >To: Gayathri Viswanathan; [EMAIL PROTECTED] >Subject: RE: Java security question > > >Gayathri, > > Obfuscation would help prevent someone from decompiling and >understanding >your code, but not from changing it. You should sign your JAR file. Tools >like Visual Cafe have this capability built in, or you can write a small >utility to do it yourself using the javax.cript package. If you look on the >JavaSoft site you can get more data about signing JARs. > >Zack > > >> -Original Message- >> From: Gayathri Viswanathan [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, April 19, 2000 12:41 PM >> To: [EMAIL PROTECTED] >> Subject: Java security question >> >> >> Hi ! >> >> I have written a Java applet and we wish to make it into a product. I have >> the applet setup so that all the >> resources that it needs are within a jar file. How can I make sure that >> other people to whom we may sell the >> software will not be able to disassemble the code or change some of the >> image files or property files ? >> Is obfuscation the way to go ? Can anyone help me ? >> >> Thanks a lot. >> >> -- Gayathri >> >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >> > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 R&D Informix Software
RE: Java security question
I agree with you there. Anyway I guess maybe we should stop this thread now since it's not an actual java-linux issue.. At 07:48 AM 04/21/2000 -0400, Zack Grossbart wrote: >Rajesh, > > The scheme you are discussing is very similar to what Cisco does with a >lot of their network monitoring code. Cisco used the actual software and >not the install. This is probably a better option, given that the install >can also be tampered with or possibly reverse engineered and rewritten. >However, there are some caveats. First, this requires the machine have some >unique id. There are a couple of option there, but the most popular is Mac >address. Some Cisco software uses IP address, but this is prone to >difficulties given that the IP address of a given machine is subject to >change. Second, this scheme requires a server to do authentication. You >need to have some server authenticate or else it is possible to break. > > So the bottom line is, any software you install on a users machine is >theoretically something that the user could get at and change. The only way >around this is to have a client and server architecture, and have the actual >logic of the application on the server. However, in real life the chances >of someone wanting to do this are pretty slim. Consider it similar to a car >alarm. They don't make your car impenetrable to thieves, but they do make >your car more difficult to steal. > >Zack > > >-Original Message- >From: Rajesh Nair [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 19, 2000 4:22 PM >To: Gayathri Viswanathan; 'Zack Grossbart'; Gayathri Viswanathan; >[EMAIL PROTECTED] >Subject: RE: Java security question > > > > >This would require a self-coded lock or something, I presume. It's always >good to have obfuscation on the java class code. Like Zack mentions once >its in somebody's hands, they could make changes. >If obfuscation is really as good as it sounds, wouldn't it be possible to >limit the applet that has been installed once to make sure it cannot be >copied onto another location? I mean, say your applet has been >been installed on machine A. The applet is signed and has access to >installed m/c. Applet during installation, >creates a lock that identifies this machine uniquely. Person P is able to >make a small change say to logo >and sells it to Party Q. Party Q runs applet install. Install knows it's >being dumped on another m/c. Install >spews scary legalise at Q and fails to install? > > >If the applet is being used like normal applets, it would have access to m/c >that is serving it, right? >Does this sound even remotely fair to do? > > > >At 02:05 PM 04/19/2000 -0400, Gayathri Viswanathan wrote: >>Zack, >> >>I have already signed my Java applet with a certificate from Thawte. But I >>thought that >>this means that Thawte certifies that noone has changed the jar file. But >>what if after >>accepting the certificate, some malicious user wishes to change the >contents >>of the jar file >>by say changing some image files (used for displaying logo) and then >signing >>it again and then >>selling it ? Would obfuscation help in this ? Can obfuscation be used on >>applets ? >>Is there any other alternative ? >> >>Thanks. >> >>-- Gayathri >> >>-Original Message- >>From: Zack Grossbart [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, April 19, 2000 1:30 PM >>To: Gayathri Viswanathan; [EMAIL PROTECTED] >>Subject: RE: Java security question >> >> >>Gayathri, >> >> Obfuscation would help prevent someone from decompiling and >>understanding >>your code, but not from changing it. You should sign your JAR file. Tools >>like Visual Cafe have this capability built in, or you can write a small >>utility to do it yourself using the javax.cript package. If you look on >the >>JavaSoft site you can get more data about signing JARs. >> >>Zack >> >> >>> -Original Message- >>> From: Gayathri Viswanathan [mailto:[EMAIL PROTECTED]] >>> Sent: Wednesday, April 19, 2000 12:41 PM >>> To: [EMAIL PROTECTED] >>> Subject: Java security question >>> >>> >>> Hi ! >>> >>> I have written a Java applet and we wish to make it into a product. I >have >>> the applet setup so that all the >>> resources that it needs are within a jar file. How can I make sure that >>> other people to whom we may sell the >>> software will not be able to disassemble the code or change some of the >>> image files or pro
RE: Java security question
You are right, applets are sand-boxed. But applets can be signed thus allowing the user to 'trust' the applet. Once trusted the applets are allowed system resources that otherwise they are deprived of. For example, An untrusted applet is not allowed to obtain the IP address of it's client. It always gets localhost. But a trusted applet can retrieve the actual IP address of a client it is running on among other things. Here is another location of hostile applets: http://metro.to/mladue/hostile-applets/ As you can see security breaches allow untrusted applets to retrieve IP addresses also.. Anyway bottom line signed applets or trusted applets can workaround most of the sandbox securities. Also Gayathri is facing a different issue of how to make sure that her applet code is not engineered after it has been sold. At 07:11 AM 04/21/2000 -0700, john wrote: >hi all, > >I have been reading this thread for a while now. >I have a question about the java security in general >and specifically caters to applets downloaded from >the internet sites while browsing. >People have raised security questions when users >browse and download applets on their local computers. >We have things called as hostile java applets etc. >here is a reference.. >www.rstcorp.com/hostile-applets/index.html > >BUT all these applets run on the JVM and they cannot >access resources outside the JVM. so where is the >security problem ? I have been at a loss to really get >to the bottom of this. fine java applications can >access >system resources. but not applets. they do not have >the rights to run beyond the JVM(sandbox). >please correct me if i am wrong. > >thanks >john > >--- Zack Grossbart <[EMAIL PROTECTED]> wrote: >> Rajesh, >> >> The scheme you are discussing is very similar to >> what Cisco does with a >> lot of their network monitoring code. Cisco used >> the actual software and >> not the install. This is probably a better option, >> given that the install >> can also be tampered with or possibly reverse >> engineered and rewritten. >> However, there are some caveats. First, this >> requires the machine have some >> unique id. There are a couple of option there, but >> the most popular is Mac >> address. Some Cisco software uses IP address, but >> this is prone to >> difficulties given that the IP address of a given >> machine is subject to >> change. Second, this scheme requires a server to do >> authentication. You >> need to have some server authenticate or else it is >> possible to break. >> >> So the bottom line is, any software you install on >> a users machine is >> theoretically something that the user could get at >> and change. The only way >> around this is to have a client and server >> architecture, and have the actual >> logic of the application on the server. However, in >> real life the chances >> of someone wanting to do this are pretty slim. >> Consider it similar to a car >> alarm. They don't make your car impenetrable to >> thieves, but they do make >> your car more difficult to steal. >> >> Zack >> >> >> -Original Message- >> From: Rajesh Nair [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, April 19, 2000 4:22 PM >> To: Gayathri Viswanathan; 'Zack Grossbart'; Gayathri >> Viswanathan; >> [EMAIL PROTECTED] >> Subject: RE: Java security question >> >> >> >> >> This would require a self-coded lock or something, I >> presume. It's always >> good to have obfuscation on the java class code. >> Like Zack mentions once >> its in somebody's hands, they could make changes. >> If obfuscation is really as good as it sounds, >> wouldn't it be possible to >> limit the applet that has been installed once to >> make sure it cannot be >> copied onto another location? I mean, say your >> applet has been >> been installed on machine A. The applet is signed >> and has access to >> installed m/c. Applet during installation, >> creates a lock that identifies this machine >> uniquely. Person P is able to >> make a small change say to logo >> and sells it to Party Q. Party Q runs applet >> install. Install knows it's >> being dumped on another m/c. Install >> spews scary legalise at Q and fails to install? >> >> >> If the applet is being used like normal applets, it >> would have access to m/c >> that is serving it, right? >> Does this sound even remotely fair to do? >> >> &g
Re: regarding blackened menu item
You probably need to change the look and feel.. At 04:23 AM 05/11/2000 -0400, kamesh jayachandran wrote: >I have developed a gui in java, It works fine on windows but shows blackened >menu item when it is run under linux.I am not able to see whatever I typed in >the textfield ,it gets cluster of blackcharacters as one types in the >textfield.I have posted the same problem to the list before but got no >replies.I have searched the mail archives for any clue to this problem ,I got >no replies to my bad luck.I would be happy if anyone here help me in this. >I have stock install of RHL6.1.Sun JDK1.2.2 . >Thanks in advance >kamesh jayachandran > > >kamesh jayachandran >Software Engineer >MicroLand limited >Bangalore > > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 R&D Informix Software
Re: Classpath setting problem
You may want to check if your CLASSPATH is exported or if you have specified both the compressed and uncompressed jars in the classpath. I put the jars under the $JAVA_HOME/lib directory and that seemed to work At 08:58 AM 06/20/2000 +0530, Hrishiraj Nair wrote: > > Hi , > > I use Mysql along with JDBC1.2 on Linux. It is required that I download the > Mysql driver for linux to do the same. I could download the driver > (mm.mysql.jdbc-1.2b) from <http://www.mysql.com>www.mysql.com > > As stated in the documentation it is required to set the classpath, after > installing the driver. I did so but after which my Java program gives me an > error "Class Not Found". > > Please help. > Hrishi. > > PS : The Java program was used to open a connection to the database and see > if it connects, a fairly simple code :) Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 -- R&D Informix Software -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Classpath setting problem
Thanks. You are right. Hadn't had my coffee yet : -} At 01:44 PM 06/21/2000 -0700, Adam Ambrose wrote: >The more proper place may be to put any extention packages in >$JAVA_HOME/lib/ext, as I just discovered the other day from here: > >http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html > > >Rajesh Nair wrote: >> >> You may want to check if your CLASSPATH is exported or if you have specified >> both the compressed and >> uncompressed jars in the classpath. I put the jars under the $JAVA_HOME/lib >> directory and that seemed to >> work >> >> At 08:58 AM 06/20/2000 +0530, Hrishiraj Nair wrote: >> > >> > Hi , >> > >> > I use Mysql along with JDBC1.2 on Linux. It is required that I download the >> > Mysql driver for linux to do the same. I could download the driver >> > (mm.mysql.jdbc-1.2b) from <http://www.mysql.com>www.mysql.com >> > >> > As stated in the documentation it is required to set the classpath, after >> > installing the driver. I did so but after which my Java program gives me an >> > error "Class Not Found". >> > >> > Please help. >> > Hrishi. >> > >> > PS : The Java program was used to open a connection to the database and see >> > if it connects, a fairly simple code :) >> >> Rajesh Nair >> [EMAIL PROTECTED] >> Ph: 913 599 7201 >> >> -- >> R&D >> Informix Software >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Rajesh Nair [EMAIL PROTECTED] Ph: 913 599 7201 -- R&D Informix Software -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
