Slashdot Mirror

It's funny that you mention Web Services, as it's one of the places Java has actually moved forwards.

Gone are the days where you need Apache Axis. Java comes with a web service stack right out of the box now. They're really easy to set up in Netbeans, too.

Unfortunately, the Java poster-child, Eclipse, hasn't adopted this web service stack yet. Not that I dislike Eclipse, but it tends to ignore things added to Java in favor of third party implementations... such as Apache Axis 1... and SWT.

Given that SWT is an Eclipse product, Eclipse has exceptionally poor support for it. Eclipse's Visual Editor Project doesn't even work on Eclipse 3.3, 3.4, or 3.5... the latest stable version of VEP being released on January 30, 2007. It finally resumed development a few months ago, but who knows how long it will be until a stable release comes out.

Servlets are downright evil. JSP's tag soup isn't much better. JSF sounds interesting, but until Facelets become more common, it's fairly useless.

Even Oracle is starting to push certain third party products. Oracle's Eclipse distribution (which we use where I work) includes plugins for webapp tools such as the Spring Framework.

Summary From the foregoing discussion it should be clear that Java's date-handling classes are not just complicated, but also poorly designed. Encapsulation is leaky, the APIs are baroque and not well-organized, and uncommon idioms are employed frequently for no good reason. The implementation holds additional surprises (I suggest a look at the actual type of the object returned from Calendar.getInstance( Locale ) for all available locales!) On the other hand, the classes manage to treat all of the difficulties inherent in internationalized date handling and, in any case, are here to stay. I hope that this article was a little contribution in helping to clarify their proper usage.

PHP doesn't scale well? Wha?

"The PHP Scalability Myth"
http://www.onjava.com/pub/a/onjava/2003/10/15/php_ scalability.html

Hmm...interesting...this article says that there are 64-bit VMs with JIT. And this one talks about "beta versions for Windows 2000 and Linux on the Itanium platform (the virtual machine being a true 64-bit application)." Now it may be that these JITs are just compiling to x86 code, which then runs on an Itanium, so maybe it wouldn't be quite as fast as code that was specifically generated for the Itanium instruction set, but still I would think the performance would be plenty good enough for running applets in a web browser, which is what the OP was talking about. AFAICT, the issue is simply that nobody has put the work into packaging the existing 64-bit VMs as browser plugins.

Well, considering that AJAX is used on only a tiny proportion of web sites, and often not to particularly good effect, I'd say that's a bit of a silly claim. In any case, AJAX often suffers from the same flaws as pseudo-web technologies like Flash before it: lack of bookmarkability, breaking back buttons, etc. These are far more likely to doom it than any random security flaw.

Thankfully, someone already though of it... More than a year ago, at least, in here

Sure, there should be a standard way to do it, but it's not impossible :p

There are plenty of good open source CMS systems in Java.

At the bank I work at we use OpenCMS.

Magnolia Community Edition is probably better.

Apache Lenya is another CMS written by a well known group but I can't vouch for it

JBoss Nukes is poorly documented but written by JBoss so should be good.

As for the JDBC emulator... Have you looked at ORM tools like Hibernate? You can design tables and have hibernate automatically build objects that impliment the table design. Then, your custom objects would interact with the auto-generated objects. It's not perfect, but really abstracts the database from your application.

The best part is that you can create a complete application without writing a single SQL query by simply using a RAD tool (mysql-query-browser for example) for the databsae design, and something like hibernatesync for Eclipse to auto-generate the XML mapping files and the objects.
http://www.onjava.com/lpt/a/5537

Besides the fact that there is already a JVM that implements the Real-Time Specification for Java and is available for free from Sun? There's even a introduction for it to help developers get an idea of just what it has to offer.

