Re: [The Java Posse] Any thoughts on Swift?

[Jess Holle]

C is essentially the recognized, practical "high-level portable 
assembler" language.  It's the closest thing to assembler that allows 
production of portable source code that has been proven to work for 
developing a huge range of software (drivers, operating systems, 
embedded control, servers, desktop applications, etc...) for a huge 
range of hardware and operating systems.


C is essentially never "too big" or "too slow".  Combined with its huge 
mindshare it seems almost permanently ensconced as the "almost bare 
metal" tool.  Sure something will likely dethrone it someday -- but I'd 
not bet on that day being soon.


On the other hand, is C truly a high enough language for /effective 
/development of some of the world's biggest applications?  Not really.  
Is it really the most effective tool for developing smaller applications 
that don't really have to be "to the metal"? Arguably not.  As such C 
will frequently be passed over for many of these sorts of projects (at 
the very least by C++, but often by Java, C#, and a long list of languages).


--
Jess Holle

On 6/11/2014 2:28 PM, clay wrote:

Your reasons for preferring C are stability and long term longevity?

Are those factors really that important? If a language only lasts 40 
years rather than 100 or 1000 years, do you actually care? Like in a 
roaches will outlast human kind sort of way? Is stability the big 
thing holding you back from Java or C#? For all the legitimate gripes 
about Java/C#, basic stability and compiler crashes generally are not 
among them.


Secondly, that isn't consistent with your preference of Scala on the 
JVM and Idris off the JVM. I find it hard to believe that Scala+Idris 
have better stability than Java and will be around longer than Java. I 
prefer Scala over Java for the advanced elegance, conciseness, and 
expression, but IMO, Scala has been a buggier language than Java, it's 
less serious about backward compatibility, and it probably won't last 
as many decades into the future as a legacy technology as Java will.


Other tools might not have "the VM cost", but they all have some 
performance profile that can be quantified and logically compared. 
Java often does fairly well in those tests.



On Wednesday, June 11, 2014 11:41:38 AM UTC-5, Ricky Clarkson wrote:

I'm not saying I agree, but there are reasons.  C works.  You
aren't going to get a compiler segfault, then discover a debugger
bug while trying to debug the compiler, then fix that only to find
that your build tool doesn't work when your path contains spaces,
and then find that you can't read MP3 files without an extra
library that hasn't been maintained since the big bang, etc.  If
you need to write your own C compiler for any reason, nobody is
going to sue you.

C will still exist when Objective-C, PHP, ASP, VB, Perl, Python,
Ruby and probably C# and Java, have all bitten the dust, because
it *actually* works everywhere and is kind of a base on which
pretty much everything else can be built without incurring 'the VM
cost', however imaginary or real that cost may be.

It's also almost one of *the* bases, barring the 100s of special
cases it is a really simple language, kind of fundamental the same
way Scheme, Smalltalk and Forth are (i.e., hard to reduce further
without losing real capability).


On Wed, Jun 11, 2014 at 7:45 AM, clay > wrote:


On Friday, June 6, 2014 12:31:34 PM UTC-5, KWright wrote:

Nope!

C or Idris, I'll also accept Assembler.

and Scala's the least bad you can get if otherwise tied to
the JVM. :)


I completely understand why you prefer Idris/Haskell over
Scala and Scala over Java.

But why on Earth would you also prefer C? That seems to go the
opposite direction and be a big step down from Java?

All the things Scala fixes from Java are broken in C as well:
if expressions, for/monad comprehensions, focus on
immutability, pervasive type inference, cleaned up generics,
array syntax that is unified with generics (Array[Type] rather
than Type[]), language level currying and partial functions,
overridable var/val and ideal property system, singleton
objects instead of static.

And C/C++ is worse than Java: #define/#include, header files,
__declspec, library dependency system is a wreck, ABI issues
across binaries, hairy legacy issues that are far worse than
Java, wildly varying implementations of the "standard", super
complex networking/threading/file apis that make the Java
standard library a work of art. Did you ever use COM/ActiveX?
Have you ever worked with international strings in C? It's a

Re: [The Java Posse] Any thoughts on Swift?

[Jess Holle]

I also assume ARC requires less memory than GC does for decent performance.

GC is maximally easy for the developer, but conversely assumes a certain 
wealth of computing resources.


On 6/5/2014 11:51 AM, Kevin Wright wrote:

This one has also been doing the rounds recently:

https://leverich.github.io/swiftislikescala/


On 5 June 2014 16:41, Josh Berry > wrote:





On Thu, Jun 5, 2014 at 10:59 AM, Fabrizio Giudici
mailto:fabrizio.giud...@tidalwave.it>> wrote:

How much greater? Because in Java GC is hardly a speed problem
nowadays (unless we're talking of games, which at this age I'm
completely unaware of).


I think it is less "unless we're talking of games" and more
"unless we are talking of somewhat resource constrained devices." 
Games are easy to discuss in this context as they are usually

attempting to use every resource of their host platform as
efficiently as possible.

So, while it is great that memory is getting cheaper and cheaper
every day, I am at a loss as to why the twitter app requires
upwards of 80megs on my phone.  More, if I can let it.  And that
is just twitter.

I am also curious is to how this affects battery life.

And, of course, I could probably get by with just buying a newer
phone.  :)  I've thus far avoided the upgrade cycle of
"disposable" electronics.  Just doesn't feel responsible.

-josh

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to javaposse+unsubscr...@googlegroups.com 
.
To post to this group, send email to javaposse@googlegroups.com 
.

Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.

Re: [The Java Posse] Any thoughts on Swift?

[Jess Holle]

With Swift's ARC you have unowned and weak references, which you're 
expected to use to resolve such issues.


So the programmer certainly has more responsibility for memory 
management -- hopefully with greater speed as a result, else it's just a 
universally bad idea.


On 6/5/2014 5:27 AM, Fabrizio Giudici wrote:

On Wed, 04 Jun 2014 17:28:56 +0200, BoD  wrote:


Ok thanks for this link, interesting stuff there indeed :)
I guess I'll google a bit to see if I can understand the difference
between ARC and a GC.



I'm just catching up with the email and feeds after four days of 
totally isolation and I'm still reading Cédric's post... In any case, 
this ARC vs GC subject recalls me of the first days with Java. ARC is 
just a primitive way to do automatically memory management and it's 
definitely more limited than GC. It basically keeps a counter of users 
of a given object releasing it when the counter decrements back to 
zero, so -for instance - pure ARC can't solve circular references: two 
objects linking each other will keep at least a value of 1 on their 
linked objects, preventing collection.




--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.

Re: [The Java Posse] Re: Any Excitement about JDK 8?!?

[Jess Holle]

Thanks for a nice sane post!

I was despairing of seeing any on this thread.

On 2/27/2014 8:31 PM, Reinier Zwitserloot wrote:
Perhaps you don't see a peep in this channel is because any discussion 
will instantly devolve into a scala fanboy fest? This post turned into 
one halfway throughout clay's 1st post!


I'm guessing there's not much happening because:

* Testing lambda features is still a ways out, but the IDEs are just 
now coming online. I believe IntelliJ has beta support. Netbeans 
definitely does, and you can now chuck a plugin into Eclipse Kepler 
and have fun with it. Still, it is _very_ early. More to the point, 
perhaps, those who really want to play around with this stuff have 
been able to do so for a long time, and for them nothing is changing.


* The exciting bits about lambda are split between "What is it? Let's 
talk about how to bring closures to the java platform!" and "How does 
it make my day-to-day programming java different / easier?". We're in 
the limbo in between. We can't use it yet in 'real' code (certainly 
not until JDK8 is released officially, and then still slowly as 
libraries need to come online, you first need to convince the dev 
team, you have to test your stuff on JRE8, yadayada), but the 
feature-set and design is completely frozen and has been for a long 
time now. Essentially, there isn't much to talk about. Did you see the 
insane traffic about it on this mailing list and elsewhere around the 
time the syntax discussions were going on? The rank-and-file that 
haven't looked at it yet (A) don't hang out here, and (B) still 
haven't looked yet. They will in a few more months. But they'll mostly 
just adopt it, anybody that really was itching to discuss it would 
have done so a long time ago.


* We haven't had a podcast to start the discussion in quite a while.

As far as your downsides:

* Java's lambda approach is unique. It is more concise than scala's 
(due to not needing to mention the types of the variables), and the 
type system does not involve monstrosities such as Function22... all the way through W>. As far as I know, no language, certainly 
no popular/mainstream one, has gone with the novel concept of 
requiring the closure to have context such that its nominal type can 
always be strictly determined. All other languages either have 
functional types and will optionally auto-box into a nominal type if 
the context dictates that this is necessary (scala), or, don't have 
any nominal typing in the first place, and treat a function just as 'a 
function', without caring about types in the first place (javascript, 
python, ruby, etc). This alone already shows that calling java 'way 
behind' is misleading. Java is an apple, and scala is a pear.


* Scala is not 'basically java 8 + syntax cleanup + pattern matching'. 
For starters, scala has operator overloading and 'implicit', and more 
pragmatically speaking, if you look at generic random java code, it 
looks completely, utterly different from generic random scala code. 
The communities are totally different. The mindset? Totally different. 
The preferred models and API approaches? totally different.


* If we're going to bash adoption rates, scala still isn't even close 
to upgrading so that its closures can interop better with java's, 
mostly because scala doesn't want to end up in a situation where the 
class files it produces can't run on JRE6, last time I talked with 
Odersky & team. That's fair, but it goes to show that the 
compatibility dance is something that takes a while everywhere.


* Busying terms like 'philistines' and 'pathetic', while we're 
probably all guilty of doing that from time to time, mostly just makes 
you sound like Ranty McRantersons. If the aim is to engender some 
discussion, I'm guessing that isn't the best of ways to get it going 
into a fruitful direction.


On Thursday, 13 February 2014 21:46:16 UTC+1, clay wrote:

I'm disappointed there is not a peep about JDK 8 in this forum.

IMO, the main features are:

- Cleaner lambda expression syntax than the anonymous inner class
route from Java 1.1
- Functional collections in the standard JDK as opposed to relying
on somewhat obscure add-on libraries like FunctionalJava or Clojure.
- Standard Optional type which actually includes map and flatMap
unlike the philistines from Guava. OptionalInt doesn't include
these for some odd reason.
- Lots of VM improvements. No permgen! Some of my microbenchmarks
saw 10% speedups on old code, which is completely unexpected.
- New date/time library. Successor to Joda as a standard library.
If you have to deal with calendar date/times and can afford JDK8+
runtime requirement, this is a super elegant library.

Downsides:

- Still way, way behind Scala. Scala is basically Java 8 + a ton
of syntax clean up and fixing legacy problems inherited from its C
origins + pattern matching system + for comprehensions designed
for

Re: [The Java Posse] Re: No more podcasts?

[Jess Holle]

Understood -- though I'd second the request for keeping Roundup in the 
title where applicable, as I'm really only interested in listening to 
recordings of the regular podcast (though I might like to /attend/ the 
Roundup in person some year).


On 2/20/2014 3:13 PM, Carl of the Posse wrote:
We've all been very busy and have had a really hard time getting 
together to record.


Hopefully we'll figure something out in the near future. We do want to 
keep things going.


--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to javaposse+unsubscr...@googlegroups.com.

To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [The Java Posse] Java Plugin Download site unavailable

[Jess Holle]

Did you try downloading the installer from 
http://www.oracle.com/technetwork/java/javase/downloads/index.html and 
running it manually?


On 10/13/2013 11:01 AM, Zentech Frank wrote:
I've reached out to Oracle and have not received any response or 
support, so I thought that I'd try a Java group. I'm currently not 
able to download the java plugin from Java.com. All versions seem to 
be affected: http://java.com/en/download/manual.jsp
I have attempted from 15 + computers/devices of all operating systems 
from 8 different networks from all around the US. Not sure if this is 
just affecting just US, but I've tried some http proxies in other 
countries and no luck from there as well.
Does anybody already have this software downloaded (specifically 
Windows 64 bit). I cannot find an alternative download site on the 
internet anywhere. I can download JRE/JDK from many sources on the 
internet, but that doesn't allow for browser based plug support. I'm 
just looking for the Java browser plugin.


Any help would be appreciated.
--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to javaposse+unsubscr...@googlegroups.com.

To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [The Java Posse] Java 8 delayed...again

[Jess Holle]

I think Oracle had initially promoted the notion that they had the 
resources, discipline, and release management skill to get Java releases 
out on predictable basis.


It was a nice notion.  Certainly they were able to do better than Sun 
while Sun was broke.


Now, however, we're seeing the lie put to that notion.  Either:

1. Oracle's not willing to put enough of their resources in,
2. Oracle doesn't have enough bodies with the depth of JVM knowledge
   necessary (and one can't develop such experience overnight), or
3. More bodies won't help -- period.

I'd guess it's somewhere between 2 and 3 (though 2 often means #1 
occurred some time back when things were looking rosier).


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [The Java Posse] Re: Parallelism for Java8

[Jess Holle]

Of course the good thing is -- once code is formulated in terms of 
lambda predicates, switching parallelism engines is a smaller matter.


So if fork-join is full of it, use a different one.  Sure, it will take 
a bit of a code change to avoid the default parallel streams, but 
nothing near what it took to change from hard-wired, procedural, 
data-traversal-and-logic-all-in-one code.


That's not to defend fork-join -- just rejoicing that its far easier to 
switch parallelism algorithms with lambdas.


On 2/26/2013 11:32 AM, Casper Bang wrote:
Very interesting article. While I can't claim to understand it all in 
detail, I am not too surprised (this is Java after all). How can one 
expect a coherent, simple and pragmatic parallel programming model, by 
a CS professor isolated at his university?!


This is in stark contrast to C#, where the elephant is chopped up and 
digested in pragmatic pieces by a team of designers meeting 3 times a 
week, responsible for the programming model as a whole (one does not 
need to be a CS major to use PLINQ, Parallel.For etc.).


Bummer :/

On Tuesday, February 26, 2013 3:46:51 PM UTC+1, Edward Harned wrote:

My last article caused a lively discussion:
https://groups.google.com/d/topic/javaposse/Rfp7t23lQTo/discussion


I've added a new article just for Java8:
http://coopsoft.com/ar/Calamity2Article.html


constructive criticism is always welcome.

ed

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to javaposse+unsubscr...@googlegroups.com.

To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [The Java Posse] Re: Tabs and spaces - I don't get it

[Jess Holle]

On 1/25/2013 10:51 AM, Brian Smith wrote:
Tabs are nice because users can pick their own display width.  Spaces 
are nice because non leading space can be formatted more accurately. 
 There's very little difference in readability though.
Tabs are only workable if everyone involved is fanatical about 
consistently using them for every block indent and never ever using them 
for anything else.  That level of consistency doesn't exist in real 
world developer groups -- and thus they become untenable.
The only thing that's important in the tabs vs spaces debate is to 
pick one and stick to it and enforce it consistently.

Proper usage of tabs in beyond any enforcement regime I've seen.
Converting files from one to the other is a good way to make version 
control hard to use, particularly if you're using a editors that can 
annotate a file with changes.  Finding out when a particular line was 
changes is a complete pain in the arse when someone's helpfully 
autoformatted the file changing every line.  Some combinations can 
effectively ignore whitespace change, many cannot.  Best not to do 
that, instead if you really care, block commits that break whichever 
policy you choose.
Set your diffing tools to ignore space changes and then there's no issue 
with tab-to-space conversion muddying them up.


Now if you do more general reformatting then, yes, that makes version 
control hard to follow, but sometimes there's little alternative when 
someone's made a complete mess of things.  At that point you just do a 
separate commit for the reformatting and move on.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [The Java Posse] Re: Tabs and spaces - I don't get it

[Jess Holle]

Tabs are evil unless they're used with /fanatic /consistency throughout 
a source file.


Even with everyone's editors set to use tabs, I've yet to see the 
necessary level of consistency in the real world.


For example,

   public void foo( SomeTypeA a, SomeTypeB b, SomeTypeC c, ...
SomeType X x, ...) {
  for ( ... ) {
someBigUglyMethodCall( someBigExpression1, someBigExpression2, ...
   someBigExpressionN, ... );
...
  }
   }

If everyone editing the file (1) uses tabs in all cases where they mean 
to imply a block indentation and (2) uses them in absolutely no other 
cases in the file, then tabs are livable.


The temptation to use tabs to achieve the proper spacing for "SomeType 
X" and "someBigExpressionN" is overwhelming, though -- as it's a lot 
fewer keystrokes, depending on one's tab setting. That's the problem, 
however, by doing this the developer is assuming a tab-to-space 
conversion factor -- but this conversion factor is specific to their tab 
setting.  Once someone tries to edit the file with a different tab 
setting it becomes an unreadable mish-mash.


Add to this the fact that some folk are smart enough to follow rule #2 
and some aren't and some folk will inevitably use spaces rather than 
tabs in case #1, and tabs simply become utterly untenable.


Having an editor immediately convert tabs to spaces as you type is 
really the only solution.  It reduces keystrokes, but doesn't allow 
things to devolve into an utter mess.  Yes, one can have some blocks of 
code using 2 space indentation, others using 3, others using 4, etc, but 
one can still decipher the meaning of each block and following the 
formatting of the surrounding code (when in Rome...) is dead-simple and 
shouldn't trip up even the least diligent developer.


Whenever I see tabs in a source file I immediately eradicate them -- 
often letting the IDE reformat the whole file as it's often at a point 
that this is really the only way to achieve readability.


--
Jess Holle

On 1/25/2013 10:30 AM, Kirk Pepperdine wrote:

+1 on no tabs

On 2013-01-25, at 5:26 PM, Tor Norbye <mailto:tor.nor...@gmail.com>> wrote:


I'm pretty sure it's not just me and that Carl is equally adamant 
against tabs. I also don't think anyone on the Posse disagreed with 
it, even if they aren't as passionate about it as Carl and I.


If you've never run into a file with mixed tabs or spaces, 
congratulations, you're on a team where everyone has agreed on 
formatting settings. Consider yourself lucky.


Eclipse formats using tabs by default, and I'm pretty sure IntelliJ 
and NetBeans use spaces by default, so unless you're careful to all 
use the same IDE, or to check in settings files to make sure everyone 
has the right format, you might accidentally start mixing. And I 
think regardless of whether you're a tab-person or a space-person, 
everyone agrees that mixing is bad. I won't rehash the arguments for 
why we think spaces are better than tabs; it sounds like your post 
was stating that you don't think there's an issue here, and I've seen 
a lot of code, including core JDK classes, mixing spaces.


(Here are some really old blog entries I wrote related to tabs:
https://blogs.oracle.com/tor/entry/code_advice_3_no_tabs
https://blogs.oracle.com/tor/entry/tabs_are_evil_part_2
https://blogs.oracle.com/tor/entry/tabs_are_evil_part_3
Two of them show source files, one from the JDK, one from the 
findbugs source code, where I encountered mixed indentation.

)

-- Tor

On Friday, January 25, 2013 7:28:40 AM UTC-8, rakesh mailgroups wrote:

Hi all,

something I've always wanted to ask - I've heard Tor complain
about this issue about using spaces or tabs many times over the
years.

Its not something I've ever encountered in over 10 years of Java
development.

Is it just Tor's OCD kicking in about how he would like to see
the code? Or is it a legitimate issue I just don't happen to come
across?

In a team, usually everyone is using the same IDE, so we can all
just use the same "beautifier" - Intellij for example, has the
"format before checkin" option and even Eclipse had something
similar for formatting the code on demand.

Or perhaps this is a Netbeans issue? I've often felt that
Netbeans was only one step up from a text editor so maybe the
issue is more prevalent there.

Rakesh


--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com 
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com 
<mailto:javaposse+unsubscr...@googlegroups.com>.

Visit this 

Re: [The Java Posse] Episode 404...

[Jess Holle]

On 1/23/2013 7:18 AM, Casper Bang wrote:



Brits still measure distances in miles, height in feet and inches
and weight in stone and lbs.  The height and weight thing might be
changing with the current generation of schoolchildren, I'm not
sure, but miles look to be there to stay.  If you want to
standardise things, shall we start with the spoken language and
leave the units until continental Europe uses English instead of
their local dialect? :)


Well, the empire is no more; so the UK too will have to conform. 
English is already standardized as *the* international language and 
indeed, things are flowing nicely between Italians, French and Danes 
on this very list. I disagree that the language is more important to 
standardize though, that's a red herring in the light of math and 
science. Imagine if nobody agreed on the units of time...?!


Time is such a critical unit of measurement that it has eluded 
decimalization.


We still use minutes and hours -- base 60 rather than base 10. 
Similarly, while radians are used in scientific circles, common language 
references to angles are in degrees.


