Slashdot Mirror
Java2 SDK v. 1.4 Released
pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.
SDK 1.3.1 stability was terrible on Redhat 7.1 and 7.2 Hopefully 1.4 will be much better. Otherwise I will have to continue using IBM's 1.3.0 SDK.
I've been working on a server that takes a lot of connections in Java, and you can finally do it with the support of "select" in Java 1.4. But no support for SSL. I undertand why it happens, but this "we'll get around to doing the security later" is why we don't have a lot of security.
Java will always present a dilemma. With the push for portability, you often have to wait for the platform itself to support things like this (select) or kludge it in very non portable ways. But that portability leaves the system behind which hurts it in competition with other systems more tolerant of innovation and the fracturing it brings.
A good philosophy would be to rule that every time a system library or feature needs to do something that an ordinary user can't do, they don't just build it in, they make a way that an ordinary user could write it. That paves the way for more innovation.
Has it been over a year since you last donated to the Electronic Frontier Foundation
I hope that Swing is faster now under linux. I played with netbeans and jedit and although there are really good they are not very fast on linux. on a slower windows PC jedit stated much faster than on my linux box.
a few days ago I played a little with Ruby (the coolest language available IMHO) and Gtk+. although the bindings are not yet finished they work very well under Linux and this is much faster than Java/Swing.
Maybe Ruby is the future. At least I hope so. If Ruby gets more stable modules Ruby can be the Number One OOP language. It is cleaner than Perl or Java, the Programms are shorter, the Language is more intuitive and.... and.... and. This is only my humble opinion. See for yourself if you like ruby. check out http://www.ruby-lang.org
talk about a joke getting old!!
In Soviet Russia you dant have to put up with these crappy jokes
A summary of all the new features is available here:e s.html
http://java.sun.com/j2se/1.4/docs/relnotes/featur
Articles about the news APIs and how to use them available here:
http://java.sun.com/j2se/1.4/articles.html
Being bitter is drinking poison and hoping someone else will die
This makes me so happy. Coming from C++, I really really missed assertions. They give me much more confidence in my code. Some people seem to have trouble using them, but after a while they can become second nature. In fact, one can come to rely very heavily on them.
Well that kind of gives an answer to every javahead that says "Why bother with Mono, when you have J2EE? What a waste of time."
Mono is at least opensource... can you say the same for J2EE? Will you ever be able to say the same?
And still no generic data structures (a.k.a. templates in the C++ world)... all those explicit downcasts from Object hurt and need to be optimized away by the JIT...
-Hein
The 4 GB address space limit has become a severe limit on Java bloat. It's good to see that Sun finally addresses this problem.
I have a dual boot machine at home, one partition Windows 98, the other Slackware 8.0. Today I downloaded and installed the new Java SDK 1.4.0-rc on both systems. And while I think that some iscolated windows difficulties causes my oppinion to be rather biased, I found the install much easier going on Linux.
However I will note that, while the Java Web Start was installed on Windows, I didn't find any version of it for linux. And the downside to the Web Start I found is that it constantly wanted to download and install a new version of Java Runtime Environment 1.3.x everytime I lauched an application. And then after the download, and installed, I'm prompted to reboot the computer. After rebooting and trying to launch again, it again starts to download JRE 1.3.x and through the whole cycle all over again.
As well, with my windows install I found I was constantly having difficulties getting it to use the default classpath (ie, no environment variable set for CLASSPATH). I ended up having to resort to specifying the classpath at the command line. And no matter how much I tried, I could no manage to get Swing to work properly.
However on the other hand, the Linux install was rather straight forward, with a few simple steps: Change download to executable; Run it; move the extracted directory to a shared path (as su); add the java/bin directory to the search path; and finally add the java/man directory to the search paths for man.
The windows installer was straight forward, though the above problems still hampered me.
-- Never monkey with another Monkey's monkey
Hmm, if SDK v1.2 became "Java2", shouldn't v1.4 be called "Java4"? Oh I see, "Java2" was a "marketing trick" used in the tough year 1997 and the name has stuck.
Perhaps,but remember that the change from 1.1 to 1.2 contained some major rehaul of APIs.
In this 1.4 release Sun kept a carefully budgeted set of new features and emphasized quality and performance, like they said they would. You can expect more changes in 1.5 (codename Tiger) which is planned to come some time around the middle of 2003. If that will be Java3, who knows, they have just started working on it.
Being bitter is drinking poison and hoping someone else will die
Autopr0n.com actualy runs using the first beta of JDK1.4. I needed the new ImageIO libraries for the, um, 'site previewer :P' (and the regexs made some of the parsing I'm doing a lot easier :). I tried 1.4b3 but it was far more unstable, and my regexs broke.
:P
Definetly cool that the stable version is out, I'll have to upgrade at some point, when I have time.
Hopefully they'll implement this at Topcoder.com too, so I don't have to keep using the old docs in the compos
autopr0n is like, down and stuff.
Jesus, Sun's PR corps must have flipped their collective shit when they read Karen Tegan's remark. While in general I find that kind of bluntness refreshing, a director of Platform Compatibility spouting off and essentially saying, "Well, that sucks for you, but we make money off of compatibility testing. We give everything else away for free, so cut us a break." is really a testament to the Sun Micro (brutally) plain-talking attitude.
.NET takes off, they will loosen up to benefit from a little more old-fashioned agrarian innovation and buzz.
Deeper, though, I think, is the need to rein in Java a bit....It has achieved ubiquitousness, and I think Sun knows it. Watch. If
I guess it would be nice to have SSL built into java, but you could write it yourself, it's not like it's a fundementl language flaw. The specs are out there, and the java Crypto API would probably help you out quite a bit.
autopr0n is like, down and stuff.
see subject
autopr0n is like, down and stuff.
Throw the classpath in your AUTOEXEC.BAT file on the C: drive on your win98 machine. Should work.
autopr0n is like, down and stuff.
OK.. I am a Java fan... (recently this has been changing though.)
.Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.
:)
I have mixed feelings with JDK 1.4.
The JPDA (debugging) support in 1.4 is vastly improved. You can now redefine classes in a running virtual machine. This is really cool and I have written an Ant 'Redefine task to take advantage of this.
The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.
There is also some controversy.
The JSPA agreement that one has to sign to participate in the JCP is WAY too restrictive for Open Source developers. The Apache Software Foundation has a good document where they drawn the line in the sand on their participation.
The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.
The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.
As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.
They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.
As far as C# vs
Also.. check out my Reptile project. It is Java based, only requires JDK 1.2 and incorporates some really cool Java/XML stuff.
Are there some good articles out there (besides the sun ones) on how to use the new features?
thx
matt
Are there any _good_ java VMs and class libraries? Kaffe looked decent, but appears to be a little "stale" wrt the current state of the art. Are there any projects working to address this?
I just took a look at the three patents Kodak is suing Sun over, and, huh?
Sure looks like Kodak claims it invented OLE.
Which, hey, they may have, and Microsoft either licensed or stole it.
What's the real story?
--Blair
No, it's the real release. It doesn't say Release Candidate anymore. It has been RC for a while but now it's for real. I call this news.
It's its. They're their, there. You're your. Who's whose? A looser loser, though those two too threw through the trough.
This is in regard to the kodak suit.
What I find especially bothersome is the the fact that Koday (supposedly) had these patents. They did nothing with them. Sun produced a product, hyped it, sold it, improved it and put in millions of dollars and man hours into it.
Kodak then comes in and demands money after the fact when they made no attempt to actually do anything.
I think that's crazy. Why punish the people who got off their asses and did something especially if the punisher was too lazy or stupid to actually make use of their idea.
This isn't just about sun and kodak either. Who was suing palm recently? Same thing.
Sit on your ass doing nothing, wait for somebody else to do all the work. Then sue them and retire in the bahamas. It's the american way I guess. Sure beats working.
War is necrophilia.
If I had mod points, I would give them all to you.
Yes java is the most overrated language next to esperanto only.
no sig error.
Due to import control restrictions, the JCE jurisdiction policy files shipped with the Java 2 SDK, v 1.4 allow "strong" but limited cryptography to be used. An "unlimited" version of these files indicating no restrictions on cryptographic strengths is available.
The JSSE implementation provided in this release includes strong cipher suites. However, due to U.S. export control restrictions, this release does not allow alternate "pluggable" SSL/TLS implementations to be used
What seems even stranger now is that you cannot used "pluggable" implementations (in JSSE). Maybe the "nasty" europeans/asians/africans/martians would provide some unlimited strong cryptography pluggin otherwise???
The platform is not the language.
Java is good partly because of its pragmatic syntax (C++ish with some sugar added, some sugar taken away), but mostly it's good because of its excellent class library.
Though I haven't written anything serious for a year or so due to a job switch, I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.
Cheers,
Ian
The article says nothing about the nature of
the supposedly infringed patents. Here's their
titles:
US05206951
Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types
US05421012
Multitasking computer system for integrating the operation of different application programs which manipulate data objects of different types
US05226161
Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types
???
"facade of neutrality"?
:)
:)
Do you even read Slashdot?
I don't think anyone claims this is an unbiased news site. It's a message board for Linux geeks. Love it or leave it. Or present your own viewpoint.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
My favorite thing about using 1.4 is code like this:
public void methodA throws MyException {
try { Driver d = Class.forName(driverClass).newInstance(); }
catch (Exception ex) { throw new RuntimeException("problem loading driver"); }
}
can now be this:
public void methodA throws MyException {
try { Driver d = Class.forName(driverClass).newInstance(); }
catch (Exception ex) { throw new RuntimeException("problem loading driver", ex); }
}
Notice the RuntimeException constructor now has the original exception passed to it. It can be retreived higher up the stack, and I believe is printed during a ex.printStackTrace(...). It lets you pass the root cause exception up the stack trace, while preserving the entire state, without having to declare it everywhere.
But I can't forsee Ruby supplanting Java for large projects. The typing is too dynamic, and this ends up being a big headache and source of problems in larger code bases. More concertely, the lack of compile-time type checking makes it hard for Ruby to scale to big projects. You don't find out until runtime if something is type correct, and even then maybe not until some rare execution sequence occurs. Or, worse, it might be type correct in the Ruby sense (i.e., an object can receive a certain message), but not be at all type correct from the programmer's point of view, which might manifest itself in difficult-to-find bugs.
This is a problem with dynamic casting in Java/C++, too, but in those languages the dynamic type checking is the exception rather than the rule (this will get a lot better when Java introduces parametric types in 1.5). More fundamentally, though, at least those languages offer compile-time type checking support, whereas Ruby does not and cannot (since code can be dynamically injected into objects).
5. Notice of Automatic Software Updates from Sun. You acknowledge that the Software may automatically download, install, and execute applets, applications, software extensions, and updated versions of the Software from Sun ("Software Updates"), which may require you to accept updated terms and conditions for installation. If additional terms and conditions are not presented on installation, the Software Updates will be considered part of the Software and subject to the terms and conditions of the Agreement.
6. Notice of Automatic Downloads. You acknowledge that, by your use of the Software and/or by requesting services that require use of the Software, the Software may automatically download, install, and execute software applications from sources other than Sun ("Other Software"). Sun makes no representations of a relationship of any kind to licensors of Other Software. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE OTHER SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Antti S. Brax - Old school - http://www.iki.fi/asb/
What's wrong with the Sun articles? Sun has always done an exceptional job documenting and writing tutorials for the Java API(s) and language. I credit Sun with starting the whole trend of supplying high quality, public documentation with languages and APIs.
Kodak baught a company that was doing stuff with it, or trying to. Now their suing because they wan't more money.
autopr0n is like, down and stuff.
Swing should be much faster under X anyhow, they have totally re-written that sub system.
I thought http://www.jboss.org/ and http://www.exolab.org/ were getting pretty close to open souece J2EE?
(BTW yes j2se 1.4 does mean scrolling in Netbeans without any plugins).
Swing is much faster on linux, and it is about
8-10 times faster on a remote X session.
Why is this not under the developers section?
I have read the articles. There have also been a lot of these articles when jsdk 1.3 came out and Swing was not much faster. Swing is a cool idea. If it could match the performance of VB on windows or Qt in Linux there would be much more cross platform apps and this would also help linux onto the desktop.
Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications. The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia was demoed as part of the keynote with everyone watching and they were all impressed. Months later I was informed by the "head Java dude" at Apple on his Australian tour that WorldBook is completely written in Java - but noone knew.
Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java. It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code). Sure there are some things that Java can't do that you need native code modules to handle but that facility is available.
The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations.
Java's not perfect, but I seriously don't think that it's Java that corrupts young programmers. You can write good code in almost any language - I see an awful lot of really bad Java code written by C programmers but I'm not about to claim that C is corrupting old programmers.
I prefer using a more sophisticated error handling object which uses exceptions (I'm talking C++, here) to trap and bubble up errors. This way you can decide what to do about a particular condition based on how severe it is and what avenues for error/status reporting you have access to.
You also don't neccesarily lose important data on an error just because a customer is reporting it (you can log something that you don't want the user to see).
Remember that the closer your debug binary is to your release binary, the more valuable your runtime experience with your debug version is when testing your release version.
Why is Grand Theft Auto a much more serious crime than Reckless Driving?
The article says Wang Labs.
Why is Grand Theft Auto a much more serious crime than Reckless Driving?
It's a shame that Kodak/Wise never enforced the patents to stop MS from developing OLE. That would've saved many people's sanity.
This sig made only from recycled ASCII
This means that they are claiming that if you agree to this licence, you are also agreeing to the licence of any application which installs itself (and you have agreed to let it install itself).
I'm sure that that is not legal, and could invalidate the whole agreement. On the other hand, I don't see how a licence agreement that you haven't signed is worth the pixels its printed on.
To say that Sun's online license agreements are binding would be to say that you are not allowed to click on a button with two words on it which is displayed on the web without agreeing to this contract.
As someone pointed out in response to another article, not agreeing to the licence agreement preserves your right to click on the "I Agree" button without agreeing to the licence agreement. It is in the agreement that it says that you agree that clicking the button means that you agree.
Is that convoluted enough?
Why is Grand Theft Auto a much more serious crime than Reckless Driving?
Oh yes, and I nearly forgot a trivial-but-annoying one:
perl -e 'fork||print for split//,"hahahaha"'
The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia was demoed as part of the keynote with everyone watching and they were all impressed.
When have mac users not been impressed at MacWorld? BBSpot has a great parody story Apple Faithful Ready "Ooohs", "Aaahs" for Jobs Keynote. I'm not trying to criticize Mac users here at all, I'm just saying that impressing people at MacWorld doesn't prove much at all.
I've never used assertions, but they seem a great complement to unit testing. Unit testing allows you to write code to test your functions and easily see if something breaks, the major problem is that they lack an easy way to look inside objects to keep an eye on internal consistency. Assertions can be great to catch those silly little boundary mistakes.
A good unit testing framework for Java is JUnit, they are available for other languages as well.
BTW, you can create your own assertions with Log4J, so even JDK 1.1/1.2/1.3 users can use them:
if(logger.isDebugEnabled())
if (bla>10)
logger.warn("bla>10, bla=" + bla);
This uses almost no CPU-time if debugging is disabled. Log4J is a very good logging package, it surely beats System.out.println, check it out!
The Drowned and the Saved - Primo Levi
I'm so sick of reading this anti-Java crap by people who either (a) haven't used java or (b) have only written small projects in C/C++. I just can't believe the assertions being made by some people.
... almost zero.
Specifically for this posting, I can't comment on the Unicode stuff, but:
* Wrappers work OK. They allow good performance for the primatives without the many problems void* can cause. The wrappers are hardly difficult to use and in fact they're used pretty infrequently.
* Variable arguments to functions: Java is not C. Get over it. Not every feature of C is worth cluttering up the language for. The number of times I've needed varargs in my life is
* You can't create a list anonymously: What about average(new int[] { x, y, z }) ?
* The syntax is intentionally inflexible: Sun added assert even though many people didn't like it. Here's an assert class:
public Class Assert {
public static void assert(boolean assertion) {
if (!assertion)
throw new RuntimeException("blah");
}
}
You can put Assert.assert(boolean) anywhere and it will throw a runtime exception on failure.
This stuff is not rocket science, but hardly anyone posting to these threads seems to have a clue about Java. Java has it's flaws but IMO they are far less serious than C or C++ for writing large applications.
... why most geeks are against software patents.
sigh....
IANAL but write like a drunk one.
Go and look at WorldBook on OS X and you will also be impressed. More importantly though, noone realised it was a Java application. It looked and acted just like a C/C++ application.
Remember, this is Sun the people who released Solaris 2.0 which:
- was the first version of Solaris
- declared itself to be SunOS 5.0
- was an implementation of System V Release 4.0
Obviously being able to count is not a prerequisite for getting a job in Sun's marketing department.
Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java
I find the example set by WorldBook 2002/MacOSX to be a stunning demonstration of Java's potential if Sun would just wake up and smell the coffee (pun intended).
I like Java a lot - both as a language, and as a bytecode platform. I use it daily at work, and at home for my own projects (after many years of flipping between C, C++, and a dozen other niche languages)
My only major bugbear with the JDK is not with Java itself, but with Swing: It's godawful slow (The Hello world app should not take 30 seconds to display on a P400), it's API is occasionally appalling (JTree anyone?), and it has a habit of being occasionally buggy.
Above all, it reinvents the wheel with widgets. The Look and Feel implementation very occasionally looks and feels like a platform native application (Win2k LnF anyone?). However, it usually looks and feels like someone has tried to reimplement a system native toolkit using only a blunt light blue crayon.
For many a year I have whined to all that would listen "Why the *@*)(!&*@ doesn't the Java widgeting toolkit defer to system native widgets for window display? Surely this would look better and run faster than pixel blitting a widget look-a-like!"
MacOSX provides just such an API. Although Objective-C is the `preferred' language of Cocoa, there are Java bindings. Note - this API is NOT Swing - it is a MacOSX extension API. Consequently, a MacOSX application built in Java should be almost indistinguishable from a native compiled app in terms of look and feel. And according to your comments, performance is also indistinguishable.
I have played with Java bindings for Gnome; they provide blindingly fast gui performance, using the same java runtime as is used by Swing. However, there are several java binding projects for Gnome (all partially complete), and none of them really address the general problem of widgeting across platforms.
I have also played with Eclipse, the IBM Java . Their widget toolkit is cross platform in API but system native in widget; however, I have found the performance of the Eclipse widget set to be almost as bad as Swing. However, it is beta code - we may have to wait and see if anything improves with age.
Java/Gnome demonstrates that it can be done under X. Eclipse demonstrates that it can be done cross platform. MacOSX demonstrates that it can be done well enough as to be indistinguishable from system native widgets.
So can anyone tell me: WHY hasn't it been done? (And don't say its because they don't want to break backward compatibility - Look at 1.4's NIO framework and VolatileImage).
Russ Magee %-)
... and never, ever play leapfrog with a unicorn.
My favourite new feature is that lightweight components can now be run in headless mode - see
C ha nges.html#headless
http://java.sun.com/j2se/1.4/docs/guide/awt/AWT
You have to set a property to true:
-Djava.awt.headless=true
as a switch when running the VM for example. Then you can generate server-side graphics on Unix without having to run XVfb. This has been an annoyance for some time, as you had to have different deployment rules depending on your target OS, as NT always has a graphical environment taking up resources whether you want it or not, so it wasn't an issue there.
The upshot is that you can now use java.awt.Image.BufferedImage as an image source in servlets that generate dynamic images, instead of java.awt.Frame, which always seemed wrong. It uses less resources too, as it doesn't have to do a context-switch to your X server to create images!
Hey, there are lots of great new features in this new release, but that is the first one that made life easier for me.
Yes and no. The Cocoa APIs are an extension that is not cross-platform, however if you use the Swing libraries on OS X, by default they use native widgets. So you can write a 100% pure Java application that uses native widgets on OS X. I would expect that this kind of thing will flow back into Sun's JVM around 1.5 or so.
That's worrying. Mainsoft's only product is MainWin, a library for emulating Windows API on Unix (similar to the library version of Wine).
Why is Java rely on emulated Windows code?
You can use templates to make C++ put on a pink tutu and dance a little dance for you. Alexandrescu uses them, for instance, to make C++ forcibly multiply inherit a chain of classes into a single child class. He also has a single inheritance template setup and a lot of other sick and twisted stuff that every C++ programmer should at least know about.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Yes and no. The Cocoa APIs are an extension that is not cross-platform, however if you use the Swing libraries on OS X, by default they use native widgets.
Ok - this was not my understanding. I thought the OS X Swing libraries were an Aqua-esque LnF, but not Aqua widgets themselves. However, I'm not a Mac junkie, so I don't speak from experience on this point. If they are native widgets, it certainly bodes well IMHO.
I would expect that this kind of thing will flow back into Sun's JVM around 1.5 or so.
I certainly hope so...
Russ Magee %-)
... and never, ever play leapfrog with a unicorn.
It shouldn't be any harder. You don't need an IDE to write in the Java language for the J2SE platform, but Sun still provides a free(beer) IDE that includes a form designer. Likewise, you don't need an IDE to write in the C# language for the .NET platform, but M$ still provides an expensive IDE that includes a form designer. Besides, the languages are so similar that it may even be possible to take simple business logic (not I/O) written in one language and simply recompile it in the other language.
Will I retire or break 10K?
I use Java at work and I had to beat 5 fucking team leads with a crow-bar to convince them to move to Java 1.2. Now they all run the other way when they see me coming -- it's a lot harder to get near them with a crow-bar. By the time my company gets done with its final focus meeting to decide that moving to 1.4's a good idea, Sun will be releasing Java 2.4 (With telepathic user interface code.) If I get all used to how great Java 1.4 is, work will suck more, and it already sucks so much that light can't escape.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
OK -- do you have a link? Sun's page still says Release Candidate, if you go to the download page it still has 'rc' in the filename. So, to me, it still looks like a Release Candidate, not the final release.
What am I missing?
Moo!
I beg your pardon? Does someone hold the patent to "computer system that uses objects" too?
The title of a patent has no legal force. You must read the claims to understand the patent.
Will I retire or break 10K?
Java *can* be made to run as fast as C/C++ apps but it's rare and only for certain applications of Java. Different compiling and runtime techniques technique such as JIT compiling and using HotSpot can get "primitive functions" - those on arrays of int, floats, etcetera to near comparable C/C++ code. However, the Java built-in libraries have enough built-in bloat to make further promises of speed indistinguishability just plain misleading ("it works fine, just avoid this list of 50 poorly implemented classes"). No, Java the language isn't slow, but Java the set of Sun library implementations has many, many deficiencies.
Also, I wasn't saying that all of Java is one big bug but you can't argue that there are a tremendous amount of bugs in Java's standard APIs. Things like horizontal scrolling not working for JTables. I mean c'mon, really - that's just a standard bounds checking and listener notification algorithm and the bug has been around since 1998. I know JTree has major problems (e.g., node rendering of icons works differently for nodes being edited than those not) and the DefaultTreeNodes in the Java API are overwritten to no end other than inefficiency. Drag and drop doesn't work with multiple items, thus almost no one ever uses DnD in the apps I work on - hell, even I don't because at least I can rely on copy and paste. Well, within the same application, actually, outside of the same VM trouble starts.
It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code).
Well yes, it runs, but it is far from guaranteed that it runs _well_. I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof. [The reason I made a custom class for this was because JTextArea and JEditPane were horrendous due to my need for special formatting - I have literally 50 times better performance now than with JEditPane and about 10 times better performance than with JTextArea on my wintel machine.] I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms. Of course, my machine is 3 years old - so is Java 1.2 SE but as I was saying, Sun relies on hardware to catch up. I'm sure it would run fine on a 1 GHz dual processor G4. [Actually I think graphics cards have a large part in Java's performance.]
they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java
Believe me, when something crashes that means to me that it wasn't written in Java. I have never dealt with another language so stable. Even when internal exceptions are thrown I've seen apps soldier on through their own bad states and actually still work, though they do of course become flaky. LnF hasn't really been much of an issue either - Windows and Linux have always looked like crap (haven't tried XP yet) so I've never expected Java apps on either of them to look good and really wouldn't care if widgets on them weren't completely "native-looking". On Mac, it looks sweet except for text rendering. It really is the performance problems and the bugs in Sun's libraries that are the worst thing about Java. The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it or else I have to either write my own version of that widget or steal their source, fix it, recompile it and then only be able to use it internal to the company." It's not a great working method - if they allowed for people to make fixes to Sun code instead of all of us having to either live with the bugs or rewrite entirely new classes, Java would have a much better set of library implementations. Instead people like me have to decide whether we can spare the time to write whole new versions of objects with the same functionality but, well, functional, or tell our boss and have our PR tell our customers "Yes, we know that doesn't work right. It's a problem with Java and there's nothing we can do to fix it." Believe me, as a professional programmer I can tell you that happens over and over again and it is a situation that benefits no one (well, except if you have direct competition that isn't reliant on sun's java libraries, then they benefit).
The New I/O utility looks interesting -- possibly powerful enough to overcome the problem preventing me from using Java right now: 16-bit characters.
Yes, 16-bit characters are nice for internationalization, but if I'm trying to slurp up 600 MB of data, it really hurts to have to store the text portions using two bytes per character. I know it's not politically correct, but perhaps a choice of char sizes would have been nice? (I'm a Java newbie, though -- there's probably an esoteric way around it.)
1.3 completely broke Java on Cyrix. Once you installed 1.3 you were SOL - every time a VM started, you'd get an illegal instruction error. Sun used an optional P6 instruction that Cyrix chose not to implement to keep power consumption down. Instead of checking CPUID to see if the instruction was available, they just checked the processor familly and assumed that the instructioon was there. Intel's docs clearly state that the instruction is completely optional and that apps should check a flag returned from CPUID before using it.
Sun has known about this for over a year now, but they refused to fix it. Hopefully 1.4 will actually run on by Cyrix box now.
t'nera semordnilap
A wild guess here, but maybe [this article is not in the Developers section] because it is under the Java section?
No, it's under the Java topic, and topics != sections. I would send further discussion (this is already off-topic) to Meta Slashdot Discussion, but according to the hidden sid index, it no longer exists.
Will I retire or break 10K?
Ok, so 1.4 may be faster. 1.4 may be more stable on Linux. 1.4 may be more robust. But, they still didn't fix the thing that annoys me the most about Java. Why is it so freaking complicated to do a simple read from the keyboard???
Okay, I expected someone would mod parent post down and went to download and install the **1.4.0 final release**...
Of course, no problem with the install and I made sure I didn't get the Release Candidate.
Now what? Insightful mod and AC ranting?? Maybe you guys should hit the refresh button harder!
I would again have to contest this. WorldBook makes very heavy use of graphics (as does the stuff I work on) and it still managed to perform well and didn't seem to have any problems with bugs. There are bugs in almost every library and I have not found there to be any more in the Java APIs despite constantly working with the latest betas and early access releases.
I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof.
I would be very suspicious that when you wrote your custom class you optimised it based on your knowledge of Windows and not of Mac OS - the two graphics subsystems work very differently so your optimised code is likely to have actually been the worst possible code for OS X. If you want to benefit from Java's cross-platform abilities you actually have to use them. The API is the key to getting cross-platform compatibility because it is reviewed and optimised for each OS it is ported to. Your code doesn't have a hope of knowing as much about the system or being better optimised. I spend all day running the exact same Java application on Mac and Windows (95 and XP) and it runs the same on both at about the same speed because I take advantage of the APIs.
I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms.
JBuilder is not heavily tweaked for OS X, it's just well written Java code. Poke around JBuilder's files and you'll find it doesn't do much more than a simple 'java -classpath blah com.borland.JBuilder' For the record I find Java runs perfectly fine on everything from a P100 right up to the 1.2Ghz Athlon and from a Rev B iMac (300Mhz) up to the 400Mhz G4 laptop I currently use. Perfectly fine in this case means comparable to programs written in C. Yes there's a longer launch time in most cases (again, OS X makes huge inroads into this and 1.5 will likely adopt this technology to reduce loading times and memory requirements significantly).
On Mac, it looks sweet except for text rendering.
I don't know about you, but I quite like the smooth, easy to read look that Java's text gets on OS X with it's antialiasing.
The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it
I really haven't seen that many bugs in the Java APIs that you would consider it worse than other libraries. If you are consistently having trouble with JTree then it may be worth extending the class to fix the bugs where possible (and you'd be amazed at how much you can achieve this way) or develop your own solution (as a last resort). Consider that with C/C++ you don't get *any* graphical abilities for free (all provided by 3rd party libraries which are completely platform specific etc, etc), you really aren't that badly done by if you have to implement a couple of custom widgets in Java.
When it comes down to it, the solution is to write good code. I can be pretty certain (but not 100% sure obviously) that you are not writing good *Java* code because you are so anti Java. You simply have not accepted the languages strong and weak points and so can't take advantage of the strengths. You also seem to come from a background in another language (C/C++ would be likely) and you don't seem to be willing to adapt to the "Java way" because you are hooked on the "C/C++ way" (or whatever previous language you prefer).
I apologise for any offence in the above statements, I can see from your posts that you are neither stupid nor irrational and in fact are quite intelligent with a fairly open mind. However, changing programming languages is really difficult particularly when they seem as similar as Java and C++. You have to realise that Java is only asthetically similar to C++ but is in fact based on a very different grounding principle. C++ looks for speed and efficiency at the cost of safety (buffer overflow anyone?) and platform independance, whereas Java focuses on safety and cross-platform consistency at the expense of speed (yes there is a speed penalty to be taken but in most cases it is an acceptable trade off and great gains are being made). Further to this, C++ is a procedural language which has had object oriented "stuff" added on top whereas Java was designed from the start to be object oriented (with some procedural elements).
Basically, there is nothing stopping you from developing your own API for Java but I'm pretty certain that you can't do a better job than Sun has - if it was so easy and/or the Java API is so bad, why hasn't anyone created an alternative?
Someone further down said:
>An enum is just a primative aliased by a name.
Yes, they are, so I can write the C code
enum color={red,green,blue};
switch (color) red:--; green:--; blue:--;
(my sntax may be wrong, but you get the idea)
as Java:
static final RED=1, GREEN=2, BLUE=3;
switch (color) RED:--; GREEN:--; BLUE:--;
(don't remember if you can have mutiple vars inited in the decl, but you get the idea)
But what if I have two enums "ranges" with some of the same names? Like:
enum PersonType={Client, Customer, Vendor, Supplier};
enum ComputerType={Client, Server, Desktop};
if I defined all the enum lables as finals in Java, and then used them in switch statements/assigns on variables, I don't get the type-checking I do in C. So in C:
enum PersonType aPerson = Desktop;
would be flagged as an error, but in Java the equivalent
int PersonType = DESKTOP;
would be perfectly fine as far as the compiler is concerned.
This could be a problem..
The link is java.sun.com as far as I'm concerned. As of right about now (14 Feb, a sunny Swedish afternoon) I don't see any Release Candidate and/or 'rc' in the filename (well, the Sparc version has...).
What you're missing is probably clearing of cache and throat.
It's its. They're their, there. You're your. Who's whose? A looser loser, though those two too threw through the trough.
This is a very common problem that people run across using the Web Start. The reason is that if you are using a JVM that is a pre-release or has a '-' in the version name, webstart will assume it's a beta and will attempt to download a 'release' version. Here's what you do to trick it:
Hopefully that should cover it.
I tried jDiskReport, and it was really sweet!
-Chris
Hi, I forgot to mention, but when you change the version value from 1.4.0-rc to 1.4.0 you MUST hit enter in the edit field and not just OK or else it won't take the change.
-Chris
Yeah, that must be the reason they
I am sure there are other examples, too.
Are you absolutely sure you have checked out the 1.4 release at all?
...finally works with the old banking applet I'm forced to use. Cheers!
My class and I was at Sun Microsystems in Ireland in 2001. They talked a lot about how good Java was. But when I asked one of the top people this simple question "Why isn't staroffice programmed in Java?", they said "We don't know, actually".
I know why. It's because Java just can't compete with faster languages when it comes to larger programs that require real window handlement. (personal opinion ofcourse).
Now on to the "so-called" platform independability. I personally have been asked several times to convert java programs so they can be run on UNIX platforms (like HP-UX) because they just didnt perform well on those platforms. Instead we chose TCL or similar. Which seem to do the job.
Best luck to Java in the future. Hope you programmers can fix these "small" problems :-).
These people have looked deep within my soul and assigned me a number based on the order in which I joined.
Uh, the following code:
// process next command
DataInputStream din = new DataInputStream(System.in);
while (curLine = DataInputStream.readLine())
{
}
Will read lines of characters from the keyboard. This is difficult?
-Chris
The story should have read "no LICENSED open source J2EE implementations". There are OS J2EE app servers (JBoss), and in fact they are quite good... the problem (as stated in the article) is that it's hella expensive to get the official seal of J2EE. That doesn't mean it doesn't work!
.NET is better, you have to ask how good an open .NET server you're going to be able to build without ASP.NET or Windows Forms. Neither of those are part of the current ECMA submissions, though as stated in the .NET article yesterday they are expected to be submitted at some point...
.NET (at least under windows). It will be interesting to see if .NET app development is nearly as annoying as MFC was (I doubt it will be).
Now if you think
At the moment J2EE has gone through a lot of refinement, and I think makes a pretty good platform for server side development. I think desktop code is still up for grabs by either Jvaa or
"There is more worth loving than we have strength to love." - Brian Jay Stanley
...what MS employees who get paid to make fake posts on Linux geek discussion groups as anonymous cowards try to erect to cover their tracks.
Eternal vigilance only works if you look in every direction.
Anyone who knows java realises that there is not a speed problem in general. What has given Java a bad name in the past is the poor AWT / Swing libraries.
What would make a *big* difference on the desktop would be if people used a nicer native widget implementation similar like SWT provided by OTI in the eclipse project (www.eclipse.org)
This would make java desktop application responsive and give them a professional look & feel and most users wouldn't realise they were written in Java. In fact I couldn't believe Eclipse was written in java when I whizzed through those pull-down menus and I write Java code 9-5.
I run the latest version of Eclipse and it's GUI is as fast as any native application under windows.
I guess it would be difficult for Sun to admit that they have messed up the GUI implementation twice.
Matt.
Others have corrected some other points pretty well, but I thought I'd throw in two other points I didn't see well covered:
1) Warnings/errors. After many years of real world programming, I'm going to say right now that that is an error. If you find a variable that is not initialized, it is going to be a bug - even if not now, nine times out of ten it will be at some point in the future.
I personally am happy to have that not compile instead of relying on someone else to run lint (or the equivilent) frequently over the code... things like this are one of the reasons Java programmers don't need to run Lint style checks much. The langauge and general programming conventions help elimiate "dumb as a hammer" errors that we ALL make from time to time.
2) Java has some nice internationalization support if you really care to do it correctly for all cases - you can use a BreakIterator to properly navigate through a string for any language.
Java has always had (I think) well thought out tradeoffs between performance and ease of programming that led to things like this, but generally always supported some way to do things "more correctly" if you really needed to - wrapper objects are an example of this is so is String not handling characters wandering past 16 bits in size. You have the primitive type wrappers if you need them (as you noted), and also the heavy-duty internationalized support classes like BreakIterator and Collator.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I understand that sometime in the not too distant future, a MinGW distribution for Windows will be available.
I use Java for most of my development using IBM's (sometimes Sun's) JDKs, but I hope in the future to use the GNU tool chain for many projects.
-Mark
I enjoy developing with Java, but for the last year or two I have increasing felt that the time is appropriate to freeze the platform except for bug fixes.
A similar situation existed a few decades ago in the Lisp world: there were many great dialects of Lisp and a large committee effort stirred everything together as ANSI Common LISP. Is Common LISP perfect? Of course not, but it is a very stable platform supported by both free Open SOurce implementations and several very good commercial products.
I would like to see Sun slow down the marketing-driven new releases.
I think that the Java community would now be best served by a stable frozen platform.
Anyway, just my opinion :-)
-Mark
While this may be a useful addition to the language, I am somewhat pissed off about the way the keyword was introduced. Despite the temporary "strategy" offered by Sun in the latest JDK to avoid problems with legacy source code containing "assert" as an identifier, a LOT of code will need to be rewritten. For example, Java implementations of rules engines and expert systems commonly use "assert" as a method name (the function of this method in rules systems is similar to the function of the keyword). This should have been a reserved keyword from version 1.0 and up!!! Supposedly, assertions were part of the original spec, ao I am puzzled why they weren't more careful (I mean, GOTO is a reserved keyword, so WTF?). Sun has done a good job of managing the Java specification, but this was definitely a fsck-up!
Dude, read up. There is an excellent discussion of the reasoning behind their design decisions. They give a very good justification for adding a keyword; in fact, it's one of the FAQ questions:
Unlike a lot of other languages (C++ and C# spring to mind), the Java designers have been very tight about letting multitudes of constructs into the language. Java's minimality and internal consistency is one of the reasons it's been so successful, and its designers know this. They are very intelligent people who are making decisions very carefully -- and they're not going to add something to the language unless they have a very good reason.
In this case, they have a very good reason.
Java chars are 4 bytes long, just like java integers. Maybe you're thinking of shorts?
Because Java contains a lot of special-casing for String objects (such as overloading '+' and forcing a toString() method in every class), and because String is final, you can't write your own class BetterString which fixes this unicode problem and still works like a String.
Ever heard of security? Stability? Do you know what immutable objects are? Can you imagine the havok that would insue of Strings could change their values arbitrarily after creation time? If you didn't answer yes to all three, shut up.
There is no universal type like void* in C. There is Object, but primitive types (int, char, float, etc.) are not objects. You can't pass them by reference. There are duplicate, object wrappers for these (called Integer, Character, etc.) which can be passed by reference, but you spend stupid amounts of time wrapping and unwrapping primitives.
The only time this is ever at all a bad thing is when you try to put primitives into collections that take objects. Hopefully the plans for generic collections will allow you to move the two lines of code that convert the primitives to objects and back will be replaced by a more interesting two lines of code somewhere else.
A function cannot take variable arguments of arbitrary type. The closest you can get is a function which accepts an array of Objects. (But Object is not a universal type - you can't give primitives to such a function without wrapping them).
Just suppose you could find a genuinly good use for a function that needs variable arguments of unpredictable type -- and object array is as good as anything. Just wrap any primitives and declare the array right where you need it (although you don't appear to know that such a thing is possible -- see next response).
You can't create a list anonymously. if x, y and z are ints, and "average" is a function which takes an array of ints, you can't do "average({x,y,z})". This makes the previous limitation more serious.
RTFM. Try average(new int[]{x, y, z}).
Things that should be warnings are in fact errors. For example, this snippet won't compile, because "a might not have been initialized": int a;int b = 0;if(b == 0) {a = 1;} System.out.println(a);. There are times when you want to write code logically equivalent to this, but the compiler makes you pointlessly initialise the variable at the start. The programmer may know things that the compiler doesn't; in this instance, that a will be initialised. It would be better for the compiler to merely warn, and then a runtime error to occur if the programmer was wrong.
Java warnings are, quite honestly, the best thing since sliced bread. I watch people trying to write C++ programs who regularly forget to initialize variables and spend hours trying to figure out what's going wrong. Java 1.4 is getting even stricter with the rules for acceptable code, which means that more programmers will have to fully understand the implications of what they've written. This is a Good Thing (TM).
The syntax is intentionally inflexible. To add a worthwhile "assert" statement, Sun had to add it to the core language, which is something that only Sun can do. Compare C, where anyone can write a reasonable assert macro. The same thing will apply to other things which you might want to do, but can't.
Have you ever seen an obfuscated java contest? I rest my case.
byte is signed in Java - instead of running from 0 to 255, it runs from -128 to 127. If you want to write the byte 0xA9 ( = 169) to a binary file, you have to call it -31
Every primitive number type is signed in java. That means number types are few and consistant. No warnings (not that these warnings are bad) about implicit casts between signed shorts and unsigned longs. If you must hold a number between 0 and 255 directly in a primitive, use the int type. It you want to complain that the int type will hold numbers that are too big, just & off all of the bits you don't want before you display the final number or whatever.
where is it?
4 25 7&mode=thread&tid=122
r y_ id=2602
i remember reading
http://slashdot.org/article.pl?sid=01/12/23/031
http://daily.daemonnews.org/view_story.php3?sto
yeah whatever?
remove NOT from email.
For example, if you have code like this:
import java.sql.*;
// start up a class, do some stuff, and then...
import java.util.*;
Date date = new Date()
The compiler will come back with a message like: "Can't figure out if you mean java.sql.Date or java.util.Date". So its not ever a namespace clash, because the compiler catches those problems before they get started.
As far as poor documentation of dependencies, that isn't really a factor either. You can't look at the import section to determine class dependencies anyway, because you don't have to import a class to use it. You might want to make that a convention, but its one of those things that is hard to maintain over a lot of code. If you want to call that 'source-code-level documentation' you can, but that's not what it is. Its not 'source-code-level' any more than the javadoc comments are.
-Mike
Java is NOT slow, Java code can run very quickly, especially if written properly, just like most other languages. It may not be as fast as optimized C++ code, but it's not slow, either.
Java ISN'T perfect, but you're beating on points that are simply wrong. You should probably learn about what you're talking about before you post. Write that one down.
I see the biggest issue being that Sun essentially has a choke hold on Java, particularly J2EE. Improvments and updates are unlikely to come as quickly as they would if Java were more open.
Computer Science is Applied Philosophy
I imagine that Sun's marketing wanted to appease IT managers whom are weary of any thing that is versioned 1.x, while appeasing developers who hate version inflation. Java was renamed "The Java 2 Platform" and the JDK was renamed J2SE.
Will there ever be a Java 3? Possibly, but the dual versioning would start getting absurd because the same product would have two mutable version numbers, confusing the situation even further (plus J2EE would be renamed J3EE).
Another good question: will the next major release of MacOS be X 11.0 or XI 11.0?
I just started rolling out a javahelp application on my 'doze boxes, only to find that hsviewer crashes. These are fully patched W2K boxes, and trawling the web produces no mention of hsviewer.exe exploding in on itself. Suggestions ? (apologies for the offtopic post - my monday deadline prompted it).
JDK1.4 has alot of features, but the biggest improvments is BUGS! The Java group spent 6 months doing nothing but fixing bugs. We went from 60 bugs in the Server compiler down to 0. JDK1.4 is much more stable the previous releases
Java supports skinnable look and feel "themes" with the AWT. my guess is that the windows theme requires some windows code emulated on UNIX boxes.
just a guess tho.
IBM's 1.3 series of JVM's are faster, more stable and better supported than the line series. How long are we going to have to wait until IBM releases their version. IBM have been throwing their weight around recently with Java (& Linux). Lets see if they are willing to keep up that so called support.
I'm a big fan of JBOSS, and (though I haven't tried it) would've liked to see Enhydra succeed as open source. But I don't see why Sun should grant a J2EE trademark to them. Sure, the price might have been outrageous, but companies like IBM and and BEA seem willing to pay it. Sun allowed them to see the source from the reference implementation and allows them to use the parts of it that haven't been implemented independently yet.
The spirit of open source isn't about marketing. And the J2EE mark is just that. JBOSS is very successful on its own right, and whether Sun blesses it shouldn't matter. Apache has succeeded without Netscape or Microsoft's compatibility certification, though there are still companies who feel more comfortable with a web server branded by a large corporation. Though this draws comparison with Versign refusing to recognize certificates from Apache, its not quite as bad, and eventually, they were forced to accept. Anyway, verisign isn't exactly to be held up as a model corporate citizen
It might be desirable for Sun to open up java to public standardization, but I don't think anyone build on java expecting that to happen. Its like WINE expecting Microsoft to certify it as 100% Windows compatible (even if it really were.)
It may be one day that people will want their J2EE implementations to be JBoss compatible.
Two thumb up on JDK1.4. The new io (nio) alone is worth the switch. I've been playing with it since beta one, and except for a strange bug (now fixed) in UDP where all incoming packets on all channels each falsely reported their origination address as having come from the same address as was reprorted on the first packet... except for that!:)... this stuff rocks. Packet transmission speeds are up something like 40-50% or more if I recall correctly. It's quick.
The Channel abstraction for talking to sockets also happens to be a nice one. The whole nio library has the taste of having been well-thought out by someone who really new what he was doing.
C//
Try the following snippet out on jdk 1.3.1 and 1.4.
public class JDK14Bug {
public static void main(String[] args) {
java.rmi.server.RemoteServer.setLog(null);
}
}
The javadoc says "Log RMI calls to the output stream out. If out is null, call logging is turned off."
To me 1.4 is broken. If I pass in a null I now get a NullPointerException with 1.4.
So I raised a bug on the java.sun.com site. A couple of weeks ago I get an email telling me it is a duplicate of another bug (which it isn't!). I was also told this is now the expected behaviour. It clearly doesn't follow the javadoc and has broken existing behaviour. I asked for Sun to look again but alas no reply.
What gives!
I am on a s-l-o-w dialup connection, and it is almost impossible to download a 12MB file, in one shot, under this condition.
Therefore, I need to find a place where I can do somekind of "getright" or "netvampire" type of "segmented" download.
In other words, I need to find an exact URL (either HTTP or FTP) so to get the "segmented" download session going.
Is there anyone who can provide the exact URL for the Java 1.4 JRE kit, please?
Thanks in advance !
Muchas Gracias, Señor Edward Snowden !
I mention autopr0n in my sig, but the majority of my posts here do not talk about it. If you want to see for your self, just go here and read the last 25 commenst I've made.
autopr0n is like, down and stuff.
The poster disagrees with my interpretation of the quote (the jury is still out for me on which interpretation is more accurate), and says so in a polite enough manner.
My response was to think about what he said and consider it seriously.
I agree with some of your points, and disagree with others; however, I have little emotional incentive to seriously consider your points or respond to them since your post comes across as arrogant and offensive.
Perhaps sometime you will not be perfectly and unambiguously correct about something, and someone else will point it out. Will you be more likely to listen to them if their comment begins by calling you an idiot?
Anyway, it would be nice to have a stimulating discussion in which we potentially learn something from each other rather than a pissing contest where we assert our egos. In response to my misstatements, I would much rather hear, "here's the real scoop" than "shut up because you don't know what you're talking about."
Why is Grand Theft Auto a much more serious crime than Reckless Driving?