I'm curious to know a bit more, purely because we are trying to re-invent the wheel where I currently work with a similar system that will across our different development environments (.Net, PHP, Java) in a unified way. Upon first usage, Rails appeared to have it nailed for me so much of our emulation has been holding that as a benchmark... but if there are better options I'd love to be looking closer at them. The most simple introduction to JDO I found was here:

http://www.onjava.com/pub/a/onjava/2002/02/06/jdo1 .html

So with the person class I define in the class all of available attributes, a getter and setter for each, and a constructor.

On rails in a production environment it would be:

class Person
end

and the first time the model is called its structure is defined by ruby/rails and cached. Now if you wish to define (or redefine) aspects of the model, you are free to do so. I can replace the automagically generated accessors with whatever I feel like. I can also redefine field mappings and all manner of other things. So from the example given by O'Reilly I can't immediately see the benefit JDO provides in terms of development, I can come to the exact same point with a comparable amount of code in Ruby or I can short cut it and accept the default behaviour with substantially less. All with no SQL at all.

Where the difference may well exist is in the SQL generated in the back end, and I suspect this is where the original developers/engineers of each solution had a difference in opinion. I'm more accustomed to seperating the SQL logic into views and stored procedures from the outset to improve performance and provide means of controlling how everyone accesses the data. It means much playing around with SQL pre-deployment to improve queries and indexes on tables. Rails has taken the view that theoretical performance issues may never occur and time spent addressing them could well be time wasted, or even worse that your theoretical issues are wrong and bottlenecks occur in other parts of the system. It's this view which means that "high-performance SQL" can not be "automatically generated". The system can't intuitively know the best way to index a table or order data until real world usage occurs, and so that is left as an exercise to the reader. If/when it becomes an issue then it's time to incrementally start over-writing the default options in the areas that need to be addressed. I'd take this approach as under engineering at the outset and then engineering where required later. While I haven't had to deploy a site under serious load yet, I have to say that that it has definitely had it's benefits. And I'd back myself to write more appropriate and beter performing SQL (and indexes) for a given situation than a tool that attempts to do it automatically... so it's an approach that seems more sensible to me.

So I accept that the O'Reilly example was fairly basic, but if the only difference is in the performance of the SQL generated by the two frameworks then personally I think the rails approach makes more sense as good performing queries aren't solely dependent on the way you write a select statement.

> No", who would run PHP on Java anyway?

Those who are fed up with the JSP crap: http://www.onjava.com/pub/a/onjava/2004/06/09/jsf. html?page=1

> Why?

Because Apache/PHP on Tomcat delivers java based content more than two times faster than Tomcat standalone: http://php-java-bridge.sourceforge.net/NEWS

> Why would open-sourcing it help?

So that we don't have to re-invent the wheel everytime a new API comes out: http://php-java-bridge.sourceforge.net/server/docu mentation/API/javax/script/Bindings.html. Note that it is (C) by Nandika Jayawardana , Sanka Samaranayake, a clean-room implementation of the abandoned JSR223 API from SUN: http://www.jcp.org/aboutJava/communityprocess/edr/ jsr223/

Also note that the JSR223 API is *not* part of the official java, rather a re-written API which has been inspired by JSR223. If java were free software (not necessarily open-source) that crappy JSR223 API whould have never appeared.

> No, what is lacking?

Support for Unix Domain Sockets. Because of this the FreeBSD Java implementation is 300 times (!) slower than the Java implementations on Linux, Solaris or Windows:

http://groups.google.de/group/comp.lang.php/browse _frm/thread/1eeeddb37086688/8d3414d188a327a9?rnum= 2#8d3414d188a327a9

And

http://php-java-bridge.sourceforge.net/snaps/FreeB SD/TestServ.java

Haven't you seen annotations ?

With that being said, Java EE 5 will make enterprise Java developer's lives much easier. EJBs, everyone's favorite whipping boy, are a lot easier to code now.

Bwuaah hah aha hahahaha. Let's see, we go from EJB's are evil to a lot easier to code now. Sure, after getting burned and poked in the fires of hell by Sun's concept of a business layer, just getting slow roasted on a spit is prefered.

