Java questions which don't deserve their own thread, yet.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Coredump posted:

However if try to use the line:
code:
System.out.println(arrayToString2({"chicken", "bacon", "ham"}, ","));
I get an illegal start of expression error. WHHHYYY???

Try this:

code:

System.out.println(arrayToString2(new String[] {"chicken", "bacon", "ham"}, ","));

The String[] toppings = { ... } syntax is only valid when you're initializing the contents of the array at the same time you're declaring the variable. In your example above, you want to initialize an "anonymous array", which in Java is done by putting new ElementType[] before the array items in braces.

_{edit:grammars}

Flobbster fucked around with this message at 23:30 on Feb 7, 2010

# ¿ Feb 7, 2010 13:24

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 20:02

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

zootm posted:

A lot of thought seems to have gone into making enums "work right".

If only they could have applied the same amount of thought to other parts of Java, like generics.

# ¿ Feb 9, 2010 20:35

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Glimm posted:

In my Java class I am required to use FindBugs in all projects. I'm having trouble in my latest lab because I am getting a FindBug message "may fail to close stream" on the line I've commented below. Anybody point me in the direction to fix this problem?

code:

BufferedReader in = null;
try {
     in = new BufferedReader(new FileReader(filename)); //FindBugs error here
                   //do something with the file
   } catch (FileNotFoundException e) {
	System.out.println("Could not find file: " + filename);
	System.exit(-1);
   } catch (IOException e) {
	System.out.println("I/O Exception failure: " + filename + ": "
	+ e.getMessage());
	System.exit(-1);
   } finally {
	if (in != null) {
	try {
	     in.close();
	} catch (IOException e) {
		System.out.println("I/O Exception failure: " + filename
	        + ": " + e.getMessage());
		System.exit(-1);
	}
    }
}

I don't personally have any experience with FindBugs, but "finally" blocks don't get executed if you call System.exit, so maybe that's why it's complaining? In a real world situation it probably doesn't matter too much, but as far as FindBugs is concerned, there are still paths in your code where "in.close()" never gets called.

Does the flag go away if you close your reader inside the catch clauses before you call System.exit?

# ¿ Feb 27, 2010 19:56

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Surface posted:

Free Email To SMS Gateways (Major US Carriers)

These work with varying levels of success, so I'm not sure if I'd depend on them for anything critical.

I've been generalizing the e-mail notification mechanism on the server I work on to provide different kinds of notifications, like SMS and Twitter. I tested out the e-mail->SMS gateway using my number on AT&T and the messages I sent were either completely lost or arrived 12 hours later.

I think what we're going to end up doing is using some of the sample code out there that sends post requests directly to Google Voice (since it lacks a real API) to send text messages through that. It didn't appear that there was anything in the TOS preventing it.

# ¿ Mar 22, 2010 13:36

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Internet Janitor posted:

Any thoughts? What am I missing here?

This appears to be a perfect storm of weirdness involving the way Java handles varargs and generics. The signature of Arrays.asList is the following:

code:

public static <T> List<T> asList(T... a)

Since the method takes variable arguments, you can pass them in separately or as an explicit array, as you have done. Inside the method, "a" is just an array of 0 or more elements of type T. By the rules of Java generics, type parameters like T must be reference types, such as an instance of a class or an array, but not a primitive. So, the substitution that you're expecting, where T = char and your array is treated as the varargs array with two char elements, won't work:

code:

public static <char> List<char> asList(char... a) // where a = new char[] { 'a', 'b' } <-- NO

The compiler then tries the next best thing, T = char[], which does work: it treats the whole array as the one and only element of the varargs array:

code:

public static <char[]> List<char[]> asList(char[]... a) // where a = new char[][] { new char[] { 'a', 'b' } } <-- OK

So the list you get back is a List<char[]> that contains one element, which is an array of two characters.

