Weblogs Forum - What Are Your Java Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 5 6 7 8 9 10 11 12 13 ... 18 | » ]

Wladimir van der Laan

Posts: 2
Nickname: wump
Registered: Feb, 2007

Re: Why I don't like Java

Posted: Feb 15, 2007 5:06 AM

What I like about java:

- The language. Clear, readable (generally), predicable and typesafe.

- The compiler. Fast, good error reporting.

- The tools. Eclipse, for example.

What I don't like:

- Too many different ways to do the same instead of one good one. You see this in for example persistence methods. All the abbreviations get me an headache very fast.
Sometimes I even resort to implementing something myself because all of the ready-made alternatives lack at least something.

- The GUI system. This points starts to improve recently with initiatives like accelerated Grapics2D, native-like swing GUI.

- Slow startup time of large Java apps. They should really cache the JIT'ed code somewhere.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 6:58 AM

> Well, if you want a technical reason, it is due to the way
> the JVM locates classes. When you ask the JVM to load a
> particular class, say using
> Class.forName(clsName), it will search for
> the class by its file name. Having a difference between
> the class name and file name would have made this process
> unncessarily complicated.
>

Another way to look at it is that it made writing the compiler a lot easier. Java isn't the first language to compromise the application developer's experience in order to make the language design process and implementation easier.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Why I don't like Java

Posted: Feb 15, 2007 7:53 AM

> Today I wrote a ten-line Perl script that reads a
> comma-separated file and, after massaging the data, puts
> that info into a database. Most of those ten lines had to
> do with ODBC.

Here's how I'd write this in Java, covering all the exceptional cases and using my http://sqlfactory.dev.java.net projects support for managing JDBC reliably. I count 26 lines, and I didn't actually try to reduce the number of lines needed.


public static void main( String args[] ) throws IOException, SQLException {
    FileReader fr = new FileReader( args[0] );
    try {
        BufferedReader rd = new BufferedReader( fr );
        String ln;
        DatabaseManager mgr = SQLFactory.getConnection( 
            "footprint", url, drvr, user, passwrd,
            conntime, transtime );
        PreparedStatement ps = mgr.prepareStatement(
            "insert into tbl (f1,f2,f3,f4,f5) "+
            "values (?,?,?,?,?)";
        try {
            while( ( ln = rd.readLine() ) != null ) {
                String arr[] = ln.split(",");
                for( int i = 0; i < arr.length; ++i ) {
                    ps.setObject( i+1, arr[i] );
                }
                ps.executeUpdate();
            }
        } finally {
            mgr.release();
        }
    } finally {
        fr.close();
    }
}

I think that there's not a lot of pain here. Instead, there are issues that just take code to work through. I'm taking advantage of JDBCs auto field type conversion through the PreparedStatement.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Why I don't like Java

Posted: Feb 15, 2007 8:05 AM

> /* [Me] I can't name a file 1.java, or 1goodTest.java
> because those aren't valid classnames. There's no
> technical reason for this restriction, it's just how
> things are.
>
> [Response] This rule makes it trivial to locate the source
> for class. Something which can be quite tedious in C++,
> where the programmer can scatter the methods of a class
> all over the place.
> */
>
> So it's not a technical reason, simply a "I think it's
> best to do it this way, therefore Everyone Must Do It This
> Way." I don't usually want to name a file 1.java (unless
> it's in a directory, of say, tests; where I then need to
> name it test1.java), but I don't see why Gosling should
> *force* me to name my files according to his rules.

The source file names can be different. It is possible to put a non public class inside of the source file for another class.


package a.b.c;

public class A {
    B b;
    public A( int val ) {
        b = new B(val);
    }
}

class B {
    int val;
    public B( int v ) {
        val = v * 100;
    }
}

should be placed the A.java source file. Class files, on the other hand, have to be locatable by the runtime environment. So, a particular classes .class file (if stored on a filesystem), is best named the same as the class name.

My biggest complaint in this arena is that Eclipse actually violates the JLS by using the directory structure as the "package" name instead of using the "package statement" declared name. That's a tool imposed naming scheme that is quite annoying for me.

Some of the compilers do actually (unfortunately they get it wrong in many cases) try and do dependency analysis and recompile classes other classes than the one that you are compiling. Having source file names the same as the classname, and located into a package based directory structure is part of the requirement for them to make this attempt.