1. JBoss is not the leading product in the J2EE market. It's a competitor, but nowhere near the top.

You might want to check your facts before posting this kind of FUD.

...is a good guy to write this sort of thing since he's been programming Java for a long time and has also branched out into "dynamic Java" things like Groovy. He's done a bunch of stuff on dbUnit (including a dbUnit chapter in Java Testing Patterns), too. So he's had enough experience with Java to know what's what.

I'm probably biased, though, since Andy also wrote the CPD Ant task.

Problem is that Java programmers have been bought up by big companies deploying enterprise applications and they really haven't been contributing to open source projects.

My only complaint about AJAX sites is it makes bookmarking something damn near impossible.

All AJAX developers should take a look at this article: AJAX: How to handle bookmarks and back buttons.

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is news? ONJava did a detailed, four-part analysis of .Net and Java security a year or so ago:

• Java vs. .NET Security, Part 1
• Java vs. .NET Security, Part 2
• Java vs. .NET Security, Part 3
• Java vs. .NET Security, Part 4
• Java vs. .NET Security, Epilogue

This is obviously not about the PHP Language itself as you are definitely looking at your alternative as better... While I can program java, I can program python, etc etc... I use PHP for the web, and in an enterprise environment as that! You claim PHP is the root of all evil, take a look at an operating system, whose job is it to make sure that any type of security whole is plugged? Yours. Next lets talk about scalability, PHP is highly scalable as long as you understand the structure and logic of the language, which is not like your current language. That is why it bugs you. Currently I have around 30 files that operate 70 websites (and no this is a single set they are not mirrored on all the sites). Pretty much they are mainly objects and a few controllers which the user can override the global scope in site of their local scope for pages. The configuration is easy and sql injections can happen in just about any language. Programming for the web I can pretty much show you vunrible applications everywhere. This is not just a PHP thing. How about the infamous buffer overflows with Java? Had that one happen? This thread is mainly all opinionated with no factoral history. And if you are going to call out something as huge security risks without providing a fact then you are just blowing steam up everyone for no reason. Get a job, learn more about secure computing, and stop trying to advocate other languages as better than this or that when it is simple opinionated with out any benchmarks, security advisories, references. Now heres my turn. Java has security problems because people code them in according to your philosophy, as for the tutorial on writing secure php code... well here is one for java: http://www.javaworld.com/javaworld/jw-12-1998/jw-1 2-securityrules.html Meanwhile here are the latest records for programming languages (latest versions) php: http://secunia.com/product/3919/ asp.net: http://secunia.com/product/2173/ java jdk: http://secunia.com/product/4621/ j2ee: http://secunia.com/product/2644/ python: http://secunia.com/product/4604/ As for scalability : http://www.onjava.com/pub/a/onjava/2003/10/15/php_ scalability.html http://www.oreillynet.com/pub/wlg/5155 there are numerous resources on the net on writing secure code for all programming languages, everything you mentioned in this entire "rant" is worthless and doesn't do anyone any good. Please go crawl back in your hole.

Read On!

http://www.onjava.com/pub/a/onjava/2003/10/15/php_ scalability.html

• http://www.onjava.com/pub/a/onjava/2004/08/04/mave ntips.html
• http://www.theserverside.com/articles/article.tss? l=MavenMagic

Basically Maven is an extra layer on top of Ant. Or another way of putting it is that Maven is way to program Ant in an XML based language called Jelly. Maven has the concept of repositories and versions, so that you can say that a particular jar file requires specific versions of other jar files in the repository. If you find yourself writing a lot of similar Ant code, Maven is definitely worth a look. It takes a little while to get into, but once you do it is fairly straight forward.

