Louis Denning

Due to the way AWT/Swing works, code that updates GUI elements should be run on the EDT. However, I'm not sure what doesn't need to be run on the EDT. For example, amongst other things, when initializing a window (like a JFrame, for instance), or setting its dimensions/location before it is first displayed/made visible, need it be run on the EDT? Should I just wrap everything in a SwingUtilities.invokeLater call?

Okay, most of us have probably seen this class of question before, but I've got something else to ask: Is StringBuilder faster than "+" even outside of a loop?

Exempli gratia:String s = "{" + getData() + ", " + getSomethingElse() + "}";vs what it translates intoString s = new StringBuilder("{").append(getData()).append(", ").append(getSomethingElse()).append("}").toString();vs another way of writing itString s = new StringBuilder().append("{").append(getData()).append(", ").append(getSomethingElse()).append("}").toString();vs with a predetermined expected lengthString s = new StringBuilder(littleOverExpectedLength).append("{").append(getData()).append(", ").append(getSomethingElse()).append("}").toString();
I expect the first two to be equivalent, for the latter is translated from the former during compilation. I would expect the third one to have an internal char buffer of some default size (probably 8, I believe) that expands (probably doubling) as needed. The last one hopefully allocates enough space for everything without needing to expand the internal buffer.

My questions now are:

(1) Would the fourth case be non-negligibly faster than the other three, where there is probably buffer expansion to do?
(2) When would it be justifiable to use each of the cases?
(3a) Would most JVMs be smart enough to optimize this "unnecessary" buffer expansion away, perhaps into something like the fourth case?
(3b) Are there any JVM options that do this kind of optimization?
(3c) How might Java 9's "String Indification" handle this?
(4a) Is the following practical in the slightest:public static String experimentalConcat(String... strs) { StringBuilder sb = new StringBuilder(Stream.of(strs).mapToInt(String::length).sum()); Arrays.asList(strs).forEach(sb::append); return sb.toString(); }(4b) Less functionally...public static String lessFunctionalExperimentalConcat(String... strs) { int totalLen = 0; for (String s : strs) totalLen += s.length(); StringBuilder sb = new StringBuilder(totalLen); for (String s : strs) sb.append(s); return sb.toString(); }...though not very convenient in handing primitives.
(5) Where'd the Edit button go?

For some context, I sometimes program in Frege, a Haskell implementation for the JVM, where millions of small immutable objects are made and probably don't last 10 nanoseconds before becoming garbage. I'm curious of the extent of the performance impact in this case, and what the JVM would do about this.

We all know that member functions are called methods, but why is it that they're called "methods"? From where did the term originate?

Is because objects have their own way of doing things (i.e. behaviour), so one could say that they have their own "methods" or something?

(can't seem to figure out how to edit a post)

Edit to previous post: "If you change the object pt1 is pointing to..." could be worded better as "If you modify/mutate the object pt1 is pointing to..."

In Java, object references can be thought of as little fingers hanging out inside the JVM pointing to things.
Point pt1, pt2; // okay, we're gonna have two fingers, pt1 and pt2 pt1 = new Point(100, 100); // make a new Point object and make the first finger point to it pt2 = pt1; // make the second finger point to what the first finger is pointing toOr at least that's what my old mentor used to visualize them as.


If you change the object pt1 is pointing to, e.g. by doing
pt1.x = 200;then the change will be reflected in the object pt2 is pointing at.

But if you change what pt1 is pointing to, e.g. by doing
pt1 = new Point(300, 300);then pt1 and pt2 will no longer be pointing to the same thing.

To what degree would the JVM (in my case, HotSpot) perform optimizations pertaining to immutable objects? That is, if the JVM determines that some objects are effectively immutable (e.g. either because all of its member fields are declared as final or the instances of its class are never mutated), what are some optimizations that the JVM may perform?

Supposing that the data returned by the getter does not change (e.g. by another thread), wouldn't the JVM most likely optimize the getter call away into something like the first version (e.g. maybe putting the returned value into a spare register or something), given that the getter does not have any side effects in being called multiple times?

After a little more research, it seems that the reason why "%20" appears in place of a " " is due to the behaviour of the URL class. Simply converting the URL into a URI before calling getPath() on it solves the issue. This may help catch other URL-style percent codes that may arise from Unicode characters in the classpath or something.

Thanks for the help!

I seem to have discovered what the issue was. There was a URL-style "%20" where a space should've been in the classpath returned by JARMain.class.getProtectionDomain().getCodeSource().getLocation().getPath(). Simply adding .replace("%20", " ") seems to have solved the problem.

Yes, both classes are where they should be.

Error: Could not find or load main class Main

Nothing else from stderr. Very bizarre since this used to work just fine. Perhaps I missed a detail?

The test JAR contains only those two classes, where the manifest specifies JARMain as the main class. Upon running the JAR, once by double clicking the JAR, and once by command line, no GUI shows up, as mentioned in the first post. Running the JAR with Main as the main class works, but, of course, that does not accomplish my goal.

I want to be able to have the JAR re-execute itself with JVM arguments determined at runtime, whatever the options may be. A bad example would be if I wanted the JAR to read some config files or something, determine what JVM arguments to use, and then re-execute itself with those arguments using ProcessBuilder or Runtime.exec(String) or something (bad example because the user might as well have ran a shell or batch script or something with the options specified).

Dumb deployer:
import java.io.IOException; public final class JARMain { private JARMain() {} public static void main(String[] args) throws IOException, InterruptedException { new ProcessBuilder("javaw", // also tested with "java"   "-client", // example option; maybe didn't want to default to -server or something   "-Xms32M",   "-Xmx4096M", // maybe I need more memory   "-XX:+UseCompressedOops", // example option, not much point doing this   "-XX:+UseParallelGC", // example option, not much point doing this   "-cp",   JARMain.class.getProtectionDomain() .getCodeSource() .getLocation() .getPath(),   "Main").inheritIO()  .start()  .waitFor(); } }
Dumb main:
import java.awt.*; import javax.swing.*; public final class Main { private Main() {} public static void main(String[] args) { /* just to see if anything is displayed */ JFrame frame = new JFrame("Self-Deploy Test"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(0xC0, 0x60); frame.setLocation(0xC0, 0xC0); frame.setVisible(true); } }

I find it really bizarre that what I did earlier used to work.