My current Eclipse is Oxygen.2 Release (4.7.2) and there's Java 9.0.1. Essentially Java 9 works and particularly auto import works (for "ordinary" classes and packages), but auto import (and autocompletion) does not work for javafx.*. If I manually type import java and press Ctrl+Space, then list of matching packages pops up where I can see javafx.* hierarchy. But when I type e.g. import javafx.stage and press Ctrl+Space it automatically adds .*; and does not display any classes in the package. When I type Stage somewhere in the method body and press Ctrl+Space, there are no suggestions for it. However when I type add an import (like import javafx.stage.Stage) then code compiles and runs.
Any clues how to fix auto completion and auto import feature (which, as I said, works for other classes, like for instance java.time.LocalDateTime or many othres).
javafx* classes are blocked during code completion due to access rules governing the access to system packages. Looking at, e.g., Eclipse bug 527353 the mechanism for dynamically computing the list of accessible packages had not been finalized in Eclipse Oxygen. As a result, only a static profile can be used. That file currently mentions:
NOTE: The JavaSE-9 profile is not yet finalized.
Since dynamic computation according to JEP 261 includes the javafx packages - if available -, I think the static profile should list those as well, or be abandoned in favor of fully relying on JPMS rules, only.
You can, however, avoid the problem by explicitly defining an access rule granting access to javafx/** at
Java Build Path > Libraries > JRE System Library > Access rules.
Related
This question already has answers here:
Accessing com.sun.tools.javac.util from Java 9
(2 answers)
Closed 3 years ago.
I've been trying to modify the AST using annotation processors. I tried extending Lombok, but that seemed too hard, so I decided to use things from com.sun.source.* and com.sun.tools.javac.* However, I am using java 11, and the document I was learning from, "The Hacker's Guide to Javac" http://scg.unibe.ch/archive/projects/Erni08b.pdf, uses Java 6. The api they used is now internal and my module cannot read it.
In IntelliJ, it gave me a few errors, but I clicked on the suggestions (which said things like "Add --Xxx-xxx to xxx" without paying attention to them. When I tried compiling with Maven, it failed, since the module does not read the internals of jdk.compiler.
These are some of my imports:
import com.sun.source.util.Trees;
import com.sun.tools.javac.tree.JCTree;
import com.sun.tools.javac.tree.TreeMaker;
import com.sun.tools.javac.tree.TreeTranslator;
import com.sun.tools.javac.util.Context;
My module-info file contains
requires jdk.compiler;
requires java.compiler;
I got messages like "[ERROR]package com.sun.tools.javac.util is declared in module jdk.compiler, which does not export it to module OtherAnnot" and "[ERROR] (package com.sun.tools.javac.tree is declared in module jdk.compiler, which does not export it to module OtherAnnot)"
Edit: I guess this is a duplicate, but I wanted to know if there was some alternative API for AST transformations in java 9.
With the introduction of Project Jigsaw, the JDK has been modularized, allowing users to create their own modules as well. These modules allows you to export packages of yours, allowing programs that require your module (in their module-info.java) to use the exported packages.
Ideally, you'd be prohibited from using classes that reside in packages that are not exported. However, to not break backwards compatibility, VM flags were introduced that allow you to forcefully export packages (that don't belong to you) to your module.
Given your error message, the respective VM flag to add is:
--add-exports jdk.compiler/com.sun.tools.javac.tree=OtherAnnot
The pattern here is:
--add-exports THEIR_MODULE/THEIR_PACKAGE=YOUR_MODULE
If the compiler complains that packages aren't exported to the unnamed module, then you can use the following:
--add-exports THEIR_MODULE/THEIR_PACKAGE=ALL-UNNAMED
I'm trying to do a few imports from com.apple.eawt (using Eclipse) like this:
import com.apple.eawt.AboutHandler;
import com.apple.eawt.AppEvent;
But I get "the import com.apple cannot be resolved" for each statement.
I've looked at other similar questions, and it seems people are saying it is a build path error. I tried the suggestion in one of the questions to add an accessibility rule like this:
But I still get the error even after restarting Eclipse. The other thing is that all of the questions I've seen are using MacOS, so I don't know if that makes a difference.
The com.apple.eawt package is a MacOS-specific package intended to permit java applications to work like native MacOS applications. You would only find this package in a JRE/JDK for the MacOS platform. You say you're building on Windows, which wouldn't have this package.
On top of that, beginning with Java 9 the com.apple.eawt and other Apple-specific packages are encapsulated and no longer accessible without taking special steps. Even if you were building on MacOS, you'd have to override the encapsulation to access the package.
JEP 272 describes a public API which is intended to be a cross-platform replacement for com.apple.eawt. If you're motivated, you may be able to port your program to the new API.
Further reading:
Migrating to JDK 9: Removed macOS-Specific Features
JDK-8048731 : JEP 272: Platform-Specific Desktop Features
JDK-8160437: com.apple.eawt.Application is not exported
I have auto import enabled in idea, but it requires me to open the file in the editor (like it should). Now, i have done some regex magic, which means across 100+ classes i am using new classes that need to be imported. Since its all done with find/replace, those files have never been opened in the editor, and therefore the new classes havent been auto imported. Is there any way to run auto import unambiguous references across all files? cause currently, i have to compile, and then open all the files from the errors window? Optimize imports aparently doesnt do new imports.
I am not sure in which version of IntelliJ this feature became available (I am currently using 2017.1.1) but you can select a package from the project browser and in the context menu optimise imports for that package or use the keyboard shortcut Ctrl+Alt+o.
I just used this to update the imports of all my classes after changing my import settings and it worked like charm.
I can compile my program just fine if I specify sublibraries of com.itextpdf.*, but for some reason, my compile fails if I simply do import com.itextpdf.*. But, like I said, if I specify the sublibraries I'm using, such as
import com.itextpdf.text.Font.*;
import com.itextpdf.text.pdf.*;
Everything compiles just fine. In the case where it fails, the error I'm getting is "package com.itextpdf does not exist", but I know it does. I include it properly in the build path, and Eclipse doesn't give any compile errors in any case. The error only comes up when I try to build with Ant.
At this point, I don't mind specifying the sub libraries I'm going to use to make sure I get a build. But I am curious, why wouldn't Ant allow this?
You, and Eclipse, think of java namespaces as a hierarchy. However, in the Java specification, they are not. There is no relationship between "com.itextpdf.text" and "com.itextpdf.text.Font". They are different strings, end of story.
As a matter of style, you may want to set up Eclipse to automatically organize your imports and explicitly specify every class you use in the import section of your class. This avoids ambiguity when "com.itextpdf.text.Font.String" and "com.itextpdf.text.pdf.String" both exist, but you only want to reference one of them. This style would be incredibly tedious and inconvenient if you were programming in emacs or vi, but with Eclipse it is automatic and invisible, unless you scroll to the top of your file.
In Eclipse 3.5, say I have a package structure like this:
tom.package1
tom.package1.packageA
tom.package1.packageB
if I right click on an the tom.package1 package and go to Refactor->Rename, an option "Rename subpackages" appears as a checkbox. If I select it, and then rename tom.package1 to tom.red my package structure ends up like this:
tom.red
tom.red.packageA
tom.red.packageB
Yet I hear that Java's packages are not hierarchical. The Java Tutorials back that up (see the section on Apparent Hierarchies of Packages). It certainly seems like Eclipse is treating packages as hierarchical in this case.
I was curious why access specifiers couldn't allow/restrict access to "sub-packages" in a previous question because I KNEW I had seen "sub-packages" referenced somewhere before.
So are Eclipse's refactoring tools intentionally misleading impressionable young minds by furthering the "sub-package" myth? Or am I misinterpreting something here?
Eclipse can't possibly violate the JLS in this case, because it has nothing to do with compiling or running Java source or bytecode.
The refactoring tools behave as they do because that behaviour is useful to developers. The behaviour is useful to developers because, for many intents and purposes, we do treat packages as hierarchal (a.b.c has some kind of relationship with a.b, even if that relationship is not consistent from project to project). That doesn't mean Java treats them as hierarchal intrinsically.
One example where people treat packages as very hierarchal is in configuring a logging framework such as log4j. Again, it's not intrinsic to log4j, but that's how people use it in practice.
Java packages are not hierarchical in the sense that importing everything from package A does not import everything from package A.B.
However, Java packages do correspond directly to the directory structure on the file system, and directories are hierarchical. So Eclipse is doing the correct thing - it is renaming the directory, which automatically changes the name of the parent directory of the renamed directory's children (to state the very obvious).
even java itself has the concept of subpackage:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
java -ea[:<package name>"..." | :<class name> ]
Enable assertions. Assertions are disabled by default.
With no arguments, enableassertions or -ea enables assertions. With one argument ending in "...", the switch enables assertions in the specified package and any subpackages. If the argument is simply "...", the switch enables assertions in the unnamed package in the current working directory. With one argument not ending in "...", the switch enables assertions in the specified class.
If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. So, for example, to run a program with assertions enabled only in package com.wombat.fruitbat (and any subpackages), the following command could be used:
java -ea:com.wombat.fruitbat... <Main Class>
Java's packages are not hierarchical, but Eclipse stores packages on your system's file structure.
tom.package1.packageA is represented on a Windows file system as tom/package1/packageA.
When you ask Eclipse to refactor a package name, you're asking Eclipse to change the name of the file system directory structure.
You can have packages in Eclipse like:
tom.package1.packageA
tom.package2.packageB
tom.package3.packageC
You'll just have different 2nd level file system directories.