The key to this MQ project is getting the interoperability btn languages to actually work. I see no mention of Perl, for example. Or of any scripting language. Certainly if they wish to "walk the walk" as well as "talk the talk" there should be reference implementations for each *client* language they wish to integrate, ditto for the server-framework, although the latter would be a smaller pool.

If they can't do this, then the best thing is to stick to sockets for inter-language interoperability:-)

BTW, there are rumours of C++ interop with JMS - Code Mesh and MantaRay I suppose you could use jython for python so I suppose you could say that JMS is spreading outside the compound but I'm not convinced.

ALso, having it in the kernel is a Good Thing. Well, it is if you're windows - I think most windows system comes with a MQ, although I suspect that these are stripped-down versions of a more expensive "Enterprise System". If this system came with the kernel, then I'd've had one less thing to worry about :-)

There's no mention either of a proper Java implementation - including Message Driven Beans. This is the one part of JMS which is worth keeping, I think.

in short, good on the big picture but a lot of niggling worries. I shan't be attempting to use this system until rev 2.

Yes, the security model for .Net and Java are quite comparable.

O'Reilly On Java seems much more straightforward than the two links in the writeup, although I just googled "aspect oriented programming intro"...

• http://java.sun.com/j2ee/javaserverfaces/
• http://www.onjava.com/lpt/a/4042
• http://www.onjava.com/lpt/a/4130
• http://www.onjava.com/lpt/a/4747
• http://www.onjava.com/lpt/a/5066
• http://www.onjava.com/lpt/a/5067

• http://java.sun.com/j2ee/javaserverfaces/
• http://www.onjava.com/lpt/a/4042
• http://www.onjava.com/lpt/a/4130
• http://www.onjava.com/lpt/a/4747
• http://www.onjava.com/lpt/a/5066
• http://www.onjava.com/lpt/a/5067

• http://java.sun.com/j2ee/javaserverfaces/
• http://www.onjava.com/lpt/a/4042
• http://www.onjava.com/lpt/a/4130
• http://www.onjava.com/lpt/a/4747
• http://www.onjava.com/lpt/a/5066
• http://www.onjava.com/lpt/a/5067

• http://java.sun.com/j2ee/javaserverfaces/
• http://www.onjava.com/lpt/a/4042
• http://www.onjava.com/lpt/a/4130
• http://www.onjava.com/lpt/a/4747
• http://www.onjava.com/lpt/a/5066
• http://www.onjava.com/lpt/a/5067

• http://java.sun.com/j2ee/javaserverfaces/
• http://www.onjava.com/lpt/a/4042
• http://www.onjava.com/lpt/a/4130
• http://www.onjava.com/lpt/a/4747
• http://www.onjava.com/lpt/a/5066
• http://www.onjava.com/lpt/a/5067

First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ For a free introduction read: http://www.onjava.com/lpt/a/4744

My personal advice is a stack made of:

1. JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/
2. Spring for the business logic. http://www.springframework.org/
3. Hibernate for persistence. http://www.hibernate.org/

Don't forget to have fun.

DISCLAIMER: I develop heavily in both C# and Java, more C# than Java, about 80% C#, 20% Java, not by choice but based on client demands.

I don't think it's fair to compare Java 1.5 (released) vs. C# 2.0 (beta, who knows when it'll actually be released). That's like comparing Linux to Longhorn.

And re: IDEs, while programming so much in VS.NET, I missed all of the cool features of my IDEA IntelliJ Java IDE that I was excited to buy ReSharper, bringing some of IDEA's cool features to VS.NET.

One of the main things I like about .NET, though, is that the libraries seem to be more consistent, whereas the Java APIs have evloved and been added to by different developers using diffferent programming styles and approaches to patterns, each package seems to implement different programming styles and constructs, but you get used to it after a while. Plus, Java has so much deprecated code, they need to clean those out once and for all and clean up the APIs, see this for more details of what I'm talking about.

