Assert statement (JDK 1.4). Bug in OJC ???!!!

It appears to be bug in the Oracle Java Compiler (OJC) of JDev 9.0.3 and JDev 9.0.2, if you have an assert statement in a method of a class that has an inner class or in a method of the inner class (any assert statement, anywhere in the code).
If the assert statement is in a method of the inner class, the OJC reports the following errors:
Error(x,y): variable $ad not found in class EnclosingClass.InnerClass
Error(x,y): constructor AssertionError(<anything>) not found in class java.lang.AssertionError
If the assert statement is in a method of the enclosing class, the OJC reports the following errors:
Error(p,q): constructor AssertionError(<anything>) not found in class java.lang.AssertionError
Obviously the option -source 1.4 is passed to the compiler; besides the option
AddVMOption -DEDITOR_ENABLE_ASSERT=true is set in jdev.conf
Certainly I can compile the code with the javac compiler of Sun's JDK 1.4.
Pablo.

Arno,
Please disregard Stuart's reply. There has been some confusion happening. We are aware of the issue and it has already been fixed in a subsequent (still not available) release. Please send me an email to [email protected] and I will send you a patch that fixes the issue. The patch is compatible with 9.0.3.1035. I assume that's what you are using.
Regards,
Michel

Similar Messages

Help with assert statement