Why doesn't it try T = Character instead? The compiler is choosing the "path of least conversions", so to speak. It's "easier/less effort" to treat the array as the object that it is instead of boxing every element in the array for you. That's why your final example works, because you've explicitly done the boxing for it already:

code:

public static <Character> List<Character> asList(Character... a) // where a = new Character[] { 'a', 'b' } <-- OK

This is just another illustration of one of those wonderful edge cases in Java generics that lead me to detest the way they've implemented them. :suicide:

# ¿ Mar 27, 2010 03:26

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

I am in posted:

I'll give a hint about the culprit. If you redo the code above to use this brace style
code:
if(condition) {
  doSomething();
}
you should see the problem quite quickly.

Telling him to switch to an inferior brace style is a terrible way of pointing him to his problem.

# ¿ May 31, 2010 21:13

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

TRex EaterofCars posted:

The generics. If you put List<Integer> instead of List<Object> it works how you want. If you want to refer to a List of anything just use List and ignore the parametric warnings.

This is what wildcards are for. If you want a method that takes a List of anything, do this:

code:

	public void method(List<?> o) {
		System.out.println("method two: " + o);
	}

# ¿ May 31, 2010 22:45

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

I just started working on a Tomcat application and it's been a while since I've done anything with Tomcat. I'm having a heck of a time solving the "where do we store user's preferences" problem.

Basically, the application let's the system administrator configure, through the application interface, a location on the file system to store user files, among other things. All the serious configuration data would be stored here as well, but this means we need a known fixed writable location where we can store the path to this storage area.

Obviously everything inside the web application's directory is writable, but the problem is that if we release an update and the user drops the new WAR file in for auto-deployment, the settings we've stored there get clobbered along with everything else.

Another option is to store this in a dot-file relative to user.home, but my worry is that if Tomcat is running as a daemon then this might not be a good place. Is that always guaranteed to be a write-permitted location?

So where the hell can I store a single string value in a place that is both writable from inside the web application, always known at time 0, and isn't going to be clobbered by auto-deployment?

Flobbster fucked around with this message at 18:51 on Jun 4, 2010

# ¿ Jun 4, 2010 18:48

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

TRex EaterofCars posted:

You should use jndi to specify that poo poo. You won't clobber it with deploys and each tomcat instance could have its own configuration (development/testing/production etc).

I tried that, but when I try to update the property from the control panel I've written in my app, I get an exception saying that the context is read-only.

In my WEB-INF/web.xml file I have this:

code:

    <env-entry>
        <env-entry-name>storageLocation</env-entry-name>
        <env-entry-type>java.lang.String</env-entry-type>
    </env-entry>

and I was trying to use this code to update it:

code:

    File location = ...;
    InitialContext ctx = new InitialContext();
    ctx.rebind("java:comp/env/storageLocation",
            location.getAbsolutePath());

What am I missing here? Do I need to get the context a different way?

# ¿ Jun 4, 2010 20:27

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Luminous posted:

I already have some classes that represent data and actions on that data

Call the plugin that contains these "Plugin-A".

quote:

and want to create a plugin that can either (or both) display that data or trigger actions on that data.

And call this "Plugin-B".

