Java 8 (no really :)) bugs

[yorick]

Here's an "Unofficial Hotfix" for b91, which fixes an issue with maptool and Java 8. I've seen it crop up with one 4e framework, and most everyone else doesn't run into it. I'm making the hf build available just in case people need it. If your campaign is working great with the standard build of b91 and Java 8, you should stay with that.

https://dl.dropboxusercontent.com/u/236 ... 1.UHF1.zip

Original thread start:

I've tested b89 with Java 8, to see how it would behave. It worked mostly, but I got an exception when editing a power in the framework we use.

I think there's value in making sure b90 works with Java 8, so that we don't have a repeat of the "works only with certain Java versions" problem, as that costs MT players.

Devs, are you on board with that? If so, I'll happily grab a beta build of b90, test again, and post the errors I am seeing.

[JamzTheMan]

Ya, I was going to look into Java 8 and MT myself once it goes GA. I don't have time right now and didn't want to mess with the early access builds.

Feel free to post any exceptions here though for tracking.

[Lee]

From an average user's perspective, jumping to Java 8 is not advisable at this early stage as there is not much benefit while the rest of the computing world catches up. MT's stage of maturity is parallel to Java 7 and is likely to stay that way for quite some time (perhaps even years) while Java 7 is still being actively updated.

[yorick]

@Lee, I hear you. But the point is that some folk will install Java 8. I don't want a repeat of what happened with Maptool and Java 7, where we had to spend, I kid you not, an hour before each session to troubleshoot people's Java installs and teach them how to load Java 6 and point Maptool to it. What a pain. I'd like MT to work with "whatever Java" people happen to have, and if that is restricted to the currently actively supported versions - 7 and 8 - that's fine by me.

[yorick]

Here is one issue I can reproduce with MT b89 and b90 when using Java 8.

Open the Rumble framework 5.1.3 (http://forums.rptools.net/viewtopic.php?f=58&t=16440) with 6MB of stack

Choose a character, click Management, Edit Character.

Select the Powers tab, edit a Power.

Click the text next to attack (X against AC, or something along those lines)

In the dialog that comes up, change the attack type to anything but what it is now, click OK

The error message that is displayed is:

ava.util.ConcurrentModificationException
at java.util.LinkedHashMap$LinkedHashIterator.nextNode(Unknown Source)
at java.util.LinkedHashMap$LinkedKeyIterator.next(Unknown Source)
at java.util.Collections$3.nextElement(Unknown Source)
at net.rptools.maptool.client.ui.htmlframe.HTMLPane.setText(HTMLPane.java:165)
at net.rptools.maptool.client.ui.htmlframe.HTMLPanel$2.run(HTMLPanel.java:92)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:36)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

[wolph42]

thanks for the extensive report. When I find the time ill have a look to see if i can pin point the issue.

[yorick]