Hi all ,
The following is the discussion given in "JAVA LANGUAGE SPECIFICATION " at the section The assert statement(14.10)It says about the circularity to be treated as special condition in assert.
Tried to execute the code , encountering a compile time error
at // assert enabled =true;
following is the code :-
DISCUSSION
There is one case that demands special treatment. Recall that the assertion status of a
class is set at the time it is initialized. It is possible, though generally not desirable, to execute
methods or constructors prior to initialization. This can happen when a class hierarchy
contains a circularity in its static initialization, as in the following example:
public class Foo {
public static void main(String[] args) {
Baz.testAsserts();
// Will execute after Baz is initialized.
class Bar {
static {
Baz.testAsserts();
// Will execute before Baz is initialized!
class Baz extends Bar {
static void testAsserts(){
boolean enabled = false;
assert enabled = true; // COMPILATION ERROR
System.out.println("Asserts " +
(enabled ? "enabled" : "disabled"));
Invoking Baz.testAsserts() causes Baz to get initialized. Before this can happen, Bar
must get initialized. Bar�s static initializer again invokes Baz.testAsserts(). Because initialization
of Baz is already in progress by the current thread, the second invocation executes
immediately, though Baz is not initialized (JLS 12.4.2).
If an assert statement executes before its class is initialized, as in the above
example, the execution must behave as if assertions were enabled in the class.
DISCUSSION
In other words, if the program above is executed without enabling assertions, it must print:
Asserts enabled
Asserts disabled
So please let me go through the right course so as to execute the aforementioned program.
Regards
Mukul Sharma

Dear Sir jverd ,
even if we code assert (enabled=true);
this works absolutely fine ,because enabled is declared of type boolean,and according to syntax we can write
assert Expression1, Expression2 , where Expression1 is of type boolean. I've tried this out and the rendered output was the expected one.
One more thing that i would like to confess , the code given in java language specification at section 14.10 is absolutely right. Mistake lied in the way i was trying to compile the code. actually i was trying that on IDE , so compilation error was given in the respected file.So when i tried to compile the same file on notepad , i was just compiling the(individual) source file in which i was getting error. Before that i must compile the superclass also , since there is static circularity , compiling the individual file gives error.
To rectify that if we compile all three files together i.e.
javac -source 1.4 *.java OR javac -source 1.4 Foo.java
In this case it works properly. even if we code assert enabled =true;I am extremely very soory for that ,I coudn't compile that in a proper manner. I regret for the inconvinience you all had to face.I assure you not to log any problem without trying that thoroughly in future.
Thanks for your supprt.
Regards

[svn:cairngorm3:] 17872: Popup: Exposed set accessor of open for view state usage and fixed bug when closing from model within popup .

Revision: 17872
Revision: 17872
Author:   [email protected]
Date:     2010-09-27 08:04:40 -0700 (Mon, 27 Sep 2010)
Log Message:
Popup: Exposed set accessor of open for view state usage and fixed bug when closing from model within popup. http://www.spicefactory.org/forum/viewtopic.php?p=3932. Added new sample to show model and view state interactions.
Modified Paths:
    cairngorm3/trunk/libraries/Popup/src/com/adobe/cairngorm/popup/PopUpBase.as
    cairngorm3/trunk/libraries/Popup/src/com/adobe/cairngorm/popup/PopUpFactory.as
    cairngorm3/trunk/libraries/Popup/src/com/adobe/cairngorm/popup/PopUpWrapper.as
    cairngorm3/trunk/libraries/PopupTest/.actionScriptProperties
    cairngorm3/trunk/libraries/PopupTest/src/samples/MyPopup.mxml
    cairngorm3/trunk/libraries/PopupTest/src/samples/PopUpPM.as
Added Paths:
    cairngorm3/trunk/libraries/PopupTest/src/PopUpModelExample.mxml
    cairngorm3/trunk/libraries/PopupTest/src/samples/MyPopupWithModel.mxml

Lots to be excited about. BUT...Just updated to 8.1 on one of my computers to test it out...
Sadly, the following issue is NOT fixed for me. Is it with new projects only? I haven't started a new project on 8.1 I've only opened an old project but the issue that I'm referring to which involves also a delay/freeze of anywhere from a few seconds to a MINUTE while the render bar goes from yellow to red and then back to yellow is still there. Boo.
On the list above...
Switching between sequences can turn the render bar red.
This issue is incredibly easy to replicate. I really do hope it gets fixed. Here are the steps:
1) Create two sequences with multiple short clips (the more clips the better)
2) Make sure GPU acceleration is enabled.
3) Add warp stabilizer to the clips in both sequences. Again, the more clips the longer the delay/freeze will be as the render bar goes from YELLOW to RED and then eventually back to YELLOW again.
4) Hit SAVE.
5) Now, toggle between sequences. You'll hit a short delay with a few clips stabilized and a LONG delay with lots stabilized. In my case this delay is around a full minute. The render bar will go from YELLOW to RED and then back to yellow...eventually.
6) Toggle back to the original sequence and the delay occurs again.
7) Once you've toggled between sequences and have gone through this delay, that's it, there is no longer a delay...UNTIL...(and here's the big kicker)...until the project is SAVED again. After that the issue returns when you toggle between sequences. Both saving manually and AUTOSAVING cause this issue. No way around it except not editing with GPU acceleration.
Not sure what the issue is...caching issue when saving maybe? Either way, it stinks and it's still there in 8.1. Big bummer.
Again, lots to be excited about with this release but I really was hopefully this specific issue was resolved.
Sigh.

I cannot use my pogo account as it states firefox has a bug in it and will not let java open

I cannot use my pogo account this is what it states, how do I fix this, it worked fine this morning and tonight it isn't working
It looks like you’ve the new version of Firefox. Unfortunately, there is currently a bug that is preventing players from playing Java games with version 3.6.14 of Firefox.

See this: <br />
https://support.mozilla.com/en-US/kb/pogo-and-other-java-pages-dont-work

Jdk 1.5 bugs

I sent these to the provided feedback email, but that felt a little too much like a black hole, so I figured that I would post those issues here as well. Please let me know if there is a more appropriate forum. Also, my apologies if these problems have been mentioned before.
I have noticed runtime and/or compiler errors with the following pieces of code:
Example:
List<Integer> list = new ArrayList<Integer>();
list.add(1);
for (int i : list) {}
Error (run-time):
Exception in thread "main" java.lang.VerifyError: (class: Test1, method: main si
gnature: ([Ljava/lang/String;)V) Expecting to find integer on stack
Example:
int[] array = new int[1];
array[0] = 1;
for (Integer i : array) {}
Error (compile-time):
An exception has occurred in the compiler (1.5.0-beta). Please file a bug at the
Java Developer Connection (http://java.sun.com/cgi-bin/bugreport.cgi) after ch
ecking the Bug Parade for duplicates. Include your program and the following dia
gnostic in your report. Thank you.
java.lang.ArrayIndexOutOfBoundsException: -1
at com.sun.tools.javac.jvm.Code$State.pop(Code.java:1505)
at com.sun.tools.javac.jvm.Code.emitop0(Code.java:588)
at com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:233)
at com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:246)
at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:803)
at com.sun.tools.javac.jvm.Gen.visitVarDef(Gen.java:954)
at com.sun.tools.javac.tree.Tree$VarDef.accept(Tree.java:502)
at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:648)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:683)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:669)
at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:720)
at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:967)
at com.sun.tools.javac.tree.Tree$Block.accept(Tree.java:531)
at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:648)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:683)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:669)
at com.sun.tools.javac.jvm.Gen.genLoop(Gen.java:1013)
at com.sun.tools.javac.jvm.Gen.visitForLoop(Gen.java:984)
at com.sun.tools.javac.tree.Tree$ForLoop.accept(Tree.java:577)
at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:648)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:683)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:669)
at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:720)
at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:967)
at com.sun.tools.javac.tree.Tree$Block.accept(Tree.java:531)
at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:648)
at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:683)
at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:905)
at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:841)
at com.sun.tools.javac.tree.Tree$MethodDef.accept(Tree.java:473)
at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:648)
at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2167)
at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:321)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:460)
at com.sun.tools.javac.main.Main.compile(Main.java:584)
at com.sun.tools.javac.main.Main.compile(Main.java:536)
at com.sun.tools.javac.Main.compile(Main.java:41)
at com.sun.tools.javac.Main.main(Main.java:32)
Example:
List<Double> list = new ArrayList<Double>();
list.add(1.0);
list.add(2);
for (Double d : list) { System.out.println(d); }
Error (run-time):
1.0
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer
at Test1.main(Test1.java:13)
Sincerely,
Kevin Regan