The roots of these unit systems are positively ancient 
(http://en.wikipedia.org/wiki/Sexagesimal), tracing back to the 
Sumerians in the 3rd millennium BC!  Talk about your ancient, antiquated 
"hill-billy" unit systems.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Episode 404...

[Jess Holle]

On 1/23/2013 6:44 AM, Fabrizio Giudici wrote:

On Wed, 23 Jan 2013 13:37:53 +0100, Jess Holle  wrote:

While the US is often prone to stubbornly "go its own way", I don't
actually see that as a big part of the equation here.
I don't comment on the "own way", since the important thing is whether 
a given way makes sense or not. So far USA went their own way for some 
things that made sense. Units don't in my opinion.

I think this is mostly about most folk in the US being unable to stomach
the thought of changing to some "weird" new units that they're
unfamiliar with.  They live their lives thinking solely in terms of
pounds, gallons, ounces, miles, feet, and inches. Kilograms, liters,
kilometers, and meters are positively Martian to most people in the US.
I'm not sure how well those who don't take a good sampling of science
courses really get introduced to SI units, much less their compelling
nature.  Even among those who are, many don't see them in use enough to
/think /in terms of them.  [It helps when you're into things like
cross-country skiing where measurements are primarily in SI units --
even in the US.]
Correct, but didn't the UK face with the same problem and survived? 
They also faced with a reform in their currency, as well as many 
Europeans faced with a complete change in the currency (whether a good 
idea or not is another matter).


Besides lack of familiarity there's also a vicious anti-government 
undercurrent.  There'd be a huge public outcry against the US federal 
government if the government took away the units Americans are familiar 
with and forced European ones down their throats -- and that's exactly 
how many Americans would see it and portray it.


Of course, I still think the US government should switch over to SI 
units as quickly as possible -- but no politician wants to pay the 
political price.  Also, those in the federal government are old 
(relatively speaking) and tend to have non-scientific/technical 
backgrounds -- and thus are perhaps even less comfortable with SI units 
than their constituents.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Episode 404...

[Jess Holle]

While the US is often prone to stubbornly "go its own way", I don't 
actually see that as a big part of the equation here.


I think this is mostly about most folk in the US being unable to stomach 
the thought of changing to some "weird" new units that they're 
unfamiliar with.  They live their lives thinking solely in terms of 
pounds, gallons, ounces, miles, feet, and inches. Kilograms, liters, 
kilometers, and meters are positively Martian to most people in the US.  
I'm not sure how well those who don't take a good sampling of science 
courses really get introduced to SI units, much less their compelling 
nature.  Even among those who are, many don't see them in use enough to 
/think /in terms of them.  [It helps when you're into things like 
cross-country skiing where measurements are primarily in SI units -- 
even in the US.]


Then there's the investment required to switch unit systems across a 
country the size of the US.  Is the investment worth it? Certainly.  But 
US politics are heavily skewed against national investments.  One 
political party is all about starving the government of tax revenue and 
spending and investing in nothing (except for corporate welfare in 
various guises).  The other is primarily about preserving and fostering 
government entitlements that account for most of the country's 
discretionary spending. Everyone wants more government than they're 
willing to pay for and no one puts enough priority on investments -- but 
rather just kicks the can down the road for the future.  This is true 
for things ranging from the metric system to public infrastructure 
(sewer systems, bridges,...) to education and research.


On 1/23/2013 5:56 AM, Casper Bang wrote:
Name calling aside, it *is* a little funky how the US prefers to go 
their own way rather than converting to the standardized metric 
system. Yes it's going to confuse old and conservative people for a 
time, just as it has in the past other places, but just get it over 
with once and for all. Unfortunately I did not hear this item in 
Obama's inauguration speech (but it was nice and unprecedented to hear 
about green energy).


We probably all remember the famous software bug* that caused the 
international Mars Climate Orbiter probe to crash into Mars, due to 
NASA issuing thrust instructions in lbs rather than newtons: 
http://en.wikipedia.org/wiki/Mars_Climate_Orbiter


*Technically this was not a bug nor a lack of specification, but a 
human error based on culture, however it would not have happened if 
everyone agreed on the primary quantities/units.

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/Ane7WVyow8UJ.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Episode 404...

[Jess Holle]

The politically correct term might be "legacy" units, though antiquated, 
medieval, pre-industrial, and byzantine all seem more accurate.


I live in the US and am thus stuck with such units -- whatever one calls 
them.  When in engineering school I found that a decent HP calculator 
made crazy units pretty much immaterial, though. Unfortunately it's my 
understanding that HP pretty much lost the high-end calculator market 
since I moved on into software -- or have I heard wrong?  [My HP 48SX 
still works pretty nicely over 20 years later :-)]


On 1/22/2013 1:33 PM, Robert Casto wrote:
Hopefully you understand that the word "hillbilly" can be offensive to 
people?




On Tue, Jan 22, 2013 at 2:27 PM, Simon Ochsenreither 
mailto:simon.ochsenreit...@gmail.com>> 
wrote:


I adopted the term “hillbilly units” as an umbrella term for all
these different kinds of measurement units which are normally used
by a combination of the US and another random third-world country,
and it has made it considerably easier in those situations where
one wants to refer to all those measurements not directly derived
from the SI units, but where one doesn't actually care about which
non-standard system it is exactly.

-- 
You received this message because you are subscribed to the Google

Groups "Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/IlDyE8R-4LMJ.

To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Robert Casto
www.robertcasto.com 
www.sellerstoolbox.com 
www.lakotaeastbands.org 
--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Syntax for default methods and order of type parameters changes. Both to the worse?

[Jess Holle]

I like the default placement.

The Mapper parameter bit just seems inexplicable, though. Principle of 
most surprise?


On 11/14/2012 7:27 PM, Ricky Clarkson wrote:
The rationale was to make default a modifier instead of even more 
special syntax than it needs to be.


The parameter order isn't very important to me, just a mild irritation 
that they seem to want to do it the exact opposite way to everything 
that already exists.



On Wed, Nov 14, 2012 at 9:52 PM, Simon Ochsenreither 
mailto:simon.ochsenreit...@gmail.com>> 
wrote:


The default method syntax will change¹ from

public void method() default { foo(); }



to

public default void method() { foo(); }


I haven't found any reasonable rationale for it on the mailing
list (or elsewhere).

I wonder why they changed it to be inconsistent with Java's
existing default value syntax.

They also changed around the type parameter order to "align better
with EG discussions"²:
So basically having a functional interface like Mapper will
now mean "it maps to A from B" and not "it maps from A to B" anymore.

A reasonable explanation would be that it follows the order of
methods definitions. But on the other hand, that would be
inconsistent with both the definition of lambdas itself (A -> B)
as well inconsistent with the flow of chained operations like
list.map(...).filter(...) ...

Ideas/opinions?
Just NIH? Or some evil master plan to ship with requested
features, but prevent widespread usage by making them worse than
necessary (Optional comes to mind...)? Just joking. :-)

¹
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006482.html
²
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006461.html
further discussion in

http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-November/000314.html
-- 
You received this message because you are subscribed to the Google

Groups "Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/0TIctYYriksJ.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Returning Void

[Jess Holle]

Two words:

   ivory tower

Retrofitting concepts into languages where there's little *real* benefit 
serves only to waste resources that could be better spent elsewhere -- 
and to risk breaking things, e.g. backward compatibility, that do have 
real, tangible benefit.


We're in the real world, developing real software.  Nothing is perfect 
and no one has the luxury to repeatedly up-end everything to rework 
everything that wasn't 100% perfect.  Sure, when there are serious 
issues you go back and rework things, but there are time/resource vs. 
compability/migration-cost vs. perfection vs.  tradeoffs that one 
must carefully weigh.  That's one reason it's called software engineering.


On 10/15/2012 6:37 AM, Kevin Wright wrote:



On 15 October 2012 12:01, Reinier Zwitserloot > wrote:


On Monday, October 8, 2012 1:33:06 AM UTC+2, Simon Ochsenreither
wrote:

I think it is an interesting example how some "pragmatic" and
superficially simpler approach tends to break down and cause
complexity in both the spec and the implementation compared to
the "academic" solution.


Yes, java has no type that represents "there is no value that is
this type, not even 'null'". It would be cool if this type
existed; a method that had this as return type cannot actually
return, ever. It has to exit abnormally: Either it runs
System.exit(0), which should probably at that point return this
special Nothing type (so that you can type: return
System.exit(0)), or it has to throw an exception. There are no
other ways out.


There are other cases too, it also crops up in recursion where there's 
absolutely no information whatsoever available for type inference. 
 Just consider:


def method[A](x: A): A = method(x)


Something like this, without tail recursion, would ultimately crash 
the JVM with a StackOverflowException.


More importantly though... even given a variant that did terminate and 
didn't stack overflow, what type could reasonably be inferred *except* 
for Nothing?


Unfortunately, introducing this kind of concept is exactly the
kind of thing java does NOT do, and languages like Scala DO do:
it's not a matter of superiority, it's a matter of tradeoffs: If
this Nothing exists, it cannot actually be a subtype of Object; a
List cannot accept an instance of List, because I can
still put nulls in List, and nulls are not a valid value for
Nothing. Hell, generics in general play havoc with this: Using
trickery I can make a List with nulls in it, and then
write return thisHackedList.get(0), which means in practice that
Nothing needs type checking (i.e. that would lead to a
ClassCastException or similar, even if .get(0) returns null).


Fortunately, this is *exactly* you you want to do with an immutable list!

The only way to add an element to an immutable list is to create a new 
list containing the old one as a subset.  This means that the type of 
every element in the existing list must subclass the element type of 
the new list.


To put it another way, this means that the element being added to an 
immutable list must be a superclass of the element type of all 
elements already in the list.


And, because such lists are immutable, they must be built up by 
starting with an empty list.  This empty list must have an element 
type such that *anything* you might add to it is a superclass.


The element type of such an empty list MUST be the subtype of every 
other type in existence.


That type is Nothing, and Scala's empty list (called Nil) is, indeed, 
an instance of List[Nothing]


List[Nothing] not only makes sense, it's actually a necessary 
requirement to get immutability right.  It also only works if Nothing 
is very much a subclass of Object, and Null, and anything else you 
care to mention.


That's the kind of thing where java has decided that the practical
upside of having a 'Nothing' value is not actually that much; it's
largely academic, and it definitely "feels bad" that the language
is not complete, and that this awesome concept is not actually in
your language. However, adding it to the language definitely
incurs a cost: The compiler needs to do all sorts of things to
treat Nothing specially, and this is going to make the spec much
more complicated.


What of the cognitive cost to having this concept that developers must 
necessarily encounter, then forcing them to use hacks and workarounds 
because it cannot be represented in their programming language?


Scala-like design says you accept the complexity hit, and
theorizes that if you go whole-hog on this you can actually remove
a lot of complexity because the language is much more flexible. So
far that seems like it's been working out reasonably well for
scala. The java-like design says that these mostly academic
features just aren't important enough, and i

Re: [The Java Posse] Dick's Apple vs Samsung comments

[Jess Holle]

On 9/4/2012 12:14 PM, Cédric Beust ♔ wrote:


On Tue, Sep 4, 2012 at 7:53 AM, Casper Bang <mailto:casper.b...@gmail.com>> wrote:


Eventually Apple will bury themselves by burning too many bridges
- I.e. imagine if Samsung cuts off their supply of NAND chips, SSD
drives, IPS panels etc.?!


Agreed. I think their expansion strategy is unsustainable and they are 
on the wrong side of history. If you think about it, not much has 
changed, they are doing exactly what they attempted to do 20-30 years 
ago: offer a completely closed and 100% Apple controlled ecosystem. 
The attempt failed pretty quickly back then because of the rise of 
Microsoft and of custom and cheap PC's.


They are being more successful this time around because they have a 
few great and very successful products that netted them a large amount 
of cash, so the main difference is that they can try this failed 
strategy for longer, but in the end, it will fail again. The cash and 
the court victories against Samsung are just minor battles that won't 
change the outcome of this war in the long run.


I was a /huge /Apple fan 20 years ago.  Their GUI was /far/ more usable 
than Windows (it wasn't just a matter of who has the most eye candy like 
it is now) or anything else out there.  They had well documented APIs 
that anyone could use to write and market software on their devices.  
Their hardware may have been single-sourced, but I never really had an 
issue with that as long as there was a compelling reason to buy it.  The 
/software/ market was open to all in contrast to what they're trying to 
pull these days.


Now I can't see buying into any Apple products, with the possible 
exception of replacing my ancient iPod someday when it dies, though I'll 
certainly look around for a good alternative first.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Dick's Apple vs Samsung comments

[Jess Holle]

Personally I'd long since reached the same conclusion as Dick, i.e. that 
I really shouldn't buy any more Apple products.


That said, I won't stand in the way of anyone else (including my wife) 
buying them.


My reasons include their litigious patent suit stuff, but that's just 
piece.  I'm also voting with my feet against their heavily walled garden 
approach to applications for the iPhone and iPad -- and whatever else 
they can force in that direction apparently (e.g. shipping the Mac Mini 
without a CD/DVD drive and trying to nudge it in the same direction...).


I see Apple as the new Microsoft -- but worse in that with Microsoft you 
were always free to produce and market your app in their effective 
monopoly space (Windows) whereas Apple doesn't want you to have that 
much freedom.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Opinions: How long to wait for Jigsaw?

[Jess Holle]

Realistically Jigsaw in no way facilitates removal of long-deprecated code.

At *best* it would allow for deprecated *classes* to be moved to a 
separate, optional module.  It can't do a thing about deprecated 
methods.  Removing those would still utterly fragment the Java community.


