any risk in moving to java 1.6

Thread view:

Timasmith - 02 Dec 2006 03:43 GMT

I was wondering if anyone knows if there is any major risk to moving to
Java 1.6 now prior to their official release?

I am primarily using Eclipse, JBoss and Hibernate and obviously dont
want to introduce bugs if 1.6 is not ready for them?

I guess it has little impact on Eclipse but may impact other
technologies?

Reply to this Message

Knute Johnson - 02 Dec 2006 04:44 GMT

> I was wondering if anyone knows if there is any major risk to moving to
> Java 1.6 now prior to their official release?
[quoted text clipped - 4 lines]
> I guess it has little impact on Eclipse but may impact other
> technologies?

I've been using 1.6 for months and have not come across any problems.
Of course I'm only using one tiny little bit of the API. 1.6 is due out
this month though so there won't be many changes. The last weekly build
was 104 on the 1st of November. Try it, you'll like it :-).

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Pawel Szulc - 02 Dec 2006 08:26 GMT

havent notice any bugs, though i was using from the new API only the
java.awt.Desktop class - which is new in Mustang. beside that i was
using normal java classes and everytthing was alright. you souldnt run
to anny problems.

Reply to this Message

Jacob - 02 Dec 2006 09:07 GMT

I've used 1.6 for quite some time, and all my existing projects
seems to work just fine.

Except for this irritating detail:

To acheive antialiased fonts in Swing for JDK <= 1.5 I've lots of
c.putClientProperty(com.sun.java.swing.SwingUtilities2.AA_TEXT_PROPERTY_KEY, true)
scattered around the code. But the SwingUtilities2 class doesn't exist
in 1.6 (no other than myself to blame when using a class wich
such a silly name: It begs of becomming deprecated :-)

1.6 has a different approach for setting antialiasing as far as I know.

Isn't it time antialiased fonts are used by default? Why whould you
ever want non-antialiased fonts anyway?

Reply to this Message

Chris Uppal - 02 Dec 2006 16:41 GMT

> Isn't it time antialiased fonts are used by default? Why whould you
> ever want non-antialiased fonts anyway?

Because antialiased body-text is the very handiwork of the Devil. It should be
banned. And all memory it removed from public archives; the programmers who
invented it "un-personned"; and all voluntary users of it compelled to
undertake remedial training (which includes electrodes).

-- chris

Reply to this Message

RedGrittyBrick - 02 Dec 2006 21:40 GMT

>> Isn't it time antialiased fonts are used by default? Why whould you
>> ever want non-antialiased fonts anyway?
>
> Because antialiased body-text is the very handiwork of the Devil.

OK, You are anti-anti-aliasing, but maybe you are pro-sub-pixel-rendering?

http://en.wikipedia.org/wiki/Antialias
http://en.wikipedia.org/wiki/Font_rasterization

Could you explain in more detail what you find objectionable?

Reply to this Message

Chris Uppal - 03 Dec 2006 14:52 GMT

> > > Isn't it time antialiased fonts are used by default? Why whould you
> > > ever want non-antialiased fonts anyway?
> >
> > Because antialiased body-text is the very handiwork of the Devil.
>
> OK, You are anti-anti-aliasing,

Yes, I am. How could you tell ? <gin/>

> but maybe you are pro-sub-pixel-rendering?

Not really. I don't like it and don't use it (except that Adobe Acrobat
Reader's interpretation of font hinting seems to require it to make any sense
at all of it's built-in PostScript fonts at the sort of text sizes I read at).
The only positive thing that can be said about sub-pixel antialising is that
it's less objectionable than whole-pixel antialising.

> Could you explain in more detail what you find objectionable?

Two things.

One is that making (body) text blurry is bad/tiring for the eyes, in that it
removes the hard edges the eye needs to find a consistent focus. (You should
note that I have no medical training at all, let alone a speciality in the
physiology of the eye -- this is the opinion of a moderately informed amateur,
not a statement of some scientific consensus.) Blurring the text may make it
/prettier/ (or less ugly), but not more /readable/.

Second, there is no need of it. In fact it is an inferior technical solution
to an economic problem. If a given font looks ugly, or is hard to read, at a
commonly used point size, then that's just a flaw in the font. The correct
thing to do is not to blur the typeface (you might just as well smear your
monitor with Vaseline and have done ;-) but to replace that font. Windows
comes with some excellent fonts, which are clear, elegant, and legible (at
least at the point sizes I use), and have no need whatsoever of antialising.
Linux, the last time I looked, comes with a hodgepodge of ghastly, virtually
unusable fonts. I have no idea about other OSs (though I find it hard to
imagine the Mac shipping with anything less excellent than Windows in this
area). I assume that this deficiency in Linux (if it still exists), and the
corresponding emphasis on antialising in the Linux world, is because the
programmers would rather attempt a programming fix to the problem that typeface
design is /difficult/, than spend the necessary time learning to become
first-class typographers. My point here is not Linux-bashing (and I'm not
normally this approving of Windows!), but to give an example of how antialising
is applied as a patch to "fix" a problem which really needs a completely
different /kind/ of solution.

-- chris

Reply to this Message

Eric Sosman - 03 Dec 2006 17:01 GMT

>>>> Isn't it time antialiased fonts are used by default? Why whould you
>>>> ever want non-antialiased fonts anyway?
[quoted text clipped - 22 lines]
> not a statement of some scientific consensus.) Blurring the text may make it
> /prettier/ (or less ugly), but not more /readable/.

My medical training is on a par with Chris', but I once
attended a lecture on this topic, given by a mathematician who'd
been consulting with some vision researchers. The lecturer had
done a lot of 2D Fourier analysis of visual fields, and filtered
them in various ways: Remove high-frequency components, remove
low-frequency components, add noise of various kinds, leave the
amplitudes alone but diddle the phases, and so on.

One of the conclusions he reported was that the task of
reading printed material makes more use of high- than of low-
frequency components: You can filter out the low-frequency
information and leave a page of text readable, but if you take
out the high-frequency stuff it becomes much more difficult to
recognize letters and words. And guess what? The hard edges
that Chris likes produce high spatial frequencies, whereas an
averaging filter diminishes high frequencies and enhances low
frequencies.

The lecturer also mentioned that serifs are particularly
high-frequency features of some fonts, leading to a conjecture
that sans-serif fonts might be less legible than their serif'ed
brethren. At the time he was unaware of any research to support
or refute the conjecture, but (1) he was the helpful mathematician
and not the vision researcher, and (2) things may have changed in
the intervening couple of decades.

Signature

Eric Sosman
esosman@acm-dot-org.invalid

Reply to this Message

Tris Orendorff - 04 Dec 2006 16:46 GMT

>> Isn't it time antialiased fonts are used by default? Why whould you
>> ever want non-antialiased fonts anyway?
[quoted text clipped - 3 lines]
> invented it "un-personned"; and all voluntary users of it compelled to
> undertake remedial training (which includes electrodes).

Sheesh! Thank you for your opinion, Pastor Strate. Now for the news.

Signature

Tris Orendorff
[Q: What kind of modem did Jimi Hendrix use?
A: A purple Hayes.]

Reply to this Message

Knute Johnson - 03 Dec 2006 00:14 GMT

>> I was wondering if anyone knows if there is any major risk to moving to
>> Java 1.6 now prior to their official release?
[quoted text clipped - 21 lines]
> Isn't it time antialiased fonts are used by default? Why whould you
> ever want non-antialiased fonts anyway?

I thought text was anti-aliased in 1.6? It sure looks better.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Timasmith - 03 Dec 2006 06:10 GMT

> >> I was wondering if anyone knows if there is any major risk to moving to
> >> Java 1.6 now prior to their official release?
[quoted text clipped - 28 lines]
> Knute Johnson
> email s/nospam/knute/

I guess I was lulled into a false sense of security... JBoss with RMI
broke, the few posts with the problem suggest some obscure settings so
I guess I wait for smarter people to figure it out.

ERROR - Got marshalling exception, exiting
java.io.StreamCorruptedException: invalid type code: 00
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1356)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1642)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
    at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
    at
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480)
    at java.util.Calendar.readObject(Calendar.java:2609)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
    at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1846)
    at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
    at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
    at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at
org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
    at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
    at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
    at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
    at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
    at
org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
    at
org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
    at
org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
    at org.jboss.remoting.Client.invoke(Client.java:525)
    at org.jboss.remoting.Client.invoke(Client.java:488)
    at
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
    at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
    at
org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
    at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
    at
org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
    at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
    at
org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
    at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
    at
org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)

Reply to this Message

any risk in moving to java 1.6

Free Magazines