GetCellEditor() / stopCellEditing() different in Java 1.4.0

Until Java 1.3.1 I used to do this to get user's entered value into the model when user clicks Ok:
if (jTable1.getCellEditor() != null) jTable1.getCellEditor().stopCellEditing(); // otherwise the modifications of the last cell is not notified!
Since Java 1.4.1 getCellEditor() returns null. Thus, modifications are not stored any more.
What to do in Java 1.4.1?

I do not know why you cannot access the Sun site from your Windows 98 PC, but I have succesfully downloaded the plug-in to a network drive, mapped the network drive on another computer and installed from there. I have also copied multple versions to a writeable CD, and then installed them on a PC that is off the network. The Java 1.4.0_03 plug-in installation file is named j2re-1_4_0_03-windows-i586.exe and is zip format.

Similar Messages

Different between Java TRial Edition

Can someone please explain the difference between different SAP Java editoin available at:
https://www.sdn.sap.com/irj/sdn/downloaditem?rid=/library/uuid/cfc19866-0401-0010-35b2-dc8158247fb6
Regards
Suhail

Javascript is a scripting language usually embedded in HTML. Java is an partially compiled programming language much more powerful than Javascript.

What are Crypto Cards, and what are they different from Java Cards?

Hi,
I just heard the name 'Crypto Card'. I thought Java Card is the only standard for smart card. Could anyone tell me what are Crypto Cards, and what are they different from Java Cards? Thanks in advance.
Joey

Probably any card that offers cryptographic capabilities (crypto coprocessor) could be called "Crypo Card", but likely the term was referred to cards offering a pkcs#11 interface.
Pkcs#11 is the standard for accessing crypto devices, like tokens, cards, or accelerators. Such a device can be easily accessed for example from your browser to perform cryptographic and digital signature operations.
A Javacard can operate as a pkcs#11 device in you install on it an applet dealing with the pkcs#11 requests.

What do people think about the different Generic Java approaches?