Personally I'd like to just see the basic "app developer level" 
modularity from Jigsaw and leave the native-package-system integration 
and core class library modularization to Java 9 or 10 or whatever.  
Having a simple module system that is understood by both the compiler 
and runtime would help ordinary developers who don't need something as 
complex as OSGi (e.g. don't need to juggle multiple versions of 1 jar 
within one JVM or web/enterprise app as they just manage to figure out a 
combination of versions of different libraries that works and move 
forward using those -- it's usually pretty easily done).


How long would I hold Java 8 for this?  Not terribly, but I don't think 
this is really being considered.  The Jigsaw folk seemed really hung up 
on the native-package-system integration and core class library 
modularization in previous talks.


On 8/30/2012 10:16 AM, Kevin Wright wrote:
I always figured that anyone who wanted lambdas that much would be 
sailing the choppy JVM waters on a differently lingual boat by now. 
 It's not as though you even have to change your ops infrastructure or 
much of your tooling to do so.


(hint: rename scala.jar/clojure.jar/groovy.jar/whatever.jar to 
apache-closures.jar, release your project binaries as you always did. 
 Don't make a song and dance about it, it's easier to ask forgiveness 
than to request permission)


Jigsaw on the other hand... That means distinctions like SE/ME can be 
done away with, long-deprecated code can finally be removed, startup 
time, download time, and memory foot print can be reduced, etc.  It 
makes Java far more suitable for running on something like the 
Raspberry Pi.  These are cross-cutting concerns that benefit all 
languages on the Java platform.


Defender methods and method handles are also just plain awesome.  Even 
without lambdas, I'd fully expect some powerful optimisations to 
be realised on top of those two.




On 30 August 2012 15:57, Thomas Matthijs > wrote:


On Thu, Aug 30, 2012 at 4:03 PM, Ricky Clarkson
mailto:ricky.clark...@gmail.com>> wrote:
> I want my lambdas now and I'm in a job where using non-Java
languages
> will be a difficult sell.  The earlier the release the better
for me.
>
> I've seen classpath hell exactly once, actually in a current
project,
> and plan to deal with it in a different way - attempting to
> find/create a combination of libraries that don't have version
> conflicts, and where that is not possible, moving tasks out of the
> same JVM process.
>
> The other benefit would be JVM startup time, which is less and
less an
> issue each year as machines get faster and Java doesn't get bigger.
> I'd like to see the startup time be improved further, but
lambdas will
> affect me more than cutting down startup from 5 seconds to 1.
>


I agree fully, jigsaw won't fix any problem i currently have, lambdas
on the other hand would be very beneficial

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Why is Oracle so slow?

[Jess Holle]

Ah...

I'd missed that article.

Yes, that is rather reprehensible!

[I'd assumed the flaw was either newly discovered or hadn't been 
privately known that long.]


On 8/30/2012 8:37 AM, Casper Bang wrote:

On Thursday, August 30, 2012 2:26:11 PM UTC+2, JessHolle wrote:

Hmm

I guess I'm slow here.  I only heard about the latest
vulnerability on 8/26 or so.  I can't see anything indicating it
was widely know prior to that.

I'm missing where the 4 months comes from on the latest issue.

Some vulnerabilities may have gone 4 months -- but some
vulnerabilities are rather minor too.


There's a high-level report about it at arstechnica:
http://arstechnica.com/security/2012/08/critical-java-bugs-reported-4-months-ago/

If it already made it into malware kits, works on all platforms, and 
considering there are 100M installations vulnerable - then it's very 
serious issue for Oracle and Java's rep.

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/pJEOBz0seS8J.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Why is Oracle so slow?

[Jess Holle]

Hmm

I guess I'm slow here.  I only heard about the latest vulnerability on 
8/26 or so.  I can't see anything indicating it was widely know prior to 
that.


I'm missing where the 4 months comes from on the latest issue.

Some vulnerabilities may have gone 4 months -- but some vulnerabilities 
are rather minor too.


On 8/30/2012 6:16 AM, Casper Bang wrote:

On Thursday, August 30, 2012 1:07:43 PM UTC+2, JessHolle wrote:

I too love to gripe about big corporations of all stripes, but...

Just hold your horses just a bit longer here.


Usually I would, but 4 months seems long for such a serious bug that 
affects so many across language, culture and platform (we're likely 
talking > 100M installations). People are taught to stay up-to-date. 
However, in this case, running the top-notch JDK7 is less safe than 
running an older 6.0.

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/SR1b9EJPtmoJ.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Why is Oracle so slow?

[Jess Holle]

I too love to gripe about big corporations of all stripes, but...

Just hold your horses just a bit longer here.

On 8/30/2012 12:14 AM, Casper Bang wrote:
Forget about spending a decade debating closures - I'm talking about 
patching security holes here! The last couple of years, Java has 
become the predominant vector of attack, to the point that I recommend 
friends and family *not* to run it at all. Life is rarely that simple 
however, as i.e. the case with a Danish national SSO solution (taxes, 
banks etc.), for all practical purposes requiring applet functionality 
to be enabled for every citizen.


The latest vulnerability already seems to have the Poison Ivery trojan 
spreading all over. It seems however, we're far from 
zero-day vulnerability attacks, as these were brought to Oracle's 
attention some 4 months ago: 
http://www.security-explorations.com/en/SE-2012-01-press.html


I have now stitched together Chrome plugin to only allow certain 
trusted applets to run, but your average Joe don't have that 
option. There's still no fix available and that's just not good enough!

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/hJTW5OLDg6wJ.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Apple vs Samsung

[Jess Holle]

Apple's overall behavior is entirely relevant to programmer's, though.

Their walled-garden business model is really troubling -- as profitable 
as it has been for some.


 * There is no alternative access to this market
 o Apple has a monopoly on this access and you play by their rules
   and conditions or don't access this market at all.
 * Apple takes a substantial cut.
 o There's no competition on access to this market, so no market
   forces keeping this in balance.
 * Worst of all Apple decides who can access this market -- does so
   /after/ the product has been developed and can remove this access at
   any time for no reason.

To me this is a really troubling business model for application 
developers.  Sure, it can be profitable -- yet you're reduced to being 
sharecroppers surviving at Apple's whim and on Apple's terms.


Given that Apple is the most valuable US company ever (though not in 
inflation adjusted dollars), I think we're looking at the new evil 
empire.  Back to Java, Apple has used its power to say "no" to Java on 
many of their devices, whereas even Microsoft didn't do anything to 
prevent Java from working on most of their devices or to close off the 
ability to sell Java-based applications for them.


--
Jess Holle

On 8/25/2012 4:30 AM, Ricky Clarkson wrote:


Oracle case: Can you write a library that provides compatibility with 
someone else's library?


Samsung case: Can you copy your competitor's handling of 
finger-to-screen events?


The Oracle case was clearly more relevant to programmers.

On Aug 25, 2012 4:07 AM, "Fabrizio Giudici" 
mailto:fabrizio.giud...@tidalwave.it>> 
wrote:


I completely fail to understand why we (and the rest of the
blogosphere) have spent hundreds of emails discussing the Oracle
vs Google suite, as something that could menace Android and thus
the freedom to innovate, while almost nothing has been said about
the Apple vs Samsung, which is just a proxy for Apple vs Google.
BTW, Oracle has lost (at least the first round) challenging on
technical stuff, I mean something related to the *implementation*
of a VM, Apple has won on "pinch to zoom", which is 100x absurd.
My only explanation is a prejudice against Oracle (added to a
previous prejudice against Sun), which seems much stronger than
the prejudice against Apple.


-- 
Fabrizio Giudici - Java Architect, Project Manager

Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio.giud...@tidalwave.it <mailto:fabrizio.giud...@tidalwave.it>
http://tidalwave.it - http://fabriziogiudici.it

-- 
You received this message because you are subscribed to the Google

Groups "Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Apple vs Samsung

[Jess Holle]

We elected the idiots, yes.

Of course, position statements on patent law haven't exactly been 
front-and-center in campaigns.


In general, US elections have more to do with

1. Appealing to enough special interests to get loads of money to
   inundate the masses with campaign ads
2. Forming an /image /(not substance) that connects with their base and
   a few independents
3. Repeating terse, almost meaningless 60-second blurbs ad nauseum

Deeper discussion is too time consuming.  It's also too dangerous to the 
candidate as they might actually talk about the real complexity of 
issues rather than simple, pat answers.  No pure party line fully holds 
water when one takes a deep look at any issue.  Instead, real solutions 
tend to be complicated, nuanced, and involve some mix of ideas from a 
variety of sources -- something no US political party will really 
tolerate today.


I think Mickey Edwards (author of 'The Parties Versus the People') might 
be on to something 
(http://www.pbs.org/newshour/bb/politics/july-dec12/edwards_08-21.html) 
urging:


 * No closed, single-party primaries but rather a primary taking all
   candidates from all parties with the main election being a runoff
   between the winners
 o Today's closed primaries produce extremist candidates from all
   parties
 * Huge reductions of party power and party separation in Congress
 o Right now if you don't tow the party line you get no power in
   Congress, party-purity reigns supreme

--
Jess Holle

On 8/25/2012 6:09 AM, Jan Goyvaerts wrote:
Since when are laws concerning IP making much sense ? Since when is 
the law a synonym for justice ? That must be a long time ago now...


Absurd yes - but it's Legal Absurdity. And therefore, if they don't 
comply to The Law, they're criminals. And will be punished. But if 
they comply, they'll pay $1bn. And will be punished too. Nice, this 
Legal Injustice.


But to be honest, didn't *we* elect those idiots voting those absurd 
laws ? So maybe the law is such a mess because we'd rather not use our 
brains at the election.


On Sat, Aug 25, 2012 at 11:30 AM, Ricky Clarkson 
mailto:ricky.clark...@gmail.com>> wrote:


Oracle case: Can you write a library that provides compatibility
with someone else's library?

Samsung case: Can you copy your competitor's handling of
finger-to-screen events?

The Oracle case was clearly more relevant to programmers.

On Aug 25, 2012 4:07 AM, "Fabrizio Giudici"
mailto:fabrizio.giud...@tidalwave.it>> wrote:

I completely fail to understand why we (and the rest of the
blogosphere) have spent hundreds of emails discussing the
Oracle vs Google suite, as something that could menace Android
and thus the freedom to innovate, while almost nothing has
been said about the Apple vs Samsung, which is just a proxy
for Apple vs Google. BTW, Oracle has lost (at least the first
round) challenging on technical stuff, I mean something
related to the *implementation* of a VM, Apple has won on
"pinch to zoom", which is 100x absurd. My only explanation is
a prejudice against Oracle (added to a previous prejudice
against Sun), which seems much stronger than the prejudice
against Apple.


-- 
Fabrizio Giudici - Java Architect, Project Manager

Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio.giud...@tidalwave.it
<mailto:fabrizio.giud...@tidalwave.it>
http://tidalwave.it - http://fabriziogiudici.it

-- 
You received this message because you are subscribed to the

Google Groups "Java Posse" group.
To post to this group, send email to
javaposse@googlegroups.com <mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.

-- 
You received this message because you are subscribed to the Google

Groups "Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this g

Re: [The Java Posse] Groovy love

[Jess Holle]

There are issues.

That said, most developers move on and get a lot done without being 
overly bothered.


A few just seem to get stuck on every wart -- making mountains out of 
mole hills (or warts).


On 7/30/2012 6:11 AM, fabrizio.giud...@tidalwave.it wrote:
 > I definitely see a lot of frustration from people over Java's type 
system.  Can't say I blame 'em, to be honest.
I'd like to see some numbers here :-) because I don't see any 
particular frustration at all. I'm not saying it's hassle-free, I'm 
saying is quite manageable and there's not frustration.


--
f.g.
--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

Along these lines I'd really like to know why the "core" of Jigsaw (a 
simple, language-level, integrated module system for developers) cannot 
be delivered in Java 8 and the rest of it (modularizing the JVM, 
integration with native packaging systems, etc) in Java 9.


On 7/24/2012 3:22 AM, Jan Goyvaerts wrote:
As suggested in the latest podcast, I'm definitely in favor of having 
Mark Reinhold interviewed. So he can express his opinion about the 
future of Jigsaw if delayed to JDK9. --
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/22/2012 12:45 AM, Reinier Zwitserloot wrote:

On Saturday, July 21, 2012 2:29:00 PM UTC+2, JessHolle wrote:

What about modularizing the JVM? That's only important to allowing
the Java SE codebase to be more readily re-used in other
environments -- and /possibly/will yield faster startup time
(though a good refactoring could likely do that by itself).


Modularizing a fairly large program usually leads, down the road, to a 
project with better code quality, less bugs, and all that. That's one 
more thing to chalk on the 'pro' side of jigsaw. Also why delaying it 
is acceptable to me, if the conclusion is that this can't be done 
properly in time for java8.
Modularization of the JVM itself can be delayed without any real issue 
from my perspective.


Same goes for native packaging integration (though how is it that Java 
still doesn't have a standard Windows service wrapper!?!).


Getting a simple all-in-one build-time and runtime module system 
integrated into the language, however, is key and /far/ more important.  
That piece should come in Java 8 -- without the rest of the less 
critical, and thus distracting, stuff.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/21/2012 9:48 AM, Kevin Wright wrote:


On 7/20/2012 2:42 PM, Kevin Wright wrote:

Nothing wrong with a half-baked solution.  Something can have
definite value even if it's not "complete".  But without the
ability to evolve the thing and change APIs under a different
version number, it's too risky to release in such a state.

No module system will give you what you want -- an ability to
radically and incompatibly change longstanding public APIs
whenever and wherever this is deemed more correct/pure/perfect,
e.g. wherever you'd do it differently if you could do it all over
again.


Radically change - yes
Whenever and wherever - no

I'm only concerned with two classes of issue here:

1. The big, infrequent changes:  removing Corba, breaking swing out 
into a separate module, a one-off replacement of all methods using 
enumeration to use iterable.  The sort of legacy stuff that you often 
hear people wishing could be changed with each new release, but which 
is tied to backwards compatibility.
Most of this isn't worth the sort of heartburn / community fracturing it 
would engender.  Removal of CORBA is a separate case, of course, as this 
largely can just be moved to a separate module without actually changing 
APIs in any incompatible fashion.  Rather it can just be pushed out of 
the way.  That said, it wouldn't buy me anything whatsoever either -- 
not because I use CORBA but rather because CORBA packages being present 
does not hurt me in any way whatsoever.
2. Very new stuff that's still evolving.  Instead of hiding JavaFX 2 
from the public for so long, it could have been released as a 
versioned module.  Frequent changes here wouldn't be a problem in the 
same way as for more established functionality, because nobody's yet 
had time to build up any legacy code around them.


The extreme way that I works because it happens in a very lean 
environment, where the developers are all co-located, the 
"application" is made up of numerous modules all communicating via 
JSON, and where almost all our services are for in-house consumption 
by our own client app.


I can't imagine that approach working in the Java libs for a second.

As you say, that works in a very lean, colocated, environment.

This sort of change would fall on its face for large distributed 
environments with large less modular source bases, lots of usages of 
external Java libraries, etc.


In short, it wouldn't fly for a good number of large Java-based 
development organizations.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/21/2012 6:58 AM, Josh Berry wrote:
Which keeps bringing me back to the question of, what exactly is the 
win of jigsaw? A faster startup of the jvm? What else? 
My assertion is that the only real near-term win of Jigsaw is a simple 
module system that meets the needs of build-time and runtime modularity 
for a good portion of the community -- all with a single system that is 
well integrated into the language itself.


Today one must use both Maven and OSGi (or equivalents) to accomplish 
this -- and neither is well integrated with the language.


What about modularizing the JVM? That's only important to allowing the 
Java SE codebase to be more readily re-used in other environments -- and 
/possibly/ will yield faster startup time (though a good refactoring 
could likely do that by itself).


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/20/2012 2:42 PM, Kevin Wright wrote:
Nothing wrong with a half-baked solution.  Something can have definite 
value even if it's not "complete".  But without the ability to evolve 
the thing and change APIs under a different version number, it's too 
risky to release in such a state.
No module system will give you what you want -- an ability to radically 
and incompatibly change longstanding public APIs whenever and wherever 
this is deemed more correct/pure/perfect, e.g. wherever you'd do it 
differently if you could do it all over again.


That's a recipe for destroying the community -- irrespective of the 
module system.  OSGi wouldn't support that any better -- just imagine an 
application using libraries which had 4 different versions of the 
java.lang.String that they are trying to call one another with or having 
to support 4 different flavors of your library (and maintenance bug 
fixes to each) just to deal with the 4 different versions of 
java.lang.String.  Now imagine being faced with 4 different versions of 
java.lang.String and 4 different independently varying versions of 
java.util (what's the point in having modules if you can't increment 
some versions indepedently)...


Modularity is important.  Library versioning is important.  Neither 
allows you to redesign the core language APIs without either providing 
backwards compatibility or fracturing the community -- those are your 
choices.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/20/2012 12:16 PM, Fabrizio Giudici wrote:
(Given that I'm spot on with Kevin about the reduction of the 
technical debt, but it's another story).

I think the question here is what's actual, substantive technical debt.

Having code that calls APIs which return Enumerations (as per one of 
Kevin's examples) isn't what I'd call technical debt, especially given 
that there are often no existing alternatives in core API classes.  
Having a new version of java.packageX come out that removed all these 
APIs and prevents one from upgrading to any future versions of the 
library until one refactors one's entire source base /and /moves to new 
library versions and/or changes/drops libraries to achieve the same with 
all the libraries one uses isn't a case of dealing with technical debt.  
It would be a case of insanity -- and a sign to switch platforms to 
something that doesn't treat its community in such an insane fashion (or 
never move to a new version of the platform, but that's insane in its 
own right).


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

It's great if someone foots the bill for religious refactoring.

Not all organizations will.

Nor can I say that I'd argue for footing such a bill when one has 
millions of lines of code that work just fine but just happen to have 
been written against older versions of Java.  Who cares if they use 
Enumeration or Iterator if they work?


Worse, if you have loads of 3rd-party libraries, you can't reasonably 
refactor all of them to some new version of Java, especially if some are 
closed source.  You can try to find alternatives, but you can't always.


This puts organizations in an expensive rock-and-a-hard-place spot -- 
and many will simply stay behind.  That unnecessarily fractures the Java 
community.  This is coming from someone who has spent a lot of time and 
energy to run and compile everything with the latest JVM, latest Tomcat, 
latest of most everything.  Even so, refactoring everything for purity's 
sake -- that's not even in the top thousand priorities.


On 7/19/2012 3:57 PM, Kevin Wright wrote:
I'm currently working on an application that consists of 74 distinct 
modules in GitHub, most of which are in scala.  One of the smaller 
modules I've recently been working on has 45k lines, this is down from 
70k about a month ago (hey, I practice what I preach, and am a strong 
believer in staying clean of technical debt)


Across all projects, we're well over a million lines of code (most of 
which is Scala, remember, and so equivalent functionality to 3-5x that 
many lines of Java), all under 2 years old.  So in terms of size, I'm 
working at the same order of magnitude.


One of our "secrets" in getting where we are now, having an 
application that we can work on at blazing speed, is a willingness to 
cut code and to refactor ruthlessly.  If it begins to look 
"enterprise", if there's any obvious technical debt, then that's a 
code smell - it's not bragging material.


I can honestly say that refactoring to new versions of APIs, or 
removing the use of deprecated methods has never been a problem.  The 
very same IDEs that you previously referred to are particularly good 
at this sort of challenge, and *this* is the correct use of a decent 
tool - instead of simply hiding stuff.





On 19 July 2012 21:13, Jess Holle <mailto:je...@ptc.com>> wrote:


To give some further insight:

The enterprise application I work on has been on the market for
over a dozen years now.  The latest version has millions of lines
of code, some portion essentially unchanged in the last 12 years
and some using the very latest Java 7 features and much in
between.  The latest version uses many dozens of libraries ranging
from Java 1.1 era libraries that are no longer maintained to some
that require Java 7.  Requiring that everything jump to some new
version of java.lang or java.util or any such to move to Java 'n'
(or module rev 'n') would postpone any move to Java 'n' (or module
rev 'n') by a long, long time and cause us an enormous amount of
expense that we'd scream at Oracle about for years to come.

Oracle's not stupid -- such a move would be digging their own
grave.  It's not the sort of language or platform evolution their
customers can tolerate.


On 7/19/2012 2:59 PM, Jess Holle wrote:

Note that with something like OSGi juggling multiple versions of
one module within a JVM you still have java.lang.String and
java.lang2.String interoperability issues -- except they both
have the same class name (just different Class objects, different
methods, etc) to add to the confusion.

There's no free lunch here.

On 7/19/2012 2:43 PM, Jess Holle wrote:

P.S. For similar reasons most any open source project with any
brains keeps all old methods and classes around once their APIs
are initially stable -- and moves to an entirely new package
when they find they need to violate this.  That allows use of
old and new APIs in parallel within the same classloader without
any OSGi fanciness.  Breaking API compatibility otherwise is
nasty, user-vicious behavior.  Moving to a new package for Java
classes is a non-starter in most cases -- better to deal with
cruft than to deal with java.lang.String and java.lang2.String
interoperability issues.

On 7/19/2012 2:39 PM, Jess Holle wrote:

The problem is that you then can't move to the latest module
and thus get access to the new APIs anywhere in your JVM
unless/until you expunge all usages of the old APIs from all of
your own millions of lines of code and all of the dozens of
3rd-party libraries you use.

This is a Python 3 schism.  You wouldn't be able to move to the
latest of module X until your whole world was an ivory tower.

This would be a guaranteed reci

Re: Fwd: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

The problem is that you then can't move to the latest module and thus 
get access to the new APIs anywhere in your JVM unless/until you expunge 
all usages of the old APIs from all of your own millions of lines of 
code and all of the dozens of 3rd-party libraries you use.


This is a Python 3 schism.  You wouldn't be able to move to the latest 
of module X until your whole world was an ivory tower.


This would be a guaranteed recipe for all enterprise Java shops to stick 
on whatever release was before this -- forever.  You'd schism the 
community each and every time you produced a new module version.


For similar reasons most any open source project with any brains keeps 
all old methods and classes around once their APIs are initially stable 
-- and moves to an entirely new package when they find they need to 
violate this.  That allows use of old and new APIs in parallel within 
the same classloader without any OSGi fanciness.  Breaking API 
compatibility otherwise is nasty, user-vicious behavior.  Moving to a 
new package for Java classes is a non-starter in most cases -- better to 
deal with cruft than to deal with java.lang.String and java.lang2.String 
interoperability issues.


Note that even with something like OSGi juggling multiple versions of 
one module within a JVM you still have java.lang.String and 
java.lang2.String interoperability issues -- except they both have the 
same class name (just different Class objects, different methods, etc) 
to add to the confusion.


Oracle's not stupid -- such a move would be digging their own grave.  
It's not the sort of language or platform evolution their customers can 
tolerate.


On 7/19/2012 3:20 PM, Kevin Wright wrote:

Oops, copying list...

---

Who's being forced?

You don't specify modules at all and you automatically get the latest 
version of the standard lib modules compatible with java 7 APIs.


You specify LATEST, and you're exposed to changes in API's

You specify exact version numbers, and you're certain that your code 
will compile and run, even against a newer version of java.


People can move at their own pace, however slow that may be, but it 
may also be a fast pace - in which case you'll no longer be held back 
by the demands of backward compatibility all the way to java 1.0


On Jul 19, 2012 8:20 PM, "Jess Holle" <mailto:je...@ptc.com>> wrote:


On 7/19/2012 2:09 PM, Kevin Wright wrote:

And how does simply hiding stuff deal with this "unfortunate" mess:

http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Enumeration.html

No amount of {display: none} in the javadoc CSS will allow those
methods to return an iterator instead, not unless you deprecate
them all and implement new versions with subtly different names,
and that's just one of the more obvious examples!

Just use a wrapper Iterator (with unsupported operation for remove()).

Jigsaw is the *only* way we'll be able to bump up version numbers
and genuinely remove methods or change their signatures.  As you
said, this stuff can be hidden in JavaDoc (hell, ScalaDoc already
does something similar by banishing them to the bottom of the
page:

http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable)

But... That then has to be reimplemented for each and every tool,
in each and every language running on the Java *platform*.  And
it *still* doesn't allow you to change signatures in a
backwardly-compatible fashion.

Ah...  So you're suggesting creating substantially different
(gutted) APIs for new versions of the core library modules,
thereby forcing one to update everything one would use in their
whole JVM process to use the new APIs for that module rather than
old ones in order to use anything (including bug fixes) from the
new module version. That's a complete non-starter as I see it --
that's back to Python 3.0 albeit on a more granular scale. That
would be chaos for anyone with millions of lines of code and many
dozens of 3rd-party libraries in their JVM, i.e. those with large
enterprise applications like many in Java's bread-and-butter
space, including me.

In reality Jigsaw is nothing more than a "move crufty *classes*
into a separate, optional module" solution here.  Changes within a
    class still require all the same API evolution considerations one
had before.  That's life in the real world.

--
Jess Holle


--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/19/2012 2:09 PM, Kevin Wright wrote:

And how does simply hiding stuff deal with this "unfortunate" mess:
http://docs.oracle.com/javase/7/docs/api/java/util/class-use/Enumeration.html

No amount of {display: none} in the javadoc CSS will allow those 
methods to return an iterator instead, not unless you deprecate them 
all and implement new versions with subtly different names, and that's 
just one of the more obvious examples!

Just use a wrapper Iterator (with unsupported operation for remove()).
Jigsaw is the *only* way we'll be able to bump up version numbers and 
genuinely remove methods or change their signatures.  As you said, 
this stuff can be hidden in JavaDoc (hell, ScalaDoc already does 
something similar by banishing them to the bottom of the page: 
http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.Traversable)


But... That then has to be reimplemented for each and every tool, in 
each and every language running on the Java *platform*.  And it 
*still* doesn't allow you to change signatures in a 
backwardly-compatible fashion.
Ah...  So you're suggesting creating substantially different (gutted) 
APIs for new versions of the core library modules, thereby forcing one 
to update everything one would use in their whole JVM process to use the 
new APIs for that module rather than old ones in order to use anything 
(including bug fixes) from the new module version.  That's a complete 
non-starter as I see it -- that's back to Python 3.0 albeit on a more 
granular scale.  That would be chaos for anyone with millions of lines 
of code and many dozens of 3rd-party libraries in their JVM, i.e. those 
with large enterprise applications like many in Java's bread-and-butter 
space, including me.


In reality Jigsaw is nothing more than a "move crufty *classes* into a 
separate, optional module" solution here.  Changes within a class still 
require all the same API evolution considerations one had before.  
That's life in the real world.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

How does adding new default packages remove unfortunate historical methods?

By adding new copied classes without the methods in question? That's not 
a solution as I see it.  By making the new class a base-class of the 
other -- that's not a general solution either due to Java's single 
inheritance model.


On 7/19/2012 1:40 PM, Jan Goyvaerts wrote:

Why not just adding new default packages to replace java.lang & al ?

On Thu, Jul 19, 2012 at 8:37 PM, Jess Holle <mailto:je...@ptc.com>> wrote:


Tweaking Javadoc and IDE support to hide cruft is simple and
effective as compared to having to refactor the entire JVM class
library.  It allows hiding of methods we'd all like to forget,
which Jigsaw can't.  The only other way to remove an undesirable
method is to actually remove it -- and break lots of stuff in the
process. That's pointless.  Just tweak Javadoc and IDEs and move
on -- simple and effective.

Swinging Jigsaw at this misses the icky method issue entirely and
puts far too high a priority on JVM modularity without cause.

As I see it, Jigsaw is primarily for modularizing the rest of the
world in a simple, easy-to-use fashion.  The rest of the stuff
(including modularizing the JVM) could really be put off until
Java 10.


On 7/19/2012 1:19 PM, Kevin Wright wrote:

Not a bad summary.

The thing is, we don't actually *have* a rug yet.  Jigsaw is the
rug, and things get swept under it by simply removing them from
higher-numbered versions of a module.

To do it in Javadoc and IDEs is more akin to "sweeping it under
the furniture".  With the catch that we'd have to build a couple
of new bespoke additions to our existing furniture for this
express purpose.  Try putting a new tenant in the house (e.g.
Scala, or Groovy) with their own furniture, and the whole
exercise has to be repeated.

*This*, to my thinking, is the over-engineered waste of time and
effort.

Java is not just a language, it's a platform.  By forgetting that
and only focussing on their "catch-up" features, Oracle is once
again snubbing the community.


On 19 July 2012 18:57, Jess Holle mailto:je...@ptc.com>> wrote:

No, that's not an accurate paraphrase at all.  I'll try again:

  * Fix and extend the language as appropriate
  o Wherever possible without breaking substantial
amounts of existing code, changing its meaning, etc. 
If you want to go ahead and break all existing code

go somewhere else, e.g. Python 3.
  o Not all extensions are good -- care is obviously
needed to select and shape these in keeping with the
language.
  * Add great /new /APIs.
  * *BUT* do *not* waste any significant time and energy
trying to remove clunky old APIs.

Sweep clunky old APIs under the rug and move on.  That sounds
harsh and sloppy, but that's life in the /real /world.
Anything else is "ivory tower" material *unless *you're
talking about an embedded or mobile environment -- in which
case, yes, jettisoning cruft (or lazily loading it on demand)
is important.  It's a waste of time and energy otherwise. 
Just mark the cruft, hide it in Javadoc and IDEs (with an
ability to easily unhide it, of course), and move on. 
There's no need for the cruft to bother a non-embedded,

non-mobile developer.


On 7/19/2012 12:32 PM, Kevin Wright wrote:

To Paraphrase:

/Don't bother fixing the language, just offload even
more burdens onto the tooling.  Any other attitude is
"Ivory Tower" material/


I couldn't disagree more.  This is the sort of thinking
that, IMO, resulted in the monstrosity we knew and hated as
legacy J2EE, the abuse of SAM types in the swing library,
the Calendar class, and the need for generic parameter
folding in IntelliJ.

Piling yet more levels of over-engineering on a crumbling
foundation is no solution.  Every now and again, the only
sane practice is to have a proper spring clean and simply
take out the trash.

That can't happen until we have versioned modules, just in
case there are folk out there who actually still *want* some
of that trash...


On 19 July 2012 15:51, Jess Holle mailto:je...@ptc.com>> wrote:

On 7/19/2012 9:38 AM, Kevin Wright wrote:

The loss of Jigsaw is massive and significant.  Having
modules, especially versioned modules, is what will
allow the language to evolve.

Sure, it would lead to smaller runtimes, but als

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

Tweaking Javadoc and IDE support to hide cruft is simple and effective 
as compared to having to refactor the entire JVM class library.  It 
allows hiding of methods we'd all like to forget, which Jigsaw can't.  
The only other way to remove an undesirable method is to actually remove 
it -- and break lots of stuff in the process.  That's pointless. Just 
tweak Javadoc and IDEs and move on -- simple and effective.


Swinging Jigsaw at this misses the icky method issue entirely and puts 
far too high a priority on JVM modularity without cause.


As I see it, Jigsaw is primarily for modularizing the rest of the world 
in a simple, easy-to-use fashion.  The rest of the stuff (including 
modularizing the JVM) could really be put off until Java 10.


On 7/19/2012 1:19 PM, Kevin Wright wrote:

Not a bad summary.

The thing is, we don't actually *have* a rug yet.  Jigsaw is the rug, 
and things get swept under it by simply removing them from 
higher-numbered versions of a module.


To do it in Javadoc and IDEs is more akin to "sweeping it under the 
furniture".  With the catch that we'd have to build a couple of new 
bespoke additions to our existing furniture for this express purpose. 
 Try putting a new tenant in the house (e.g. Scala, or Groovy) with 
their own furniture, and the whole exercise has to be repeated.


*This*, to my thinking, is the over-engineered waste of time and effort.

Java is not just a language, it's a platform.  By forgetting that and 
only focussing on their "catch-up" features, Oracle is once again 
snubbing the community.



On 19 July 2012 18:57, Jess Holle <mailto:je...@ptc.com>> wrote:


No, that's not an accurate paraphrase at all.  I'll try again:

  * Fix and extend the language as appropriate
  o Wherever possible without breaking substantial amounts of
existing code, changing its meaning, etc.  If you want to
go ahead and break all existing code go somewhere else,
e.g. Python 3.
  o Not all extensions are good -- care is obviously needed to
select and shape these in keeping with the language.
  * Add great /new /APIs.
  * *BUT* do *not* waste any significant time and energy trying to
remove clunky old APIs.

Sweep clunky old APIs under the rug and move on.  That sounds
harsh and sloppy, but that's life in the /real /world.  Anything
else is "ivory tower" material *unless *you're talking about an
embedded or mobile environment -- in which case, yes, jettisoning
cruft (or lazily loading it on demand) is important.  It's a waste
of time and energy otherwise.  Just mark the cruft, hide it in
Javadoc and IDEs (with an ability to easily unhide it, of course),
and move on.  There's no need for the cruft to bother a
non-embedded, non-mobile developer.


On 7/19/2012 12:32 PM, Kevin Wright wrote:

To Paraphrase:

/Don't bother fixing the language, just offload even more
burdens onto the tooling.  Any other attitude is "Ivory
Tower" material/


I couldn't disagree more.  This is the sort of thinking that,
IMO, resulted in the monstrosity we knew and hated as legacy
J2EE, the abuse of SAM types in the swing library, the Calendar
class, and the need for generic parameter folding in IntelliJ.

Piling yet more levels of over-engineering on a crumbling
foundation is no solution.  Every now and again, the only sane
practice is to have a proper spring clean and simply take out the
trash.

That can't happen until we have versioned modules, just in case
there are folk out there who actually still *want* some of that
trash...


On 19 July 2012 15:51, Jess Holle mailto:je...@ptc.com>> wrote:

On 7/19/2012 9:38 AM, Kevin Wright wrote:

The loss of Jigsaw is massive and significant.  Having
modules, especially versioned modules, is what will allow
the language to evolve.

Sure, it would lead to smaller runtimes, but also to
cleaning up classes where more than half the methods are
deprecated.  It would allow type signatures to be changed.
 It would allow Java to (finally!) drop some of the baggage
that it's been carrying around since before V1.0
I don't see dropping baggage, including methods as relevant. 
This is "ivory tower" material.  It has very, very little

impact on the real world -- unless one just can't deal with
the fact that the real world is not an ivory tower.  The only
thing I believe really should be done here is treatment of
@Deprecated (or a new @Obsolete) annotation in Javadoc to
hide all such methods/classes by default -- and to have IDEs
do the same.  That's it -- just hide the cruft by

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

No, that's not an accurate paraphrase at all.  I'll try again:

 * Fix and extend the language as appropriate
 o Wherever possible without breaking substantial amounts of
   existing code, changing its meaning, etc.  If you want to go
   ahead and break all existing code go somewhere else, e.g. Python 3.
 o Not all extensions are good -- care is obviously needed to
   select and shape these in keeping with the language.
 * Add great /new /APIs.
 * *BUT* do *not* waste any significant time and energy trying to
   remove clunky old APIs.

Sweep clunky old APIs under the rug and move on.  That sounds harsh and 
sloppy, but that's life in the /real /world. Anything else is "ivory 
tower" material *unless *you're talking about an embedded or mobile 
environment -- in which case, yes, jettisoning cruft (or lazily loading 
it on demand) is important.  It's a waste of time and energy otherwise.  
Just mark the cruft, hide it in Javadoc and IDEs (with an ability to 
easily unhide it, of course), and move on.  There's no need for the 
cruft to bother a non-embedded, non-mobile developer.


On 7/19/2012 12:32 PM, Kevin Wright wrote:

To Paraphrase:

/Don't bother fixing the language, just offload even more burdens
onto the tooling.  Any other attitude is "Ivory Tower" material/


I couldn't disagree more.  This is the sort of thinking that, IMO, 
resulted in the monstrosity we knew and hated as legacy J2EE, the 
abuse of SAM types in the swing library, the Calendar class, and the 
need for generic parameter folding in IntelliJ.


Piling yet more levels of over-engineering on a crumbling foundation 
is no solution.  Every now and again, the only sane practice is to 
have a proper spring clean and simply take out the trash.


That can't happen until we have versioned modules, just in case there 
are folk out there who actually still *want* some of that trash...



On 19 July 2012 15:51, Jess Holle <mailto:je...@ptc.com>> wrote:


On 7/19/2012 9:38 AM, Kevin Wright wrote:

The loss of Jigsaw is massive and significant.  Having modules,
especially versioned modules, is what will allow the language to
evolve.

Sure, it would lead to smaller runtimes, but also to cleaning up
classes where more than half the methods are deprecated.  It
would allow type signatures to be changed.  It would allow Java
to (finally!) drop some of the baggage that it's been carrying
around since before V1.0

I don't see dropping baggage, including methods as relevant.  This
is "ivory tower" material.  It has very, very little impact on the
real world -- unless one just can't deal with the fact that the
real world is not an ivory tower. The only thing I believe really
should be done here is treatment of @Deprecated (or a new
@Obsolete) annotation in Javadoc to hide all such methods/classes
by default -- and to have IDEs do the same.  That's it -- just
hide the cruft by default and you can easily forget it's there
(unless you're unreasonably anal even for a software developer).

Having a simple, easy-to-use, integrated modularity solution is
relevant to everyone who hasn't crossed the OSGi chasm.  Actually,
having modularity integrated at the compiler level is relevant to
everyone who doesn't need hotswapping of modules or juggling
multiple versions of the same module in the same JVM (really in
the same classloader, as one can certainly have multiple versions
across web apps in the same JVM without OSGi or any such, for
instance).

--
Jess Holle




--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/19/2012 9:38 AM, Kevin Wright wrote:
The loss of Jigsaw is massive and significant.  Having modules, 
especially versioned modules, is what will allow the language to evolve.


Sure, it would lead to smaller runtimes, but also to cleaning up 
classes where more than half the methods are deprecated.  It would 
allow type signatures to be changed.  It would allow Java to 
(finally!) drop some of the baggage that it's been carrying around 
since before V1.0
I don't see dropping baggage, including methods as relevant.  This is 
"ivory tower" material.  It has very, very little impact on the real 
world -- unless one just can't deal with the fact that the real world is 
not an ivory tower.  The only thing I believe really should be done here 
is treatment of @Deprecated (or a new @Obsolete) annotation in Javadoc 
to hide all such methods/classes by default -- and to have IDEs do the 
same.  That's it -- just hide the cruft by default and you can easily 
forget it's there (unless you're unreasonably anal even for a software 
developer).


Having a simple, easy-to-use, integrated modularity solution is relevant 
to everyone who hasn't crossed the OSGi chasm.  Actually, having 
modularity integrated at the compiler level is relevant to everyone who 
doesn't need hotswapping of modules or juggling multiple versions of the 
same module in the same JVM (really in the same classloader, as one can 
certainly have multiple versions across web apps in the same JVM without 
OSGi or any such, for instance).


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

Agreed.  A simple, unified, compile-time/runtime/language-level module 
system is all I really want from Jigsaw.


Modularizing the JVM and (most silly of all) integrating with 
platform-specific deployment tools (e.g. rpm) are really uninteresting 
to me.  I can see how they're all good things for the long-term health 
and expansion of Java, but those can all be Java 9 or 10 things.  
Simple, integrated modularity is the important thing to get sooner.


On 7/19/2012 8:45 AM, Reinier Zwitserloot wrote:
I'm flabbergasted that this entire thread is lamenting the fact that 
we aren't getting 'smaller JREs' now for java 8.


Like 95% of the rest of the world of java, my java apps tend to be 
long running and tend to be on machines I control, i.e. make the JRE 
2GB for all I care, it just doesn't matter one iota. Bootup can take 
10 seconds too, still don't really care.


But I'm REALLY disappointed (not annoyed; if this is the right call, 
it's the right call. A rushed API is never a good idea): I wanted 
jigsaw for the ability to modularize my projects, and make development 
simpler by just being able to stick my dependencies in a file. A 
unification, of sorts, between the maven idea (build-time dependency 
management) and the OSGi idea (run-time dependency management). I'm 
probably expecting way more of jigsaw than it really is, but you gotta 
start somewhere, and a modularization system that is an intrinsic part 
of the language and which is what the JVM itself is modularized on 
seems like a fantastic start.


On Tuesday, July 17, 2012 8:49:51 PM UTC+2, Mwanji Ezana wrote:

http://mreinhold.org/blog/late-for-the-train


I had just read an interesting practical intro to Jigsaw by Paul
Sandoz, so I'm sad to see it go.

Moandji

--
You received this message because you are subscribed to the Google 
Groups "Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/15vptfPjuvYJ.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Project Jigsaw probably pushed back to Java 9

[Jess Holle]

On 7/19/2012 4:28 AM, Phil Haigh wrote:

Having a large JRE isn't an issue for my server development work...


Agreed.

Jigsaw is lots of things:

1. A simple module system that is really well integrated into the Java
   language, compiler, and runtime
2. A modularization of the JVM itself
3. Removal of classpath configuration
4. Integrations with platform-specific deployment tooling

None of these are really *critical* for Java's current bread-and-butter, 
which is server-side development work, of course.


#1 would be very nice, though -- and I'd love to see just that delivered 
in Java 8, jettisoning the rest as fluff/frosting to be added in Java 
9.  It's unclear, however, how one could be sure the module system is 
adequate and won't need major rework in Java 9 without also tackling #2 
in Java 8, so perhaps one would also need to tackle #2 in part for Java 
8 in this case.


#2, #3 and #4 seem like really, really low priority for server-side 
work.  They are more important in terms of allowing Java to spread 
beyond (or at least not contract to) its bread and butter.  They are key 
for allowing Java SE to be right-sized for lots of other environments.  
They would also apparently be key to any notion of replacing the 
antiquated Java ME with something better -- unless Oracle is simply 
going to concede mobile (including tablets) entirely to Android 
forever.  [Personally I'd think Google and Oracle should actually be 
working /together/ to grow dovetail Android and a right-sized/mobilized 
Java SE in the long term.]  It's a sad statement for Oracle that they 
can't get their act together here before 2015 at the earliest.  As a 
server-side developer, though, I have to say I don't really care /that/ 
much.  Just give me #1.


As for #4, some of the deployment demos we saw at previous JavaOne's 
seemed truly irrelevant.  Cool, but irrelevant.  If time wasted in this 
area has held Jigsaw out of Java 8 that would be a real shame.


Overall, if you *need* modularity today, there's obviously OSGi. If you 
don't *need* it, but it would be nice to have, then you're left torn 
between biting off the complexity of OSGi (it's certainly more complex 
than something integrated into the language, compiler, and JVM runtime) 
and putting modularity off until Oracle gets around to it someday in the 
hazy future (2017 after yet another delay?!?).


--
Jess Holle

P.S. I'm talking about modularity that impacts the /runtime/, of 
course.  One can get /build-time/ modularity in loads of ways, Maven 
being the prime example.


--
You received this message because you are subscribed to the Google Groups "Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Java End of Life Time

[Jess Holle]

Glad to hear that they're not all nuts.

I've seen IT organizations who want to jump on new stuff once there is a 
stable or release label on it (deserved or not) to those firmly in 
category #2.


Frankly I see some of those in category 2 as using risk as an excuse.  
Part of the issue here tends to be that they utterly fail to budget for 
change or plan for it in any way -- failing, for instance, to ensure 
even minimal knowledge transfer/maintenance about the system over time.


On 2/13/2012 5:13 PM, Ricky Clarkson wrote:
My current client is a bank that's too big to fail(tm), and they're 
definitely in the first camp, partly out of fear of not getting 
support when they need it.


On Mon, Feb 13, 2012 at 12:43 PM, Jess Holle <mailto:je...@ptc.com>> wrote:


Is there any sort of an ETA / target release date for a "stable"
Java 7 (including Java Plug-In!) for Mac OS X?

On every other substantive platform (even AIX!) it seems the time
is now right to /require/ Java 7 for new product releases.  Mac OS
X is a boat anchor for the Java community, though.  You end up
either having to cut it loose (i.e. not support it) or it drags
you down and holds you back.

--
Jess Holle

P.S. I suspect any bank that moves from Java 1.4.2 in the near
future will move to Java 6 precisely because it is so old and
proven at this point.  There are 2 types of IT stances: (1) those
that want active maintenance and are thus amenable to (controlled)
change in software they depend upon and (2) those who'd really
prefer something that has entirely stopped changing in any way
whatsoever -- even if that means no maintenance.  Category (1)
includes early adopters but also those who very carefully gauge
when a technology is mature enough to be a trusted replacement for
older versions.  Category (2) includes folk like banks who are so
averse to change that they're deathly afraid of maintenance releases.


On 2/13/2012 9:30 AM, John Yeary wrote:

Ugh!

I wasn't implying that it shouldn't be supported right now. As
Mark, and Andrew pointed out there are some obstacles and
opportunities: "Official" JDK 7 is not available for Mac OSX, and
the user community will likely need support for OpenJDK 6 going
forward.

Denis pointed out that Windows builds are not necessarily being
consumed with vigor. This will likely be the case as the JDK
advances on for  other versions as well.

I am kind of surprised by Andrew though... I find that folks who
are using OpenJDK on RedHat will tend to migrate from old tech to
new tech quickly. ;-)

I think that with limited resources, the folks who are working on
OpenJDK (volunteers not paid) will likely focus on the next
generation stuff. Anecdotal evidence based on experience. It does
open the opportunity for companies to support it in the ecosystem
for older editions. Even back porting changes in 7, 8, 9... if
they will work and improve the user experience.

There are a number of banks who are still on JDK 1.4.2. This
represents a big obstacle to moving forward. Eventually, it will
be a bigger task once they decide to move ahead. Hopefully, the
move won't be to JDK 6. It is like falling up stairs. ;-)

John



John Yeary


<http://javaevangelist.blogspot.com/>
<https://twitter.com/jyeary> <http://www.youtube.com/johnyeary>
<http://www.linkedin.com/in/jyeary>
<https://plus.google.com/112146428878473069965>
<http://www.facebook.com/jyeary>
<http://feeds.feedburner.com/JavaEvangelistJohnYearysBlog>
<http://netbeans.org/people/84414-jyeary>


"Far better it is to dare mighty things, to win glorious
triumphs, even though checkered by failure, than to take rank
with those poor spirits who neither enjoy much nor suffer much,
because they live in the gray twilight that knows not victory nor
defeat."
-- Theodore Roosevelt



On Mon, Feb 13, 2012 at 6:21 AM, Mark Derricutt mailto:m...@talios.com>> wrote:

I'd say we need to support it for the simple reason that Java
7 is not yet available on OSX.

-- 
"Great artists are extremely selfish and arrogant things" —

Steven Wilson, Porcupine Tree

On Sun, Feb 12, 2012 at 3:11 AM, John Yeary
mailto:johnye...@gmail.com>> wrote:

Why would we want to continue to support JDK6 when the
community is focused
on JDK7, JDK8, and JDK9. There may a future in someone
(company) other than
Oracle to provide the support from the OpenJDK side of
things. However, I
think th

Re: [The Java Posse] Re: Java End of Life Time

[Jess Holle]

Is there any sort of an ETA / target release date for a "stable" Java 7 
(including Java Plug-In!) for Mac OS X?


On every other substantive platform (even AIX!) it seems the time is now 
right to /require/ Java 7 for new product releases.  Mac OS X is a boat 
anchor for the Java community, though.  You end up either having to cut 
it loose (i.e. not support it) or it drags you down and holds you back.


--
Jess Holle

P.S. I suspect any bank that moves from Java 1.4.2 in the near future 
will move to Java 6 precisely because it is so old and proven at this 
point.  There are 2 types of IT stances: (1) those that want active 
maintenance and are thus amenable to (controlled) change in software 
they depend upon and (2) those who'd really prefer something that has 
entirely stopped changing in any way whatsoever -- even if that means no 
maintenance.  Category (1) includes early adopters but also those who 
very carefully gauge when a technology is mature enough to be a trusted 
replacement for older versions.  Category (2) includes folk like banks 
who are so averse to change that they're deathly afraid of maintenance 
releases.


On 2/13/2012 9:30 AM, John Yeary wrote:

Ugh!

I wasn't implying that it shouldn't be supported right now. As Mark, 
and Andrew pointed out there are some obstacles and opportunities: 
"Official" JDK 7 is not available for Mac OSX, and the user community 
will likely need support for OpenJDK 6 going forward.


Denis pointed out that Windows builds are not necessarily being 
consumed with vigor. This will likely be the case as the JDK advances 
on for  other versions as well.


I am kind of surprised by Andrew though... I find that folks who are 
using OpenJDK on RedHat will tend to migrate from old tech to new tech 
quickly. ;-)