javac had/has a -m command line argument which tries to do a dependency based compile (like the make(1) tool). It looks at the source file and the class file last modified times and recompiles the out of date classes.

I don't think this is the correct place for this behavior, and I really don't think a particular source directory structure should be required. I do believe that it makes sense to have the class source file use the same name as the public class to aid in finding the definition of a particular class.

If you've ever worked on a large project where others are creating source files and you are trying to work through a bug that involves others sources, you'll appreciate not having to waste time scouring the source tree for their source. Some IDEs make this trivial by just "CTRL-click" or some such on method and/or class names.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Why I don't like Java

Posted: Feb 15, 2007 8:10 AM

> - Slow startup time of large Java apps. They should really
> cache the JIT'ed code somewhere.

I've recently started trying to change the compile point of the JIT to see if I could improve this. I reduced the startup of one of my applications by 75% by adding

-XX:CompileThreshold=10

to my java command line. The client JIT compile point is, by default, 1000 method entries before compilation.

Don't try 1, that will make it take forever to startup, but try 10, 100, 500 etc to see if there's a breaking point where something that your application is doing a lot of at startup gets compiled and things suddenly start faster.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 10:12 AM

@Mitchell

> One pain point of mine is general installation/upgrade
> procedures for Java, including the sheer size of it. Not
> only is this a support headache for customers who do not
> already have Java, but then to explain to them that they
> need to download and install a 15MB program just to
> execute my own program is a little embarrassing.

We normally bundle a JRE with our apps. Makes the install bigger but we know we have a version that was tested, the user doesn't have to think, and disk space is cheap.

> Thanks to the new DST laws, nearly all my
> customers have to download a new version of Java

What are the DST laws?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Why I don't like Java

Posted: Feb 15, 2007 10:43 AM

> Here's how I'd write this in Java, covering all the
> exceptional cases and using my
> http://sqlfactory.dev.java.net projects support for
> managing JDBC reliably. I count 26 lines, and I didn't
> actually try to reduce the number of lines needed.

Not to try to one up Greg here but with some simple wrappers around the JDBC stuff, you can bring that down to this:

public static void main( String args[] ) throws IOException, SQLException {
    BufferedReader rd = new BufferedReader(new FileReader( args[0] ));
    try {
        String ln;
        QueryManager mgr = QueryManager.getManager();
        Update insert = mgr.createUpdate("insert into tbl (f1,f2,f3,f4,f5) "
            + "values (?f1?,?f2?,?f3?,?f4?,?f5?)", false); // set autocommit to false
 
        while( ( ln = rd.readLine() ) != null ) {
            String arr[] = ln.split(",");
            int index = 0;
 
            for(Iterator i = insert.getParameters().iterator(); i.hasNext(); index++) {
                insert.setObject((String) i.next(), arr[index]);
            }
 
            insert.execute();
        }
 
        mgr.commit();
    } finally {
        rd.close();
    }
}

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 10:51 AM

> What are the DST laws?

The US Congress, in it's infinite wisdom, decided to extend daylight savings time. It's ostensibly to save energy but will probably have the opposite effect. It means that I'll have more days to wake up in pitch-black darkness.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 12:22 PM

> I agree. I'm really trying to ask people who are
> programming in Java today what their pain points are.
Well, I don't feel pain when programming in Java.

I would feel pain if I had to program in a non-statically-typed language without IDEA or Eclipse (I can tell the difference, because sometimes I have to use some scripting language).

In other words: The Java deficits are not a major factor of productivity, but seeing the trend as it is, I hope to be able to switch to C# or maybe Scala in 2 or 3 years.

Mitchell Stewart

Posts: 7
Nickname: mstewart
Registered: Jan, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 12:46 PM

@Morgan

Yea, we do bundle a JRE normally, but we also have a product that utilizes Java Web Start. Now the html file that serves up the jnlp file does some magic to ensure Java is installed, and can direct people to download Java (even does it automatically if you are on Windows) but there is always the case where this doesn't work...and the manual process has to be performed. For instance..non-windows clients, security settings on the client machine, etc.

And as James said, there are new DST laws in Amurica that are starting this year in March. I believe DST starts earlier and ends later. Eventually the entire year will be under daylight savings...

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 12:47 PM

> I think there's a fine line between "pain point" and
> "wishful thinking". I think that suggestions that
> fundamentally alter Java to the point that it is
> unrecognizable are unfair. Take for instance the
> suggestion to remove semicolon...or to convert Java to a
> dynamically typed language. How do you reconcile older
> Java programs with these kinds of changes?