The first example maybe is a normal "feature" hidden somewhere in the specs. It would read something like: "No autoboxing in extended for loops".
The second example is clearly a bug. It either compiles or not, it should never crash.
The third example maybe is the appropriate behavior.
This is a list of Double declared here. Then you add an int to the list.
I don't think the boxing conversion should convert int to Double.

Bug in ojc (compiler)

JDev Team,
OJC successfully compiles the following code but javac does not. Case test compilation should fail since it is not a compile time constant. I have another question though. Why is JDeveloper using OJC? What are the benefits? Please let me know.
final int test;
test = 2;
int x = 0;
switch (x)
case test: System.out.println("case test compiled");
Thanks
Bala.

Hi,
I can reproduce this problem, and I have filed bug 6748835.
One main reason OJC exists is for performance. It's faster than javac, and uses less memory.
Thanks,
Brian

TOO_MANY_ROWS leaves variable in indeterminate state - Is this a bug?

Hello all,
Please see below that despite the handled exception, PL/SQL still alters the coontents of the variable. - I cannot reply on its initial state if there is a possibility of a TMR exception ..... it seems.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
5 rows selected.
SQL> -- Is this a problem ????
SQL>
SQL> set serveroutput on
SQL>
SQL> create table tab1(col1 varchar2(12) );
Table created.
SQL>
SQL> insert into tab1 values ('A');
1 row created.
SQL> insert into tab1 values ('B');
1 row created.
SQL> insert into tab1 values ('A');
1 row created.
SQL>
SQL> select * from tab1;
COL1
A
B
A
3 rows selected.
SQL>
SQL> declare
2 l_var varchar2(12) := 'Y'; -- initialise
3 begin
4
5 dbms_output.put_line('Initialise l_var: '||l_var);
6
7 select col1
8 into l_var
9 from tab1
10 where col1 = 'A';
11
12 dbms_output.put_line('Never get here - l_var: '||l_var);
13
14 exception
15 when TOO_MANY_ROWS then
16 dbms_output.put_line('What am i now? l_var: '||l_var);
17 end;
18 /
Initialise l_var: Y
What am i now? l_var: A
PL/SQL procedure successfully completed.
SQL>
SQL>
SQL> drop table tab1;
Table dropped.
SQL>
If you would like to try this yourself, cut from here ....
-- Is this a problem ????
set serveroutput on
create table tab1(col1 varchar2(12) );
insert into tab1 values ('A');
insert into tab1 values ('B');
insert into tab1 values ('A');
select * from tab1;
declare
l_var varchar2(12) := 'Y'; -- initialise
begin
dbms_output.put_line('Initialise l_var: '||l_var);
select col1
into l_var
from tab1
where col1 = 'A';
dbms_output.put_line('Never get here - l_var: '||l_var);
exception
when TOO_MANY_ROWS then
dbms_output.put_line('What am i now? l_var: '||l_var);
end;
drop table tab1;