I think that with limited resources, the folks who are working on 
OpenJDK (volunteers not paid) will likely focus on the next generation 
stuff. Anecdotal evidence based on experience. It does open the 
opportunity for companies to support it in the ecosystem for older 
editions. Even back porting changes in 7, 8, 9... if they will work 
and improve the user experience.


There are a number of banks who are still on JDK 1.4.2. This 
represents a big obstacle to moving forward. Eventually, it will be a 
bigger task once they decide to move ahead. Hopefully, the move won't 
be to JDK 6. It is like falling up stairs. ;-)


John



John Yeary


<http://javaevangelist.blogspot.com/> <https://twitter.com/jyeary> 
<http://www.youtube.com/johnyeary> <http://www.linkedin.com/in/jyeary> 
<https://plus.google.com/112146428878473069965> 
<http://www.facebook.com/jyeary> 
<http://feeds.feedburner.com/JavaEvangelistJohnYearysBlog> 
<http://netbeans.org/people/84414-jyeary>



"Far better it is to dare mighty things, to win glorious triumphs, 
even though checkered by failure, than to take rank with those poor 
spirits who neither enjoy much nor suffer much, because they live in 
the gray twilight that knows not victory nor defeat."

-- Theodore Roosevelt



On Mon, Feb 13, 2012 at 6:21 AM, Mark Derricutt <mailto:m...@talios.com>> wrote:


I'd say we need to support it for the simple reason that Java 7 is
not yet available on OSX.

-- 
"Great artists are extremely selfish and arrogant things" — Steven

Wilson, Porcupine Tree

On Sun, Feb 12, 2012 at 3:11 AM, John Yeary mailto:johnye...@gmail.com>> wrote:

Why would we want to continue to support JDK6 when the
community is focused
on JDK7, JDK8, and JDK9. There may a future in someone
(company) other than
Oracle to provide the support from the OpenJDK side of things.
However, I
think that the focus should be on getting companied to stay
current.



--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Java 7 FUBAR'D?

[Jess Holle]

I believe the loop bug was fixed -- unofficially in Update 1 and 
officially in Update 2.


I've noticed a few minor glitches in old UIs run under Java 7, but not 
investigated further, as it wasn't until Update 2 that I took Java 7 
seriously.


On 1/26/2012 5:26 AM, Steel City Phantom wrote:
last i heard of java 7, the loop bug was still an issue and the 
overall opinion was it wasn't ready for a production environment.  but 
that information was as of a few months ago, it may have changed since 
then.  i know that for my client, im recommending staying with java 6 
in production until our next generation systems are ready, sometime in 
2013.


On Thu, Jan 26, 2012 at 4:41 AM, Robin > wrote:


Hi all,

The company I work at deploys a webstarted java client to about 200
customers. We initially developed on Java 5 back in 2004 and migrated
our customer base to Java 6 when that became available. For the most
part customers were fine with this as we made the final cut off match
the EOL for Java 5 anyway, my point being we generally adopt the newer
versions as they become available. Java 6 EOL in July 2012 is rapidly
approaching (http://www.oracle.com/technetwork/java/eol-135779.html)
and although we've worked to make the changes need we keep seeing new
issues. I'd think it might just be us but Oracle don't seem to be
pushing Java 7 out in the updates (I got Java 6u30 in the latest
update) so it seems they maybe aren't confident it's ready for prime
time.

Is anyone else seeing this? Is anyone thinking moving customers (or
themselves if server side) to Java 7 is going to be a mistake right
now?

--
You received this message because you are subscribed to the Google
Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
You want it fast, cheap, or right.  Pick two!!
--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Addicted to Scala - I hate the Java Posse!

[Jess Holle]

The closest thing I've found to a real-world usage for "normal" AOP was 
temporary debugger-like pointcuts via AspectJ.


By "normal" I mean via AspectJ, XML, or the like.

Targeted byte-code weaving via ASM is daunting, but truly useful in very 
limited cases.


On 12/20/2011 5:28 PM, Kevin Wright wrote:



In general though I distrust and avoid AOP -- until it's really
the only alternative.


I have yet to see either a theoretical or real-world usage of AOP 
where it's not just a hack to deal with the lack of first-class & 
higher-kinded functions.


Bring on the closures and method handles already, then it'll *never* 
be the only alternative!


Or, if impatient, just use groovy/scala/clojure/jruby/mirah.  If 
you've gone AOP then you're already using a different language, either 
AspectJ or - far, far worse - XML [1].  Seeing as you're flipping 
language anyway, at least flip to a decent one :)



