Static import bug?

Hey just discovered something new...does this sound like a bug to you guys?
I have a class with a static method called, say, omgMethod()
and I have another class with a method (not static) with the same name (omgMethod) but different signature.
now when I try to use import static classA.omgMethod in the second class, it generates a compiler error:
cannot find symbol method omgMethod( etc...)
any thoughts? i'm thinking about adding it to the bug report.
-Cuppo

I'm not so sure about that. I have never used static import so I checked out Sun's tutorial which is here:
http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html
It talks about importing "members" and says you can import "members" individually. And (I had to look this up too in the JLS), "members" means classes, interfaces, fields, and methods.
So that says to me that you can indeed import a static method from another class, and then use it without qualification. Yeah, I'm surprised too. But you're just importing the method's name, not its signature. So if that name conflicts with a name of a method in your class, then I don't know what is supposed to happen. I looked through the JLS a bit and section 6.5.7.1 says
"The Identifier must name at least one visible (�6.3.1) method that is in scope at the point where the Identifier appear or a method imported by a single-static-import declaration (�7.5.3) or static-import-on-demand declaration (�7.5.4) within the compilation unit within which the Identifier appears.
See �15.12 for further discussion of the interpretation of simple method names in method invocation expressions."
Possibly section 15.12 discusses conflict resolution in this case. But I will let you carry on from there.

Similar Messages

BUG: JDeveloper code editor shows valid static import call as error

