This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 41865

Summary: Support basic editing capabilities of projectless Java sources
Product: java Reporter: Jesse Glick <jglick>
Component: UnsupportedAssignee: Tomas Zezula <tzezula>
Status: RESOLVED FIXED    
Severity: blocker CC: dkonecny, mmatula, ttran, tzezula
Priority: P2    
Version: 4.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 41606    
Bug Blocks:    

Description Jesse Glick 2004-04-08 19:17:55 UTC
Even when we do ad-hoc project support, it is
still annoying that almost nothing works in the
text editor for a Java source without an
associated project, except syntax coloring etc.

We could surely support some limited functionality
in this case, by guessing at the right query
values. Suggest:

1. Boot classpath should be set to default Java
platform, i.e. IDE's own J2SDK, since this is
often going to be what is wanted anyway.

2. Source path could be set for a *.java file in
case it contains a package declaration which
matches its file path. I.e. if you come across
/home/me/whatever/org/foo/Foo.java containing the
line "package org.foo;" then guess that the source
path should be "/home/me/whatever". This would let
e.g. Alt-G work within the same source root at least.

(Scanning a Java source for a package declaration
is pretty cheap, since it has to be the first
significant token in the file; you just need a
very simple filter/lexer that throws out line and
block comments and looks for a package statement.
Open File used to have this; it was not very
complicated.)

3. COMPILE classpath (also RUN) could be set to be
GlobalPathRegistry's merged COMPILE classpath,
maybe? Or GPR.getSourceRoots (or similar, minus
BOOT paths) might work - code completion would see
a source root in the classpath and not have to map
it using SFBQ, so it would hopefully use the
source root as is.

Don't suggest providing any actions (e.g. Compile
File), only queries needed for editing capabilities.
Comment 1 Jesse Glick 2004-04-08 19:18:51 UTC
Such basic query impls need to be given a lower priority than anything
else since they are only guesses.
Comment 2 Jesse Glick 2004-04-27 15:52:29 UTC
Might be an important user migration issue.
Comment 3 Jesse Glick 2004-05-28 15:20:05 UTC
Martin mentioned to me that this could be even more important after
the refactoring merge - otherwise you can't even jump to methods in
the editor toolbar, etc. I could try to implement a prototype.

Martin suggested always returning non-null for ClassPath.getClassPath.
I think this is not a good idea: e.g. if the source is *not* in the
right package structure, you really should not return some fake source
root just for the sake of returning something. Apparently the
refactoring infrastructure does not fully handle null CPs (used in a
lot of places?), but hopefully this could be fixed in one place in the
infrastructure - MergedClassPath or whatever it is - rather than in
the general ClassPath API, which may be used directly by any module
and should not return meaningless values.
Comment 4 Tomas Zezula 2004-06-16 13:26:43 UTC
Checking in
src/META-INF/services/org.netbeans.spi.java.classpath.ClassPathProvider;
/cvs/java/j2seplatform/src/META-INF/services/org.netbeans.spi.java.classpath.ClassPathProvider,v
 <--  org.netbeans.spi.java.classpath.ClassPathProvider
new revision: 1.4; previous revision: 1.3
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java,v
done
Checking in
src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java;
/cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/DefaultClassPathProvider.java,v
 <--  DefaultClassPathProvider.java
initial revision: 1.1
done
Comment 5 Jesse Glick 2004-06-16 19:56:49 UTC
Something strange here. CP.COMPILE requests are served by asking GPR
for all COMPILE paths registered. This means if you have projects A
and B open, A dep on B, and open some projectless Java file, it will
get code completion for B but not A. Bug or intentional?
Comment 6 Tomas Zezula 2004-06-17 08:45:36 UTC
At the beginning it was intentional. The COMPILE classpath of unknown
source == to GlobalPathRegistry.COMPILE classpath.
This does not offer in the code completion classes from projects sources.
I will add to the COMPILE path also all sources not covered by the
GPR.COMPILE path.
Comment 7 Jesse Glick 2004-06-17 17:03:06 UTC
Is it possible to take GPR[SOURCE] and include those in your COMPILE
path? I am not sure what happens if you list sources in your COMPILE
path. (There is no API to get the binaries from sources, only sources
from binaries.)