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.

«‹›5 »

zootm: Aug 8, 2006; We used to be better friends.

Twitchy posted:

If you have the JDK installed most IDE's will let you right click the Class name and goto the source code.

Just ctrl-clicking the item in question should take you there in Netbeans or Eclipse.

# ¿ Jun 5, 2008 12:19

Adbot: ADBOT LOVES YOU

# ¿ May 9, 2024 20:43

zootm: Aug 8, 2006; We used to be better friends.

You're only reassigning the field jList1; the original JList instance is still displayed in the UI. What you should really be doing is is assigning a DefaultListModel to jList1 once, never reconstructing jList1, and modifying the model (i.e. the DefaulListModel object) directly.

For what it's worth you look like you're using Netbeans. Create a new property (i.e. a getter) for a ListModel instance on the main object and use that in the designer as the model for the element (there's a dropdown that'll let you select any property of the right type). Just have a field containing the (one!) DefaultListModel instance you're using, have the getter return that, and operate only on that.

zootm fucked around with this message at 19:51 on Jun 10, 2008

# ¿ Jun 10, 2008 19:42

zootm: Aug 8, 2006; We used to be better friends.

More explicitly, the property (along with the field) would look like this:

code:

DefaultListModel listModel = new DefaultListModel();

public ListModel getListModel()
{
    return listModel;
}

Now, the NB 6 releases seem to have this jazzy new binding framework stuff that lets you bind to whatever property on whatever object you feel like. To do this for this simple example, go to the properties for your JList in the editor, select the "..." to bind the property "model", then select the object "Form" (which refers to the current form) and there should be a property "listModel" listed, corresponding to your item. Select this and it will insert something like ${listModel} into the box and that's your binding done and dusted.

From then on just write your action handlers to update the model and the changes will be shown in the UI. You do not need to manually update the UI at all, Swing is pretty good for noticing changes in its underlying models and updating automatically.

Edit: Here is the full source to an example which I just made in the UI designer, hopefully it'll be illustrative. The only methods I wrote are the ones detailed above and the content of the "hilarityButtonActionPerformed" method (the method itself was added by the designer). Incidentally I don't know how the binding stuff works in full but it might be possible to bind your data more directly to the "elements" property of the JList.

zootm fucked around with this message at 21:05 on Jun 10, 2008

# ¿ Jun 10, 2008 21:02

zootm: Aug 8, 2006; We used to be better friends.

No problem. Incidentally, though, Java 5 and 6 can call 1.4 JARs without any problem at all; unless you need the code you produce to run on 1.4 or earlier it shouldn't be an issue at all.

# ¿ Jun 11, 2008 09:30

zootm: Aug 8, 2006; We used to be better friends.

Netbeans, using its newer Swing Application Framework stuff, is very good at making SAF apps. I assume your other Netbeans entry is the Netbeans framework itself, which is neat but only really for apps which are a lot like Netbeans, like you state. Eclipse is much the same when used as a framework.

I wouldn't go with QtJambi since I'm not a big fan of Qt, although as you say it might fit well with you since you do like the framework. Swing has the advantage of (these days) integrating very well with both Windows and Linux (GTK+) systems; the OS X stuff is nice too but Apple provide it themselves and it can be a little slow. Pre-Qt4 I'm not sure how great Qt is across platforms.

zootm fucked around with this message at 14:27 on Jun 11, 2008

# ¿ Jun 11, 2008 14:23

zootm: Aug 8, 2006; We used to be better friends.

You're right, BeefofAges, Java doesn't have operator overloading.

# ¿ Jun 20, 2008 11:00

zootm: Aug 8, 2006; We used to be better friends.

This all seems extremely complicated, but the implementation looks at least mostly correct - the paper in question is here. Concurrent algorithms are something of a black art and I this is currently hurting my head.

You could be correct though, it might be that head should be written as an atomic reference to the same node as tail rather than being the same atomic reference. Not sure, though. The line in the paper there is:

code:

Q�>Head = Q�>Tail = node

If Head and Tail are both supposed to be independent atomic references to "node", that would tally better with them each being a separate AtomicReference instance.

Edit: The implementation given is consistent with (not the same as, but consistent with) the one in OpenJDK. :psyduck:

zootm fucked around with this message at 11:18 on Jun 21, 2008

# ¿ Jun 21, 2008 10:58

zootm: Aug 8, 2006; We used to be better friends.

poopiehead posted:

The OpdenJDK implementation looks ok. tail and head are volatile read-only fields. They use this special atomic reference class that handles all of the writes to the fields using reflection. Hopefully that makes you feel better