I presume you are talking of "right" in a moral sense, rather than any other sense. An nice philosophical point.
Look at it this way. In the old days, Oracle wiped the variable whenever a TOO_MANY_ROWS exception was raised. This is "clean" but sometimes people might want to know the previously fetched value. Hence the change in Oracle 8. If you don't want to know the value, then just ignore it in the exception handler.
The only scenario it which I can see this being a potential problem is when you're fetching into an OUT parameter.. This is of course A Bad Thing and as it happens Oracle seems to save us from ourselves (at least in 9.2.0.6)...
SQL> set serveroutput on
SQL> var n number
SQL> create or replace procedure get_emp_sal (p_name in varchar2, p_sal out number)
2 as
3     l emp.sal%type;
4 begin
5       select sal into l
6      from emp
7      where ename = p_name;
8      p_sal := l;
9 exception
10      when too_many_rows then dbms_output.put_line('l='||l);
11 end;
12 /
Procedure created.
SQL> exec get_emp_sal ('VAN WIJK', :n)
l=1250
PL/SQL procedure successfully completed.
SQL> print n
         N
SQL> create or replace procedure get_emp_sal (p_name in varchar2, p_sal out number)
2 as
3     l emp.sal%type;
4 begin
5      select sal into p_sal
6      from emp
7      where ename = p_name;
8 exception
9      when too_many_rows then dbms_output.put_line('l='||l);
10 end;
11 /
Procedure created.
SQL> exec get_emp_sal ('VAN WIJK', :n)
l=
PL/SQL procedure successfully completed.
SQL> print n
         N
SQL> Cheers, APC

Mail attachment assertion failure Yosemite - Mail app bug

