Visibility into SlickEdit's class path

[rygaard]

First, this is not a feature request.  This is a requirement for me to get my job done in a reasonable time.

You MUST provide:

• Some way for the user to discover what class path SlickEdit is using.
• Some way for the user to disable the facility that packs my classpath into a temporary JAR file.

To address visibility into SlickEdit's classpath, provide an option to leave SlickEdit's temporary JAR in the file system instead of deleting it.  This would be unadulterated forensic evidence.  A dialog box showing the classpath would not allow the user to confirm that what is displayed is what is actually used.

I've spent the last few weeks battling SlickEdit's classpath issues instead of doing my job.  Altering my class path and then hiding it is not a bug; it's a serious design flaw.  It prevents me from doing my work by preventing me from diagnosing problems.  If I could simply see what SlickEdit is doing, I could help you resolve these issues in hours instead of weeks.

I would like some response to this, because I paid for support when I recently upgraded to V26 and I upgraded from a single-platform license to a multi-platform license.

Thank you.

[patrick]

Yes on the classpath visibility.  When we had to add the feature for really long classpaths exceding command line limits, I missed the fact that not having the classpath show up on the javac command line anymore is a debugging problem.  I'm working on integrating that with the Verbose option for the build tools.

Not so sure about being able to disable it.  Debugging problems from command line length issues wasn't straightforward, and I wouldn't want to see it pop up again.   What extra feature would that setting buy you once you can see the true classpath (and jar file)?

[rygaard]

Moving the classpath into a JAR file means, in some cases, that SlickEdit must modify the classpath by reordering it.  Reordering the classpath can sometimes prevent proper compilation.

If I disable your classpath contraction, I'd take it on at my own risk.  Then I'd be doing battle directly with javac over the class path length, instead of through an intermediary.  For example, I could consider restructuring the directories in my project, or using classpath wildcards, or building and maintaining my own classpath JAR outside of SlickEdit, or whatever.

These are some possible approaches to the issues you describe regarding disabling the classpath contraction:

• When the user disables the classpath contraction, display a warning dialog box.
• When the user invokes project-compile and they have disabled classpath contraction, inspect the output for a command-line-too-long error message.  If the message occurs, display a dialog box that suggests turning on classpath contraction.  Or it could just say "I told you so!  Neener, neener, neener!"
• All of the above

To be sure, I don't know if this addresses the needs of your other customers, so this is just my suggestion.

[rygaard]

Just to be clear:  re-ordering the classpath is not a problem for me on my current project, so I could survive if you don't offer an option to disable classpath contraction.  But I REALLY need visibility into the classpath.

[patrick]

Agree, need visibility one way or the other.   I wouldn't want classpath entries to be reordered on principle.   The code should follow the order listed in the Java Options dialog.

Looking at the output of debugging on the projects here, it looks like the classpath entries are ordered in the same order that they are listed in the Java Options dialog.  The one big exception I see is that groups of jars added by wildcards are added in the order they are iterated, which isn't necessarily the same order that you see in a directory listing.  So if someone expected A.jar to be before B.jar because of alphabetical sorting, it's definitely possible that won't be true in this case.   This isn't specific to putting the classpath in a jar, the ordering for wildcards wasn't guaranteed for a command line classpath either. 

And it looks like the order we specify ends up being the order that makes it into the final MANIFEST.MF that ends up in the jar, so I don't think it gets changed there.

Am I missing some re-ordering case that you're seeing?

[rygaard]

Suppose:

• I'm on Windows
• My SlickEdit project is in D:\MyProject
• My classpath looks like:
     D:\MyProject\MySubsystem1
     C:\ThirdPartyDirectory\libs\*
     D:\MyOtherProject\src

According to https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html:

Currently, the URLs must be relative to the code base of the JAR file for security reasons. Thus, remote optional packages will originate from the same code base as the application.

If SlickEdit places its temporary JAR file on Drive C, then there is no way to construct a relative path from the temporary JAR to the first and third entries in my classpath.  Thus, the temporary JAR could only list C:\ThirdPartyDirectory\libs\*, and the other two directories would need to be explicitly listed on the javac command line after the temporary JAR file.  This is re-ordering the classpath.

If SlickEdit places its temporary JAR on Drive D, then the classpath must be re-ordered for similar reasons.

[rygaard]

There's another reason for disabling classpath contraction:  SlickEdit is way too aggressive when deciding whether or not to apply classpath contraction.  There are situations where disabling classpath contraction would not result in an overly long command line.

[patrick]

That's true, the spilling of classes onto the command line classpath for jars on multiple drives will change ordering.

I'll think on it. 

[rygaard]

Can symbolic links make a directory on another drive look like it's on the same drive?

I pose this as a question because Microsoft's implementation of symbolic links is not the best.

[patrick]

Unsure.  I've seen some posts that suggest that the JVM is aware of Windows symlinks, and the Oracle JDK may even use them in their installations.  But it's not clear if it would allow you to use relative paths for a file on another drive in a manifest.  The relative path limitation is couched as partly a security concern in their docs, so if they are aware of symbolic links, they would be able to see the true location of the file, and disallow it if they wanted to.