[1] e.g. defining pointcuts in Spring


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Addicted to Scala - I hate the Java Posse!

[Jess Holle]

On 12/20/2011 4:15 PM, Kevin Wright wrote:

No need to be so disparaging!

It's not just about logging, AOP is used for database transactions as 
well...
And performance profiling / instrumentation via byte-code weaving (ala 
ASM, AspectJ, etc, being too heavy), especially to code you don't own 
(e.g. JVM internals).


In general though I distrust and avoid AOP -- until it's really the only 
alternative.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Addicted to Scala - I hate the Java Posse!

[Jess Holle]

On 12/20/2011 2:22 PM, Alex Turner wrote:

I could ask what's wrong with AOP, but you're probably thinking about
the same as me on that one.  I like to call code like that "god"
code.  It's the hidden mysterious force that can really screw things
up without almost anyone knowing where it came from and why, or being
able to fathom it's intention.  Sometimes though - a little divine
intervention is handy :D
Agreed.  I hate the idea of doing AOP when there's a more easily 
understood and maintainable alternative or of 99% of developers in an 
organization of any size doing/seeing any AOP.


Sometimes, however, there's a place for a few engineers to write "god" 
code that is nicely tucked away and does what needs to be done and can't 
be done as well any way but AOP.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Java One or Java ho-hum

[Jess Holle]

I had even worse issues last year.

I couldn't find anything (apart from places with /really/ scary reviews) 
less than $400 or $500 per night.  I'd never had such an issue with any 
previous Java One, having always managed to stay in the parc 55, francis 
drake, or other nice places.  Even decent corporate travel policies have 
their limits.


I ended up in downtown Oakland.  It worked pretty well thanks to the 
train, but it seemed rather silly given that Oracle could have saved 
everyone the trouble by not having Java One and Open World at the same time.


On 10/24/2011 3:03 PM, Carl of the Posse wrote:
To defend Dick a bit: I was the one who booked our rooms. I checked 
the links through the conference and also via Orbitz, and saw prices 
in the many hundreds per day. Some were $1000+, but I guess there are 
always a few of those.


For us, $300+ per night per person was a bit out of our budget--we 
don't have a big revenue stream :). So our $130 per night via Orbitz 
seemed like a good deal at the time. Maybe I failed in getting to the 
conference pricing: I'll try harder to use that next year.



--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/javaposse/-/NfGy3O14vZMJ.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Fork/Join criticism

[Jess Holle]

The alternative to inheritance is general object composition -- which 
allows each of the objects to be strewn all of the heap with respect to 
one another.


Inheritance, however, stuffs all the fields into 1 bucket that all moves 
together.


Object fields are pointers to elsewhere in the heap in any case, of 
course.  I'm talking about primitives.


On 10/21/2011 4:56 AM, ricky.clark...@gmail.com wrote:
I haven't followed this very well but can you explain how inheritance 
makes F/J not cause cache flushes?


Sent from my BlackBerry® wireless device


*From: * Kirk 
*Sender: * javaposse@googlegroups.com
*Date: *Fri, 21 Oct 2011 10:41:51 +0200
*To: *Ray Hindman
*ReplyTo: * javaposse@googlegroups.com
*Subject: *Re: [The Java Posse] Re: Fork/Join criticism

Hi,

I can only comment on the use of Unsafe and inheritance and 
performance. There are cases, and F/J is most likely one of them, 
where inheritance could be a win. Getting separation putting memory 
distance between shared an non-shared variables can result in them 
being place in difference cache lines. That can have the effect of 
prevent multi-thread access from causes each thread to cause the other 
threads to continuously flush their cache. Cache flushing can be a 
huge drain on performance.


Until we get a normalized path to CAS that is baked into the JMM or 
Java Language Specification, we're stuck with unsafe.


Regards,
Kirk

On Oct 21, 2011, at 7:49 AM, Reinier Zwitserloot wrote:


I can retort a few of these, but certainly not all of it.

--Exceedingly Complex--

Yes, but, complaining that F/J (ab)uses com.sun.misc.Unsafe is just 
stupid, in my opinion. The whole point of F/J is that _it_ abstracts 
away the considerable complexity inherent in aggressively efficient 
multicore usage so that the code written using the F/J framework is 
simple. Also, a framework like F/J is one of the few times you 
actually get to adopt the maxim "Micro-optimize this stuff to pieces, 
I don't care if the code becomes far more difficult to manage going 
forward". That's what core frameworks have to do to get the job done. 
For example, quite a few code in Math is very, lets be nice and say 
'uniquely' written, i.e, complete gobbledygook with a comment 9x as 
large as the method explaining the arcane voodoo magicks going on, 
but, nobody should be complaining about this. Math is complex so your 
code doesn't have to be.


Why is F/J such as a mess of inheritance? Yeah, well, I kinda agree 
with the ranter on that one. inheritance isn't, as far as I know, a 
clear win for performance (the opposite, usually), and I doubt it 
makes the API any cleaner either.


--Unstable--

We have but the word of our ranter. The fact that F/J has a long 
history of tickets, assuming they've all been fixed, doesn't really 
say much about how unstable this piece of software is. All software 
has bugs, a project that carefully maintains a list and is open to 
3rd party tickets shouldn't be punished for that. Let's flip it 
around: If F/J did not have an extensive bug list, would that mean it 
IS stable? That's clearly a silly argument.


Multicore is inherently complicated, though outsiders usually think 
"Geez, this has got to be much, much simpler than these supposed 
rocket scientists are making it!". Guess what? Only outsiders hold 
that view. Once you tussle with trying to write efficient multi-core 
code that works on all platforms and acts consistently, you start to 
agree that it's just that complicated, period.


--Lack of attributes--

A lot of these I just don't follow at all. What does this mean?: 
"There is no error detection/recovery/reporting (other then thrown 
exceptions)"? What kind of detection/recovery/reporting should F/J be 
doing? It's core CPU work, errors at this level are invariably 
unrecoverable and highly unexpected (your CPU or OS is buggy, or the 
framework is), unless the cause is a bug in hosted code, but 
propagating exceptions back out of the fork/join workers is exactly 
how a library is supposed to handle this, so what's the complaint 
again? I don't understand.


Stall detection, anomaly detection, and performance monitoring is 
nice, but, I'm kind of at a loss in regards to the flow of the rant. 
First the argument is that this should be simpler, then the argument 
turns into: But it's missing all these possible but quite complicated 
features. Which way is it?


--Academic exercise--

This stuff is beyond my comprehension, unfortunately.

--Inadequate in scope--

F/J working on either J2ME or an EE virtual server buit around RMIing 
calls around the server park? Come on, that's a preposterous idea. It 
would be nice, but, so are unicorns.



Didn't feel like going further into it today.


--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/jav

Re: [The Java Posse] Patent Wars reach new low - Microsoft and Nokia make desperate jackass move.

[Jess Holle]

As per the recent This American Life episode, some of the most famous 
patent trolling companies spin out shell companies [or sell the patent 
to another company working essentially as a subcontractor with a portion 
of all patent revenue going to each party] in cases to lessen their own 
reputation for trolling.


It all stinks.

On 9/2/2011 9:20 AM, Fabrizio Giudici wrote:

On 09/02/2011 03:19 PM, Kirk wrote:
Brilliant because now MS and Nokia no longer take the pr hit for 
patent trolling.. awesome

Yep. It's like to outsource credit recovery to The Sopranos.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] -Xmx is hurting java

[Jess Holle]

It's just like the pre-OS-X Mac OS in this regard :-)

Though I can understand why it is hard to avoid -Xmx for various GC 
algorithms whereas the pre-OS-X Mac OS really had no excuse.


On 8/12/2011 7:48 AM, phil swenson wrote:

http://eblog.chrononsystems.com/xmx-is-hurting-the-usability-of-java

I've been saying this since I first discovered the terrible
OutOfMemoryException in 1999.  Xmx makes java inherently unstable.
You can't rely on your app to stay up until you find the magic Xmx
setting.  WTF!?

Dick/Carl/Tor/Joe - when you talk to Mark Reinnhold, can you bring this up?



--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Are there any techie SUPPORTERS of software patents left?

[Jess Holle]

Until the patent office can figure out how to judge real innovation and 
uniqueness in a software patent it should stop issuing any.  They should 
also declare that existing software patents are suspect and set a very 
high burden of proof for any to retain their legitimacy.  The patent 
office and/or courts could then invalidate 99+% of all existing software 
patents.


Whether there are any sufficiently innovating and unique items to 
deserve a patent in this area is an open question.  However, the vast 
majority of software patents that come up in lawsuits, etc, are broad, 
non-nonsensical land grabs of vast conceptual spaces without any 
evidence of originality of thought.  These should clearly be invalidated.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Java7 and loops - Before FUD gets out of hand...

[Jess Holle]

On 8/9/2011 3:46 PM, Casper Bang wrote:

Now with 1.7 it's once again unusable - remarkably, incremental
loading of rows when visualizing table data is all screwed up. So I
have to keep JDK 1.6 only to run SQLDeveloper.  It's irritating
because that's a program from the same company that now provides JDK,
so it looks like an ugly case of left hand not knowing what the right
hand does. It's not a recent bug from the very latest JDK 7 builds; I
noticed the problem months ago, so they just didn't test during the
beta period, or didn't care.

It's interesting that SQLDeveloper always does version checking and
warns users of potential problems, it kind of says something about the
developers lack of trust in binary backwards compatibility of the Java
platform. However, what REALLY bothers me about SQLDeveloper, is how
it always freezes when you loose a connection over VPN, or just keep
it open for more than an hour or so.
Or that if you click on the wrong thing (the dreaded "Data" tab), you'll 
get an OutOfMemoryError as it tries to bring the entirety of the data 
table into memory -- without regard for how big the table is or how 
little memory you have...


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Java7 and loops - Before FUD gets out of hand...

[Jess Holle]

I don't think one should discount the possibility of bugs in the JIT 
compiler uncovered by Lucene having a much broader impact in other 
production code that hasn't yet been run for long periods of time on 
Java 7.  Just because something runs on Java 7 for an hour or two isn't 
sufficient -- we've seen JIT bugs surface [1] that require days of 
execution to get enough passes through critical code to JIT it to the 
point of breakage.


Bugs in the JIT compiler should be taken extremely seriously.  Crashes, 
poor performance, etc, are not nearly as big of a deal as quietly and 
mysteriously incorrect results.


Oracle had 5 days to change the default value of the optimization flag 
in question -- and I believe they should have done just that.  If I 
wanted a JVM where I had to flip a bunch of knobs just to get it to run 
correctly I'd use IBM's JVM.


--
Jess Holle

[1] This was in Tomcat and due to a JIT bug involving String.indexOf() 
optimization on some Intel hardware that occurs from Java 6 Update 18 
through 23.


On 8/3/2011 10:17 AM, Robert Casto wrote:
And why should Oracle have to worry about what the Lucene guys are 
doing anyway. Now that they know about the bug they will test for it. 
But they can't be expected to test every piece of software out there 
that runs on Java. The Lucene guys should have tested against Java7 
long ago and seen this issue and reported it or worked around it. I'm 
just glad that a new version is out and I can't wait for Java8 and 
hopefully get some long awaited for features, better date library, and 
much more. With a great Java8 release, Java as a language will have a 
long life ahead.


On Wed, Aug 3, 2011 at 11:05 AM, Kirk <mailto:kirk.pepperd...@gmail.com>> wrote:


I don't think this is a denial of the bug, it's just that out of
the blocks there is a huge amount of FUD about a problem that the
Lucene guys could have looked at quite a while ago.

Regards,
Kirk

On Aug 3, 2011, at 12:03 AM, Mark Derricutt wrote:


If it was just "a broken lucene" then maybe, but this revealed
bugs in Hotspot itself.

I'd be curious to know how/why these bugs never revealed
themselves earlier in whatever tests hotspot currently has, and
whether or not any test cases have since been added to cover this
now.

Mark


On 3/08/2011, at 9:11 AM, Kirk wrote:


Bottom line, everyone knew it was coming the builds were
freely avaliable. I've been using 7 on my Mac for months so
I don't have much sympathy in this case.



-- 
You received this message because you are subscribed to the

Google Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse+unsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.


-- 
You received this message because you are subscribed to the Google

Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Robert Casto
www.robertcasto.com <http://www.robertcasto.com>
www.sellerstoolbox.com <http://www.sellerstoolbox.com>
--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] JDK7 loop compilation bugs ?

[Jess Holle]

I really don't like that Oracle knew about this and released anyway 
(even if it were only hours prior to the release) -- without making


  -XX:-UseLoopPredicate

the default.

It's better not to release on time than to release something that 
customers don't trust.


Having to add JVM options just to get a JVM to work correctly is a 
non-starter.  That's the sort of thing I expect from IBM JVMs -- and 
detest them for.  The default mode of the JVM should be correct and 
stable -- with -XX:+UseLoopPredicate, etc, allowing those most desperate 
for speed to live dangerously on their own time.


On 7/29/2011 5:05 PM, Mark Derricutt wrote:

Yes, but you can work around it by using:

  -XX:-UseLoopPredicate

I'm getting tired already of seeing many sites ranting about this bug without 
mentioning the work around described in the actual Oracle bug tickets.

The tests that actually uncovered the problems were only written last month:

   https://issues.apache.org/jira/browse/LUCENE-3079

I've not looked at the tests/patches yet but I'm curious as to what they're 
doing that managed to uncover this problem, and just how likely it is to hit in 
normal day-to-day code that no other tests fails/hit it.

Mark



On 30/07/2011, at 1:10 AM, Michael Barker wrote:


It's annoying, I was hoping to drop it into our CI environment next week...




--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Spring's Rod Johnson on OSGi

[Jess Holle]

But that still leaves open the question as to whether the right solution 
is to provide more tooling for OSGi or something simpler and possibly 
better integrated with the language, e.g. Jigsaw.


On one of the point items I have to agree with the Posse -- if you get 
to the point where you want different versions of the same library being 
loaded at the same time, then that's generally a sign that your overall 
dependency management has gotten out of control or that some modules are 
not being adequately maintained.  Sure, in some rare cases such a need 
will occur, I've seen it -- but I'd be loathe to add complexity to >98% 
of development for the <2% problem.


On 6/24/2011 9:44 AM, Neil Bartlett wrote:

Rod's message is a fair bit more nuanced than the headlines and
soundbites would suggest. He said that OSGi productivity is low
compared to "traditional" Java development, and it may surprise you to
hear that I agree with him on that point... currently.

However I don't consider that a reason for giving up on the goal of
building modular software. I and several others believe that OSGi can
actually be made *MORE* productive than non-OSGi development, and we
intend to prove it by building the tools that SpringSource failed to
build.

I do think that SpringSource could have solved this problem as well,
but they chose to focus on products like tcServer that were easier to
sell and provided faster profits. Actually this created opportunities
for smaller companies so ultimately I'm grateful to them.

Neil

On Jun 23, 9:22 pm, phil swenson  wrote:

http://www.theserverside.com/news/2240037102/OSGi-Not-Easy-Enough-to-...

"We have changed our views on OSGi over the years, and one of the
reasons for that is that OSGi simply cannot be made as easy to use and
as productive as we feel is consistent with Spring values."

"Niche"


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JavaDoc due for an overhaul

[Jess Holle]

Javadoc does seem really hard to make any reasonable use of without 
search for anything of size.


A nice integration with Lucene/Solr would seem to be in order...

On 6/21/2011 8:53 PM, phil swenson wrote:

where's my search? ;)

On Tue, Jun 21, 2011 at 4:13 PM, Steven Herod  wrote:

New style sheet in action:  http://download.java.net/jdk7/docs/api/



On Jun 4, 11:10 am, Reinier Zwitserloot  wrote:

The link ishttp://blogs.oracle.com/jjg/entry/what_s_up_javadoc- somehow a
space got lost there. Just in case anyone didn't figure that out :)

Thanks for the link, robilad!

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.




--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: James Gosling vs. Java 1.4.2

[Jess Holle]

Hmm...

No user benefits like greatly improved JVM performance between 1.4.2 and 
1.6?


On 5/30/2011 10:24 PM, Steven Herod wrote:

The opposition to moving beyond 1.4.x would be mainly the cost.

You have a working application which is stable, you are expending
minimal effort maintaining, and suddenly someone is proposing you
spend effort/cash to give developers a warm fuzzy feeling and the end
user no actual visible benefit.

Hard to justify.  Easier to wait until the app is retired.

On May 30, 9:57 pm, Ricky Clarkson  wrote:

The semantics are pretty clear, as you get compile errors when you get
things wrong.

Java developers *were* used to unsafe casts.  I'm regularly in ##java
on freenode IRC and see fewer and fewer people trying to use untyped
collections.  It still happens, though mainly by accident.

I've seen some new Java code using untyped Vectors and Hashtables
recently, but a) the [ir]responsible developers just left b) that
would have happened no matter what Java had done short of removing
Vector and Hashtable.

--
Skype: ricky_clarkson
UK phone (forwards to Skype): 0161 408 5260







On Mon, May 30, 2011 at 1:13 AM, Casper Bang  wrote:

It's quite elegant that in general if I update a dependency and that
dependency has switched from raw types to generics, I generally have
nothing to do.  With the .NET approach I would have to marshal between
old and new collection types constantly.

Yes but at least the semantics would be clear up front right there in
the type-system and you'd avoid various pitfalls (Java developers are
used to unsafe casts and unsafe array variance) as well as pave the
way for a deprecation/migration strategy. Sometimes something must die
in order to leave the way for something new, or all we get are zombies.
--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group 
athttp://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Gavin King: A new language and SDK designed to replace Java in the enterprise

[Jess Holle]

On 4/13/2011 8:42 PM, Alan Kent wrote:
Scala has some cool looking features, but maybe its because I jump 
between so many projects and don't stick with any particular code base 
for so long, all the DSL like stuff in Scala puts me off.
This is what really put me off with Ceylon -- too much DSL-like stuff 
that I really had to work hard to mentally parse in large part because 
different things were so similar in syntax it took a lot of effort to 
figure out which one was being done by a particular chunk of code.


Also := is a really annoying assignment operator...

--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Gavin King: A new language and SDK designed to replace Java in the enterprise

[Jess Holle]

The only thing that Ceylon seems to have going for it is somewhat closer 
affinity to Java syntax than Scala.


Still Scala's got real momentum and has been shaped by lots of real 
world usage.  Do I wish it was more C/Java-like in syntax?  Absolutely 
-- I think it'd be taking over in force if it was.  Even so, I don't see 
why a half-baked, unfinished project that's been languishing for 2 years 
should jump ahead of Scala.


--
Jess Holle

On 4/13/2011 9:55 AM, Joseph Ottinger wrote:

2011/4/13 Cédric Beust ♔:

Another thing that puzzles me about Ceylon is the timing: Gavin says that he
and his team have been working on it for two years and yet they don't even
have a prototype to show. Reaching such a stage should take a few months to
one programmer.

Especially when all you *really* need to do is rename scala to
Ceylon... or, heck, just use COBOL. I guess my main confusion around
Ceylon is who needs it.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: McNealy says with Apple takeover, he would have 'screwed up' iphone and iPad

[Jess Holle]

On 2/28/2011 9:43 AM, Casper Bang wrote:

That's probably a bit of an optimistic interpretation, given how they
allowed AMD to dominate for so long all the way into the profitable
server segment (i.e. Oracle recommended Opteron rather than Xeon).
Itanium was more of the sensible parallel diversification line you
have in mind, which was buried for more mundane backwards
compatibility reasons.
I believe it was buried on technical grounds as an alternate parallel 
attempt that happened to dead-end, as much as for backwards 
compatibility reasons.  Itanium was better termed Itanic as in 
"Titanic".  While the chip contained many interesting technologies, the 
whole added up to something that even the best compilers seemed to get 
very little real value from.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: #340: various comments

[Jess Holle]

Google missed an opportunity -- they should have bought the rights to 
call it the Dalek virtual machine (ala Doctor Who) :-)


On 2/14/2011 1:03 PM, mezmo wrote:

I stand corrected.
Thanks!


On Feb 14, 10:52 am, Cédric Beust ♔  wrote:

It's Dalvik, by the way (a small village in Iceland where, contrary to a
widespread rumor, the author of the VM had never set foot before naming the
virtual machine after it :-)).

--
Cédric



On Mon, Feb 14, 2011 at 6:55 AM, mezmo  wrote:

I just want to get something off my chest about Joe's continued
confusion about the Sun/Microsoft suit and how Dalvek is different.
Microsoft was adding keywords, adding classes to the standard java
libraries, and refusing to support RMI and JNI, adding some custom
classes in the java.namespace to do similar things with COM. Plus they
wanted Sun to thank them for it and allow them to still call it Java.
Google with Dalvek on the other hand has gone out of its way to make
sure that everyone knows that Dalvek is not Java. It doesn't directly
run plain Java bytecode, and if there is a java.* class anywhere it
does pretty much exactly what the original did. For non-standard
extensions, those are in clearly marked android.* packages, which I
personally believe if Microsoft had done, Sun wouldn't have had nearly
as strong a case as they did.
--
You received this message because you are subscribed to the Google Groups
"The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.

--
Cédric


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Mac vs. Java: Nothing to see here, move along: Eclipse and NetBeans run just fine on OpenJDK.

[Jess Holle]

This is simple: Apple figures that 1 of the 2 options is true.  If 1, 
then they should kill it.  If 2, then they shouldn't waste money on it.  
I don't see how Apple sees an upside to spending any money supporting 
Java on the Mac -- given that they want everything other than native, 
platform-specific Cocoa development in C/C++/Objective C and HTML 5 off 
their platforms.