When I was looking at the OpenJDK one, it looked a lot like both head and tail fields were initialised to the same container instance, and the container instances used the reflection thing to update their "next" and "item" fields. Confusing anyway!

# ¿ Jun 21, 2008 22:34

zootm: Aug 8, 2006; We used to be better friends.

That's not what I thought I read at all! I'll need to check up on that again. Neat, anyway.

# ¿ Jun 22, 2008 00:54

zootm: Aug 8, 2006; We used to be better friends.

I think the ByteBuffer solution is the "correct" one here, but if that Swap thing works for you and it's a small project then I suppose you may as well.

# ¿ Jun 25, 2008 08:56

zootm: Aug 8, 2006; We used to be better friends.

csammis posted:

Also why are you using @Override on an interface method?

Eclipse does it by default, warns if you don't, and it's as useful there as anywhere

# ¿ Jun 26, 2008 18:32

zootm: Aug 8, 2006; We used to be better friends.

poopiehead posted:

In C#, it's even part of the method signature.

In C# the keyword does actually mean something, though; in Java it's not required mostly because it's just a check, as you say. It is very useful in the cases that you note.

poopiehead posted:

On using @Override with interfaces, it will actually cause a compiler error in Java 5, but will not in Java 6.

Yeah, I think that's why people are surprised to see it.

# ¿ Jun 27, 2008 11:24

zootm: Aug 8, 2006; We used to be better friends.

Changing the command line arguments only changes the memory available to Eclipse itself; your program runs in a completely separate VM. You can manage this from within Eclipse. One way to do it is in Preferences, go to Java/Installed JREs, "Edit..." the one you use, and then put args in "default VM arguments". You can also do it on a per-launch configuration basis by playing with them in your project settings.

# ¿ Jun 28, 2008 00:25

zootm: Aug 8, 2006; We used to be better friends.

Smackbilly posted:

Oops, yeah, I was thinking in C++ there (where a throw with no arguments re-throws the exception you just caught).

This also works in C#, incidentally. I thought you'd put a C# code sample in the Java thread there, which was jolly confusing.

# ¿ Jul 10, 2008 09:32

zootm: Aug 8, 2006; We used to be better friends.

I'm pretty sure there's not in the default libraries.

# ¿ Jul 13, 2008 22:51

zootm: Aug 8, 2006; We used to be better friends.

I think the libraries just use the OS stuff transparently, and there isn't a direct way to do that. I imagine there's about a billion libraries available for it though.

Edit: Actually it looks like this might let you access stuff through JNDI, although the one "review" of it I saw didn't seem to rate it highly. This library looks a bit more direct, and is allegedly used by quite a few projects.

zootm fucked around with this message at 09:24 on Jul 14, 2008

# ¿ Jul 14, 2008 09:19

zootm: Aug 8, 2006; We used to be better friends.

csammis posted:

What sort of metric is "classy," and how are virtual methods informal? A virtual (abstract) method is exactly what you want here, and like 10011 said it'd just be protected if you didn't want callers to access it*.

* barring Java's retarded implementation of protected, there, I said it

People who prefer stuff that's a little different might want to do this through composition:

code:

class ProfitModel implements Runnable
{
  private final Runnable step2;

  public ProfitModel( Runnable step2 )
  {
    this.step2 = step2;
  }

  public void run()
  {
    getPeopleToSignUp();
    step2.run();
    profit();
  }
}

Used with an anonymous Runnable it does what you want, either passing it inline or even doing this through inheritance:

code:

class AgricultureProfitModel extends ProfitModel
{
  public AgricultureProfitModel()
  {
    super( new Runnable() {
      public void run()
      {
        plantCrops();
      }
    } );
  }
}

code:

public ProfitModel getMarketingProfitModel( Masses masses )
{
  return new ProfitModel( new Runnable() {
    public void run()
    {
      masses.brainwash();
    }
  } );
}

Usually for that sort of thing it's advantageous to use an actual class for the given Runnable to make it more testable, but these techniques will hide the functionality more in the way you want I think.

# ¿ Jul 14, 2008 19:27

zootm: Aug 8, 2006; We used to be better friends.

clayburn posted:

Anyone know how to restore the build.xml file that NetBeans creates? I have a project and somehow mine got messed up and now it won't compile.

The project.xml file that NetBeans generates is incredibly small, the main stuff is in the "nbproject" directory. If you create a new project the build.xml you have will be almost exactly what you need (there will probably be references to the project name etc.). What's the issue you're having?

