Bug no Java?

Ola Daniel

eu não cheguei puxar suas classes e testar, mas o rápido que eu ví, é que na sua segunda compilada você compilou apenas o BugBean. Acredito se você compilar a classe com o Main, irá dar erro… (pelo menos eu acho)

Estranho isso passar pelo class verify da jvm
Tem cara de bug.

ManchesteR, isso eu sei… até falei isso no post.

Mas o problema é a JVM deixar rolar isso em runtime.

Onde será que eu informo no site da SUN?
Vou olhar!

Eu tava comentando isso com o Paulo um tempo atras. Nas VMs que eu botei a mao, a diretiva que fazia a verificacao de seguranca nao existia. Vi alguns posts sobre o assunto, e ate como “resolver”, mas nunca funcionou direito.

Rafael

"danieldestro":

Pessoal,

Outro dia, mostrando um pouco de Java para um amigo, eu me deparei com a seguinte situação:

Criei uma classe com um método main, que utiliza um Java Bean, acessando um atributo da classe bean. Porém, quando eu troquei o atributo de public para private, compilou e rodou normal.

Não seria isso considerado um BUG do Java? Pois como Java é moduralizado (classes), suponho que ele deveria verificar em runtime, os acessos aos atributos, métodos e outras, e não apenas em tempo de compilação.

Vejam o código simples:

public class BugBean {

  public String name;

  public BugBean() {}
}

public class TestBug {

  public static void main( String args[] ) {
    BugBean bug = new BugBean();
    bug.name = "The Big Bug Bean";
    System.out.println( bug.name );
  }
}

Para compilar e executar:

javac *.java
  java -cp . TestBug

Rodou normalmente, como esperado. Porém, se eu altero o código da classe BugBean, vejam o que acontece:

public class BugBean {

  //AGORA É PRIVATE
  private String name;

  public BugBean() {}
}

E compilo e rodo:

javac BugBean.java
  java -cp . TestBug

O programa roda normalmente.

Creio que seja um BUG do próprio Java. O que acham???

Estou usando Windows XP, como JDK 1.3.1 e JDK 1.4.1_02.

É isso aí!

Sei não. talvez seja um bug, mas eu tenho o seguinte palpite: acho que o compilador fez inlining na referência da classe BugBean dentro da classe TesteBug, o que acaba resultando neste comportamento. Mas é só um palpite.

isto é um bug mesmo, ou se preferirem, uma feature
tem que recompilar as duas classes para estas alterações fazerem efeito

Pééééééé. O javac nao faz nenhum tipo de otimização, como inlining. Quem faz isso é o hotspot

Pééééééé. O javac nao faz nenhum tipo de otimização, como inlining. Quem faz isso é o hotspot ;)
Putzzzzz!!! De fato… perdi 1 milhão?

SEGUE A RESPOSTA DA SUN PELO BUG REPORT QUE EU ABRÍ:

Hi Daniel Destro do Carmo:

You are describing Bug-id 4030988, entitled “Private isn’t!”?

http://developer.java.sun.com/developer/bugParade/bugs/4030988.html

The solution is to turn verification for all loaded classes
by adding “-verify” to the command line.

Public Summary:
Unless the “-verify” switch is supplied when starting the VM, it is possible
to create bytecodes which refer to private members of other classes,
and these bytecodes will be accepted by the VM if they are loaded
from disk via the classpath.

This is not a security hole, because only bytecodes loaded from local disk
are exempt from verification. However, it can cause some kinds of erroneous
non-applet code to spuriously link and run, at least until a recompilation
detects the problem.

If you are concerned about the possibility of this kind of
access, add the “-verify” or “-Xfuture” flags to the command
line when you start a Java Virtual Machine.

Best Regards-
Tim Bell [email removido] J2SE Engineering
Sun Microsystems Java Software http://java.sun.com/j2se

---

SunNetwork EMEA 2003 Conference and Pavilion

“Get Connected to the Future of Network Computing!”

WHEN: December 3-4, 2003
WHERE: ICC * Berlin, Germany

For more information or to register for the
conference, please visit http://sun.com/sunnetwork.

---

----------------- Original Bug Report-------------------

category : java

release : 1.4.1

subcategory : tools

type : bug

synopsis : JRE does not check accessibility of class members at runtime.

description : FULL PRODUCT VERSION :

java version “1.3.1_02”

Java™ 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)

Java HotSpot™ Client VM (build 1.3.1_02-b02, mixed mode)

java version “1.4.1_02”
Java™ 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot™ Client VM (build 1.4.1_02-b06, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows XP

A DESCRIPTION OF THE PROBLEM :
One, try to introduce Java to a friend I did the following:

I wrote two classes, one with the main method, that instantiate the other class and calls its attribute. It was just to show how Java works!

The first class called a public attribute from the other class and set a value (String). I compiled and ran the program. All right! As I was trying to explan how accessors work, I changed the attribute of the second class to private. I compiled just the second class and ran the program again, and it worked, for my surprise. I was expecting the program to abort due to a forbiden access.

You can take a look at the code:

public class BugBean {
public String name;

public BugBean() {}
}

public class TestBug {

public static void main( String args[] ) {

BugBean bug = new BugBean();

bug.name = “The Big Bug Bean”;

System.out.println( bug.name );

}

}

So, the next step was:
javac *.java
java -cp . TestBug

All fine… the reasult was what I was expecting for. But, when I changed the code of the ohter class:

public class BugBean {

//NOW IT IS PRIVATE

private String name;

public BugBean() {}
}

So, the next step was:
javac BugBean.java
java -cp . TestBug

It runs fine again.

Wasn’t it suppose to abort? Or, at least thrown an error?

I was using Windows XP, with both JDK 1.3.1 ande JDK 1.4.1_02.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create classes
compile both classes
run the program
change one class to private accessor
compile the changed class only
run the program again

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Program abortion

REPRODUCIBILITY :
This bug can be reproduced always.
workaround :
suggested_val :
cust_name : Daniel Destro do Carmo
cust_email : [email removido]
jdcid :
keyword : webbug
company : Softech Network
hardware : x86
OSversion : win_xp
bugtraqID : 4030988
dateCreated : 2003-11-28 05:33:02.5
dateEvaluated : 2003-12-01 10:51:10.797