.NET supports delegates, which are effective "safe" function pointers. The .NET Framework libaries use these as the mechanism for event-driven programming models as opposed to Java which requires listeners interfaces. Although its debateable, I personally find this produces much more elegant code, although there are others who disagree with me - the point is, listener interfaces can be implemented in .NET too. In Java, you don't have a choice.

A form of Java delegates is possible.

In a simialr fashion, .Net is missing Dynamic Proxies, for which there is a similar .Net solution here.

No...your comparison is "apples to oranges" and has no basis. MS did not compare it properly. They used stored procedures, etc, where the J2EE was an exercise of keeping the business logic in the beans and not in the database. The java blueprints were never meant to be an exercise of performance over different design pattern examples. See the real low down on the MS Petstore implementation. Its just another example of the FUD that is sold by M$.

Here's an article from Jack Herrington on PHP's scalability

And here is an actual link to the article.

I think to settle this debate is a possible real-world example. Look at the story on the Jboss Nukes Project. It explains the CPU utilization and speed of the PHP version and how moving to a J2EE implementation decreased the wait times dramatically.

Its difficult to argue with facts.

I am starting on a new standalone server now doing something different, but I am going to stick with Java, and will be happy to see what 1.5 does for me.

But I have seen Java run slow before, and I will tell you this: in every instance it is due to someone writing some needlessly complicated J2EE application with layer upon bloaty layer of indirection. All the wishing in the world won't make one of those behemoths run fast, but it's not fair to blame Java. Maybe blame Sun for EJB's and their best practices, or blame BEA for selling such a pig.

Stuff I like in the Java world:

• sun's 1.4.2 on hyperthreaded xeons
• Jetty (fast!)
• Piccolo XML parser (fast!)
• Lea's concurrency library
• Grosso's expirable cache [click]
• hibernate
• JAM on Maven [click]
• eclipse

So it looks to me like Sun is trying to pull a Microsoft and hope people use the bundled product even if it's inferior. But like I said, Java developers already know where to get Eclipse.

...on OnJava - they're excerpts from the book.

These excerpts are pretty good - he talks thru some scoping issues that can be tricky. OuterClass.this.foo and all that sort of thing.

I want Java to succeed, but I don't think it will ever be simpler than Perl for web applications.

I will concede that in cases where your userbase is intelligent enough to actually know what CPU architecture they are running

Easy. Sniff the user agent and move the version matching the user's platform to the top.

it appears Java 2, Micro Edition does in fact meet those criteria

Thanks. I wonder if anybody has actually tried to make a GBA game in J2ME without an aJile coprocessor.

Pity is also my main source of income.

I guess you can't have everything.

The basic idea is to trust your peers,
rather than the centralized system now.

Of course that raises all kinds of questions;
still it's compelling to consider the approach.

The O'Reilly introduction is HERE

Cheers, Joel

You can get a very rough idea of the performance gain here (scroll down to "Trove Primitive Collections"). It's a significant difference.

Of course, for most apps that people are writing for Java (i.e. webapps for business), an optimization of this magnitude won't be noticable--all the time is spent in the DB or network. On the other hand, IIUC, MS intends to write large sections of Longhorn in C#.

One of the biggest changes seems to be support for the JSP 2.0 specification, which incorporates JSTL (Java Standard Template Library) version 1.1. For more info on what this means, read this article at OnJava.com. The Expression Language (EL in the article) adds a lot of nice features to help keep your JSPs clean without having to use struts.

I downloaded Tomcat 5 from an apache mirror, and I am impressed. It was a drop-in replacement for the Tomcat 4 that was included with OSX Panther 10.3.x.

There was a classic response to Dijkstra's GOTO article. It proposes the COME FROM statement, which has lately been reinvented in aspect-oriented programming as the pointcut.

http://www.fortranlib.com/gotoless.htm

apparently, the folks at JBOSS do think php scales as well as java. of course they have a product to push, but they did use php and found it wouldn't hold up.