# ¿ Jul 18, 2008 00:25

zootm: Aug 8, 2006; We used to be better friends.

Profilers can usually track where allocations happen as well as what was allocated, I'd investigate that. Is it possible that you're keeping one massive transaction open, or just re-using something that's supposed to be discarded? I'd guess it's somewhere in the database connector but I've really no idea I'm afraid.

# ¿ Jul 24, 2008 11:50

zootm: Aug 8, 2006; We used to be better friends.

Entheogen posted:

I believe you want to look into finalize() method. You can overload that for your class and it will get called by garbage collector when it frees that object from heap.

The finalizer is never what you want to use. If the memory isn't being freed when the object is no longer referred to, it's got a bug; however much more common is that the object itself is supposed to be dropped but isn't.

In the case of java.net.IDN the methods are all static and it cannot be overridden or instantiated anyway, so the point is moot, but in general if you think it's a good idea to use a finalizer you're likely to be wrong. They're sadly not very useful.

Entheogen posted:

I don't know how IDN class works, but perhaps it has handle to some native resources and is not designed to free them? This is usually how memory leaks occur in Java. You could perhaps write your own class extending from IDN and then free whatever IDN doesn't?

It doesn't use native code, it's pure Java. Looking at the source I'm also pretty sure it doesn't have any leaks (which are most commonly caused by hanging references in pure Java code). I think you're looking in the wrong place Fehler.

# ¿ Jul 24, 2008 20:53

zootm: Aug 8, 2006; We used to be better friends.

Entheogen posted:

How can I determine endianess of a floating point number at run time? That is, I am reading a binary file and I would like to determine whether I should reverse the bits or not. Is this even possible?

I'm pretty sure it's not possible unless you know what the number should be, but then you wouldn't be trying to read it...

# ¿ Aug 1, 2008 09:23

zootm: Aug 8, 2006; We used to be better friends.

GT_Onizuka posted:

Recommendations for a Java memory profiler? I don't want to attach it to any IDE as I need to run it all remotely. We're using Java 1.5.

The IDE ones usually work remotely (certainly the NetBeans one can, I think it's pretty standard), but I've had better success with JProfiler remote. Not free, though.

# ¿ Aug 16, 2008 10:03

zootm: Aug 8, 2006; We used to be better friends.

Chuu posted:

According to the book I'm using to study, this should be equivalent to Implementation #1. Read naively, to me this means "Wait for the class lock before executing "counter()" then "Wait for the class lock before executing the return statement" i.e. it should automatically deadlock. Since it's functionally equivalent though, I assumed the "synchronized" keyword meant "somewhere in this method something is synchronized, not necessarily the entire method, unless you do not see a synchronized block, then the entire method is synchronized" i.e. it won't deadlock. Does what's expected, prints "hi". The problem is . . .

You've misinterpreted it. The synchronized keyword on a method signature always obtains a lock on the class object, even if there's a synchronized block inside the method. What you're missing is that the lock is held by the running thread - so when you run that inner block you already have the lock you ask to obtain.

Chuu posted:

So what exactly is the difference in #2 and #3, or is there something going on here that my trivial example isn't showing?

If you write code outside of the inner synchronized block in 2, it will still be synchronized, in 3 any code outside of there will not require the class lock to be held to run.

All three programs are equivalent but a synchronized block on the class within a synchronized method as in 2 will never do anything.

As an extreme example, here's another equivalent program:

code:

class Lock2 {
  static int count = 0;
  public static synchronized int counter() {
    synchronized(Lock2.class){
      synchronized(Lock2.class){
        synchronized(Lock2.class){
          synchronized(Lock2.class){
            return count++;
          }
        }
      }
    }
  }
}

Obtaining a lock you already have doesn't do anything.

zootm fucked around with this message at 15:00 on Aug 16, 2008

# ¿ Aug 16, 2008 14:55

zootm: Aug 8, 2006; We used to be better friends.

Chuu posted:

Ahh, ok, thanks a lot. I assumed they work the same was as mutexes on *nix.

To make sure, so if you have code like:

static synchronized void a(){...}
static synchronized void b(){...}

Any code which has control of the lock and executing a() will block any other threads from running b(), since the class level lock is associated with all static synchronized code in the entire class?

Yes. Making a static method synchronized is really just syntactic sugar for enclosing its entire contents in synchronized( Whatever.class ). Similarly putting that modifier on an instance method is equivalent to wrapping the contents with synchronized( this ).

zootm fucked around with this message at 17:46 on Aug 16, 2008

# ¿ Aug 16, 2008 17:37

zootm: Aug 8, 2006; We used to be better friends.

1337JiveTurkey posted:

Apache Derby claims to be fairly lightweight but I don't have much experience with it.

It can be quite memory hungry from my experience, but my experience is very old. It is a "full" SQL implementation, though, rather than SQLite and the like which are cut down in order to be more lightweight.

# ¿ Aug 21, 2008 09:40

zootm: Aug 8, 2006; We used to be better friends.

The non-blocking IO stuff in java.nio lets you deal with many inputs using very few Java threads. You stated before that you knew of no non-blocking alternative so there it is. It's not on Reader because Reader etc. predate all the non-blocking stuff they added in I think version 5. But really I'm kind of lost trying to figure out what all this bickering is about.

For what it's worth an N thread pool to service M readers is still only N threads (Readers do not spin up their own threads - what would be the point?). It will only service N Readers at the same time, though, which kind of defeats the purpose.

zootm fucked around with this message at 22:16 on Aug 25, 2008

# ¿ Aug 25, 2008 22:11

zootm: Aug 8, 2006; We used to be better friends.

triplekungfu posted:

No, that's not what I meant, in the example I gave earlier I had three threads servicing 15 objects.

I got bored and whipped this up. There's 5 threads servicing brs.length BufferedReaders.

To be fair if you put them all in a list and iterate over them you can service any number of BufferedReaders with a single thread, can't you? A threadpool of size 5 will at most be servicing 5 BufferedReaders at one time. It runs one task per thread at any one time and it cannot start another until one terminates if it is already using all of its threads (try this for an example using sleeps rather than Readers since I'm lazy). I think the question was about servicing several inputs at once without spinning up a service thread for each, in which case java.nio is probably the right answer.