I've noticed what appears to be a bug in the JDeveloper code validator when dealing with static imports.
The following classes demonstrate the problem:
package test;
public class Parent {
public static void parentMethod() {
 System.out.println("called parentMethod.");
package test;
public class Child extends Parent {
public static void childMethod() {
 System.out.println("called childMethod.");
package test;
import static test.Child.*;
public class StaticInheritanceTest {
public static void main(String[] args) {
 Child.childMethod();
 Child.parentMethod();
 childMethod();
 parentMethod(); //<-- this line is highlighted as an error
}Notice how on lines 7 and 8 of StaticInheritanceTest, the code validator does recognise that both parentMethod and childMethod are static methods of the Child class.
Since 'Child' has been statically imported, then parentMethod should be available. Although parentMethod is presented as an 'auto-suggest' at line 11 in StaticInheritanceTest, when you try to call it the code editor shows the call as an error and the Ctrl-Click (to drill down into the method) doesn't work.
When I run the class, it compiles successfully and runs with the following output:
called childMethod.
called parentMethod.
called childMethod.
called parentMethod.This might seem like an obscure and theoretical problem, but I've hit this whilst using Mockito, which uses exactly this kind of inherited static method to provide matchers.

Hi,
thanks. Will file a bug. This seems to be a designtime only issue that does not present a show stopper.
Frank

Static import of member of class in same unnamed package fails

I think I found a bug in the JDK 1.5 (Tiger) javac compiler. It involves static import and unnamed packages.
Consider the following compilation unit:
import static D.x;
class C {
    int foo() { return x; }
class D {
    static final int x = 1;
}Running javac from the Tiger beta 2 SDK generates the following output:
Test.java:1: cannot find symbol
symbol: class D
import static D.x;
              ^
Test.java:1: static import only from classes and interfaces
import static D.x;
^
Test.java:4: cannot find symbol
symbol : variable x
location: class C
    int foo() { return x; }
                       ^
3 errorsIn my opinion, this is a bug. This compilation unit should compile without errors.
Note that the following compilation unit compiles without errors with Tiger beta 2:
package p;
import static p.D.x;
class C {
    int foo() { return x; }
class D {
    static final int x = 1;
}Note that this issue is distinct from the issue of importing a class from an unnamed package into a named package. I totally agree that the latter is not allowed. However, the current issue is a different matter, since here I am importing members from the same package (which happens to be an unnamed package).

The unnamed package feature is deprecated. Even if this is a bug (which I sort of doubt), this may never be fixed.

Static imports in 1.5

same static variable and same static method exists in two diffrent classes, while importing these two in my own implementation class follwing different output is coming why? Using j2se version1.5
while using variable imports like
import static package.Class1.variable1;
import static package.Class2.variable1;
//giving compilation errros
while using method imports like
import static package.Class1.method1;
import static package.Class2.method1;
//it is not giving any compilation error.
Can anyone explain?

>
ah ok, when i wrote "Clearly" above i was assuming
that the spec. when it does arrive (or when i can find
it..) will disallow static imports of same signature
methods (or possibly even just same named methods?) -
and clearly any contravention of the spec should be
reported to the userIf the spec says is should do something then it should do that.
>
on the other hand, the more the compiler can do the
better since its a single point used by lots of
people, so any small extra only has to be done once
and is multiplied in the payoff - any individual
trivial error message or warning might be
questionable, but if lots are done then it saves time
I doubt that a lot of people are going to be attempting to apply static imports to the same named item.
not completely the same things, but i like the jikes
feature where it says something like "it look like
you're trying to invoke <SOME API METHOD> - this
doesn't exist but a similar method does with
signature: ... "
I suspect that happens and is going to continue to happen far more frequently than duplicate static imports.
And of course a compiler can add additional things like that. But that is rather different than suggesting that it is required.
when a case is left in the grey area then at the very
least a dozen developers will come across it and
because of the lack of some text saying ERROR will
start to question themselves - i don't see this as
pandering to the developers laziness
And yet none of the compilers warn against the "i = i++" construct.
i've not verified this, and also the lang. spec does
not seem to have been updated for 1.5???
it sounds like the compiler should just complain in
both cases?Yes but given that neither has been used I suspect
that it will complain once they are used. If it
doesn't then that is a bug.hm, a similar piece of code
import java.util.List; import java.awt.List;
complains immediately if you try to compile it - i guess this
isn't that important but i like the
complain-loudly-and-early approach - i think they also
possibly made unused imports or duplicate imports
errors or warnings for 1.5?Could be. However, the spec itself drags significantly behind the additional material. For example note that the 'current' spec doesn't have assert. So tracking down what should really be in the spec can be somewhat complicated.
Note also that I haven't really seen the OP clarify that they expect an error for both cases rather than that they expect that no error at all should show up (because they really want to use both.) And although the first is nice the second is clearly wrong. Hopefully that point is clear.

"static import" construct?

Hello,
in a recent Java Live session (http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0212.html), respected Joshua Bloch speaks about a "static import construct" that should help clarifying the way constants are defined and used. According to the context, I assume it would be a facility enabling to "import somepackage.someclass.someFinalField;" so as to use "someFinalField" as a shortcut.
I found nothing published about this construct on Sun's site (bug DB, fora, articles,...).
Do you have a link about this potential future language feature?
And is its purpose wider than constants shortcuts (not worth the effort, I deem)?
Jerome

Since no-one replied, I'll answer my own question and assign all the cyber-dollars to myself ;-)
Hello,
in a recent Java Live session
(http://developer.java.sun.com/developer/community/chat
JavaLive/2002/jl0212.html), respected Joshua Bloch
speaks about a "static import construct" that should
help clarifying the way constants are defined and
used. According to the context, I assume it would be a
facility enabling to "import
somepackage.someclass.someFinalField;" so as to use
"someFinalField" as a shortcut.
I found nothing published about this construct (...).
Do you have a link about this potential future
language feature?This topic has been publicez recently as part of JSR-201, which answers my question.
See http://jcp.org/aboutJava/communityprocess/jsr/tiger/static-import.html for reference.
Jerome

Alpha compuler cant compile enums or static imports?!?

Pardon me if this is the wrong place to ask this question but I couldnt find any forums specific to CAP program members:
When trying to compile enums and static imports that work with the public prototype compiler, I get the following errors:
C:\dev\hcj\tiger\src>c:\j2sdk1.5.0\bin\javac -version oreilly/hcj/tiger/*.java
javac 1.5.0-beta
oreilly/hcj/tiger/EnumAttach.java:18: 'class' or 'interface' expected
public abstract enum EnumAttach {
 ^
oreilly/hcj/tiger/EnumAttach.java:35: 'class' or 'interface' expected
^
oreilly/hcj/tiger/ErrorLevel.java:20: 'class' or 'interface' expected
public enum ErrorLevel {
 ^
oreilly/hcj/tiger/ErrorLevel.java:31: 'class' or 'interface' expected
^
oreilly/hcj/tiger/ForEach.java:49: ';' expected
 for (String person: importantPeople) {
 ^
oreilly/hcj/tiger/ForEach.java:55: illegal start of expression
 ^
oreilly/hcj/tiger/ForEach.java:81: ';' expected
 for (String person: people) {
 ^
oreilly/hcj/tiger/ForEach.java:87: illegal start of expression
 ^
oreilly/hcj/tiger/StaticImports.java:15: <identifier> expected
import static StatusColors.*;
 ^
oreilly/hcj/tiger/StaticImports.java:15: '.' expected
import static StatusColors.*;
 ^
oreilly/hcj/tiger/StaticImports.java:16: <identifier> expected
import static java.lang.Math.*.
 ^
oreilly/hcj/tiger/StaticImports.java:21: '.' expected
public class StaticImports {
 ^
12 errorsIs there something I am doing wrong or is this known bug?

Use the compiler flag -source 1.5

Static import from SE5 (Ex 16 on p. 91 in Thinking in Java Edn 4 by Eckel)

The following line of code is underlined:
import static net.mindview.util.Print.*;with this error displayed:
static import declarations are not supported in -source 1.4
(try -source 1.5 to enable static import declarations).
My Path variable contains these:
C:\Program Files\Java\jdk1.6.0\bin;C:\Program Files\Java\jre1.6.0\bin;D:\java\TIJ4\code
D:\java\TIJ4\code is the root folder for net.mindview.util.Print.
JRE1.6 and JDK1.6 are installed.
I also have:
i.e. a dot, in my CLASSPATH variable.
This is from the 4th edn of Thinking in Java by Bruce Eckel. If you are or have been through this stuff I would really appreciate it if we could meet on Skype every now and then to talk about issues like the one described above.
Thanks for your help,
b

Now same code is underlined:
import static net.mindview.util.Print.*;but with this error message:
package net.mindview.util does not exist
However it is mapped like this:
D:\java\TIJ4\code\net\mindview etc..
So, I have put this in to the Path variable:
D:\java\TIJ4\code because it is the root folder of net.mindview.util.
Is there something else I should do? Is is ok to have a non C directory in the Path variable?
Thanks for any help,
B

Cannot static import in JSP (WebLogic 10.3)

I am facing a problem with the use of 'static import' in JSP. This is on WebLogic 10.3. Please help/advise.
Running weblogic.jspc results in the following error:+
$ java weblogic.jspc -verboseJspc -keepgenerated -d /tmp/jsp WEB-INF/jspf/fragment.jspf
\[jspc\] Overriding descriptor option 'keepgenerated' with value specified on command-line 'true'
\[jspc\] Compiling /WEB-INF/jspf/fragment.jspf
jspc failed with errors :weblogic.servlet.jsp.CompilationException: fragment.jspf:6:17: Syntax error on token "static", Identifier expected after this token
<%@page import="static java.util.Collections.EMPTY_LIST" %>
^-------------------------------------^
fragment.jspf:6:17: The import java.util.Collections.EMPTY_LIST cannot be resolved
<%@page import="static java.util.Collections.EMPTY_LIST" %>
^-------------------------------------^
The generated Java file is not correct; the static import is split into multiple imports+
$ head /tmp/jsp/jsp_servlet/_web_45_inf/_jspf/__fragment_jspf.java
package jsp_servlet._web_45_inf._jspf;
import java.lang.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import static;
import java.util.Collections.EMPTY_LIST;
public final class __fragment_jspf extends weblogic.servlet.jsp.JspBase implements weblogic.servlet.jsp.StaleIndicator {

I'm not sure that JSPC supports static imports, I would open a support case to get clarification.

Nwrfc 0.0.5 with important bug fix!

I have just pushed version 0.0.5 of the new gem to rubygems.org (you can also access the latest repo at GitHub).
0.0.5 introduces an important bug fix in Table#each. Previously only the first row would continuously be returned. Now you can actually treat a Table like an Enumerable!

To quote Metalink Note 161818.1 (Oracle Server (RDBMS) Releases Support Status Summary)
"Terminology Used in this Article
Patch Set
*Patch sets are cumulative. For example, 10.1.0.4 includes all the fixes in 10.1.0.3 as well as new fixes for 10.1.0.4.* "

Using static import

I just downloaded the 2.2ea. I tried using the static import feature. When I try to import my own classes f.ex.
import static test1.test2.TestInferface;
i get the error
cannot find symbol
symbol : class test2
location: package test1
import static test1.test2.TestInferface;
^
if I try the static import from the example
import static java.lang.Math.*; // import static
it compiles fine. What have I got wrong here?

Doh, you were right :). Importing test1.test2.TestInterface.*; is what is needed. Works now. Thanks.
Thought I had already tried that but I guess I was wrong. I guess I was too stuck in the old way of thinking of importing classes and interfaces as a whole, I guess the static import imports class and interface members then.. Am I right?

I believe I found an import bug in LR 5.4

I believe I've uncovered an import bug in Lightroom 5.4 under Mavericks. I noticed a folder with 19 photos and videos, but LR was only showing 18. So I tried synchronizing the folder, and still only 18 were found. So, in the import screen I unchecked "Don't import suspected duplicates", and it still would not import. So, I removed the folder containing the photos from LR, then re-imported them, and still only 18 photos!
So, the .jpg file listed here will NOT import into LR regardless of my efforts. The mp4 imports just fine. It seems like a bug pertaining to files with the same name but different extensions, or something similar. Here are the file names:
bernie3_blue_baby_shopping_walmart-09-2.mp4 - IMPORTS OK
bernie3_blue_baby_shopping_walmart-09-2.jpg - WILL NOT IMPORT

I’m not sure it’s a bug but rather by design. For example if you do external editing from Lightroom in Photoshop the word Edit is automatically added to the tiff or PSD file with the same name. Simply change the file name for the jpeg and it will import. LR does permit jpeg and raw files with the same name but it requires enabling in the prefs. I assume there is no similar pref setting for videos, as they would always be numbered separately when importing directly from a camera card; so the situation would never usually arise.

Static Import question

It is a very easy (down to earth) question.
Are static imports of methods having the same name as
Object methods forbidden?public class StaticUse1 {
public static boolean equals(StaticUse1 su1,StaticUse1 su2) {
    return true;
public static boolean equal(StaticUse1 su1,StaticUse1 su2) {
    return false;
}An import somewhere else:import static apackage.StaticUse1.*;
public class Test {
public static void main(String[] args) {
    //System.out.println(equals(new StaticUse1(),new StaticUse1())); // error
    System.out.println(equal(new StaticUse1(),new StaticUse1()));
}Compiler complains about ... equals(java.lang.Object) ...

Such static imports are allowed, but they won't work because of the scoping rules of the language. The equals(Object) for the current class always shadow such methods from the static import.

Static import in J2se5

Hi All,
I m using jdk1.5. in which we hav a new feature - "static import".
I want to know, whether this is possible in JSP......?????
If anybody knows... please give me the ans with the syntax.
Thanks,
Chandrakanth.

I'm usin tomcat 5.0, configured with jdk1.5.
In servlets i m usin static import n it works fine......
I dont know... how put the static import statement in JSP file....
Can v put static import using page directive....s????????

IDML Import Bug?

Hi All,
Just wondering if anyone can reproduce what appears to be a CS4/CS5 IDML import bug.
I typed
11
22
33
44
55
(first 3 digits in bold) then tagged "22" as an XML element before exporting an IDML file.
When the IDML file is imported, I get
11
22
33
44
55
(all digits in boldface except for the trailing 2.)
The problem seems to be on the import side of CS4/CS5 since the exported IDML looks okay to me:
<ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/$ID/NormalParagraphStyle">
 <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]" FontStyle="Bold">
 <Content>11</Content>
 
 </CharacterStyleRange>
 <XMLElement Self="di2i7i6" MarkupTag="XMLTag/Story">
 <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]" FontStyle="Bold">
 <Content>2</Content>
 </CharacterStyleRange>
 <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]">
 <Content>2</Content>
 </CharacterStyleRange>
 </XMLElement>
 <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]">
 
 <Content>33</Content>
 
 <Content>44</Content>
 
 <Content>55</Content>
 
 </CharacterStyleRange>
</ParagraphStyleRange>
Comments anyone?

Hello Larry,
i am the developer of the IDMLlib http://idmllib.com/ a Java library which is able to read/modify/create IDML.
I have also noticed some strange behavior regarding the importing of IDML, where the order of elements affect the parsing of the IDML in CS4/CS5.
My first thought was, i have created an invalid IDML, but the IDML Relax NG compact schema is very explicit, order doesn´t matter.
The best example i have at hand, which is very easy to reproduce is the TabList. A valid tablist attached to ParagraphStyleRange for example looks like this:
<TabList type="list">
 <ListItem type="record">
 <Alignment type="enumeration">LeftAlign</Alignment>
 <AlignmentCharacter type="string">,</AlignmentCharacter>
 <Leader type="string"></Leader>
 <Position type="unit">144</Position>
 </ListItem>
</TabList>
If you change this by moving the Position to the top, which is no problem regarding the schema which doesn´t enforce a strict order of the elements:
element Alignment { enum_type, TabStopAlignment_EnumValue }&
element AlignmentCharacter { string_type, xsd:string }&
element Leader { string_type, xsd:string }&
element Position { unit_type, xsd:double })
So if you change this example to this, and reimport the IDML into CS4/CS5 INDD the <Position/> will not be parsed and you wont see a TabList
<TabList type="list">
 <ListItem type="record">
 <Position type="unit">144</Position>
 <Alignment type="enumeration">LeftAlign</Alignment>
 <AlignmentCharacter type="string">,</AlignmentCharacter>
 <Leader type="string"></Leader>
 </ListItem>
</TabList>
If you export this again as IDML the <Position/> if set to 0
I circumvented this problem by forcing the creation of TabList Items with a constructor that will only allow to create TabListItems with all values present and therefore i can force the order of the created childs. But i think this will not be the only problem where parsing doesn´t do what it is supposed to do.
There has been a posting from a guy complaining about different import results regarding the attribute order of IDML element:
http://forums.adobe.com/thread/637711
I will try to reproduce the behavior you decribed.
Cheers, Andreas

FB3 Beta 3 - another organize imports bug

I'm getting lucky :-) Here is another organize imports bug in
FB3 Beta3...
If you have some simple hierarchy where base class defines
public (or protected) method, and sub class tries to override this
method you will encounter this bug. Let say that base class looks
like this:
package test {
import flash.display.Shape;
public class BaseClass extends Shape {
public function BaseClass() {
public function myMethod():void {
trace("In BaseClass.myMethod()");
and that sub class looks like this
package test {
public class SubClass extends BaseClass {
public function SubClass() {
super();
Now, if you try to override myMethod() from BaseClass and
start typing in subclass something like
override public function m
and use Ctrl+Space, FB will insert appropriate method but it
will also insert errorneous import statement like this:
import test.BaseClass.myMethod;
So you will end up with sub class which looks like following:
package test {
import test.BaseClass.myMethod;
public class SubClass extends BaseClass {
public function SubClass() {
super();
override public function myMethod():void {
Wrong import is correctly marked as error but issuing
"organize import" does not remove it so it must be removed
manually.
Regards,
Damir Murat
PS: Sorry for bad code formatting but there is no option for
inserting in-line code and attach code is a little bit
awkward.

Damir Murat,
Did you already file a bug for this? If not, would you mind
adding it to the public bug base so we can track the issue.
Thanks,
Peter

Static import bug?

Similar Messages

Maybe you are looking for