According to this (http://docs.oracle.com/javase/6/docs/ap ... ption.html) this points to, quite simply, a bug. Maybe J8 is just better at detecting the bug than J7 is.

Narrowing it down is another matter entirely. I'll leave that to people more intimate with Java bug tracking tools .

[wolph42]

I mean narrow it down in theMacro. In the end it's one call that initiates this.

[yorick]

I've taken a look at what the timeline for Java 7 looks like. We are rapidly approaching a situation similar to b87, where users that installed the default Java runtime from java.com had to jump through hoops to install the older runtime to get maptool to work.

Java 7 public updates will cease April 2015, if the current timeline holds. There is a 1-year window from GA of next major release (check) and a 6-month window from next major release becoming default on java.com. That means that Java 8 will become the default runtime no later than October, possibly October 14, coinciding with the scheduled security release. Unless Oracle decide they are happy with it earlier and make it happen with the upcoming July 15 release.

[wolph42]

Interesting, as hè mote teams just explained that its far to early to start on j8 acute of the Many libs which are not yet compatibele with j8 and thus its fruitless to start so soon.

[yorick]

I think the solution will have to be what most other Java standalone apps do: Bundle the JRE with the app installer. That would create multiple installers: OSX, Windows 32, Windows 64, Linux, and maybe "unbundled JAR". By bundling the JRE, compatibility problems are resolved, issues of the nature of "I don't actually have Java installed" are resolved, and security issues in the JRE are no longer that big a concern, since the bundled JRE would never be called by anything but maptool.

It would shift the burden from the users, to the developers and a slightly longer download time. In my mind, a very worthy tradeoff. The amount of time lost to troubleshooting Java, as I have seen firsthand with my small group of players, and the amount of users lost because of this difficulty, is staggering.

Whether Mote or Maptool ultimately deliver something that isn't dependent on the default JRE, I don't care. I do believe things will need to move that way.

[Jagged]

ALL the third party suppliers I deal with who produce java apps do exactly what you suggest and bundle a jre.

[yorick]

I am inching my way towards finding out what's happening here, and why this is failing in Java 8. How to fix it I don't know yet, and will happily take suggestions and direction.

The exception is throw in net.rptool.maptool.client.ui.htmlframe.HTMLPane, called from net.rptool.maptool.client.ui.htmlframe.HTMLPanel.

The offending snippet is this:

Code: Select all

try {
			super.setText("");
			Enumeration<?> snames = style.getStyleNames();
			while (snames.hasMoreElements()) {
				style.removeStyle(snames.nextElement().toString());
			}
			style.addRule("body { font-family: sans-serif; font-size: " + AppPreferences.getFontSize() + "pt; background: #ECE9D8}");
			style.addRule("div {margin-bottom: 5px}");
			style.addRule("span.roll {background:#efefef}");
			parse.parse(new StringReader(text), new ParserCallBack(), true);
		} catch (IOException e) {
			// Do nothing, we should not get an io exception on string
		}

It bombs out on style.removeStyle(snames.nextElement().toString());.

Oracle's documentation for ConcurrentModificationException (at http://docs.oracle.com/javase/6/docs/ap ... ption.html) has this to say:

This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.

Note that this exception does not always indicate that an object has been concurrently modified by a different thread. If a single thread issues a sequence of method invocations that violates the contract of an object, the object may throw this exception. For example, if a thread modifies a collection directly while it is iterating over the collection with a fail-fast iterator, the iterator will throw this exception.

Bingo. "modifies a collection directly while it is iterating over the collection" looks like what is happening here.

Since StyleSheet is part of swing, and I won't change this from Enumeration to Iteration, I think I'll look at collecting the names of the styles to be removed, then removing them in a second step.

[yorick]

I have a solution. I thought about "ArrayList arrayList = Collections.list(elementsEnumeration);", but I can't figure out how to get toString() in there, which might have been overridden, and I don't understand the libraries in use here. Long story short, this works. Suggestions on nicer, cleaner ways of doing this are welcome.

Add this to the import section, just under import.java.util.regex.Matcher; :

Code: Select all

import java.util.ArrayList;
import java.util.List;
import java.util.Iterator;

Change the offending code in setText to read as follows:

Code: Select all

		try {
			super.setText("");
			Enumeration<?> snames = style.getStyleNames();
			List<String> stylenames = new ArrayList<String>();
			while (snames.hasMoreElements()) {
				stylenames.add(snames.nextElement().toString());
			}
			for(Iterator<String> stylesIter = stylenames.iterator(); stylesIter.hasNext();) {
				style.removeStyle(stylesIter.next());
			}
			style.addRule("body { font-family: sans-serif; font-size: " + AppPreferences.getFontSize() + "pt; background: #ECE9D8}");
			style.addRule("div {margin-bottom: 5px}");
			style.addRule("span.roll {background:#efefef}");
			parse.parse(new StringReader(text), new ParserCallBack(), true);
		} catch (IOException e) {
			// Do nothing, we should not get an io exception on string
		}

Go over the Enumeration, build a List from its elements using toString, then iterate over the List and call removeStyle for each entry. Not terribly elegant, but it works.

Comments please.
Go ahead with this?
Is there a better way of doing that?
Other than elegance, do you see something wrong with this solution?

[yorick]

I went through the source to see whether I could find any other instances where Enumerations are used that way. It doesn't seem like it. Smileys are broken, but they are broken in Java 7 as well, so I'm not worrying about that. Broken as in "don't work", not broken as in "crash Maptool".