I have seen a lot of different approaches for Generic Java, and when people find problems with each approach the normal response has been: the other approach is worse with such and such a problem, do you have a better way?
The different approaches I have seen are: (in no particular order)
Please correct me if I am wrong and add other approaches if they are worthy of mention.
1) PolyJ - by MIT
This is a completely different approach than the others, that introduces a new where clause for bounding the types, and involves changing java byte codes in order to meet it's goals.
Main comments were not a java way of doing things and far too greater risk making such big changes.
2) Pizza - by Odersky & Wadler
This aims at extending java in more ways than just adding Generics. The generic part of this was replaced by GJ, but with Pizza's ability to use primitives as generic types removed, and much bigger changes allowing GJ to interface with java.
Main comments were that Pizza doesn't work well with java, and many things in Pizza were done in parallel with java, hence were no longer applicable.
3) GJ - by Bracha, Odersky, Stoutamire & Wadler
This creates classes with erased types and bridging methods, and inserts casts when required when going back to normal java code.
Main comments are that type dependent operations such as new, instanceof, casting etc can't be done with parametric types, also it is not a very intuitive approach and it is difficult to work out what code should do.
4) Runtime Generic Information - by Natali & Viroli
Each instance holds information about its Runtime Type.
Main comments from people were that this consumes way too much memory as each instance holds extra information about its type, and the performance would be bad due to checking Type information at runtime that would have been known at compile.
5) NextGen - by Cartwright & Steele
For each parameterized class an abstract base class with types erased is made and then for each new type a lightweight wrapper class and interface are created re-using code from the base class to keep the code small.
Main comments from people were that this approach isn't as backwards compatible as GJ due to replacing the legacy classes with abstract base classes which can't be instantiated.
6) .NET common runtime - by Kennedy & Syme
This was written for adding Generics to C#, however the spec is also targeted at other languages such as VB.
Main comments from people were that this approach isn't java, hence it is not subject to the restrictions of changing the JVM like java is.
7) Fully Generated Generic Classes - by Agesen, Freund & Mitchell
For each new type a new class is generated by a custom class loader, with all the code duplicated for each different type.
Main comments from people were that the generated code size gets too big, and that it is lacking a base class for integration with legacy code.
8) JSR-14 - by Sun
This is meant to come up with a solution Generic Solution to be used in java. Currently it is heavily based on GJ and suffering from all the same problems as GJ, along with the fact that it is constantly undergoing change and so no one knows what to expect.
See this forum for comments about it.
As if we didn't have enough approaches already, here is yet another one that hopefully has all of the benefits, and none of the problems of the other approaches. It uses information learnt while experimenting with the other approaches. Now when people ask me if I think I have a better approach, I will have somewhere to point them to.
(I will be happy to answer questions concerning this approach).
9) Approach #x - by Phillips
At compile time 1 type is made per generic type with the same name.
e.g.class HashSet<TypeA> extends AbstractSet<TypeA> implements Cloneable, Serializable will be translated to a type: class HashSet extends AbstractSet implements Cloneable, SerializableAn instance of the class using Object as TypeA can now be created in 2 different ways.
e.g.Set a = new HashSet();
Set<Object> b = new HashSet<Object>();
//a.getClass().equals(b.getClass()) is trueThis means that legacy class files don't even need to be re-compiled in order to work with the new classes. This approach is completely backwards compatible.
Inside each type that was created from a generic type there is also some synthetic information.
Information about each of the bounding types is stored in a synthetic field.
Note that each bounding type may be bounded by a class and any number of interfaces, hence a ';' is used to separate bounding types. If there is no class Object is implied.
e.g.class MyClass<TypeA extends Button implements Comparable, Runnable; TypeB> will be translated to a type: class MyClass {
public static final Class[][] $GENERIC_DESCRIPTOR = {{Button.class, Comparable.class, Runnable.class}, {Object.class}};This information is used by a Custom Class Loader before generating a new class in order to ensure that the generic types are bounded correctly. It also gets used to establish if this class can be returned instead of a generated class (occurs when the generic types are the same as the bounding types, like for new HashSet<Object> above).
There is another synthetic field of type byte[] that stores bytes in order for the Custom Class Loader to generate the new Type.
There are also static methods corresponding to each method that contain the implementation for each method. These methods take parameters as required to gain access to fields, contructors, other methods, the calling object, the calling object class etc. Fields are passed to get and set values in the calling object. Constructors are passed to create new instances of the calling object. Other methods are passed when super methods are called from within the class. The calling object is almost always passed for non static methods, in order to do things with it. The class is passed when things like instanceof the generated type need to be done.
Also in this class are any non private methods that were there before, using the Base Bounded Types, in order that the class can be used exactly as it was before Generics.
Notes: the time consuming reflection stuff is only done once per class (not per instance) and stored in static fields. The other reflection stuff getting done is very quick in JDK1.4.1 (some earlier JDKs the same can not be said).
Also these static methods can call each other in many circumstances (for example when the method getting called is private, final or static).
As well as the ClassLoader and other classes required by it there is a Reflection class. This class is used to do things that are known to be safe (assuming the compiler generated the classes correctly) without throwing any exceptions.
Here is a cut down version of the Reflection class: public final class Reflection {
public static final Field getDeclaredField(Class aClass, String aName) {
    try {
      Field field = aClass.getDeclaredField(aName);
      field.setAccessible(true);
      return field;
    catch (Exception ex) {
      throw new Error(ex);
public static final Object get(Field aField, Object anObject) {
    try {
      return aField.get(anObject);
    catch (Exception ex) {
      throw new Error(ex);
public static final void set(Field aField, Object anObject, Object aValue) {
    try {
      aField.set(anObject, aValue);
    catch (Exception ex) {
      throw new Error(ex);
public static final int getInt(Field aField, Object anObject) {
    try {
      return aField.getInt(anObject);
    catch (Exception ex) {
      throw new Error(ex);
public static final void setInt(Field aField, Object anObject, int aValue) {
    try {
      aField.setInt(anObject, aValue);
    catch (Exception ex) {
      throw new Error(ex);
}Last but not least, at Runtime one very lightweight wrapper class per type is created as required by the custom class loader. Basically the class loader uses the Generic Bytes as the template replacing the erased types with the new types. This can be even faster than loading a normal class file from disk, and creating it.
Each of these classes has any non private methods that were there before, making calls to the generating class to perform their work. The reason they don't have any real code themselves is because that would lead to code bloat, however for very small methods they can keep their code inside their wrapper without effecting functionality.
My final example assumes the following class name mangling convention:
* A<component type> - Array
* b - byte
* c - char
* C<class name length><class name> - Class
* d - double
* f - float
* i - int
* l - long
* z - boolean
Final Example: (very cut down version of Vector)public class Vector<TypeA> extends AbstractList<TypeA> implements RandomAccess, Cloneable, Serializable {
protected Object[] elementData;
protected int elementCount;
protected int capacityIncrement;
public Vector<TypeA>(int anInitialCapacity, int aCapacityIncrement) {
    if (anInitialCapacity < 0) {
      throw new IllegalArgumentException("Illegal Capacity: " + anInitialCapacity);
    elementData = new Object[initialCapacity];
    capacityIncrement = capacityIncrement;
public synchronized void setElementAt(TypeA anObject, int anIndex) {
    if (anIndex >= elementCount) {
      throw new ArrayIndexOutOfBoundsException(anIndex + " >= " + elementCount);
    elementData[anIndex] = anObject;
}would get translated as:public class Vector extends AbstractList implements RandomAccess, Cloneable, Serializable {
public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
protected Object[] elementData;
protected int elementCount;
protected int capacityIncrement;
private static final Field $0 = Reflection.getDeclaredField(Vector.class, "elementData"),
                             $1 = Reflection.getDeclaredField(Vector.class, "elementCount"),
                             $2 = Reflection.getDeclaredField(Vector.class, "capacityIncrement");
static void $3(int _0, Field _1, Object _2, Field _3, int _4) {
    if (_0 < 0) {
      throw new IllegalArgumentException("Illegal Capacity: " + _0);
    Reflection.set(_1, _2, new Object[_0]);
    Reflection.setInt(_3, _2, _4);
static void $4(int _0, Field _1, Object _2, Field _3, Object _4) {
    if (_0 >= Reflection.getInt(_1, _2)) {
      throw new ArrayIndexOutOfBoundsException(_0 + " >= " + Reflection.getInt(_1, _2));
    ((Object[])Reflection.get(_3, _2))[_0] = _4;
public Vector(int anInitialCapacity, int aCapacityIncrement) {
    $3(anInitialCapacity, $0, this, $2, aCapacityIncrement);
public synchronized void setElementAt(Object anObject, int anIndex) {
    $4(anIndex, $1, this, $0, anObject);
} and new Vector<String> would get generated as:public class Vector$$C16java_lang_String extends AbstractList$$C16java_lang_String implements RandomAccess, Cloneable, Serializable {
protected Object[] elementData;
protected int elementCount;
protected int capacityIncrement;
private static final Field $0 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "elementData"),
                             $1 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "elementCount"),
                             $2 = Reflection.getDeclaredField(Vector$$C16java_lang_String.class, "capacityIncrement");
public Vector$$C16java_lang_String(int anInitialCapacity, int aCapacityIncrement) {
    Vector.$3(anInitialCapacity, $0, this, $2, aCapacityIncrement);
public synchronized void setElementAt(String anObject, int anIndex) {
    Vector.$4(anIndex, $1, this, $0, anObject);
}Comparisons with other approaches:
Compared with PolyJ this is a very java way of doing things, and further more it requires no changes to the JVM or the byte codes.
Compared with Pizza this works very well with java and has been designed using the latest java technologies.
Compared with GJ all type dependent operations can be done, and it is very intuitive, code does exactly the same thing it would have done if it was written by hand.
Compared with Runtime Generic Information no extra information is stored in each instance and hence no extra runtime checks need to get done.
Compared with NextGen this approach is completely backwards compatible. NextGen looks like it was trying to achieve the same goals, but aside from non backwards compatibility also suffered from the fact that Vector<String> didn't extend AbstractList<String> causing other minor problems. Also this approach doesn't create 2 types per new types like NextGen does (although this wasn't a big deal anyway). All that said NextGen was in my opinion a much better approach than GJ and most of the others.
Compared to .NET common runtime this is java and doesn't require changes to the JVM.
Compared to Fully Generated Generic Classes the classes generated by this approach are very lightweight wrappers, not full blown classes and also it does have a base class making integration with legacy code simple. It should be noted that the functionality of the Fully Generated Generic Classes is the same as this approach, that can't be said for the other approaches.
Compared with JSR-14, this approach doesn't suffer from GJ's problems, also it should be clear what to expect from this approach. Hopefully JSR-14 can be changed before it is too late.

(a) How you intend generic methods to be translated.
Given that Vector and Vector<Object> are unrelated types,
what would that type be represented as in the byte code of
the method? In my approach Vector and Vector<Object> are related types. In fact the byte code signature of the existing method is exactly the same as it was in the legacy code using Vector.
To re-emphasize what I had said when explaining my approach:
System.out.println(Vector.class == Vector<Object>.class); // displays true
System.out.println(Vector.class == Vector<String>.class); // displays false
Vector vector1 = new Vector<Object>(); // legal
Vector<Object> vector2 = new Vector(); // legal
// Vector vector3 = new Vector<String>(); // illegal
// Vector<String> vector4 = new Vector(); // illegal
Vector<String> vector5 = new Vector<String>(); // legal
You must also handle the case where the type
parameter is itself a parameterized type in which the type
parameter is not statically bound to a ground instantiation.This is also very straightforward: (let me know if I have misunderstood you)
(translation of Vector given in my initial description)
public class SampleClass<TypeA> {
public static void main(String[] args) {
    System.out.println(new Vector<Vector<TypeA>>(10, 10));
}would get translated as:public class SampleClass {
public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
private static final Constructor $0 = Reflection.getDeclaredConstructor(Vector$$C16java_util_Vector.class, new Class[] {int.class, int.class});
static void $1(Constructor _0, int _1, int _2) {
    try {
      System.out.println(Reflection.newInstance(_0, new Object[] {new Integer(_1), new Integer(_2)}));
    catch (Exception ex) {
      throw (RuntimeException)ex;
public static void main(String[] args) {
    $1($0, 10, 10);
}and SampleClass<String> would get generated as:public class SampleClass$$C16java_lang_String {
private static final Constructor $0 = Reflection.getConstructor(Vector$$C37java_util_Vector$$C16java_lang_String.class, new Class[] {int.class, int.class});
public static void main(String[] args) {
    SampleClass.$1($0, 10, 10);
Also describe the implementation strategy for when these
methods are public or protected (i.e. virtual).As I said in my initial description that for non final, non static, non private method invocations a Method may be passed into the implementing synthetic method as a parameter.
Note: the following main method will display 'in B'.
class A {
public void foo() {
    System.out.println("in A");
class B extends A {
public void foo() {
    System.out.println("in B");
public class QuickTest {
public static void main(String[] args) {
    try {
      A.class.getMethod("foo", null).invoke(new B(), null);
    catch (Exception ex) {}
}This is very important as foo() may be overwritten by a subclass as it is here. By passing a Method to the synthetic implementation this guarantees that covariance, invariance and contra variance all work exactly the same way as in java. This is a fundamental problem with many other approaches.
(b) The runtime overhead associated with your translationAs we don't have a working solution to compare this to, performance comments are hard to state, but I hope this helps anyway.
The Class Load time is affected in 4 ways. i) All the Generic Bytes exist in the Base Class, hence they don't need to be read from storage. ii) The custom class loader, time to parse the name and failed finds before it finally gets to define the class. iii) The generation of the generic bytes to parametric bytes (basically involves changing bytes from the Constant Pool worked out from a new Parametric type, Utf8, Class and the new Parametric Constant types may all be effected) iv) time to do the static Reflection stuff (this is the main source of the overhead). Basically this 1 time per class overhead is nothing to be concerned with, and Sun could always optimize this part further.
The normal Runtime overhead (once Classes have been loaded) is affected mainly by reflection: On older JDKs the reflection was a lot slower, and so might have made a noticeable impact. On newer JDKs (since 1.4 I think), the reflection performance has been significantly improved. All the time consuming reflection is done once per class (stored in static fields). The normal reflection is very quick (almost identical to what is getting done without reflection). As the wrappers simply include a single method call to another method, these can be in-lined and hence made irrelevant. Furthermore it is not too difficult to make a parameter that would include small methods in the wrapper classes, as this does not affect functionality in the slightest, however in my testing I have found this to be unnecessary.
(c) The space overhead (per instantiation)There are very small wrapper classes (one per new Type) that simply contain all non private methods, with single method calls to the implementing synthetic method. They also include any fields that were in the original class along with other synthetic fields used to store reflected information, so that the slow reflection only gets done once per new Type.
(d) The per-instance space overheadNone.
(e) Evidence that the proposed translation is sound and well-defined for all relevant cases (see below)Hope this is enough, if not let me know what extra proof you need.
(f) Evidence for backward compatibility
(For example, how does an old class file that passes a Vector
to some method handle the case when the method receives a Vector<T>
where T is a type parameter? In your translation these types are unrelated.)As explained above, in my approach these are only unrelated for T != Object, in the legacy case T == Object, hence legacy code passing in Vector is exactly the same as passing in Vector<Object>.
(g) Evidence for forward compatibility
(How, exactly, do class files that are compiled with a generics compiler run on an old VM)They run exactly the same way, the byte codes from this approach are all legal java, and all legal java is also legal in this approach. In order to take advantage of the Generics the Custom Class Loader would need to be used or else one would get ClassNotFoundExceptons, the same way they would if they tried using Collections on an old VM without the Collections there. The Custom Class Loader even works on older VMs (note it may run somewhat slower on older VMs).
(h) A viable implementation strategyType specific instantiations are at Class Load time, when the Custom Class Loader gets asked for a new Class, it then generates it.
The type specific instantiations are never shipped as they never get persisted. If you really wanted to save them all you need to do is save them with the same name (with the $$ and _'s etc), then the class loader would find them instead of generating them. There is little to be gained by doing this and the only reason I can think of for doing such a thing would be if there was some reason why the target VM couldn't use the Custom Class Loader (the Reflection class would still need to be sent as well, but that is nothing special). Basically they are always generated at Runtime unless a Class with the same name already exists in which case it would be used.
The $GENERIC_DESCRIPTOR and $GENERIC_BYTES from the base class along with the new Type name are all that is required to generate the classes at runtime. However many other approaches can achieve the same thing for the generation, and approaches such as NextGen's template approach may be better. As this generation is only done once per class I didn't put much research into this area. The way it currently works is that the $GENERIC_DESCRIPTOR are basically used to verify that a malicious class files is not trying to create a non Type Safe Type, ie new Sample<Object>() when the class definition said class Sample<TypeA extends Button>. The $GENERIC_BYTES basically correspond to the normal bytes of a wrapper class file, except that in the constant pool it has some constants of a new Parametric Constant type that get replaced at class load time. These parametric constants (along with possibly Utf8 and Class constants) are replaced by the Classes at the end of the new type name, a little more complex than that but you probably get the general idea.
These fine implementation details don't affect the approach so much anyway, as they basically come down to class load time performance. Much of the information in the $GENERIC_BYTES could have been worked out by reflection on the base type, however at least for now simply storing the bytes is a lot easier.
Note: I have made a small syntax change to the requested class:
public T(X datum) --> public T<X>(X datum)
class T<X> {
private X datum;
public T<X>(X datum) {
    this.datum = datum;
public T<T<X>> box() {
    return new T<T<X>>(this);
public String toString() {
    return datum.toString();
public static void main(String[] args) {
    T<String> t = new T<String>("boo!");
    System.out.println(t.box().box());
}would get translated as:
class T {
public static final Class[][] $GENERIC_DESCRIPTOR = {{Object.class}};
public static final byte[] $GENERIC_BYTES = {/*Generic Bytes Go Here*/};
private Object datum;
private static final Field $0 = Reflection.getDeclaredField(T.class, "datum");
private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C1T.class, new Class[] {T.class});
static void $2(Field _0, Object _1, Object _2) {
    Reflection.set(_0, _1, _2);
static Object $3(Constructor _0, Object _1) {
    try {
      return Reflection.newInstance(_0, new Object[] {_1});
    catch (Exception ex) {
      throw (RuntimeException)ex;
static String $4(Field _0, Object _1) {
    return Reflection.get(_0, _1).toString();
static void $5() {
    T$$C16java_lang_String t = new T$$C16java_lang_String("boo!");
    System.out.println(t.box().box());
public T(Object datum) {
    $2($0, this, datum);
public T$$C1T box() {
    return (T$$C1T)$3($1, this);
public String toString() {
    return $4($0, this);
public static void main(String[] args) {
    $5();
}as the generic bytes aren't very meaningful and by no means a requirement to this approach (NextGen's template method for generation may work just as well), here are the generated classes with some unused code commented out instead:
class T$$C28T$$C22T$$C16java_lang_String {
private T$$C22T$$C16java_lang_String datum;
private static final Field $0 = Reflection.getDeclaredField(T$$C28T$$C22T$$C16java_lang_String.class, "datum");
// private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C34T$$C28T$$C22T$$C16java_lang_String.class, new Class[] {T$$C28T$$C22T$$C16java_lang_String.class});
public T$$C28T$$C22T$$C16java_lang_String(T$$C22T$$C16java_lang_String datum) {
    T.$2($0, this, datum);
// public T$$C34T$$C28T$$C22T$$C16java_lang_String box() {
//    return (T$$C34T$$C28T$$C22T$$C16java_lang_String)T.$3($1, this);
public String toString() {
    return T.$4($0, this);
public static void main(String[] args) {
    T.$5();
class T$$C22T$$C16java_lang_String {
private T$$C16java_lang_String datum;
private static final Field $0 = Reflection.getDeclaredField(T$$C22T$$C16java_lang_String.class, "datum");
private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C28T$$C22T$$C16java_lang_String.class, new Class[] {T$$C22T$$C16java_lang_String.class});
public T$$C22T$$C16java_lang_String(T$$C16java_lang_String datum) {
    T.$2($0, this, datum);
public T$$C28T$$C22T$$C16java_lang_String box() {
    return (T$$C28T$$C22T$$C16java_lang_String)T.$3($1, this);
public String toString() {
    return T.$4($0, this);
public static void main(String[] args) {
    T.$5();
class T$$C1T {
private T datum;
private static final Field $0 = Reflection.getDeclaredField(T$$C1T.class, "datum");
// private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C6T$$C1T.class, new Class[] {T$$C1T.class});
public T$$C1T(T datum) {
    T.$2($0, this, datum);
// public T$$C6T$$C1T box() {
//    return (T$$C6T$$C1T)T.$3($1, this);
public String toString() {
    return T.$4($0, this);
public static void main(String[] args) {
    T.$5();
class T$$C16java_lang_String {
private String datum;
private static final Field $0 = Reflection.getDeclaredField(T$$C16java_lang_String.class, "datum");
private static final Constructor $1 = Reflection.getDeclaredConstructor(T$$C22T$$C16java_lang_String.class, new Class[] {T$$C16java_lang_String.class});
public T$$C16java_lang_String(String datum) {
    T.$2($0, this, datum);
public T$$C22T$$C16java_lang_String box() {
    return (T$$C22T$$C16java_lang_String)T.$3($1, this);
public String toString() {
    return T.$4($0, this);
public static void main(String[] args) {
    T.$5();
}the methods from the Reflection class used in these answers not given in my initial description are:
public static final Object newInstance(Constructor aConstructor, Object[] anArgsArray) throws Exception {
    try {
      return aConstructor.newInstance(anArgsArray);
    catch (InvocationTargetException ex) {
      Throwable cause = ex.getCause();
      if (ex instanceof Exception) {
        throw (Exception)ex;
      throw new Error(ex.getCause());
    catch (Exception ex) {
      throw new Error(ex);
public static final Constructor getDeclaredConstructor(Class aClass, Class[] aParameterTypesArray) {
    try {
      Constructor constructor = aClass.getDeclaredConstructor(aParameterTypesArray);
      constructor.setAccessible(true);
      return constructor;
    catch (Exception ex) {
      throw new Error(ex);
}

Fonts different between java 1.3.1_01 and 1.4.2_02

I have upgraded to java 1.4.2_02 from 1.3.1_01 and most of my fonts now appear to be different. Do I really need to edit my application to make my fonts look like they did in the past or is there some sort of setting that will take care of this for me. For instance in 1.3.1_01 the font sansserif-bold-12, looks bold on my display. However in 1.4.2_02 it does not look bold. If I change the size to 14, then it does look bold.
Does anyone have any ideas?

No upgrade to graphics card. I still have java1.3.1_01 installed and if I change the path to use java 1.3.1_01 my fonts look okay. When I change the path to use java 1.4.2_02, they are not bold.

TimeInMillis different in java than in C

I have a a problem getting a match between the epoche seconds derived within a C program and the return value of System.currentTimeMillis(); Here is an example:
* Simple C program for running on Windows Machines
* My testing is occuring on Win2K
#include <time.h>
int main()
   printf("hello %ld\n", time(NULL));
   return 0;
// end TestTime.c
* Simple Java Program grabbing epoche
* Tested on same system
public class TimeTest
   public static void main(String[] args)
      System.out.println(System.currentTimeMillis());
// end TestTime.javaOutput of these programs occured at Jun 12, 2002 at about 11:04am
C prints: 1023894070
Java prints: 1023894043362
Any ideas? Should I be using a different Java call? I need to compare the two which is not possible with how different the outputs are.

Wow, quickest response I have ever recieved!
I know they are not exact becuase I am at a DOS prompt doing this:
C:\test> TestTime
c time
C:\test> java TestTime
java time
I don't expect them to be identical becuase I can only type so fast.
These appear to have been run about 27 seconds apart.I have a DOS window filled with different executions and print outs. I could of copied the wrong time into the last post.
Here is a print out executing them as fast as I can type "java TestTime" after running the c version.
C: ��1023895806
Java: 1023895808029
My question is should I just append three 0's onto the C version. I need to run lines like this:
if(javaTime >= curSysTimeFromC) which would always be true due to the more accurate reading given by java. This little C program will act like a UNIX CRON. My java program edits the files read by the C version. The files are simple key/value pairs of which the C program looks for, "time=epoche_seconds", pair.

Different comportment JAVA/JSP on Oracle Schema

Hi,
I run on a probably corrupted Oracle Schema a class in two ways: first - directly run it and second - by calling the class through a JSP file (on Apache Tomcat 4.1.18), and I obtain different results (using JDBC ojdbc14.jar both times).
I run the same tests on a good schema and the results are the same.
Do you think I have a really corrupted schema? If not, what can be the problem I encounter?
Thank you

Hi Dinh,
I don't mean to be rude, but let me try and give you an idea of
how your question looks to me, by asking you a question...
I have a java application that is made up of about 150 java
classes. It runs well in Visual J++. Now I am porting it to
JDeveloper and I get a "NullPointerException". How do I fix that?
Hopefully, you get the picture. Personally, I need a lot more
information in order to help you. For starters, the stack trace
from the exception you got, and the code that throws that
exception. Just saying that 9iAS complains about "getContextName"
doesn't help, because there are at least three versions of this
method in the "javax" package hierarchy. Pardon my ignorance, but
which one are you referring to? Perhaps 9iAS is complaining about
the method "setAtribute" because you probably spelled it wrong?
Shouldn't it be "setAttribute"?
I think I speak for the majority when I say, if you want us to
help you, please supply more details.
Thanks,
Avi.

Report Result differs between Java Web and ABAP Web

Hi Experts,
We have a BW Report in BI NW 7.0. When we run the report in Bex (ABAP Stack) or ABAP Web the default results are different from the Java Web Results. There are no selection differences.
Please help me if I miss any settings or any corrections required.
Thanks in advance.
Deepthi.

Hi,
The function Calculate Results as ... could not be applied everywhere.
Recalculation of a resutls row is always based on the amount of detail cells subordinate to this cell, which is the finest details of a drilldown. It is not possible to recalculate resutls in hierarchical lists. This means that calculation of a results cell is not performed if a row or column with an expand symbol is subordinate to it. With recalculation, the newly calculated result has to change with each expansion of a node subordinate to it. This is not supported for technical reasons and would only confuse the user.
Note, however, that Calculate Results as -> Suppress Results is always executed, because the problem above does not apply in that case.
Notification Number BRAIN 141
Please refer the notes
Note 1071067 - "Calculate Singlve Value as" in list without drilldown
Note 997421 - Calculate as 'Supress Result' on hierarchy nodes
Note 857895 - 'Suppress results' for the display hierarchy
Note 853058 - Calculate Results/Single Values as ... priority rules
Hope this helps.
Regards
Srikanth

MS Access queries different to Java SQL statements

Ok, i dont understand something:
My program is connected to a MSAccess datasource. The query in MSAccess is
SELECT *
FROM Food_Data
WHERE Description Like 'Cheese*';
...but this wont work with a Java SQl query. I have to use this instead:
String query = "SELECT * FROM Food_Data " +
"WHERE Description LIKE 'Cheese%'";
Surely java would just passes the string query to MSAccess. But no. Java needs '%' as the wildcard, and MSAccess needs '*' as the wildcard.
Can anyone please explain this to me?

Well % is the standard wildcard character for SQL as defined by the ANSI standard. MS Access just doesn't conform to this standard.
Having said that, I'm still kind of astonished that it doesn't work :-)
The JDBC driver should pass the statement "as is" to the underlying DBMS, but obviously the JDBC/ODBC bridge does some "quirking". But maybe it
s the ODBC datasource. I can see a "ExtendedAnsiSQL" setting in one of my Access ODBC settings, maybe that changes something.

RPT_MOPZ_COPY_STACK_XML shows SC version differs for JAVA and DUAL-Stack xml files

Hi All,
I am using the report/program RPT_MOPZ_COPY_STACK_XML to copy the stack xml file I used from a previous upgraded system. Systems are identical. However, report shows below..
"Software Component Version KRNL64UC7.20 [01200615320200013056] differs between <System1> and <System2>"
and
Software Component Version SAPJVM6.1 [01200615320200012982] differs between <System1> and <System2>"
However, this is not the case when checked, it's strange that this particular component has the same version between the two systems, but the report says they differs in version.
Please help check how to resolve the issue.
SAP notes mentioned in below KBA were already obsolete. Solution Manager system just upgraded to 7.1 SP11.
1711612 - RPT_MOPZ_COPY_STACK_XML Report Troubleshooting.
We would appreciate your response for us to resolve this issue. Thanks.
Regards,
Philip

Hi Jansi, Divyanshu,
Both system have the same patch levels.
Here the situation, SYS1 is where we generated the stack xml file. Afterwards, used that stack file to upgrade SYS1.
Now we built SYS2, ensuring it has the same components version with the un-upgraded version of SYS1, so yes they have same patch number for same components, for this issue, kernel and jvm.
Thus, instead of running MOPZ for SYS2, we used RPT_MOPZ_COPY_STACK_XML to convert the stack file of SYS1 to be used for SYS2.
This is where we encountered below messages, when performing the copy.
"Software Component Version KRNL64UC7.20 [01200615320200013056] differs between <System1> and <System2>"
and
Software Component Version SAPJVM6.1 [01200615320200012982] differs between <System1> and <System2>"
We previously used SOLMAN 7.0 SP23, and the report is working fine there. Then recently, solman was upgraded to 7.1 SP11, and now the report is not working with the above issue.
We would appreciate if you could share actions on how we can fix the issue.
Regards,
Philip

How is javaw tool different from java tool

hi
java tool for windows start programme in a console window and javaw starts without a console window..
how is this implemented in javaw ie what is the difference which allows it to do it
thanks
asif

It is not supposed to display the console window.
Obviously it doesn't work. It did at one time.it still works (1.4.0_01). you can use it and itfires
off java without console.I believe 'still' is incorrect. In earlier versions
it did not. However this might have varied by OS.
So have you tested it on Win 95, 98, Win 2000, Win
2000 ME, Win XP Pro and Win XP Home?
on NT 4 I have tested the following...
Java Runtime's 1.2, 1.3.1, 1.3.1_02 and 1.3.1_04
Development Kit 1.1.8,1.2.1,1.3.1_04 and 1.4.0_01
in all of these javaw does what it is supposed to do... namely launch
the runtime in a another process without a command window.
on Windows 95 I have tested the following
Java Runtime's 1.3.1_02 and 1.3.1_04
Development Kit 1.3.1_04 and 1.4.0_01
these all work.
i have also tested 1.3.1_04 runtime on 2000 and know that works.
i would would imagine that since the os arch is the same these should
all work on 98 and ME. the only os i don't know about is XP. what
"versions" are you talking about? pre 1.1.8... that would be pretty old.
anyway i think the original posted was asking something I don't know
what really but i don't think it had to do with javaw not working. he
seems to be asking how something works not why it doesn't
how is this implemented in javaw ie what is the difference which allows it to do it

JNI differs from java 1.5 to 1.6 ?

Dear JNI Experts
A simple JNI appl on windows XP behaves differentely:
In 1.5 all is correct, the MessageBox gets displayed, In 1.6 The MessageBox does not display, simply returns 0.
Als an isolated TestCase the follwing Modules in java, cpp and h.
JavaCode:
public class MsgBoxTest {
static{
System.load("MsgBox.dll");
public native static boolean MsgBox(String Message, String Title);
public MsgBoxTest() {
boolean confirmed = MsgBox("Test Message", "Heading");
System.out.println("User confirmed: " + confirmed);
public static void main(String[] args) {
MsgBoxTest mbt = new MsgBoxTest();
}The c++ Function:
#include <windows.h>
#include "MsgBox.h"
JNIEXPORT jboolean JNICALL Java_MsgBoxTest_MsgBox(JNIEnv *env, jclass cl, jstring message, jstring title){
const char *Message;
const char *Title;
boolean conf = false;
int ret;
Message = env->GetStringUTFChars(message, 0);
Title   = env->GetStringUTFChars(title, 0);
ret = MessageBox(NULL, Message, Title, MB_YESNO | MB_SYSTEMMODAL);
if(ret == IDYES) conf = true;
env->ReleaseStringUTFChars(message, Message);
env->ReleaseStringUTFChars(title, Title);
return(conf);
}the .h from javah:
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class MsgBoxTest */
#ifndef _Included_MsgBoxTest
#define _Included_MsgBoxTest
#ifdef __cplusplus
extern "C" {
#endif
* Class:     MsgBoxTest
* Method:    MsgBox
* Signature: (Ljava/lang/String;Ljava/lang/String;)Z
JNIEXPORT jboolean JNICALL Java_MsgBoxTest_MsgBox(JNIEnv *, jobject, jstring, jstring);
#ifdef __cplusplus
#endif
#endifThanks foy pur help!

I'm finding the same behavior. I have a set of released DLLs used in both Java and Non-Java applications via the use of a JNI wrapper. After a recent update of the JRE we're now finding that both MessageBox and DialogBox calls are failing, but only when running under the Java version.
The MessageBox version is failing with both a return code of 0 and a GetLastError of 0. Note, this is with a GetLastError called immediately after the return of the MessageBox function.
The DialogBox function is somewhat more interesting. For test purposes we instrumented the DialogProc handler. When running under a regular Win32 application, the messages sent are: WM_SETFONT, WM_INITDIALOG, WM_SETTEXT, ..., followed by many more messages and the dialog box is up and running.
When running under a Java application the messages sent are: WM_SETFONT, WM_DESTROY, WM_NCDESTROY, then the DialogBox function returns with a value of -1 (indicating the dialog box could not be created) and a GetLastError of 0.
Given the fact that MB_SERVICE_NOTIFICATION fixes the MessageBox issue, I'm wondering if any recent changes to java.exe have stripped out some of the boiler-plate win32 standard startup code, such as binding the application to a desktop or login session.

Can two java program write to the same port by fetching data from different

can two java program write to the same port by fetching data from different ports, if yes is thing possible for a 3rd program to get all data (is there any data loss or collision)
how is this possible

can two java program write to the same port by fetching data from different portsTwo java clients can connect to the same server port and they can both write to it. However the server will see the connections as two separate accepted sockets.

What is different between JES and Java EE SDK ?

Hi
Thank you for reading my post.
can some one tell me what is different between Java EE SDK and JES ?
What i think is:
- Both of them support Java EE 5.0
- Both of them has access manager 7.1
Can we develop application on JES using netbeans IDE ?
What technicall benefits JES bring that Java EE SDK does not?
Thanks

The Java EE SDK is a developer kit that includes Application Server 9 PE,
as well as early access to other technologies and tools related
to Java EE 5 development. It is primarily targeted at developers
for doing development and prototyping -- although you can also
use it in production.
Java Enterprise System is a larger integrated stack of software and
services sold under a subscription model. The current release includes
Application Server 8.2 EE (and is therefore J2EE 1.4 based), but also
includes a large number of other products such as Web Server,
Directory Server, Portal Server, etc. For more details see:
http://www.sun.com/software/javaenterprisesystem
Note that it is an unfortunate co-incidence that the current release
of Java Enterprise System is Java ES 5, which has nothing to do with
Java EE 5!
Yes you can use Netbeans to develop applications for Java ES.
So comparing the two is really comparing apples to oranges. If you
are a developer and want to develop Java EE 5 applications than the
Java EE SDK is likely best for you.
If you are interested in a broader portfolio of software and servcies
including deploying J2SE 1.4 applications than Java ES may be a good
match.
Joe

Java.io.NotSerializableException when overwrite the JTable data into .txt

hi everyone
i had java.io.NotSerializableException: java.lang.reflect.Constructor error when overwrite the JTable data into .txt file.
At the beginning, the code will be generate successfully and the jtable
will be showing out with the data that been save in the studio1.txt
previously,
but after i edit the data at the JTable, and when i trying to click the
save button, the error had been showing out and i cannot succeed to
save the JTable with the latest data.
After this error, the code can't be run again and i had to copy the studio1.txt again to let the code run 1 more time.
I hope i can get any solution at here and this will be very useful for me.
but i dunno how to attach my .txt file with this forum
did anyone need the .txt file?
the following is my suspect code
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
String filename1 = "studio1.txt";
          try {
              FileOutputStream fos = new FileOutputStream(new File(filename1));
              ObjectOutputStream oos = new ObjectOutputStream(fos);
               oos.writeObject(jTable2.getModel());
               oos.flush();
               oos.close();
               fos.close();
          catch(IOException e) {
               System.out.println("Problem creating table file: " + e);
                        e.printStackTrace();
               return;
          System.out.println("JTable correctly saved to file " + filename1);
}this is the reading code
String filename1="studio1.txt";
        try {
               ObjectInputStream ois = new ObjectInputStream(new FileInputStream(filename1));
               TableModel model = (TableModel)ois.readObject();
                jTable3.setModel(model);
               System.out.println("reading for " + filename1);
          catch(Exception e) {
               System.out.println("Problem reading back table from file: " + filename1);
               return;
          }Edited by: Taufulou on Jan 8, 2009 11:43 PM
Edited by: Taufulou on Jan 8, 2009 11:44 PM
Edited by: Taufulou on Jan 8, 2009 11:45 PM

is this the code u mean?
i had put this code inside it but the problem still remain the same
if (jTable2.isEditing()) {
            jTable2.getCellEditor().stopCellEditing();
        }i had found a new thing that when i just double click the cell without change any data inside the table
and click the button "Save". the same exception which is
java.io.NotSerializableException: java.lang.reflect.Constructor
will come out again.

GetCellEditor() / stopCellEditing() different in Java 1.4.0

Similar Messages

Maybe you are looking for