On 10/29/2010 11:55 AM, Serge Boulay wrote:

"2. Java Desktop will never be a threat. It makes sense for apple to
stop spending the resources on keeping it up to date."

Isn't it a drop in the bucket for a company that has close to 50 
billion dollars in the bank to keep Java alive on the Mac?


On Fri, Oct 29, 2010 at 8:49 AM, Reinier Zwitserloot 
mailto:reini...@gmail.com>> wrote:


No, your argument does not make sense.

Java Desktop is no threat today. Right. But, this isn't just about
today, it's about the future. Two options:

1. Java Desktop becomes a threat. It makes sense for apple to stop
this in its tracks.

2. Java Desktop will never be a threat. It makes sense for apple to
stop spending the resources on keeping it up to date.

They are only alienating developers because certain oblivious
developers have reacted to this news in blind panic, instead of
thinking it through. Teaches Apple right for thinking developers
aren't susceptible to mass hysteria.

I'd be pissed if Apple is indeed shooting for option #1 here, but I'm
guessing it's purely about the resources. Especially with the new app
store stuff, they are taking on a very large role in quality
assurance. If the app doesn't work as advertised, apple gets a
significant chunk of the negative marketing. As well as the support
call and the refund request. I'm not entirely sure this line of
reasoning makes much sense (bugs happen, you can't stop them all), but
a basic rule that all platforms you support are built to be as robust
as you can is a good rule to have, and I'm guessing Apple does not see
the java platform (for client side apps) worth maintaining at that
level.

On Oct 28, 8:42 pm, Rob Ross mailto:rob.r...@gmail.com>> wrote:
> On Oct 28, 2010, at 9:54 AM, Cédric Beust ♔ wrote:
>
>
>
> > On Thu, Oct 28, 2010 at 3:01 AM, Reinier Zwitserloot
mailto:reini...@gmail.com>> wrote:
> > You're misrepresenting what apple is doing (or misunderstanding).
> > Apple isn't trying to bash java
>
> > Steve Jobs in 2007:
>
> > “Java’s not worth building in. Nobody uses Java anymore. It’s
this big heavyweight ball and chain.”
>
> > Your other points still hold, though. Apple thinks that Java
sucks *and* that it threatens their business model, hence the
current decision to stop providing it. The decision makes business
sense.
>
> > --
> > Cédric
>
> On further analysis, it really does *not* make sense.
>
> As has been clearly shouted from almost every rooftop in the
land, Java Desktop never became a successful toolkit for building
& running consumer desktop apps. Even I, who love Swing dearly and
spend most of my time writing Swing apps, will agree to this.
>
> If that's the case, exactly *what* threat does Java currently
pose for the consumer desktop, specifically Apple's desktop?
>
> 1. Are they worried Java desktop apps are competing with native
Cocoa apps? No, that can't be, as we've just agreed Java is not
used to write desktop apps. It's *no* threat in that space.
>
> 2. Are they worried that Java *will* become successful on the
desktop? If so, isn't that an implicit endorsement that Java is a
formidable foe in that space?
>
> Which one is it?
>
> If it's #1, then they have clearly made a strategic mistake by
alienating hundreds of thousands (millions?) of developers who
enjoy using Apple hardware for Java development, and were never
going to compete with Apple by writing Java desktop apps.
>
> If it's #2, then I say all the more reason for the community to
create a better native JDK for the Apple platform and kick their
butt in the marketplace!
>
> Rob

--
You received this message because you are subscribed to the Google
Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visi

Re: [The Java Posse] Re: Email from Jobs re Java on OS-X

[Jess Holle]

On 10/28/2010 11:11 AM, phil swenson wrote:

Your recourse would be to sell mac apps directly rather than the app
store, this is allowed on the Mac app store model.  This is how I
think the iPhone should work too.  It's ridiculous that the app store
is the only distribution method.
I'd guess that Apple will try very hard to push everyone on the Mac to 
the app store over time.


Yes, they'll probably /allow/ other distribution methods for a long time 
to come -- but they'll also try to convince customers that the only 
safe, easy way to get apps is from their store, to convince software 
vendors that this is the only way to be a first-class app on the 
platform, etc.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Mac vs. Java: Nothing to see here, move along: Eclipse and NetBeans run just fine on OpenJDK.

[Jess Holle]

Realistically, I think serious Java developers who use Macs are going to 
have to dual-boot into Windows or Linux -- at least if they're doing 
anything that's not strictly server-side.


That's what every Mac owner wanted anyway, a really cute machine running 
Linux, right?  :-|


On 10/27/2010 6:07 AM, Mark Volkmann wrote:

On Wed, Oct 27, 2010 at 4:09 AM, Neil Bartlett  wrote:

Fabrizio,

Wrong and wrong again.

First, 90% of Java developers do not use Swing or AWT.

I question that percentage. Maybe my company is an exception, but we
have had and continue to have many consulting projects that use Swing.
I'm working on two Swing applications for a client right now. They
both involve heavy use of JTables with custom table models.

I do my development on a Mac and deliver double-clickable JAR files to
users that run them under Windows.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Microsoft cuts loose Iron languages

[Jess Holle]

Or that those using them aren't the target market?

Microsoft and Oracle are both most interested in languages and tools 
they themselves would like to use to develop products.  Oracle's not 
about to develop the next generation Fusion product in Groovy, Ruby, or 
Python.  Similarly, Microsoft is not about to develop the next version 
of any of their products in such a language.  Oracle's going to do C/C++ 
for the database and Java for most everything else.  Microsoft will be 
doing C/C++ for the lower OS levels and more C# for some of the 
higher-level stuff -- but not Ruby, Python, or the like.


For both companies most of their big customers follow similar trends for 
their big, mission-critical stuff.


That's not a rip (or RIP) on dynamic languages overall, but the market 
really is not jumping on them for developing products in the same spaces 
as Oracle and Microsoft's products nor for as the foundation of large, 
mission-critical apps.


--
Jess Holle

On 10/24/2010 11:43 AM, Fabrizio Giudici wrote:

On 10/24/2010 04:17 AM, hugh4life wrote:


On Oct 23, 6:48 pm, Miroslav Pokorny
wrote:
Funny a multi billion company like Microsoft cant afford the salary 
of half
a dozen developers to keep the Iron family of languages alive so 
their CLR

moniker has some substanc
So... Oracle decided not to directly support dynamic languages 
including their IDEs; Microsoft is doing the same. Doesn't this smell 
enough as the fact that there's just a few guys using them, not enough 
to make them interesting?


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Email from Jobs re Java on OS-X

[Jess Holle]

The Mac is becoming nothing but a big iPhone (without the phone or touch 
capabilities) for your desk.  It's no longer a general computing 
platform -- it's becoming just another form factor for an utterly closed 
consumer device with a walled garden market.


I don't think Apple wants Java on it any more than they want it on the 
iPhone -- and it's unclear whether it is worth Oracle's while to fight this.


Sure we all want Java to be ubiquitous.  But when a vendor goes this far 
to drive everyone else off their platforms and, unlike Microsoft, does 
not dominate desktop computing, how far do you go?


Perhaps there's a backroom deal floating that will come to light soon, 
but it really sounds like any attempts at such a deal just plain fell apart.


On 10/22/2010 6:43 AM, CKoerner wrote:

Its time for Oracle to step up to ITS responsibility and make the JVM
for the Mac. If they do it for Linux and Windows then they damn well
should do it for the MAC.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Martin Odersky says: Skills required

[Jess Holle]

 On 9/28/2010 7:27 AM, Ricky Clarkson wrote:

A language that makes it harder to build up large broken codebases is
needed.  E.g., in Swing, it's really hard to unpick an evolved large
program that does concurrency wrong without breaking bits, whereas
.NET throws an exception if you instantiate a component on the wrong
thread, making that particular screwup impossible (unless you never
test the code and just keep growing it instead).
This is a truly silly issue with Swing.  The Swing team has argued in 
forums, BOFs, etc, that one should use AOP or other approaches to add 
assertions to Swing that things are done on the appropriate thread.  
That's a royal cop out.  No one other than the Swing team truly knows 
precisely which things must always be done on a particular thread -- and 
it therefore *must* be their job to add appropriate assertions to this 
effect.  I understand Sun was in a financial bind for the last few years 
-- that would have been an honest answer to the plea for such assertions 
in Swing.  It clearly must be done and must be done by the Swing team, 
though.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JavaFX script to be dropped, JavaFX 2.0 will be an API on the JVM, usable from Java

[Jess Holle]

 My read on this answer was that you'd be best finding something else 
to spend your time on until around March/April 2011 -- at which point FX 
/may /be worth revisiting in an early access capacity.


If that's at the top of your "to-do" list, then that's a pickle :-)

--
Jess Holle

On 9/23/2010 10:14 PM, Josh Juneau wrote:

I attended JavaFX 2.0 session today and someone asked what to do if
their company wanted to start a javafx project on Monday.  No really
good answer to that since fx script will be of no use once 2.0
arrives. The fx team said that fx script is open source and could be
brought forward, but after evaluation Oracle decided that it would
take too many hours to bring forward to the new API.

On the contrary, I like the idea of using JRuby, Jython, Groovy, or
the like for developing with the new API.



On 9/23/10, Jo Voordeckers  wrote:

Most sessions are using the JavaFX Script 1.3 syntax, some sessions by
Oracle employees show an early version of the upcoming JavaFX Java APIs, but
these are very likely to change before they'll be published in early access
(Q1 or Q2 2011).

On Thu, Sep 23, 2010 at 8:57 PM, Jan Goyvaerts™
wrote:


I was wondering about the other JavaFX sessions at JavaOne: Do they still
present something with the script syntax ? (If so, who would still go
there
?) Or are they all about the to-be-expected API ?

--
You received this message because you are subscribed to the Google Groups
"The Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
- Jo

--
You received this message because you are subscribed to the Google Groups
"The Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JavaFX script to be dropped, JavaFX 2.0 will be an API on the JVM, usable from Java

[Jess Holle]

 Sun?  Who/where's Sun?  There is no such creature now :-)

On 9/22/2010 8:32 AM, Miroslav Pokorny wrote:
By killing off JavaFX script this must be the first time Sun has ever 
made some source code of today uncompilable in the future.

--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Reinhold brought up the concept of a "value" keyword ?

[Jess Holle]

 I thought it was supposed to be like Scala's case classes, but the 
info was actually quite sparse as to what these were.


On 9/20/2010 10:43 PM, Serge Boulay wrote:
and also here. I thought it might be properties until I saw that 
explicitly listed too.


"They also introduced the concept of reification, value classes and 
the long awaited properties."


http://www.dzone.com/links/r/jdk_7_and_java_se_7_session_new_features.html

2010/9/20 Cédric Beust ♔ mailto:ced...@beust.com>>

First time I hear about it, I don't think it ever got mentioned a
single time on the Coin mailing-list. It sounds like it might be
property support?

Where did you get this information?

-- 
Cédric



On Mon, Sep 20, 2010 at 7:22 PM, Serge Boulay
mailto:serge.bou...@gmail.com>> wrote:

*"Mark Reinhold brought up  the concept of a "value" keyword
that would allow for significant suppression of the
boilerplate code for data/value classes."*
I couldn't attend javaone, does anyone know if Mark posted a
code sample or what the "value" keyword is or what it would
look like?
-- 
You received this message because you are subscribed to the

Google Groups "The Java Posse" group.
To post to this group, send email to
javaposse@googlegroups.com .
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




-- 
Cédric



-- 
You received this message because you are subscribed to the Google

Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JavaFX script to be dropped, JavaFX 2.0 will be an API on the JVM, usable from Java

[Jess Holle]

 On 9/20/2010 3:49 PM, Cédric Beust ♔ wrote:


  Just give us a decent UI that runs on any desktop OS without any
extra native libraries, etc (which kills the notion of SWT
immediately)


How so? Swing uses native libraries as well (well, AWT does). They are 
just implementing the UI at a different level than SWT.


The whole "native libraries are evil" thing died more than ten years ago.
Swing uses native libraries *but* they're a built in part of Java SE and 
part and parcel of having a Java SE implementation.


Native libraries outside this *are* evil for anyone who deals with more 
than a couple of platforms.  They're a royal PITA for client work in 
this case.


and a reasonable API (which Swing has in my book).  The rest of
the Eclipse RCP might be nice -- but it's "contaminated" by SWT
for those who want no part of SWT.


Sounds like a pretty arbitrary and emotional position, but whatever 
works for you.
It's not arbitrary in that SWT takes too much work to deploy, run, 
troubleshoot, etc, when you have to support numerous platforms.  There 
really is a realm for "works well enough everywhere" UIs -- that's 
really the entirety of HTML/JavaScript UIs, for starters.


Back to the original topic, if JavaFX's rendering engine and APIs are 
rolled into Java SE implementations than that would be yet another 
reason to stay away from SWT.  If JavaFX is just yet another add-on 
library requiring its own add-on native libraries, then it's still on no 
worse ground than SWT.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JavaFX script to be dropped, JavaFX 2.0 will be an API on the JVM, usable from Java

[Jess Holle]

 Well if they give JavaFX a /really/ nice Java API so one can use it 
from Java as easily as Swing, then there's nothing more compelling about 
SWT due to this announcement.


SWT has no point over Swing at this point (vs. when it was originally 
created) unless you or your users are /really /hung up on widgets or 
fonts tracking the native platforms /perfectly/.  Some of us really and 
truly could care less.  Just give us a decent UI that runs on any 
desktop OS without any extra native libraries, etc (which kills the 
notion of SWT immediately) and a reasonable API (which Swing has in my 
book).  The rest of the Eclipse RCP might be nice -- but it's 
"contaminated" by SWT for those who want no part of SWT.


--
Jess Holle

On 9/20/2010 3:29 PM, Cédric Beust ♔ wrote:
I think that all this move is going to accomplish is to push even more 
developers toward SWT/JFace/Eclipse RCP.


Seriously, Java FX has close to zero adoption, the only times I ever 
hear about it are either during Java One or from Sun employees or 
JavaFX book authors.


--
Cédric


On Mon, Sep 20, 2010 at 1:25 PM, Fabrizio Giudici 
mailto:fabrizio.giud...@tidalwave.it>> 
wrote:


 On 9/20/10 12:31 , Jan Goyvaerts™ wrote:

Is it going to be Swing's successor then ?