zootm fucked around with this message at 14:09 on Aug 26, 2008

# ¿ Aug 26, 2008 13:57

zootm: Aug 8, 2006; We used to be better friends.

Mustach posted:

The lesson is that everything that depends on input should be in the try block:

I'd consider this pretty bad style - it's usually best to avoid putting code that doesn't throw a given exception in a 'try' block which catches it. Removing the '= null' from the variable declaration will cause the compiler to check that any control flow to a line where you use the variable definitely assigns it.

There's two other problems here though - the compiler may not recognise that System.exit terminates control flow (although really avoiding that function is the best solution for that). The other problem is that FindBugs may not think that 'readLine' returns a non-null value.

# ¿ Aug 29, 2008 07:59

zootm: Aug 8, 2006; We used to be better friends.

Mustach posted:

code:

// zootm version
String input /* = null */;
try{
  input = in.readLine();
}catch(IOException e){
  oops(e);
}
if(input == null) continue; // error, variable 'input' might not have been initialized
else if(isExitCommand(input)) break;
else try{
  doWhateverIWantWithInput(input);
}catch(WhateverIWantException e){
  oops2(e);
}

More like this (assuming that in is a BufferedReader wrapping System.in there is no need to check if the input is null, since that stream doesn't terminate):

code:

String input;
try {
  input = in.readLine();
} catch( IOException e ) {
  throw new UnhandledException( "Unexpected error reading input", e );
}

// No compiler error below because the try block is guaranteed to have run.
System.out.println( "Input was: " + input );

Of course the other way to do it would be to just don't catch the exception, allowing it to propagate to somewhere that might actually have error-handling code. It is absolutely correct to just add a "throws" clause if you have no intent to recover from the exception. The UnhandledException up there is a RuntimeException from Commons Lang which is used when you don't have cleanup code but you can't throw a non-Runtime exception for interface reasons or similar. If you have a default value for input in this case, you can assign that in the catch too, and the compiler will not complain.

zootm fucked around with this message at 13:50 on Aug 29, 2008

# ¿ Aug 29, 2008 13:40

zootm: Aug 8, 2006; We used to be better friends.

Mustach posted:

What makes that superior to
code:
String input;
try {
  input = in.readLine();
  // No compiler error below because the try block is guaranteed to have run.
  System.out.println( "Input was: " + input );
} catch( IOException e ) {
  throw new UnhandledException( "Unexpected error reading input", e );
}
? That's all I'm arguing about, not the merits of throwing/rethrowing or exiting/not-exiting, etc.

I find that that sort of thing tends to muddy up the code clarity; the one I posted makes it immediately apparent what code throws the exception. Also when people add extra "throws" to other methods in the logic, you may not want the same cleanup code to be executed.

# ¿ Aug 29, 2008 15:17

zootm: Aug 8, 2006; We used to be better friends.

Make sure that a.equals( b ) iff a.compareTo( b ) == 0. The first condition needs to be true for 'get' to yield a value, but the second is the case where keys will overwrite elements, I think.

# ¿ Aug 30, 2008 09:48

zootm: Aug 8, 2006; We used to be better friends.

invid posted:

I'm creating a jsp powered booking system and I'm not sure how I should be doing the controller classes. I have a jsp (view) that displays all the bookings, and on that page, users can add or delete them. Currently I'm using a addBooking servlet, should I be creating a delBooking Servlet, or is there a better way to do this (MVC)?

The Servlet API is pretty much intentionally over-general. You might be better looking into something like Tapestry, or Spring MVC, and just do whatever their conventions are. You'll end up building your own framework before long, otherwise.

dancavallaro posted:

I have a bunch of mailing list data in an Excel file that I want to put in an Access file (I would prefer/it would be easier to use mySQL, but I'm doing this pro bono for a non-profit and they want it in an Access DB). Ideally I could just import the data into Access using the import wizard, but I need to do some processing on the data before I can import it, and I want to split it into 2 files. I was hoping to do this with Java, because that's the language I'm most familiar with. I was hoping to just export the Excel file as CSV data, and then write a Java program to process the data and insert it into my Access database. If there's a better way to do this, I'm open to suggestions, but I'd like to use Java and I'm just having trouble interfacing with Access. How can I use an Access database from Java?

You can access Excel documents using Apache POI (this was pretty bad for a while but I hear it's a lot better now), and I'm led to believe that you can access Access databases from Java using the JDBC-ODBC bridge driver. This claims to work.

zootm fucked around with this message at 16:10 on Sep 1, 2008

# ¿ Sep 1, 2008 16:06

zootm: Aug 8, 2006; We used to be better friends.

I think that the NetBeans 6.5 beta may have Groovy support, they've added a ton of dynamic language support in there recently and it works pretty well. Failing that some nerd may well have made nice Vim or Emacs bindings.

# ¿ Sep 2, 2008 00:51

zootm: Aug 8, 2006; We used to be better friends.

I never hear anything but glowing reviews about everything IntelliJ IDEA does so yeah, if willing to fork out the cash it's likely a good call.

# ¿ Sep 2, 2008 18:07

zootm: Aug 8, 2006; We used to be better friends.

Edit - double post

# ¿ Sep 2, 2008 18:07

zootm: Aug 8, 2006; We used to be better friends.

Could be a shaky JDBC driver I guess. Without the actual error this'll be basically impossible to diagnose though.

# ¿ Sep 3, 2008 14:08

zootm: Aug 8, 2006; We used to be better friends.

If you're having problems, surely an exception was thrown?

Also I've noticed that in your SQL statement you pass the last argument as a string, whereas in your Java code you set it as a number. Depending on your database this could cause a problem.

# ¿ Sep 3, 2008 14:34

zootm: Aug 8, 2006; We used to be better friends.

You're catching the SQLException and not using its value. Try at least printing it out.

# ¿ Sep 3, 2008 15:10

zootm: Aug 8, 2006; We used to be better friends.

If you create an interface which defines your expected method call, you can avoid using reflection (build the class and then just newInstance it then cast to MyInterface or Callable<T> or whatever).

As for your "deeper" problem, I really don't know why serialising a Class instance doesn't work - it may "just work" unless the byte array is really tiny. Also, to load your own classes in a custom way, you probably want your own ClassLoader implementation - try subclassing ClassLoader (I don't think you need the extra gubbins that SecureClassLoader buys you but I could easily be wrong).

Of course the "outside the box" solution would be to use javax.script and define the function to be called in Javascript (comes with SE6) or any one of these languages (requires bundling the runtime for the language, which can get large). Then you just need to pass the string of the source. Probably completely over the top for any reasonable use-case though.

zootm fucked around with this message at 17:33 on Sep 9, 2008

# ¿ Sep 9, 2008 17:30

Adbot: ADBOT LOVES YOU

# ¿ May 9, 2024 20:43

zootm: Aug 8, 2006; We used to be better friends.

Flamadiddle posted:

is this the proper solution?

With applets, I think it is. Executable JAR files can specify their dependencies in their manifest, so that might work too. Also Java Web Start has a magic dependency mechanism of some kind as well. Actually if you're accessing a database through an applet, maybe a full-blown Web Start app is a better fit for your use-case.

# ¿ Sep 16, 2008 19:32

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

«‹›5 »