Plugin-B must depend on Plugin-A. You have a couple options -- static classes or factories that are initialized when Plugin-A loads (therefore they'll always be ready by the time Plugin-B loads), or add instance methods to the activator/plugin class for Plugin-A that give you access to the data so that somewhere in Plugin-B you can say Plugin_A.getDefault().getMyDataModel()....

Now, if you want Plugin-B to be able to respond to changes in Plugin-A's data that it didn't initiate, you'll need to make Plugin-A expose some kind of listener interface that Plugin-B can hook into when it loads. You can either do that hooking entirely in code, or this can be where extension points come in, because then you just add the listeners as extensions in the plugin.xml.

# ¿ Jun 11, 2010 16:39

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

But you can easily translate any one-way conditional statement into a for-loop, to get around the "don't use an if" restriction:

code:

if (condition) {
    // body
}

code:

for (boolean stop = false; condition && !stop; stop = true) {
    // body
}

Sorry, I thought this was the Coding Horrors thread for a second.

# ¿ Sep 26, 2010 17:05

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Internet Janitor posted:

What the hell is wrong with Javadocs? Having a standardized, easy-to-use documentation system like Javadoc is one of the best aspects of the JDK toolchain.

My beef with Javadoc is that their HTML generation hasn't changed since probably Java 1.0, and it shows. The HTML that gets generated is a horrible mess and it's impossible to style well.

Sure, there are other tools that probably do a better job, but it would be nice if ~~Sun~~ Oracle would bring the tool into the 21st century with better semantic HTML and classes on all the elements for easy CSS application.

# ¿ Oct 11, 2010 18:06

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

tef posted:

Reminds me of my favourite eclipse bug: Only on windows! https://bugs.eclipse.org/bugs/show_bug.cgi?id=319514

Sorry tef, but the best bug is the one where the forward Delete key stops working in Eclipse after the machine has been up for about 3 weeks, only on OS X: https://bugs.eclipse.org/bugs/show_bug.cgi?id=283415 :psyduck:

# ¿ Nov 5, 2010 14:01

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Pivo posted:

Guys, please help me out. Why is the "America/Anchorage" timezone returning an offset of -10 hours from GMT? It's -9 usually, -8 in DST. It is never -10.

Are you running the absolute latest dot-release of the JRE? The time zone stuff does get updated from time to time in those.

# ¿ Nov 9, 2010 13:24

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

What's really fun is teaching students in a second-semester Java data structures class the proper way to implement equals and hashCode, especially when the concept of hash tables hasn't been introduced yet so a hash code seems pointless to them. (Why teach hashCode without mentioning hash tables? If we're teaching them to override equals, it's better that we mention hashCode at the same time since the two are so closely related.)

I saw so much of this last semester:

code:

public boolean equals(Object other)
{
    return hashCode() == other.hashCode();
}

Some students at least understood that you could use the hashcodes to short-circuit for inequality but that it doesn't say anything about equality, but even that makes my skin crawl a little bit for some reason.

# ¿ Dec 9, 2010 22:04

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Kilson posted:

I think you can wrap an ArrayList with Collections.synchronizedList to make it thread-safe. Not sure what the performance characteristics are, or even the exact behavior.

Since Collections.synchronizedList returns a list that presumably has the synchronized modifier on each method (or synchronized(this) wrapping the body), it would be obtaining and releasing the monitor on each method call, so you could still run into concurrency issues if you needed to perform multiple operations on the list but have it appear atomic for the sake of consistency.

In most cases I think it's better to explicitly synchronize the list access code instead of relying on Collections.synchronizedList.

edit: beaten

# ¿ Jan 13, 2011 20:54

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

chippy posted:

I can access these resources just fine in my code by using "res/filename.here", and I've added that folder as a source folder in Eclipse, but when I build the .jar it copies the contents of the res folder into the jar, but *not* in a folder called res, just in the root of the .jar file, so my references in the code don't work anymore. I can fix this by changing the code, but then the compiled .jar works, but it doesn't work when I launch the project from Eclipse. I presume I'm just doing something wrong in the build config, how do I make this work?

Are you trying to load the resources just using File/FileInputStream/FileReader objects? That will work when the resources are in files on your file system but not when they're in jars, because those classes don't know anything about jar files.

You need to use getResource or getResourceAsStream instead, which will work correctly in both cases.

# ¿ Jun 27, 2011 15:04

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 20:02

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Aleksei Vasiliev posted:

Java 7 was just released.

Give me closures or give me death. Don't care about Java 7 since they pushed that back.

The Javadocs don't look like rear end that came out of the mid-1990s web though, that's nice.

# ¿ Jul 28, 2011 17:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.