I'm reading this quickly (I'm eating). This sounds good for some
things (reusability, which BTW sounds as a "return to the origin",
since I remember that in 2007 Sun was saying in a way that JavaFX
runtime could have been used by the regular JavaVM (which didn't
prove true as there were not "blessed" APIs. So far so good. For
the dropping of the language, it's bad. I'm curious about binding!
If Oracle plans to revamp BeansBinding or such... and eventually
provide some language level support. I was at the Java 7 keynote,
but I didn't follow it with full attention :o) I saw Mark possibly
talking about fully supported properties, so I suppose there will
be something related to binding. Anybody can comment?

PS OTOH, the JavaFX script compiler is the JavaFX part that is
open sourced. I suppose JavaFX script could be fully supported by
aficionados if they want to keep it live.

-- 
Fabrizio Giudici - Java Architect, Project Manager

Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici
<http://java.net/blog/fabriziogiudici> - www.tidalwave.it/people
<http://www.tidalwave.it/people>
fabrizio.giud...@tidalwave.it <mailto:fabrizio.giud...@tidalwave.it>

-- 
You received this message because you are subscribed to the Google

Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Cédric


--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.



--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Scala vs. Groovy

[Jess Holle]

 Of course there's also the another issue...

If you just need a little dynamic scripting in a larger picture, you can 
do this with minimal work and no extra libraries in Java 6 if you use 
JavaScript -- and re-use existing developer skills while you're at it.  
The same can't be said for Ruby.


On 9/15/2010 9:34 AM, Jess Holle wrote:
Existence outside the JVM is one possible dimension to the reluctance 
to use Ruby.  For me the bigger issues with Ruby are:


   1. The inability to do static typing
  * An ability to easily do dynamic typing where you want is
one thing, the inability to do static typing is quite
another, though.
   2. The overt "everything's a DSL" approach that Ruby seems to
  encourage or at least that many folk seem to take with Ruby
  * This is reminiscent of Dick's comments on LISP.  Code
written by dozens of different folk seems to quite easily
end up looking more like dozens of totally different
languages.

I don't have anything against Ruby as compared to other languages with 
these same issues -- but I consider both of these to be big issues.


--
Jess Holle

On 9/15/2010 8:30 AM, Charles Oliver Nutter wrote:

You may be right. Probably the biggest challenge of JRuby (even bigger
than getting full POSIX filesystem support, native libraries/
extensions, libc-like buffered/unubuffered IO, and a whole slew of
other features) has been knocking down the "us vs them" barrier
between the two worlds. Among Rubyists, JRuby is still often seen as
"that Java thing", and they seem to have taken a solemn oath to never
touch anything Java-related. On the Java side, folks are reluctant to
stray too far from Java-like languages, and see Ruby as a cocky young
upstart getting too much press for too little power.

Of course neither attitude is healthy; Ruby and Rails are without a
doubt outstanding tools for building web applications, and on JRuby
most of the typical complaints about the Ruby platform are addressed
(performance, scaling, memory management, stability). And of course
the Ruby world can usually get those benefits just by switching to
JRuby, though their biases against "Java" often keep them from even
trying.

You can imagine it's a frustrating situation for us :)

On Sep 12, 7:15 pm, Andrew  wrote:

Hi Charlie,

Personally (and I may be wrong...) I think there is a bit of a
reluctance in the Java community to embrace anything that also has an
existence outside of the JVM.  I think there is a bit of an "Us (Java)
versus them (Ruby)" mentality, sadly.

Also, there's a thread here from 2009 that touched on some of the
attitudes towards (J)Ruby - not sure if you've seen it.

http://www.mail-archive.com/javaposse@googlegroups.com/msg05371.html

Andrew.

Twitter: @am2605

On Sep 12, 4:19 pm, Charles Oliver Nutter  wrote:




On Sep 9, 11:17 pm, Sean Griffin  wrote:

My intention is not as sensational as my subject, but it's succinct so
I'll go with it.

FWIW, I'm surprised JRuby doesn't come up more. Perhaps people don't
think about it because they feel Ruby is a "non-JVM" language more
than a JVM language?
Ruby the language (not necessarily on JRuby) likely has more users
worldwide than Groovy, Scala, and Clojure combined. By conservative
estimates there are 500k-1M folks using Ruby. There are dozens of Ruby
conferences around the world; I'll be attending 6 total this fall in
the US, Japan, Brazil, and Uruguay, and more this spring in Europe and
India. So it can't be that there's not a community to support it.
JRuby itself has defeated the idea that "Ruby is slow" already, and in
the next release Ruby performance for many things will start to
approach Java...even without requiring static types and other dynlang"
impurities. For small benchmarks, JRuby master has exceeded the
performance of all other dynamic languages on the JVM already.
JRuby integrates very well with Java, implementing interfaces (at
runtime or ahead-of-time), extending classes, and of course calling
any Java class as if it were just another Ruby class. The vast
majority of integration cases work just fine, and most folks that
choose JRuby do so explicitly because it integrates so well.
I suppose the big reason people may not consider Ruby is due to the
differing syntax and some oddities in the language? I don't find the
syntax that far off from Java...mostly it's replacing {} with
do...end, using @foo for instance variables, and omitting visibility
modifiers. So I think this is a red herring too.
I'd like to hear why nobody on this thread has even mentioned JRuby,
especially if it's something we've failed to do in the implementation
that keeps people away.
- Charlie




--
You received this message because you are subscribed to the Google Groups "Th

Re: [The Java Posse] Re: Scala vs. Groovy

[Jess Holle]

 Existence outside the JVM is one possible dimension to the reluctance 
to use Ruby.  For me the bigger issues with Ruby are:


  1. The inability to do static typing
 * An ability to easily do dynamic typing where you want is one
   thing, the inability to do static typing is quite another,
   though.
  2. The overt "everything's a DSL" approach that Ruby seems to
 encourage or at least that many folk seem to take with Ruby
 * This is reminiscent of Dick's comments on LISP.  Code
   written by dozens of different folk seems to quite easily
   end up looking more like dozens of totally different languages.

I don't have anything against Ruby as compared to other languages with 
these same issues -- but I consider both of these to be big issues.


--
Jess Holle

On 9/15/2010 8:30 AM, Charles Oliver Nutter wrote:

You may be right. Probably the biggest challenge of JRuby (even bigger
than getting full POSIX filesystem support, native libraries/
extensions, libc-like buffered/unubuffered IO, and a whole slew of
other features) has been knocking down the "us vs them" barrier
between the two worlds. Among Rubyists, JRuby is still often seen as
"that Java thing", and they seem to have taken a solemn oath to never
touch anything Java-related. On the Java side, folks are reluctant to
stray too far from Java-like languages, and see Ruby as a cocky young
upstart getting too much press for too little power.

Of course neither attitude is healthy; Ruby and Rails are without a
doubt outstanding tools for building web applications, and on JRuby
most of the typical complaints about the Ruby platform are addressed
(performance, scaling, memory management, stability). And of course
the Ruby world can usually get those benefits just by switching to
JRuby, though their biases against "Java" often keep them from even
trying.

You can imagine it's a frustrating situation for us :)

On Sep 12, 7:15 pm, Andrew  wrote:

Hi Charlie,

Personally (and I may be wrong...) I think there is a bit of a
reluctance in the Java community to embrace anything that also has an
existence outside of the JVM.  I think there is a bit of an "Us (Java)
versus them (Ruby)" mentality, sadly.

Also, there's a thread here from 2009 that touched on some of the
attitudes towards (J)Ruby - not sure if you've seen it.

http://www.mail-archive.com/javaposse@googlegroups.com/msg05371.html

Andrew.

Twitter: @am2605

On Sep 12, 4:19 pm, Charles Oliver Nutter  wrote:




On Sep 9, 11:17 pm, Sean Griffin  wrote:

My intention is not as sensational as my subject, but it's succinct so
I'll go with it.

FWIW, I'm surprised JRuby doesn't come up more. Perhaps people don't
think about it because they feel Ruby is a "non-JVM" language more
than a JVM language?
Ruby the language (not necessarily on JRuby) likely has more users
worldwide than Groovy, Scala, and Clojure combined. By conservative
estimates there are 500k-1M folks using Ruby. There are dozens of Ruby
conferences around the world; I'll be attending 6 total this fall in
the US, Japan, Brazil, and Uruguay, and more this spring in Europe and
India. So it can't be that there's not a community to support it.
JRuby itself has defeated the idea that "Ruby is slow" already, and in
the next release Ruby performance for many things will start to
approach Java...even without requiring static types and other dynlang"
impurities. For small benchmarks, JRuby master has exceeded the
performance of all other dynamic languages on the JVM already.
JRuby integrates very well with Java, implementing interfaces (at
runtime or ahead-of-time), extending classes, and of course calling
any Java class as if it were just another Ruby class. The vast
majority of integration cases work just fine, and most folks that
choose JRuby do so explicitly because it integrates so well.
I suppose the big reason people may not consider Ruby is due to the
differing syntax and some oddities in the language? I don't find the
syntax that far off from Java...mostly it's replacing {} with
do...end, using @foo for instance variables, and omitting visibility
modifiers. So I think this is a red herring too.
I'd like to hear why nobody on this thread has even mentioned JRuby,
especially if it's something we've failed to do in the implementation
that keeps people away.
- Charlie


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JDK 7 (as currently defined) delayed to mid 2012

[Jess Holle]

 On 9/13/2010 2:49 PM, Casper Bang wrote:

That is not my experiences, you generally can NOT just expect a Swing
app to look and feel correct all over. I have written a fair amount of
Swing and it's more complex and slower performing than native
bindings. You'll find the menu bar wrong placed on Mac, widget
background discolored on Linux, EDT paint issues etc. So this is
actually about the only point I agree with Steve Jobs on; native
widget toolkit is the only way to go if you want to make your users
happy.

Hmm

Well there's always things like iTunes on Windows that show you can do 
worse at cross-platform GUIs than Swing.  [Really there are just so many 
things that should work that don't, especially thing like keyboard 
equivalents for tree actions.]  Other bits like Pidgin, Firefox, 
Thunderbird, etc, on Windows don't really strike as being substantially 
"more native" than most Swing apps I use or any better or worse in such 
regards.


On the flip side, I guess as a *user* (not a developer) I could care 
less about >90% of "nativeness" of an application.  I just want some 
basic, long-standing key equivalents to work.  Beyond that, whatever 
goes as long as the resulting UI is clear, isn't just "out there" weird, 
or self-inconsistent/buggy.  The latest "widget" fads are just that -- 
fads.  Many /native /apps do their own widgets in an attempt at coolness.


I guess this comes in part from spending most of my time using Windows 
but not really liking anything about Windows -- it's just what's easiest 
to work with at work.  As a long-term Mac and UNIX user /prior to /Mac 
OS X, Mac OS X's widgets (while pretty) largely confuse and annoy me.  
Other UNIX-based GUIs today are a veritable cacophony of inconsistency.  
Given that the /vast/ majority of users are Windows users that have just 
been sucked into the platform by circumstance, I really don't see 
"native widgets" as compelling for many apps.  Something clear and 
reasonable is more than sufficient for me.  Anything more is pretty -- 
but pretty meaningless -- eye candy.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: JDK 7 (as currently defined) delayed to mid 2012

[Jess Holle]

 On 9/8/2010 3:44 PM, Casper Bang wrote:

As Kevin wrote the Scala guys are already at work on the next cool
thing (parallel collection). And for sure we don't have to wait till
mid 2012 before to see it delivered. Moreover some very interesting
tools, libraries and frameworks are already mature enough to be used
in production environments. And in my small experience they
dramatically improve your productivity. Give a loot at Akka for
example. There is only one word to describe it: AWESOME.

There's also Mono; more familiar to Java developers and with it's own
set of awesome stuff. Sadly it's missing from the JVM, but for all
practical purposes it represents a Java 2.0 (opt-in type inference,
dynamic typing, nullable types, lambda's, expression trees, properties
etc.). Scala might very well be 3.0, but I fear the gap between 1.0
and 3.0 is too great. Undeniably, Scala has a big opportunity here.
Hindsight is 20-20, but if Scala's grammar/syntax didn't deviate so far 
from the C, C++, Java, etc, tradition, it would be taking the Java 
community by storm by now.


As it is C# looks more natural to a C, C++, or Java developer than Scala 
-- unfortunately.  I'm not sure who Scala looks natural to...


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Erasure

[Jess Holle]

 It seems like it should be possible to leave generics mostly "as is" 
except for having an ability to do things like:



   {
  ...
  T array = new T[10];
   }

where the type T would be fetched from an internal runtime type holder 
associated with the instance.  A "raw" type would presumably either 
return Object.class here or a null, producing a specific exception that 
one could catch (to allow interop with older code that might pass you a 
raw type).


This again wouldn't produce the ivory tower some are looking for, but it 
would seem to cover a large percentage of the headaches caused by type 
erasure.


On 8/31/2010 2:04 PM, Kevin Wright wrote:
If there ever was a realistic move to reify Generics then, given what 
we've since learnt, wouldn't it make much more sense to first shift 
Java to declaration-site variance?


I think it's fair to believe that any future polymorphic, 
statically-typed language on the JVM would use this paradigm.  And 
reifying the alternative could well harm the JVM's potential to 
compete with .NET as a flexible multi-language platform.  This is a 
very unlikely move, as I suspect it would impact SCOracle's bottom line.


Changing Java like this is a *big* proposition though, as it would 
effectively require a breaking change in the language spec, 
sacrificing backwards compatibility.  Allowing both declaration-site 
and call-site variance would be hideously complicated!




On 31 August 2010 19:38, Jess Holle <mailto:je...@ptc.com>> wrote:


 On 8/31/2010 1:15 PM, Russel Winder wrote:

I guess the questions are not so much can you survive with
type erasure
on the JVM but are:

1. Did the CLR gain by supporting run time type parameters for
generics?

They gained 2 disparate collections libraries for starters.  Given
the plethora of Java libraries using collections, splitting the
Java universe that using old collections and that using new
collections seems like a much bigger issue than doing this to the
younger, smaller .Net library space.

2.  Why were the annotations people allowed to amend the JVM
when the
generics people were not?

Annotations didn't break anything.  The straightforward
reification approach used by .Net of 2 having different,
non-interoperable versions of APIs would have split the Java
technology space -- a "break" in my book at least.  A reification
approach that would allow seamless interoperation between old and
new libraries (i.e. with 1 collection library where any collection
can be passed to both old and new libraries) but provide runtime
knowledge of generic type parameters is a much taller order -- and
it's easy to see how this was beyond the scope of Java 5.  Anyone
who comes up with such an approach could ostensibly still add it
to Java N, though.

--
Jess Holle


-- 
You received this message because you are subscribed to the Google

Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
<mailto:javaposse@googlegroups.com>.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
<mailto:javaposse%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Kevin Wright

mail/google talk: kev.lee.wri...@gmail.com 
<mailto:kev.lee.wri...@gmail.com>

wave: kev.lee.wri...@googlewave.com <mailto:kev.lee.wri...@googlewave.com>
skype: kev.lee.wright
twitter: @thecoda

--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Erasure

[Jess Holle]

 On 8/31/2010 1:15 PM, Russel Winder wrote:

I guess the questions are not so much can you survive with type erasure
on the JVM but are:

1. Did the CLR gain by supporting run time type parameters for generics?
They gained 2 disparate collections libraries for starters.  Given the 
plethora of Java libraries using collections, splitting the Java 
universe that using old collections and that using new collections seems 
like a much bigger issue than doing this to the younger, smaller .Net 
library space.

2.  Why were the annotations people allowed to amend the JVM when the
generics people were not?
Annotations didn't break anything.  The straightforward reification 
approach used by .Net of 2 having different, non-interoperable versions 
of APIs would have split the Java technology space -- a "break" in my 
book at least.  A reification approach that would allow seamless 
interoperation between old and new libraries (i.e. with 1 collection 
library where any collection can be passed to both old and new 
libraries) but provide runtime knowledge of generic type parameters is a 
much taller order -- and it's easy to see how this was beyond the scope 
of Java 5.  Anyone who comes up with such an approach could ostensibly 
still add it to Java N, though.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Management: "For now Java is no longer an option for new development"

[Jess Holle]

 On 8/31/2010 9:51 AM, Russel Winder wrote:

On Tue, 2010-08-31 at 10:24 -0400, Robert Casto wrote:

I very much like where this thread is headed.

Having viable options with Java that Oracle can not touch sounds like
a win for the community. There is a lot of value in those libraries
that can be leveraged by a developer. That makes them productive and
of benefit to a company. If all we have to do is change the underlying
VM to something that is safe from Oracle, then so be it. I'm sure that
VM would get a lot more attention from the community to make it great
for production use.

Perhaps the JVM could then support type parameters and the abomination
that is type erasure could be dispensed with.

Er, much a do about rather little in my book.

There have been a handful of times I've hit real type erasure issues in 
years of writing generic-ridden code.  Is it the ivory tower?  No, but 
it beats having java.util and java.util2!


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Management: "For now Java is no longer an option for new development"

[Jess Holle]

 On 8/31/2010 6:52 AM, Fabrizio Giudici wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/31/10 13:28 , Jess Holle wrote:

What about heavy pressure on Oracle via all possible venues so
that they feel they need to establish a different tone in their
JavaOne keynote?

I don't think Oracle cares much about upsetting a small minority
of the community.  If they get the impression that those who are
concerned/upset are either not a small minority or are
sufficiently vocal to upset the rest of the community, then I
believe they'll adjust their approach (as little as they feel they
can get away with, of course).

I think that one possibility is that Oracle doesn't care about
upsetting the whole community, since the community itself is the
minority. You bet that a large corporate such as Oracle has got tools
(market research, etc...) to have some decent figures about who like
and don't like them. Unfortunately, we, the community, don't have any
such tool (we use the blogs to pretend to measure our size, but this
is just bullshit that leads to gross overestimates).

Frankly, I'd accept Kevin's provocation: if you get bored by Ellison's
keynotes, it would be practical to move to another VM ecosystem such
as LLVM (and, of course, forcing yourself not to be bored by Jobs'
keynotes).
Of course Oracle's lawsuit here is really based on the notion that other 
VM implementations violate their IP.  It really has nothing to do with 
Java per se -- but rather with VM technology.  Thus they may well pursue 
any/all alternative VMs, including .Net's if they have the stomach for 
an all out war with Microsoft (which is highly doubtful).


The chilling effect for Java is the message that if you try to do 
something other than the way Oracle wants you to -- including paying 
Oracle, of course -- they may come after you with patent suits even if 
you do a completely cleanroom implementation, don't call it Java (or 
J2EE or anything else trademarked by Sun/Oracle), etc.  If you believe 
software patents make sense, then I guess you'd find nothing wrong with 
this.  I don't believe software patents make sense -- and believe that 
Oracle's willingness to use them in such a destructive fashion has a 
chilling effect on the community and on innovation not only in the Java 
community but also potentially in parallel communities (i.e. based on 
other VM technologies).


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Management: "For now Java is no longer an option for new development"

[Jess Holle]

 What about heavy pressure on Oracle via all possible venues so that 
they feel they need to establish a different tone in their JavaOne keynote?


I don't think Oracle cares much about upsetting a small minority of the 
community.  If they get the impression that those who are 
concerned/upset are either not a small minority or are sufficiently 
vocal to upset the rest of the community, then I believe they'll adjust 
their approach (as little as they feel they can get away with, of course).


--
Jess Holle

On 8/31/2010 6:13 AM, Jan Goyvaerts wrote:

What about a little patience to see the keynote of JavaOne ? :-)

On Tue, Aug 31, 2010 at 13:10, Kevin Wright <mailto:kev.lee.wri...@gmail.com>> wrote:


Anyone for LLVM + VMKit? :P


On 31 August 2010 11:53, Jan Goyvaerts mailto:java.arti...@gmail.com>> wrote:

I'm afraid the opensource hardcore Java developers won't have
an easy time to get rid of oracle:

* JavaFX, Scala or anything requiring the JVM is out - unless
you're running something non-oracle like OpenJDK.
* Your IDE is Eclipse or Intellij. Because jDeveloper and
Netbeans is Oracle's now.
* Your database is not MySQL anymore either.
* Your office package is not OpenOffice anymore.
* Your CI is not Hudson anymore.

Not to mention Oracle and your management don't give a damn
about this debate either. Good luck telling them Java is to be
disposed off because its owner is considered evil now. I'd
like to see that. :-)

I'm afraid the choice is not ours any more.

So... what d'you have ? :-)


On Tue, Aug 31, 2010 at 11:34, Romain Pelisse
mailto:bela...@gmail.com>> wrote:

I would that Java is more in his mid forties, so Java buy
yourself a fancy car (Scala ?), start to play the Guitar
in a band (JavaFX ? :) ), and probably work a little bit
less... !


On 31 August 2010 11:30, Kevin Wright
mailto:kev.lee.wri...@gmail.com>> wrote:

Java is not dead.

Like all good parents, it has sat and patiently raised
its children, and they are now adults themselves.
and also, like most parents with grown-up children,
it's reached retirement age.

So, Java, we salute you, and all you have done in
raising a successful family.
Be proud of your achievements...
and get out there on that golf course to enjoy a less
stressful existence for the remainder of your years!


On 31 August 2010 10:22, Romain Pelisse
mailto:bela...@gmail.com>> wrote:

I think that Java is already dead, we simply don't
care about it :)

I mean the last "dead technology" was C or C++ -
people are still using those, the previous one was
probably Cobol, still a lot of people using those
and there is even backport of tools such as JUnit
for Cobol !

Java has been there for so long that it is not
going to disappear like Forte 4GL did overnight
(but you might people using Forte, so even on this
I maybe wrong). Perhaps we have reached a peak and
Java will go slowly down, perhaps not. But Java is
dead statement are plain nonsense.

I think Java is getting older, that for sure. Java
is no longer the language of choice for crazy new
idea or new project. The slow adoption of
Git/Mercurial in the Java world is a good hint to
that (I think). late 2008 and early 2009 most of
major non Java related Open Souce moved to Git or
Mercurial. This shift happened one year later in
the Java world.

Java is like an old person, he doesn't run as he
did in his youth, but he is far from being dead...

On 31 August 2010 10:27, Fabrizio Giudici
mailto:fabrizio.giud...@tidalwave.it>> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've first heard that statement around
2001/2002. It was the first
time I started hearing that Java was dead, and
at the time I got
seriously worried as I focused on Java since
the inception of my
career - at the time, Ja

Re: [The Java Posse] Google backs out of JavaOne

[Jess Holle]

 On 8/29/2010 9:13 AM, Cédric Beust ♔ wrote:
On Sun, Aug 29, 2010 at 5:37 AM, Jan Goyvaerts <mailto:java.arti...@gmail.com>> wrote:


This is another sad chapter in Java's history...


In my opinion, pulling out of JavaOne this way is not going to
help the Java community now, or is it ? Especially for people
not related to Oracle. And certainly for those who were counting
on Google's sessions.

Sorry to say it, but this was not exactly a mature thing to do.


I'm pretty sure that Google didn't have any choice from a legal 
standpoint.


Again in my personal opinion, I miss the point about how this is
going to hurt Oracle. I would agree were Google to abandon Java
altogether right now to start on their own. But I guess they
aren't. I'm afraid this only hurts Java and its community.


I think Oracle is irrelevant to Java's future just like Sun has been 
irrelevant to Java's future for the past ten years. This lawsuit is 
very unfortunate but it won't have much effect on Java overall.
To say that Sun has been irrelevant to Java for 10 years is a gross 
overstatement by any stretch.  The last couple of years there's been a 
pronounced lack of direction from Sun, but Java 5 was certainly not 
irrelevant, for instance.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] News from Oracle.

[Jess Holle]

 On 8/17/2010 9:28 PM, Sean Comerford wrote:
The big thing I keep seeing in all this "concern about Oracle" is that 
people continually forget or ignore WHY Sun and Java is now owned by 
Oracle: Sun focused on the wrong things (including being OVERLY 
concerned with the community) which led to them losing money year 
after year after year basically from 2001 til the end.


And like it or not, companies exist to make money (which benefits us 
by allowing us to get paid to work for them).


So yes, Oracle is going to change some stuff and in fact they MUST 
change the things that made Sun non-profitable.


And unfortunately the things that make companies profitable are not 
always "community" friendly. We as engineers love "open source" b/c it 
means our projects are more profitable and we look like heroes which 
leads to big raises + bonuses. But there wasn't much profit in that 
model for Sun and Oracle is smart enough to know there won't be for 
them either.


As far as the JDK lawsuit, like most things in life, I suspect the 
truth will end being somewhere in the middle (part money grab by 
Oracle, part legitimate beef against bastardization of technology they 
paid a fortune to acquire). But I seem to recall Sun suing a company 
several years back on similar grounds... and in that case there was no 
community angst b/c the target of the suit was everyone's favorite 
"evil software tycoon" Micro$oft.
Microsoft left  Sun precious little choice.  Sun had to fight them or 
let Microsoft create a vendor-lock-in version of Java and steer most 
Windows developers there.


The difference here is that it would appear that Sun left Google 
precious little choice -- other than to use something entirely 
dissimilar not only to the Java language but to the Java Virtual 
Machine.  [Charging an arm-and-a-leg for long-in-the-tooth Java ME 
technology didn't really leave Google much choice.]


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Dick's Crystal Ball: Oracle sues Google over Android. Facepalm!

[Jess Holle]

 On 8/13/2010 9:01 AM, Fabrizio Giudici wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/13/10 15:52 , Jess Holle wrote:

I also think this is a broader shot across the bow for anyone who
tries to ship something JVM-like without using an Oracle JVM,
paying Oracle licensing, or basing their work on the OpenJDK and
thus making it all freely available.

For instance, anyone thinking of shipping a Harmony based JVM as
part of a commercial offering should take pause.  IBM in
particular licenses Java from Sun/Oracle but also incorporates more
and more code from Harmony.  IBM's Harmony usage has every
appearance of heading towards eventually cutting the licensing cord
to Sun/Oracle -- and this suit serves as a "don't you dare" notice
from Oracle.

And, for instance, GAE?

Yeah, that would seem like a target as well...

--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Dick's Crystal Ball: Oracle sues Google over Android. Facepalm!

[Jess Holle]

 I also think this is a broader shot across the bow for anyone who 
tries to ship something JVM-like without using an Oracle JVM, paying 
Oracle licensing, or basing their work on the OpenJDK and thus making it 
all freely available.


For instance, anyone thinking of shipping a Harmony based JVM as part of 
a commercial offering should take pause.  IBM in particular licenses 
Java from Sun/Oracle but also incorporates more and more code from 
Harmony.  IBM's Harmony usage has every appearance of heading towards 
eventually cutting the licensing cord to Sun/Oracle -- and this suit 
serves as a "don't you dare" notice from Oracle.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Dick's Crystal Ball: Oracle sues Google over Android. Facepalm!

[Jess Holle]

 I suspect Oracle/Sun wants to mandate shipment of JavaFX with every 
Android device or some such.


Clearly the platform is open enough that no one is stopping them for 
shipping JavaFX for it.


On 8/13/2010 8:21 AM, Fabrizio Giudici wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/13/10 14:39 , Casper Bang wrote:

Do The Deal!?! Get JavaFX on the Android platform today!

There's that thing again. Please explain what's currently holding
JavaFX back from running on Android? Sun/Oracle could just do it.

Casper, the DID it :-) Two years ago:

http://www.youtube.com/watch?v=sopao9Y7-GQ&feature=related

This is what can be publicly demonstrated. Now you can figure out that
while it would not violate any law to distribute it, a big, healthy
corporate has many ways to inhibit a not-so-healthy corporate from
doing something. And it's not only a Sun-Google game, since going
beyond emulators involves phone manufacturers. As I have said, there
are only rumors well known in the JavaFX community about that, but
they are pretty strong and they are about Google _not wanting_ to see
JavaFX-on-the-whole running on Android.


BTW - looking at http://javafx.com/faq/ I read:

2.5 Can JavaFX applications run on an Android handset?

JavaFX is capable of running on nearly any mobile operating system,
assuming the necessary runtime files have been preloaded on the
device. Device manufacturers that are interested in including JavaFX
Mobile with their Android-based handsets are encouraged to contact
Oracle for further details.


I'm just curious on whether this "Device manufacturers... are
encouraged" was already present before January or not. No luck with
archive.org. If it's a new Oracle thing, maybe is it part of the deal?

- -- 
Fabrizio Giudici - Java Architect, Project Manager

Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
fabrizio.giud...@tidalwave.it
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxlRtsACgkQeDweFqgUGxc5LACeIb2JbjsGKBRYIRrI7CWgWezs
JV8An1Zy0UMwwX3sB4d0s97cJrbQSC4i
=OR6W
-END PGP SIGNATURE-



--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Dick's Crystal Ball: Oracle sues Google over Android. Facepalm!

[Jess Holle]

 Sun essentially forced Google to either (1) take the path they did or 
(2) go another way entirely than Java by the combination of high pricing 
and lack of recent innovation on Java ME.


I think Oracle should be rejoicing that Google took path #1 -- and 
trying to build bridges to make Android into Java ME's next generation / 
replacement.


Instead this suit has the potential to be quite damaging.

