Skip navigation
Ondrej Zizka

IDE file open script

Posted by Ondrej Zizka Dec 20, 2016

This might come in handy.

You write ` FooBar` and it most likely opens what you are looking for:


1) Tries to open the path.

2) If it doesn't exist, it tries to open that file anywhere in the directory tree (provided it has some of the file name suffixes I currently use).

3) If not exists, it opens the files that contains a type of that name (class, function, interface).

4) If not found, it opens the files that contain given pattern.


This blog's source WYSIWYG is buggy so it's hard to edit, the up-to-date version is at gist.


set -x


## If the argument is a path to a file, open it.
if [ -f "$1" ] ; then
  "$NB" "$1"

## Else if it's a path in a form of foo*bar (contains a star), open all that match, of types .java, .ts, .html, .xml, .ftl
elif expr "$1" : ".*\*.*" ; then 
  find . -path "./*/target/*" -prune -o \( -name "*$1*".java -o -name "*$1*".ts -o -name "*$1*".html -o -name "*$1*".xml -o -name "*$1*".ftl \) -print | xargs $NB

## Else if there's a TypeScript class of that name, open it.
git grep -q -E "(class|function) +$1"
elif [ $? ] ; then 
  git grep -l -E "(class|function) +$1" | head -n $MAX_FILES_TO_OPEN | xargs "$NB"

## Else open whatever matches the given pattern.
  COUNT=`git grep -l "$1" | wc -l`
  if [[ "$COUNT" -gt "$MAX_FILES_TO_OPEN" ]] ; then echo "Too many `git grep` matches, taking first $MAX_FILES_TO_OPEN."; fi
  git grep -l "$1" | head -n $MAX_FILES_TO_OPEN | xargs "$NB"

JDK 9 is about to be released somewhere in Q3 2017. There's a huge list of non-trivial new features, see below.

So in the meantime, you can have a look at this good guide what's coming upon us: The Ultimate Guide to Java 9


Compiler level properties still not there, what a disappointment. They might be in JDK 11, hopefully. This whole story reminds me how Czech highways are being built.


JEPs targeted to JDK 9, so far

102: Process API Updates
110: HTTP 2 Client
143: Improve Contended Locking
158: Unified JVM Logging
165: Compiler Control
193: Variable Handles
197: Segmented Code Cache
199: Smart Java Compilation, Phase Two
200: The Modular JDK
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
214: Remove GC Combinations Deprecated in JDK 8
215: Tiered Attribution for javac
216: Process Import Statements Correctly
217: Annotations Pipeline 2.0
219: Datagram Transport Layer Security (DTLS)
220: Modular Run-Time Images
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
223: New Version-String Scheme
224: HTML5 Javadoc
225: Javadoc Search
226: UTF-8 Property Files
227: Unicode 7.0
228: Add More Diagnostic Commands
229: Create PKCS12 Keystores by Default
231: Remove Launch-Time JRE Version Selection
232: Improve Secure Application Performance
233: Generate Run-Time Compiler Tests Automatically
235: Test Class-File Attributes Generated by javac
236: Parser API for Nashorn
237: Linux/AArch64 Port
238: Multi-Release JAR Files
240: Remove the JVM TI hprof Agent
241: Remove the jhat Tool
243: Java-Level JVM Compiler Interface
244: TLS Application-Layer Protocol Negotiation Extension
245: Validate JVM Command-Line Flag Arguments
246: Leverage CPU Instructions for GHASH and RSA
247: Compile for Older Platform Versions
248: Make G1 the Default Garbage Collector
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
255: Merge Selected Xerces 2.11.0 Updates into JAXP
256: BeanInfo Annotations
257: Update JavaFX/Media to Newer Version of GStreamer
258: HarfBuzz Font-Layout Engine
259: Stack-Walking API
260: Encapsulate Most Internal APIs
261: Module System
262: TIFF Image I/O
263: HiDPI Graphics on Windows and Linux
264: Platform Logging API and Service
265: Marlin Graphics Renderer
266: More Concurrency Updates
267: Unicode 8.0
268: XML Catalogs
269: Convenience Factory Methods for Collections
270: Reserved Stack Areas for Critical Sections
271: Unified GC Logging
272: Platform-Specific Desktop Features
273: DRBG-Based SecureRandom Implementations
274: Enhanced Method Handles
275: Modular Java Application Packaging
276: Dynamic Linking of Language-Defined Object Models
277: Enhanced Deprecation
278: Additional Tests for Humongous Objects in G1
279: Improve Test-Failure Troubleshooting
280: Indify String Concatenation
281: HotSpot C++ Unit-Test Framework
282: jlink: The Java Linker
283: Enable GTK 3 on Linux
284: New HotSpot Build System
285: Spin-Wait Hints
287: SHA-3 Hash Algorithms
288: Disable SHA-1 Certificates
289: Deprecate the Applet API
290: Filter Incoming Serialization Data
292: Implement Selected ECMAScript 6 Features in Nashorn
294: Linux/s390x Port
295: Ahead-of-Time Compilation
297: Unified arm32/arm64 Port

Windup 3.0 will be a web application. It can still be used as command line application, but on top of that, you can deploy Windup to a JBoss WildFly (or EAP) and scan your applications from a nice web UI.


Look at Windup Migration Platform and try migrating your application to the newest Java EE.


From the developers perspective, the frontend stack is Angular 2, TypeScript, ReactJS, Keycloak for security, and few other libraries. It's a bit pain for me to learn the new paradigm and to leave the very comfortable Java ecosystem, but on the other hand, looks like all the JavaScript-centered craziness is going to stay around for a couple of decades and eventually settle down, so why not embrace it (thinking, "Banzaaaii!!" )

Look at GitHub - windup/windup-web: Windup as a Web Service  if interested in code.