If you are able to wait to J2SE 5.0 the implementations of the new RowSet interface are able to provide a Resultset scrollable even though the driver is not. RowSet extends ResultSet. I haven't tried it but have a look at JdbcRowSet
I need some help about deciding how an application that transfers files from one computer to another tackles with the issue of byte order.
I am using NIO. Say Alice is sending a file to Bob. Say Alice's computer is little endian, but Bob's is big endian. I have heard that "well mannered" applications should transmit in network order. The simplest solution would be that the application sending the files would transmit before the transmition a code representing the byte order of its machine. Then it sends the file content using that byte order. Bob's machine should only convert the data to its corresponding byte order if the received byte order does not match its own. In this way we can avoid a conversion in the sending machine, and probably conversions in the receiving machines given that most of the computers are based on little endian processors.
Dou you think it is ok to contravene the network order rule?
It seems that there is no way to generate a selfcertificate via a JRE API. For instance java.security.cert.CertificateFactory needs to read an already existing certificate (encoding) from an InputStream. While CertPathBuilder requires LDAP or a Collection of certificates.
I do not want to force the users to pay to a CA, any free alternatives? In fact, I would like the program would allow the user to generate the selfcertificates, preventing the user of knowing/managing the keytool utility. I know they are not said to be reliable. But I think the user can phone the owner/subject of the selfcertificate to find out the "digitall firm" and check its autenticity. This is how I would like my program worked.
[ June 28, 2004: Message edited by: Jose Botella ]
[ June 28, 2004: Message edited by: Jose Botella ] [ June 29, 2004: Message edited by: Jose Botella ]
Try to see if the classpath enviroment variable is pointing to a directory in which an old incompatible copy of HelloWorldSwing.class inhabits. That would make to load the untrusted class before the one you really want.
Such class could also be causing troubles in the extensions directory "C:\j2sdk1.4.2_04\jre\lib\ext"
You can see which are the classes really loaded via the option "-verbose:class" to java command. In the output look for "[Loaded HelloWorldSwing]". The absence of path means it was loaded from the current directory.
That error occurs due to an improper change to a class. For instance say class A uses B.method. If B.method is changed but the corresponding invocation in class A is not, the latter will continue on calling the previous method, but because it was not recompiled the compiler doesn't warn you. NoSuchMethodError will be thrown by the JVM.
Because of the variety of problems you have experience so far, the best you can do is to delete all the classes in that directory and compile the program again.
There is a common class parent of all the Events in the JDK 1.0 Event Model. It is java.awt.Event. This model is obsolete. You can read read about it here thanks to R.G.Baldwin. You can also read about the advantages of the new Delegation Event Model in JDK 1.1 here. The common class for all the events in the Delegation Event Model is java.util.EventObject.
The use of Observer/Observable in Java to implement the publish-subscribe pattern is dated in JDK 1.0. A that time the DEM model was not out. DEM goes beyond MVC because encapsulates what has changed in an Object: the event. And we have a hierarquy of events to express different events.
The constructors are public because they need to be called from outside the package they were declared.
The short answer is that you have the ability to contruct and fire the events you need to do so; while others events are "automatically" created and managed: Low level events represent interactions of the user with the window, mouse or keyboard. The OS passes messages for this interaction to the Java runtime who contructs and fires the apropiate events. Semantic events has meaning regardless how they were spawned. When an ActionEvent signals that a button was pressed you are interested in the meaning of that hit for the program, not in knowing if the mouse or keyboard was involved. Some of the semantic events can be generated without user interaction, they can be generated programatically via the apropiate methods. Like AbstractTableModel.fireTableXXX