On 8/13/2010 12:04 AM, Robert Casto wrote:
This could kill the community around Java and force Google to decide 
on a new language for Android. Should that happen, Google has enormous 
power in its hands at deciding the next big language. Who knows how 
Apache, IBM, and others will react. Oracle might be flexing its 
muscle, and part of me hopes Google calls its bluff. If not and it 
walks away from Java, then a part of me hopes Oracle gets what is 
coming to them for killing the goose.


On Fri, Aug 13, 2010 at 12:02 AM, JamesJ > wrote:


So, the obvious solution is for Google to stick it to 'em, ditch
Java, adopt another of the JVM languages (Scala, etc) so the port
will be easy. (Wink Wink)   It will just be one more step for Java
towards irrelevance in the mobile computing space.

Seriously, this makes me mad too.  Bad move for the community,
which Dick always says is the true strength of Java.

This seems to me to be a little like when Linus was put in a
position of having to pay to manage the source for Linux, so he
surprised just about everyone and invented Git.  The smart guys at
Google may just decide to leave Oracle's party for good.  I think
that Oracle thinks that their position is stronger that it really is.


-- 
You received this message because you are subscribed to the Google

Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Robert Casto
www.robertcasto.com 


--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Tab / Spaces anyone?

[Jess Holle]

The real issue is that many developers can't handle always using tabs 
for indenting and always using spaces for spacing -- it's too much for 
them, in part because the difference is invisible and thus mistakes only 
become obvious to those with different tab stop settings.


All it takes is a few bad apples to produce an utterly bad result.  Thus 
in the real world with multiple real world programmers working on the 
code any use of tabs becomes intolerable.


--
Jess Holle

On 7/1/2010 8:03 AM, Reinier Zwitserloot wrote:

In regards to the 'you can't mix and match' rule 3: Actually, The One
True Indent style *DOES* mix and match. Specifically, it mixes 'tabs
are for indents' and 'spaces are for spacing'.

Furthermore, the general complaint "Do not randomly mix indent styles"
is of course applicable, but this is a meta-rule. I don't really see
how you can claim that this is a problem with The One True Indent
style any more than it is with the all-spaces indent style. It is true
that some editors offer an easy "all spaces please" option, and TOTI
is less common, but that's a problem with your tools. The major 3 IDEs
can all be configured to auto-format in TOTI style.

In regards to rule 4: That's misleading as well. TOTI at least offers
a future where viewing source on a tiny mobile phone screen is going
to go ever so slightly better because of configurable tab stops. With
spaces you have to pick the same indent length for all devices;
presumably 4, but on a mobile phone you'd definitely want no more than
2. Again this argument seems either a wash or if anything in favour of
TOTI over all-spaces.

On Jul 1, 12:27 pm, Paul King  wrote:
   

I tend to be in the 'tabs are evil camp' most of the time. Not that they are
evil but there are some missing rules in Reinier's list. Rule 3: If you use
tabs you must use them everywhere - you can't mix and match and everyone
else must too. Rule 4: Every tool in your toolset including all future ones
must support and allow customisation of tab sizes. If I am browsing source
diffs through fisheye and it converts tabs to 8 spaces for display purposes,
that might be fine on a large screen but less useful on a mobile phone. In
fact, this is the exact scenario where tabs could be so useful but with many
tools, they just aren't right now. It's certainly better than it was 10
years ago but still has some way to go IMHO.

Still, it's not something to get too worried about - you should be able to
convert from one style to the other with a keystroke in most IDEs.

Paul.

On Thu, Jul 1, 2010 at 7:48 PM, Mark Volkmannwrote:



 

I'm surprised that all the replies to this thread are in favor of tabs
over spaces. In my experience, the vast majority of developers favor
spaces. For me there is one main reason I prefer spaces ... printers.
Sometimes I print code. Printers seem to always use eight spaces for
tabs which causes many lines to wrap and makes it harder to read the
code. If there were a universal way to adjust that then I'd be okay
with using tabs for indentation.
   
 

This is the same reason why I don't like when lines are longer than 80
characters. Many of the lines will wrap when printed. Also, I find it
harder to read code with long lines. That's why newspaper columns
don't extend all the way across wide newspaper pages.
   
 

--
R. Mark Volkmann
Object Computing, Inc.
   
 

--
You received this message because you are subscribed to the Google Groups
"The Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
   
   


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Episode #312 - NetBeans 6.9

[Jess Holle]

On 6/29/2010 6:09 AM, Jess Holle wrote:

On 6/29/2010 4:29 AM, Jan Goyvaerts wrote:
Project scanning ! Tor mentioned this can be disabled. But really... 
why it is scanning the very same Maven libraries each time I'm 
starting up ? NB takes a kickass start and stamps right away onto the 
breaks as soon as it is scanning the tenths of Maven libraries my 
projects have. I thought Maven libraries are by their nature 
immutable. They're cast in stone once they get a final version. So 
why am I seeing each morning the same lengthy procession of scans ? 
Usually when I'm - trying - to show off Netbeans to my colleagues. :-)
First off, I have to say that the scan on demand feature did *not* 
work for me in 6.9.  I read the Wiki page on it and nothing seemed to 
work as advertised.


Secondly, I've griped about project scanning since about NetBeans 4.0 
and it's still a problem.  It should be faster and start less often.  
That said, those behaviors could be ignored as long as it didn't 
consume *too* much CPU and disk while running in the background and, 
above all, didn't stop you from doing things.  By this I mean that if 
you're doing Go-To-Type and NetBeans has once scanned the type you're 
looking for it should have no issue doing so again during scanning -- 
period.  Even if it is rescanning the source tree containing that 
type, the old data should be available the entire time except for an 
atomic switch between the old and new scan data for the given source 
file.  As it is now there are large periods of time where Go-To-Type 
(and many other functionalities) are not usable.  Also there's the 
matter that Go-To-Type is still a lot slower than I'd expect for exact 
searches.  I wrote a static analyzer using NetBeans' classfile module 
to index to a relational database, and slapped a web app on top of 
this.  It finds types all but instantaneously.  NetBeans thinks for 
quite some time in many cases.
Hmmm  It actually seems that 6.9 has resolved the last of the issues 
I mentioned.  Go-To-Type seems to be /quite /fast now.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Episode #312 - NetBeans 6.9

[Jess Holle]

On 6/29/2010 4:29 AM, Jan Goyvaerts wrote:
Project scanning ! Tor mentioned this can be disabled. But really... 
why it is scanning the very same Maven libraries each time I'm 
starting up ? NB takes a kickass start and stamps right away onto the 
breaks as soon as it is scanning the tenths of Maven libraries my 
projects have. I thought Maven libraries are by their nature 
immutable. They're cast in stone once they get a final version. So why 
am I seeing each morning the same lengthy procession of scans ? 
Usually when I'm - trying - to show off Netbeans to my colleagues. :-)
First off, I have to say that the scan on demand feature did *not* work 
for me in 6.9.  I read the Wiki page on it and nothing seemed to work as 
advertised.


Secondly, I've griped about project scanning since about NetBeans 4.0 
and it's still a problem.  It should be faster and start less often.  
That said, those behaviors could be ignored as long as it didn't consume 
*too* much CPU and disk while running in the background and, above all, 
didn't stop you from doing things.  By this I mean that if you're doing 
Go-To-Type and NetBeans has once scanned the type you're looking for it 
should have no issue doing so again during scanning -- period.  Even if 
it is rescanning the source tree containing that type, the old data 
should be available the entire time except for an atomic switch between 
the old and new scan data for the given source file.  As it is now there 
are large periods of time where Go-To-Type (and many other 
functionalities) are not usable.  Also there's the matter that 
Go-To-Type is still a lot slower than I'd expect for exact searches.  I 
wrote a static analyzer using NetBeans' classfile module to index to a 
relational database, and slapped a web app on top of this.  It finds 
types all but instantaneously.  NetBeans thinks for quite some time in 
many cases.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Subliminal messages...

[Jess Holle]

Use the #1 underdog IDE du jour [and thus #2 overall, in terms of market 
share]!


I do happen to use NetBeans, but in any case I think it's great to give 
the top underdog a good, fair shake in most any case.  The group think, 
everyone goes to the current market share leader and never considers 
anything else is how we got stuck on Windows -- and have stayed stuck on 
it so long.


--
Jess Holle

On 6/28/2010 4:33 PM, Mark Derricutt wrote:

Loved (use netbeans) the latest (use netbeans) news cast guys.  But I
(use netbeans) wonder if we could (use netbeans) cut down on the (use
netbeans) subliminal messages and (use netbeans) neural reprogramming
a little.

I think I might use netbeans.

Mark


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: NetBeans code completion for logging

[Jess Holle]

One of my pet peeves is that aspects of auto-completion do not obey your 
formatting rules...


On 6/25/2010 5:36 PM, Reinier Zwitserloot wrote:

What Wayne said - you can change the template in the settings. But few
people do this, unfortunately. A setting should be set out-of-the-box
to the most generally applicable value, and it isn't :(

On Jun 25, 9:44 pm, Wayne Fay  wrote:
   

autocompletion actions subject to reasonably easy plug-in overriding?  In
other words, if a developer is unhappy with default IDE exception handling,
can they provide an alternative without spending an eternity deep in the
   

Yes, it is pretty trivial to replace the autocompletion code template
with your own, assuming you don't want to do something especially odd.

Wayne
 
   


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

[The Java Posse] Re: Project build with NetBeans or RAD

[Jess Holle]

Overall Maven is hugely helpful in closing the gap between open source 
projects and IDEs -- since NetBeans and Eclipse can quickly open, 
browse, and build most any Maven project.  Some open source projects are 
a veritable cacophany of Java source tree roots at seemingly random 
levels of the directory tree and build.xml's all over the place, which 
can make even effective browsing of the sources with an IDE (much less 
building) a painful proposition.  [Really is it so much to ask to have 
all the source tree roots at a single consistent level in the version 
control directory tree?]


Setting your own projects up to build with Maven is a separate learning 
curve and investment, though.


--
Jess Holle

On Tue, Jun 22, 2010 at 10:38, Peter Becker  wrote:
   

Maven might feel too complex or too limiting when you come from Ant, but
once you see the tool support it is more than worth it.
 

I read some articles about maven, but I could not find the big benefit
- just additional work (where ant works by default after NetBeans
installation) and I am by tendency a K.I.S.S. guy. Especially for my
development machine I am careful - I already experienced in the past
that too many tool dependencies could make it hard to get a new
development machine up and running so that all project rebuild without
errors (COM Windows world extremely sensitive here).

I am not yet convinced to switch to Maven, but maybe somebody could
nail down the big advantage.

   


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Less IPhone

[Jess Holle]

Quality of software cannot be overrated.

The utility of unit tests towards this end is often overrated, though.  
The interesting/nasty things happen when you put the units together.  
Testing the units (e.g. and mocking out the others) is over-emphasized 
as compared to testing that /everything/ works together as intended.


On 6/18/2010 8:51 AM, Rakesh wrote:

I used to listen to StackOverflow but stopped after Joel Spolsky
stated that unit tests were a luxury when under pressure and quality
of software is over-rated.

Not my kind of guy.

Rakesh

On Fri, Jun 18, 2010 at 1:07 PM, Carl Jokl  wrote:
   

On a different topic I am now making my way through Illegal Argument.
It may take a couple of weeks. Is there also another podcast called
"Stack Overflow"?
The first 3 episodes of Illegal Argument are not on iTunes. Are they
available somewhere else?

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


 
   


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Less IPhone

[Jess Holle]

The indulgent section was always at the end and always clearly separated 
from the rest of the podcast.


If iPhone news was always at the end (i.e. after even listener 
feedback), then those who didn't like it could always just skip the rest 
of the podcast.


On 6/16/2010 12:37 PM, Carl Jokl wrote:

The Ain't your Dad's Java podcast also had news and then a more
social / indulgent section. The indulgent section wound some listeners
up and again really didn't bother me.
   


--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Not only Java

[Jess Holle]

On 6/16/2010 9:49 AM, Fabrizio Giudici wrote:

Again on this... Well, if I go to the BTRFS page
https://btrfs.wiki.kernel.org/index.php/Main_Page I still read a warning:

*Btrfs is under heavy development, but every effort is being made to
keep the filesystem stable and fast. As of 2.6.31, we only plan to
make forward compatible disk format changes, and many users have been
experimenting with Btrfs on their systems with good results. Please
email the Btrfs mailing list if you have any problems or questions
while using Btrfs.*

OTOH ZFS is stable and has been production for years. Oracle was
behind btrfs and now owns ZFS, and I've only read Oracle talking (a
lot) about ZFS. Ok, there's a chance that the two things get merged,
but in this case it makes no sense to say btrfs vs ZFS. In the other
case, Oracle would stop funding btrfs. I don't see how it's well on
its way to eclipse ZFS. Can you explain me? :-)
   
It will eclipse ZFS once it works close enough to ZFS for most Linux 
usage -- as few if any will consider ZFS as a reason to use Solaris then.


Linux does not have to be better than Solaris.  It just has to be close 
enough for most usage.


If OpenSolaris was as open and accessible as Linux (e.g. you could get 
patch set updates as easily as for Linux for starters), then Linux might 
have a higher bar to clear -- but OpenSolaris is failing in this bid by 
most all accounts.


I'm no Linux fan-boy -- I'd love to see Solaris and OpenSolaris thrive 
(though I'm not a fan-boy for these either).  I just don't think Oracle 
will pull this off.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Not only Java

[Jess Holle]

Hi guys, reading your threads I believe you're missing a point.
Java is not the only Sun amazing creature Oracle has bought.
You probably never got too much inside OpenSolaris.
That is the MOST advanced operative system around.
No Linux can compete.
No Windows can compete.
No OSX can compete.
No other Unix can compete.

The amount of technology Sun has left to us is incredible.
We can't just switch and forget about it.
They left all that to us, through their open source commitment.
Java is just one of their creatures.
And it's not going to die because of Android.
   
Solaris has good stuff, but I'm not entirely sure that it will make it. 
 OpenSolaris has been insufficiently open (e.g. patch access for 
starters) and the sheer mass of the Linux community results in rapid 
innovation there.  For instance, ZFS is hot stuff -- but is well on its 
way to being eclipsed by btrfs.


As far as Java is concerned, if it dies I believe it will have nothing 
to do with Android.  Android is more in the spirit of the recent Java 
language than Java ME at this point and the mobile space is only one 
piece of the puzzle.  In any case, I don't think Google had any other 
reasonable alternatives if they were going to use Java. Paying through 
the nose to use a stagnant platform (Java ME) that Google couldn't 
advance on their own wasn't a reasonable alternative.  Google is an 
innovator and needed an innovative platform where they were free to 
innovate further -- quite apart from the question of pricing.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Less IPhone

[Jess Holle]

Deeper question:  Should the Java Posse podcast be a developer-
perspective only show?  I already know your vote, Richard.
   
I'm fine with digression into everything from iPhones to World Cup to 
whatever -- to a point.


It's just that the iPhone thing has passed that point for me. 
 [Backtracking to the days when I used to be a huge Mac zealot, it 
strikes me as akin to a native Mac OS development podcast deepending on 
a love-fest for the latest Windows features.]


I'll keep listening and as Richard said, it's you guys' (free) podcast. 
 While I can tell you what I like or do not like, it's got to be what's 
worth the time and effort for the guys who are actually doing all the 
work.  It's got to be fun for you -- it's just that this *part* of the 
podcast has become less than fun for me.


--
Jess Holle

--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Less IPhone

[Jess Holle]

I have no complaint with more focus on Scala and Android.

The iPhone (1) doesn't allow anything like Java to even approach it and 
(2) [as I and many others I know see it] is an Orwellian scenario from a 
development marketplace perspective -- it's an attempt to lock 
developers into a sharecropping situation where the developer has no 
power whatsoever.


On 6/15/2010 9:50 AM, Robert Casto wrote:
The interests of these 4 guys have moved on definitely. I'm now 
developing on Android and am spending a lot less time listening. I try 
to use the podcast to keep up with what is happening in IT and it does 
pretty well at that. People are moving on because Java isn't moving. 
They can't be blamed for technology changing focus. They seem to be on 
the edge usually, and as such are a good listen to understand where 
things might be going.


On Tue, Jun 15, 2010 at 10:35 AM, Rakesh > wrote:


I disagree there is nothing else to talk about in the world of Java.

I mean, how many conferences do we have now centred around Java?
There's plenty there to explore and discuss on the podcast.

No one says it must be all new stuff anyway. I've mentioned in the
past people they could consider interviewing and there's endless
third-party libraries out there that could be discussed.

R


On Tue, Jun 15, 2010 at 3:29 PM, Chris Adamson
mailto:invalidn...@gmail.com>> wrote:
> The elephant in the room is that if there were more going on in
Java,
> if it were the disruptive technology that was changing the industry,
> there would be no time for or interest in what Apple is doing, or
> anyone else for that matter.
>
> Even excluding time spent on iPhone and friends, the top "Java"
topics
> seem to be Scala (a non-Java JVM language), and Android (Java
language
> running on not-the-JVM).
>
> A podcast that limits itself to the latest Eclipse plugins and
closure
> debates could be tough to keep interesting.  Better to let the guys
> find the topics that interest them.  Sometimes that's Apple,
sometimes
> it's Flash and Flex, sometimes it's Linux, sometimes it's TiVo and
> cars, and sometimes it's Java.
>
> --Chris
>
> --
> You received this message because you are subscribed to the
Google Groups "The Java Posse" group.
> To post to this group, send email to javaposse@googlegroups.com
.
> To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
> For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
>
>

--
You received this message because you are subscribed to the Google
Groups "The Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.




--
Robert Casto
www.IWantFreeShipping.com 
Find Amazon Filler Items easily!

--
You received this message because you are subscribed to the Google 
Groups "The Java Posse" group.

To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.



--
You received this message because you are subscribed to the Google Groups "The Java 
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: Less IPhone

[Jess Holle]

I believe the JavaPosse should devote about the same amount of time to 
covering the iPhone as it does to covering other things with an 
analogous impact to Java, e.g.:


   * The latest Windows OS version / service pack
   * The latest Internet Explorer version / service pack
   * The latest .Net advancements
   * Microsoft maneuvers designed to edge out cross-platform
 development and lock in developers/users
   * The latest hardware available for running Microsoft Windows

I'm no Windows fan (to say the least), but the iPhone is somewhat 
analogous to these items in terms of Java coverage.  Actually Windows 
details are *much* more relevant to Java development than the iPhone -- 
as Java actually runs on Windows!  I'd sum up the iPhone's relationship 
to Java as follows:


  1. In terms of all but web apps, it is an alternative and competing
 development technology (Objective C), OS, and product offering
 * In this regard it should be covered like .Net, Windows OS's,
   hardware available for Windows, etc, in terms of coverage
  2. In terms of web apps, it is another form-factor / variant of a
 browser to consider
 * In this regard it should be treated like Internet Explorer
   in terms of coverage
  3. In terms of the software market, it is a blatant attempt to lock
 out and eliminate cross-platform development and lock developers
 and users into their platform
 * In this regard it should be treated like Microsoft's
   anti-competitive machinations in terms of coverage

On all of these fronts there are grounds to /briefly/ cover the 
state-of-the-art of Apple's hardware and software offerings, but at much 
the same level as a Mac OS X specific podcast would cover the latest 
Microsoft OS and non-Mac-hardware offerings, i.e. as a competing and 
disparate platform with a browser that one can target with one's web apps.


Android on the other hand, while being a fork at the nuts-and-bolts VM 
level leverages Java source code.  In some ways Android is less of a 
fork from Java than Java ME (e.g. Android supports recent Java language 
features whereas ME does not).  It fully deserves deep coverage as it is 
actually something one can deploy Java software to (albeit after a 
recompile).


--
Jess Holle

On 6/15/2010 8:36 AM, Rakesh wrote:

The dilemma, as I see it, is that how can you talk about Apple
objectively when you have Joe - a self-confessed Apple groupie - who
will defend Apple to the hilt? You can't unfortunately, hence the
awkward moments a bit like watching your parents argue.

I did feel it was unnecessary to talk about WWDC on the podcast. It
almost felt a bit like 'Joe's Corner' sub-podcast.

Truly, who didn't already know the details about the new iPhone?

If you wanted to know about Apple, there are better, more objective
podcasts, to find out the details and get a proper analysis. (Buzz Out
Loud, Guardian Tech Weekly, etc).

I realise not mentioning Apple at all is unlikely, but I think there
is a limit to how much analysis can happen on the podcast. More and
more, its crossing that line where its too much because it can't be
discussed objectively.

I'm still listening but if I come across a podcast that makes it about
Java and its eco-system, I'm sorry to say I'll leave the JavaPosse
behind too.

Rakesh

On Tue, Jun 15, 2010 at 12:17 PM, Kerry Sainsbury  wrote:
   

Of course no-one is forced to listen to the podcast.. Richard, I think, was
just trying to leave some subtle, like a sledgehammer, feedback about why he
wasn't going to listen any more. In a twisted way that's actually quite
constructive.
That said, I'm sure the Posse are more interested in four friends having fun
rather than catering to a particular audience -- much as Richard does in his
own podcast (I'm quite sure Richard doesn't give a rat's arse about his
audience!)
Cheers
Kerry
On Tue, Jun 15, 2010 at 7:58 PM, Carl Jokl  wrote:
 

I might mention that the members of the Java Posse create the podcast
in their own free time and are not doing it to officially represent
any organisation or necessarily have any financial gain from running
the podcast.

That being the case isn't it the prerogative of the Java Posse to
chose what they choose to use the time speaking about. It is their
time after all, which they are not being paid for. No-one is forced to
listen to the Podcast.

I certainly would have a hard time finding time to run a podcast and
even if I did doubt people would want to take time out of their day to
listen to me ramble on about Java and things.

--
You received this message because you are subscribed to the Google Groups
"The Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit th