any risk in moving to java 1.6

[Timasmith]

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?

 

[Knute Johnson]

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?

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 .

 

[Pawel Szulc]

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?

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.

 

[Jacob]

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?

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?

 

[Chris Uppal]

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

 

[RedGrittyBrick]

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?

 

[Knute Johnson]

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?

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

 

[Timasmith]

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

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.ibjectInputStream.readObject0(ObjectInputStream.java:1356)
at java.ibjectInputStream.readArray(ObjectInputStream.java:1642)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1323)
at
java.ibjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at
java.ibjectInputStream.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.ibjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at
java.ibjectInputStream.readSerialData(ObjectInputStream.java:1846)
at
java.ibjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.ibjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at
java.ibjectInputStream.readSerialData(ObjectInputStream.java:1869)
at
java.ibjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.ibjectInputStream.readObject(ObjectInputStream.java:351)
at
org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at
java.ibjectInputStream.readExternalData(ObjectInputStream.java:1792)
at
java.ibjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.ibjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at
java.ibjectInputStream.readSerialData(ObjectInputStream.java:1869)
at
java.ibjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.ibjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.ibjectInputStream.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)

 

[Chris Uppal]

OK, You are anti-anti-aliasing,

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

 

[Eric Sosman]

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.



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/.

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.

 

[Tris Orendorff]

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).

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