Why would adding support for dynamic binding cause problems for older programs? Static typing could still be supported, but adding dynamic binding could alleviate many of the issues other posters have raised about Java interfaces. The lack of dynamism is a huge pain point for me, since it makes it very difficult to follow an OO paradigm, and it often leads to code that is cumbersome to write and maintain.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 2:16 PM

> Why would adding support for dynamic binding cause
> problems for older programs? Static typing could still be
> supported, but adding dynamic binding could alleviate many
> of the issues other posters have raised about Java
> interfaces. The lack of dynamism is a huge pain
> point for me, since it makes it very difficult to follow
> an OO paradigm, and it often leads to code that is
> cumbersome to write and maintain.

I'd guess that, in general, my programs would run slower with dynamic binding because there would be more time spent deciding what method to call. With overloaded methods, it's necessary to check all the types of all the arguments and that includes classloader comparisons and several other steps which go beyond a simple "method by name is implemented" check.

I'm a fan of interfaces. The only thing that they add is more keystrokes to type in the definition of a class. After that, they provide type safe declarations that allow you to not have to worry about whether something will resolve and actually work in the environment it is run in.

Maybe you can share why interfaces don't work for you?

I hear a lot of people talk about how many keystrokes or how much text. If keystrokes and text bulk were not the issue, what would the real issues be that would make dynamic typing really work better?

I'm not having any problems using Java to solve a large number of problems. The problem domains that I do have issues within are really about OS interfacing where JNI is the typical solution. I am an accomplished user of JNI, but I really don't enjoy using it.

Mitchell Stewart

Posts: 7
Nickname: mstewart
Registered: Jan, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 2:38 PM

Maybe it's possible to allow statically typed programs to run within a dynamically typed Java VM. But I just feel this kind of change would be such a dramatic shift from the fundamentals of Java, it being a strongly-typed OO language. Once you switch to dynamic typing, you have moved yourself into another language, imo.

Unless it's possible to "simulate" dynamic typing with a strongly typed compiler...then it could work. Just the brief things I've read about Scala reminds of this...the compiler does more work in trying to figure out what types your variables are, when possible.

david m

Posts: 4
Nickname: davidm
Registered: May, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 2:40 PM

I am surprised by most of the responses on this topic.

I am not a computer scientist, just a grunt who likes and uses Java.

What I dislike is mostly the conventions and kits developed around Java.

Trivially; variables should use underscores, not StudlyCaps. It makes it easier for int'l developers.

The lack of zero turn around time runtimes, everything requires so much weight and designing loses its fluidity. Having to restart a container for any class change.

The massive startup time for applets (not that I don't think most people have given up on them, but for projects like the Java NASA WorldWind project - interactive 3d maps in your browser, thanks to applets - it could make a big difference).

The #1 pain point though: too much choice. Too many frameworks and even low level toolkits. Sort of like PHP, in fact Java is its own ecosystem. Java is much better designed than PHP, but PHP is much easier to get into, so people spec'ing projects are preferring it, from what I've noticed. If there were fewer choices then there wouldn't be so much to explain, it wouldn't take people months to get up to speed, they wouldn't give up even though the answer is in the stack trace in front of them.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 2:56 PM

> Why would adding support for dynamic binding cause
> problems for older programs? Static typing could still be
> supported, but adding dynamic binding could alleviate many
> of the issues other posters have raised about Java
> interfaces. The lack of dynamism is a huge pain
> point for me, since it makes it very difficult to follow
> an OO paradigm, and it often leads to code that is
> cumbersome to write and maintain.

I think it's important for clarity that you point out whether you use the Alan Kay definition of OO. I'm fairly certain that most developers, especially Java developers, think of OO in the C++/Simula sense.

I suspect that you are in the SmallTalk camp from your comment here. If you are trying to use SmallTalk style approaches in Java, you are going to be very disappointed. JavaBeans are a perfect example of this.

My personal feeling is that instead of trying to retrofit Java to be a dynamic language, using dynamic languages in that can interact with Java is more likely to be successful. I've been working with this paradigm for a while and it's really pretty great, actually. Java makes a good sturdy, reliable foundation (that doesn't shift much) to build on with more pliable components.

Flat View: This topic has 264 replies on 18 pages [ « | 5 6 7 8 9 10 11 12 13 | » ]

Previous Topic

Next Topic