Hi,
I am facing a very annoying issue with Mail app. Since the upgrade to Yosemite, I am unable to save attachments with the "save all" button and the drag and drop is not working properly (sometime freezing the mail app for a minute). I am using Yosemite 10.10.2
I tried every fix I have read online, such as :
- rebuild mailboxes
- repair permissions
- remove 3 enveloppe index files in .../V2/MailData
- reindex spotlight
- run the command to repair permissions & reset home directory permissions and ACL (from this post : Mavericks Mail "Save Attachement..." doesn't work)
- onyx automations...
Nothing presented above fixed the problem.
Here are the console logs related to the issue :
20/02/2015 03:38:49,690 mdwrite[4655]: -[MDKeyRing initWithService:label:comment:] (/SourceCache/Spotlight/Spotlight-917.1/xpc-services/mdwrite/MDKeyRing.m:294) failed assertion -- Couldn't add Spotlight Metadata Privacy password to keychain! [osErr:-25295]
20/02/2015 03:38:49,973 Mail[4088]: Metadata.framework [Error]: error Connection interrupted
20/02/2015 03:38:49,973 Mail[4088]: *** Assertion failure in -[MailWebAttachment _addPrivateAttributes:], /SourceCache/Mail/Mail-2070.6/Mail/MessageDisplay/MessageView/DocumentModel/Mai lWebAttachment.m:331
20/02/2015 03:38:49,973 Mail[4088]: [QL] Exception raised while try to get launch url for preview item: Failure in _MDItemSetPrivateAttributes: 3
There is apparently a problem with the privacy attributes. Any idea of how to solve it?
Thanks for your help,
Best,
Laurent

Hi,
I am facing a very annoying issue with Mail app. Since the upgrade to Yosemite, I am unable to save attachments with the "save all" button and the drag and drop is not working properly (sometime freezing the mail app for a minute). I am using Yosemite 10.10.2
I tried every fix I have read online, such as :
- rebuild mailboxes
- repair permissions
- remove 3 enveloppe index files in .../V2/MailData
- reindex spotlight
- run the command to repair permissions & reset home directory permissions and ACL (from this post : Mavericks Mail "Save Attachement..." doesn't work)
- onyx automations...
Nothing presented above fixed the problem.
Here are the console logs related to the issue :
20/02/2015 03:38:49,690 mdwrite[4655]: -[MDKeyRing initWithService:label:comment:] (/SourceCache/Spotlight/Spotlight-917.1/xpc-services/mdwrite/MDKeyRing.m:294) failed assertion -- Couldn't add Spotlight Metadata Privacy password to keychain! [osErr:-25295]
20/02/2015 03:38:49,973 Mail[4088]: Metadata.framework [Error]: error Connection interrupted
20/02/2015 03:38:49,973 Mail[4088]: *** Assertion failure in -[MailWebAttachment _addPrivateAttributes:], /SourceCache/Mail/Mail-2070.6/Mail/MessageDisplay/MessageView/DocumentModel/Mai lWebAttachment.m:331
20/02/2015 03:38:49,973 Mail[4088]: [QL] Exception raised while try to get launch url for preview item: Failure in _MDItemSetPrivateAttributes: 3
There is apparently a problem with the privacy attributes. Any idea of how to solve it?
Thanks for your help,
Best,
Laurent

JDK 1.5 bug: FileContentsImpl.setMaxLength()

OK - not only is this a bug, but it's a good example of how incredibly horrid the new logging format is. The bug is in the JWS Swing code that displays a dialog asking the user if they want to increase the maxLength of a file. Here is the smallest relevant part of the log spewage:
(Maybe I wouldn't mind so much if com.sun.deploy.util.LoggerTraceListener was documented and provided an option to "normalize" this)
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614993</millis>
<sequence>146</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message>Exception occurred during event dispatching:
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614993</millis>
<sequence>147</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message>java.lang.IllegalArgumentException: Invalid remove
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614996</millis>
<sequence>148</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at javax.swing.JTextArea.replaceRange(JTextArea.java:505)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614996</millis>
<sequence>149</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.deploy.util.ConsoleWindow$24.run(ConsoleWindow.java:572)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614997</millis>
<sequence>150</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:201)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614997</millis>
<sequence>151</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614997</millis>
<sequence>152</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614997</millis>
<sequence>153</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614997</millis>
<sequence>154</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614998</millis>
<sequence>155</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.Dialog+1.run(Dialog.java:514)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614998</millis>
<sequence>156</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.awt.Dialog.show(Dialog.java:535)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614998</millis>
<sequence>157</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.SmartSecurityDialog.getUserDecision(SmartSecurityDialog.java:110)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>158</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.SmartSecurityDialog.access$100(SmartSecurityDialog.java:22)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>159</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.SmartSecurityDialog$1.run(SmartSecurityDialog.java:67)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>160</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.security.AccessController.doPrivileged(Native Method)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>161</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.SmartSecurityDialog.showDialog(SmartSecurityDialog.java:64)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>162</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.SmartSecurityDialog.showDialog(SmartSecurityDialog.java:59)
</message>
</record>
<record>
<date>2004-02-17T23:13:34</date>
<millis>1077077614999</millis>
<sequence>163</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.PersistenceServiceImpl$10.run(PersistenceServiceImpl.java:362)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615000</millis>
<sequence>164</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at java.security.AccessController.doPrivileged(Native Method)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615001</millis>
<sequence>165</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.PersistenceServiceImpl.askUser(PersistenceServiceImpl.java:356)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615001</millis>
<sequence>166</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.PersistenceServiceImpl.reconcileMaxSize(PersistenceServiceImpl.java:185)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615002</millis>
<sequence>167</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.PersistenceServiceImpl.checkSetMaxSize(PersistenceServiceImpl.java:168)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615002</millis>
<sequence>168</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.PersistenceServiceImpl.setMaxLength(PersistenceServiceImpl.java:97)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615002</millis>
<sequence>169</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.sun.jnlp.FileContentsImpl.setMaxLength(FileContentsImpl.java:143)
</message>
</record>
<record>
<date>2004-02-17T23:13:35</date>
<millis>1077077615003</millis>
<sequence>170</sequence>
<logger>com.sun.deploy</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message> at com.wss.c.setNewMaxLength(c.java:1697)
</message>
</record>

I just wanted to add that this is a showstopper for me as the TV-listings data just doesn't fit in the 256KB default size.

What makes JUnit better than regular assert statements?

I was reading up a little on JUnit and it seems like it's purpose is to check conditions to see if there true and shoot out an error if they're not. Unless I'm missing something doesn't assert do the same thing?

I actually had them seperate but I combined them for the post. I create a seperate method identical to the first except Gates is misspelled in the first and Bill in the second and I called them back to back and it still shoots out only one error:
package testproject;
import java.util.StringTokenizer;
import junit.framework.TestCase;
public class Main {
    public Main() {
        TestCsvParser test = new TestCsvParser();
        test.testParseSimpleLine();
        test.testParseSimpleLine2();
    public static void main(String[] args) {
        new Main();
    class TestCsvParser extends TestCase {
        public void testParseSimpleLine() {
            CsvParser parser = new CsvParser();
            parser.parse("Bill,Gates,555-1234");
            assertEquals("You returned an error!","Bill",parser.get(0));
            assertEquals("Gatesj",parser.get(1));
            assertEquals("555-1234",parser.get(2));
        public void testParseSimpleLine2() {
            CsvParser parser = new CsvParser();
            parser.parse("Bill,Gates,555-1234");
            assertEquals("You returned an error!","Bikll",parser.get(0));
            assertEquals("Gates",parser.get(1));
            assertEquals("555-1234",parser.get(2));
    class CsvParser {
        private String[] currentLine;
        public CsvParser() {
        public void parse(String inputLine) {
            StringTokenizer tokenizer = new StringTokenizer(inputLine,",");
            currentLine = new String[tokenizer.countTokens()];
            for (int i = 0; i < currentLine.length; i++) {
                currentLine[i] = tokenizer.nextToken();
        public String get(int columnIndex) {
            return currentLine[columnIndex];
}

Can not getReadMethod a jdk 1.5 bug?

import junit.framework.TestCase;
import org.apache.commons.lang.builder.ToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;
import org.apache.taglibs.standard.lang.jstl.BeanInfoManager;
import org.apache.taglibs.standard.lang.jstl.BeanInfoProperty;
import org.apache.taglibs.standard.lang.jstl.ELException;
import org.apache.taglibs.standard.lang.jstl.Logger;
import java.beans.BeanInfo;
import java.beans.Introspector;
import java.beans.PropertyDescriptor;
import java.io.PrintStream;
public class BeanInfoPropertyTest extends TestCase {
public Integer[] getPro1() {
return null;
public Integer[] getPro1(String n) {
return null;
public Integer[] getPro2() {
return null;
public Integer[] getPro2(int n) {
return null;
// public void testPro1() throws ELException {
// BeanInfoProperty property = BeanInfoManager.getBeanInfoProperty(BeanInfoPropertyTest.class,
// "pro1", new Logger(new PrintStream(System.out)));
// System.out.println(ToStringBuilder.reflectionToString(property,
// ToStringStyle.MULTI_LINE_STYLE, true));
// assertNotNull(property.getReadMethod());
// public void testPro2() throws ELException {
// BeanInfoProperty property = BeanInfoManager.getBeanInfoProperty(BeanInfoPropertyTest.class,
// "pro2", new Logger(new PrintStream(System.out)));
// System.out.println(ToStringBuilder.reflectionToString(property,
// ToStringStyle.MULTI_LINE_STYLE, true));
// assertNotNull(property.getReadMethod());
public void testC() {
Class c=BeanInfoPropertyTest.class;
try {
BeanInfo tagClassInfo = Introspector.getBeanInfo(c);
PropertyDescriptor[] pd = tagClassInfo.getPropertyDescriptors();
for (int i = 0; i < pd.length; i++) {
String name = pd.getName();
System.err.println(name + " displayName = " +
pd[i].getDisplayName());
System.err.println(name + " propertyType = " +
pd[i].getPropertyType());
System.err.println(name + " readMethod = " +
pd[i].getReadMethod());
System.err.println(name + " writeMethod = " +
pd[i].getWriteMethod());
} catch (Throwable v) {
v.printStackTrace();
result test with jdk1.4.2_05
class displayName = class
class propertyType = class java.lang.Class
class readMethod = public final native java.lang.Class java.lang.Object.getClass()
class writeMethod = null
name displayName = name
name propertyType = class java.lang.String
name readMethod = public java.lang.String junit.framework.TestCase.getName()
name writeMethod = public void junit.framework.TestCase.setName(java.lang.String)
pro1 displayName = pro1
pro1 propertyType = class [Ljava.lang.Integer;
pro1 readMethod = public java.lang.Integer[] com.alibaba.waf.tag.BeanInfoPropertyTest.getPro1()
pro1 writeMethod = null
pro2 displayName = pro2
pro2 propertyType = class [Ljava.lang.Integer;
pro2 readMethod = public java.lang.Integer[] com.alibaba.waf.tag.BeanInfoPropertyTest.getPro2()
pro2 writeMethod = null
result test with jdk1.5.0_6
class displayName = class
class propertyType = class java.lang.Class
class readMethod = public final native java.lang.Class java.lang.Object.getClass()
class writeMethod = null
name displayName = name
name propertyType = class java.lang.String
name readMethod = public java.lang.String junit.framework.TestCase.getName()
name writeMethod = public void junit.framework.TestCase.setName(java.lang.String)
pro1 displayName = pro1
pro1 propertyType = class [Ljava.lang.Integer;
pro1 readMethod = public java.lang.Integer[] com.alibaba.waf.tag.BeanInfoPropertyTest.getPro1()
pro1 writeMethod = null
pro2 displayName = pro2
pro2 propertyType = null
pro2 readMethod = null
pro2 writeMethod = null
Why pro2 readMethod is null ,can anyone explain it

i change the code ,but the result not change
What?
Please use code formatting when you post code. See formatting tips:
http://forum.java.sun.com/help.jspa?sec=formatting
Kaj

JDK 1.5 Serialization Compatibility with assert()

I have the following class:
class xyz implements java.io.Serializable {
   void doNothing() {
      int x = 0;
      assert x < 5;
}If I compile it on both JDK 1.4 (with -source=1.4) and 1.5 (with -source=1.5) platforms, the serialVersion IDs are different. If I comment out the assert statement, the serialVersion on 1.5 platform changes to be the same as the 1.4. If I rebuild the 1.4 with the assert commented out, the serialVersionID does not change.
Am I missing something here? I have code that needs to be compatible between these versions, but it now seems that the use of assert (other than the statment "assert true") built with 1.5 effects the serialization ID.

Sure, I can define my own version, but the point is that I've got many fielded classes that have not changed, but now will fail serialization when comunicating with the new system simply because of the use of assertions with 1.5.
It looks like I will be forced to either go back to 1.4, test all classes for serialization compatibility with 1.4, or remove the asserts from the code.
In any case, it does not make sence to me why adding an assertion should change the serialVersionUID of a class in the first place when compiling under 1.5 and not under 1.4.

Is this a JDK bug ?

exception
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLCon
nection.java:789)
is this a JDK bug ?
whats the come around ?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=453568To quote the link:
State      Closed, not a bug
The observed behaviour is as expected - if the http server returns
an error then getInputStream will throw an IOException.
Note that this doesn't preclude the application from reading the
response. The SOAP example can be modified as follows :-
HttpURLConnection httpConn = (HttpURLConnection)_urlConnection;
InputStream _is;
if (httpConn.getResponseCode() >= 400) {
    _is = httpConn.getInputStream();
} else {
     /* error from server */
    _is = httpConn.getErrorStream();
Given that this isn't a bug in the http client I am closing this
bug.If you are getting a 400 return code, and this exception, then it MIGHT be a bug.
PS Post full exceptions, don't cut them off.

Ojc will compile the following class. A bug?

I thought that in Java classes cannot be declared protected. ojc will however compile the following class:
protected class aclass
The Sun java compiler prints the following error:
aclass.java:1: modifier protected not allowed here
protected class aclass
Is this a known bug in the Oracle Java compiler?

Yes, it seems we have a little bug in OJC, the protected access modifier should only be allowed for member classes. I filed a bug report and I'll fix it.
Thanks!
Keimpe Bronkhorst
JDev Team

JDBC Statement Bug with OracleLite 4.0.1.2?

I have found what appears to be a bug. Has anyone else encountered this bug. I have the following code:
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select columnA,columnB from tableA");
while (rs.next())
System.out.println("ColumnA="+rs.getString("ColumnA"));
System.out.println("ColumnB="+rs.getString("ColumnB"));
rs.close();
rs = stmt.executeQuery("select column1, column2,column3 from Table1");
while (rs.next())
System.out.println("Column1="+rs.getString("Column1"));
System.out.println("Column2="+rs.getString("Column2"));
("Column3="+rs.getString("Column3"));
Column 3 is the problem. I get the
following Exception:
System.out.printlnjava.sql.SQLException: >>> [ODBC S1002] invalid column number
After researching it I found that you
cannot reuse a Statement object over and
over again. The reason is that the first
execution of a statement initializes the
number of columns to be returned and each
subsequent statement executed does not
reinitialize the column count. So in the
case above the column count is 2, and I
issue a query with 3 columns using the
same statement object, hence the bug.
I know the work around, just wanted to
know if this is a know bug.Any thoughts.
Mike H.

I've never heard of anything like this either. But I'm not sure I'm properly tracking what you say. You drop a PR file into the source well and it disappears? If you have a Finder window open and you drag it to the Batch window, you actually see the file deleted in the Finder window?
Or do you mean that the PR file doesn't get copied to the well?
Russ

Assert statement (JDK 1.4). Bug in OJC ???!!!

Similar Messages

Maybe you are looking for